Category: Game Development

Roshambo: Serious Business

Game Development / May 20, 2021 / Shaun Hamman / 0

After lamenting about my inability to finish projects but prior to identifying the actual issue I was facing, I theorized that perhaps my problem was just not having enough constraints. To test this, I decided to make a game styled like a game jam¹: 24 hour time limit with a specific art pack. This would force my scope to stay small. I found this wonderful art pack by Pixel_Poem, fired up Godot, and in a couple short hours had put a simple little scene together.

A screenshot of a darkened scene with scattered torches emitting light. Monsters hide in the darkness.

A simple spooky scene

There was still a pretty major problem I was facing though: I had no idea what I was making. I was just throwing things together hoping something would stick. It was a slow process, and with every hour that ticked by I grew more and more discouraged. Like most of my previous projects, this led me to a place where I was frustrated, had no idea what to do next, and was just completely unmotivated to continue working².

Searching around for videos or articles about how other devs start new games, I came across HeartBeast’s video and while it didn’t provide the answer I was looking for, it did give me new insight into the problem I actually had. With that, I changed my approach. Rather than picking a genre (“I want to make a dungeon crawler”) and then trying to massage all other details together to result in something I could enjoy, I tried going in the opposite direction: picking a mechanic and letting everything else revolve around that.

I wanted something simple, something that I knew couldn’t have a scope that would explode out of proportion. I also wanted something that I hadn’t really seen used very often. A few options occurred to me: Tic-tac-toe, some kind of word game, Lights-Out; none of these really intrigued me though. Then Rock Paper Scissors popped into my mind. It’s trivial to implement and I had only ever seen a single game use it as a primary game mechanic.

I briefly looked into how difficult it would be to make an AI more competent than just picking one of the three actions at random and happened across a very in-depth article. The descriptions in this article of the history, strategies, and meta game conjured a picture of tournaments in which RPS is Serious Business. This made me draw comparisons to the Pokémon Trading Card Game on Game Boy. Suddenly the clouds parted, the fog cleared, and I had a crystal clear vision of the game I wanted to make!

Over the next seven days I would work on realizing the vision I had³. It all came so effortlessly. I knew exactly what features I wanted and how to break them down into workable tasks. That’s not to say I didn’t have to experiment, try different approaches, and choose which results I liked better, or that I didn’t run into various bugs that proved difficult to resolve. I certainly did, but throughout that process I had a guiding star that ensured I would never lose my way or get overwhelmed, and that the scope would continue to stay extremely small. A bit of sanding and couple coats of paint later and Roshambo Adventure was born!

A screenshot of the title screen of Roshambo Adventure.

The adventure begins…

Within the next few days I plan on putting together a proper devlog video over on my YouTube channel showing off what I’ve built so far and what I’m planning on working on next. Keep an eye out for that! I will also be making another post here in the near future talking about my time management strategy. I’ve traditionally been extremely terrible at time management on my projects, so for this I came up with a new plan that I’ve been enacting over the past couple weeks. I’m super happy with how that has been progressing and look forward to telling you all about it!

A Very Simple Mistake

Game Development / May 19, 2021 / Shaun Hamman / 0

In my last post I talked about being discouraged that although I have technically been developing games for over twenty years I’ve never actually released a single title and how despite my skills and experience increasing over the years, I’ve found it more and more difficult to get even close to feeling like something I’ve built would be release worthy.

Every indie game developer has their own graveyard of failed and forgotten concepts, but there’s usually a number of releases scattered around as well. They may not consider these releases “successful”, but each one provides a wealth of information on what worked, what didn’t, what could be changed, and makes getting to the next release a little easier.

One of the first mistakes most new game developers make is making their scope too ambitious. The halls of Discord and r/gamedev are littered with the posts of newcomers who want to make their own Skyrim or Breath of the Wild armed with a cornucopia of ideas and aspirations but not a sliver of prior experience. Don’t start with your most exciting idea. Aspire to that by all means, but just like you’re setting yourself up for failure by fighting the final boss with no power-ups, no extra health containers, and only the starting pistol, so too are you doing so here.

After watching HeartBeast’s video and puzzling on it for a few days, I realized that my issue was a variation of this very simple problem. Coming from an enterprise software development background, I knew that the key to solving complex tasks is the ability to break those tasks into smaller, more manageable chunks that can be quickly and easily completed. My mistake was thinking that doing that was equivalent to reducing scope.

I generally try to manage my scope very carefully to make sure I’m not targeting something too big. However, my process for doing so was flawed. Rather than design content, I would design systems that I could plug into to generate more content. Picture a game with themed dungeons. If I build a dungeon generator, then creating a new dungeon is as simple as providing new theme graphics. Thus I can build one dungeon as part of my initial scope, and then just expand on it post-release.

But I realized recently that designing systems and breaking down their complexity into tasks is not the same as reducing scope overall. Sure, it means I don’t have to design 32 different dungeons, but it’s still a ton of work. If we suggest that scope is the combined total of quantity and complexity, my old process was just trading quantity for complexity while the overall total stayed the same.

I also realized that a game doesn’t have to be a certain length to be considered successful. I’ve recently been watching videos covering various games developed as part of game jams, and many of these games only provide minutes of gameplay, but are still able to provide wonderful experiences that players enjoy and remember. A game doesn’t need to be ten, forty, or one hundred hours long to be a success. It’s about the quality of the experience and how much it conveys the experience the developer intended, not the duration of that experience.

Gone Home is a great example of this. It is widely regarded as a successful indie game¹, but it is also often estimated at only having one to two hours worth of gameplay. It’s also not one that most players will return to over and over again. Duration and replay value do not determine quality.

With these two points in mind, I started a new project with an intentionally limited scope. In only a single week, I’ve found that I made more progress on this project and am happier with that progress than on any other project I can remember. Along with having a new strategy for time management², I’m very excited about this one and am very optimistic that I’ll be able to take it all the way to release! In my next post, I’ll reveal the changes I made to my process and what this new project is that was born from it!

My Game Dev Graveyard

Game Development / May 18, 2021 / Shaun Hamman / 0

For as long as I can remember, I’ve wanted to make games. In the late 90’s I discovered QuickBASIC on our family computer. Then in the early aughts I found tools like Klik & Play, Zelda Classic, and RPG Maker. A great many other tools and languages would follow as I proceeded down the path towards my current career as a software engineer, and at every step along the way I would make games.

These games would range the gamut of genres: text adventures, top-down shooters, shmups, mazes, point-and-click adventures, RPGs, strategy games, puzzle games… you name it I’ve probably tried to make it at one point or another. Many I remember, and I’m certain there are many I don’t. But you may notice there is a distinct lack of information on this site about any of them. This is because I’ve never actually finished one.¹

This is a fact that in recent years has begun to weigh on me. In the more than two decades I’ve been making games, not one scrap exists that I can show as an accomplishment even as an unfinished prototype. They say getting started is the hardest part, but when it comes to creating I and many others haven’t found that to be true. Like most game developers, authors, artists, etc. I have a veritable graveyard of half-started demos and concepts that will never see the light of day. When it comes to game development, it is well established that finishing is the hardest part. My graveyard just happens to get paved over fairly regularly so I couldn’t dredge things up even if I wanted to.²

A few weeks ago I saw a video from game developer and YouTuber HeartBeast titled Gamedev Constraints and New Beginnings. In it, he ruminates on why when he was younger he had no trouble building and releasing games, but as his skills and experience grew he found himself less able to do so. He came to the conclusion that when his skills were less refined they acted as a constraint, limiting what he could produce. Thus, he would build his game to the maximum his skill would allow for and then release. As his skills increased they became less of a limit, and he would spend more and more time trying to reach his vision of the game rather than settle for something else. He theorized that placing artificial limits on himself would help him return to that place where he could release with relative ease once he reached the maximum of what was possible.

I find myself in exactly the same predicament and while I agree completely with his findings, I’m also sure that’s not exactly the same issue I’m facing. I’ve long believed that the complete freedom that comes with having the skills and tools to build the vision you have is what prevents that same vision from being realized and I’ve strived to place constraints on myself for that reason, but still I find that as my skills have grown I’ve found it more and more difficult to be proud of what I’ve built and to be comfortable finishing and releasing anything.

While HeartBeast’s video didn’t give me the answer to my problem, it did get me thinking about the situation and if my problem wasn’t a lack of constraints then what was it? I’ve spent a lot of time contemplating this and trying to narrow in on exactly why I can’t seem to carry any of these projects to completion. I believe I’ve identified it, and the plan I’ve come up with to address it is what led to the creation of this very blog. In the next post I’ll go into what I think the issue is, my plan for addressing it, and why after only two weeks I believe I’m seeing tremendous successes that indicate I’m on the right path!

Mystery Image… What Could It Be?

Game Development / March 24, 2010 / Shaun Hamman / 0

This post has been migrated from my older blog A Bad Case of Nostalgia.

What could it be…?

Riddle me this:

What is black and white,

old and yet new,

never before seen,

but nostalgic too?