The State Pattern

Whoa. It’s been nearly a year since I’ve made a post. I’ve been busy. A lot has happened, but that’s a topic for another post.

So I’m going to try something new, well a few things. But the first thing I’m going to try is writing a blog post for my next video. I figure taking the time to explain the video in writing will help me cement the ideas and provide one more resource for you all. There are many people who’d prefer to read than to watch a video. So maybe it’s a win-win? We’ll see.

But enough of that. Let’s get onto the second new thing.

That’s is exploring programming patterns. It’s something I’ve wanted to do because I want to learn more about programming patterns. Plus Bolt 2 will eventually (!!) get released and when it does many of the basic programming patterns will be far easier to implement AND folks developing with Bolt can benefit from implementing them.

Since Bolt 2 is now fully in hiding under the protection of Unity (who knows when the alpha will make it out to the public again) the upcoming video will be entirely C# based.

I should also give credit where it’s due. I’m no genius - that should be clear if you’ve read more than a few paragraphs of my writing. Much of what I know or think I know about programming patters comes from the book “Game Programming Patterns” by Robert Nystrom. It’s well worth a look if you are unfamiliar with the topic of programming patterns..

The State Pattern

“Allow an object to alter its behavior when its internal state changes. The object will appear to change its state.”

Like any other pattern the State pattern has its limitations, but also like any other pattern when used correctly it can help to detangle code which can make debugging code or adding features easier and much less frustrating. And that’s a win no matter how you look at it.

You may have heard the term “Finite State Machine” or “FSM” thrown around. Both of these terms refer to the same thing which is an implementation of the state pattern. The Unity asset Playmaker is based on the uses of FSMs and Bolt has the ability to create them with “State Macros.”

To help illustrate the state pattern, I’ve created a simple Unity project. There is a NPC played by a capsule and it’s goal is to wander around the maze and collect the yellow cubes. When it sees a red sphere (critter) it will chase it and attack it. Nothing too fancy.

So with that in mind, how would you program this behavior? Take a minute and think it through. No cheating!

Just about ready to go up on steam! ;)

This actually doesn’t look too bade with the use of functions… but will get out of control in a hurry.

I know when I first got started with C# and Unity, I would have done it with an if statement or two (or seven). And that works. It really does. Until you need to add another behavior. Or another game mechanic gets layered in. And we all know it won’t end there. The layers will continue to get added until the code breaks, bugs appear or the project gets forgotten because it was getting too hard to work with.

Simple FSM = Enum + Switch

So let’s look at the simple FSM. I still remember learning about this and was utterly confused by how to implement it but at the same time amazed at what it did to my code once I finally got it working. At that time I hadn’t really learned to use functions well so I had 100’s of lines in my update function. Needless to say it was nearly impossible to debug and when I discovered FSMs it was a major break through!

Simple FSM using an ENum and a Switch

In the case I described above the NPC behavior can be broken down into 3 different states or 3 different smaller behaviors. I thought of these as wander, collect and attack. A custom enum can then be created with these three values.

With the enum created a switch statement can be placed in the update function. For each case we can call the relevant function for that behavior. But we still need a way to change or switch (get it!) the state. For the most part this can still be done with basic if statements.

And now this may sound like we’ve back pedaled to our original solution and just made things more complex.

But!

There is a major advantage here!

When we started, inside the update function we had to have a way to determine which state we were in - picking from ALL the possible states. Imagine how complicated that would be if there were 5, 6 or maybe even 10 different states. Yuck! Nothing clean about that.

With this method we only have to decide IF we need to change states GIVEN that we are already in a particular state. This greatly simplifies the decision making albeit at the cost of a few extra lines of code.

In a FSM it’s common that a given state can only transition to a limited number of other states. For example in my case maybe I don’t want the NPC to stop collecting if it sees a red sphere and it should only attack a sphere if it’s wandering around with no cubes in sight. If that’s the case the “state pattern” may actually reduce the amount of code needed as well as serving to untangle the code.

This implementation of the state pattern can be used for all kinds of different behaviors. It could be used to control animations, background music, or which UI elements are being displayed. 

As an aside, in my personal project, I use a vaguely similar approach that makes use of a static enum and events for game modes so that various managers and UI elements can act or react based on the state of the game. The clarity of being in exactly one state has greatly simplified my code and made it far less error prone.

So this is all well and good, but you may be able to see the end result of this approach is still messy if the number of states starts to get large.

A Step Further => More Abstract + More Manageable

Having all the states switching inside the Update function can quickly get unmanagable and if nothing else is pretty hard to look at.

So let’s go one step further. This step adds another layer or two of abstraction to the system, still has some downsides but does clean up our code and will make larger FSMs easier to manage.

This step will place each state in its own (mostly) self contained class. The state will be in control of itself and will determine when to make a transition as well as determine which state to transition to.

Step 1 is to create a new interface. In my case I’ll call the interface INPCState. The interface will have just one function that will take in all the NPC data and will return a value of the type INPCState. This returned state will be the state for the next frame as the “Do Action” function will be called by the base class of the NPC which in turn will run the behavior for a given state.

The Wander State with all the functions included

Step 2 is to create a new class for each state of the FSM and that state needs to implement the interface INPCState. Each of these classes should also contain any functions or logic needed for that state. In my case I have choosen to leave all the variables on the NPC base class. This keeps each state class tidy, but does mean that the state class will be changing values on the NPC base class which is usually something I like to avoid - you win some and you lose some.

Inside each state’s “Do Action” function we need to call the relevant functions AND we need to decide which state to use for the next frame. You can see the full code to the left, but for now let’s jump back to the NPC base class which will help make sense of the return values.

Step 3 is to refactor the NPC base class. Here we need a new variable of the type INPCState that will hold a reference to the current state. We also need instances of each state - it would be possible to make this work with static classes and using an abstract class rather than an interface, but if you know what that means you can probably implement it yourself.

The simplified NPC Base Class

In the OnEnable function I’ve set the current state to the wander state to ensure that the current state variable is never null.

Then the real magic happens in the Update function. Here we have just one line! So awesome. Here we call the “do action” function on the current state and then set the current state to the value returned from that state.

That makes total sense, I swear it does, but it’s abstract.

Give a mintue to let it sink in.

This is so clean.

Step 4 is to add conditionals to the state classes to determine which state to be in for the next frame. Notice that we have passed in a reference to the NPC base class into the “Do Action” function and from there we can get a reference to the instances of the state classes.

Pro’s

The base class is exceptionally clean. You can now see how the class appears to change it’s state (behavior). Effectively the entire Update function changes depending on the current state and what in that state’s “Do Action” function. That’s cool.

If we want to add an additional state we simply create a new class, add an instance to the NPC base class and finally add conditions to allow a transition to the new state from other states.

As long as the number of states stays fairly small 5 or maybe 10 this is a pretty manageable solution.

Con’s

It’s hard to maintain if the system truly gets complex. In this case most sophicated structures such as behavior trees might be needed.

All the variables in the NPC base class are public. Which is a bit messy and not super awesome. This could be partially solved by creating a data container that itself is private in the NPC base class but has public variables… This passes the buck a bit, but would prevent those variable from being changed by classes without access to the data container. A generic data container would also potentially open the doors a bit wider for reuse of the states by other NPC types - so worth thinking about.

As mentioned before, the states are changing values of variables on the NPC base class. Not ideal and something I usually go out of my way to avoid if possible.

Easy UI Styles for Unity

So like many of us when in the middle of the project it’s easy to get distracted and start building tools that probably take longer to create than the time the saved by the tool. And what do you know, a few years back I created Easy UI Styles…

I was finding it hard to iterate on my UI designs. I’d change a color here and it would look better, but then I’d need to change it 7 other places and then it was a tad or dark. Or a tad to light. Oh and then I wanted the font a bit smaller.

Ugh.

So Easy UI Styles let me define a style in a custom editor and then apply it object by object in the scene.

A little while back I started switching my project from UGUI text to Text Mesh Pro (holy crap it looks better) and Easy UI Styles didn’t support it. So down the rabbit hole I went! Several hours later the asset now supports 99% of the setting for Easy UI Styles - seemly there are 2 settings that can’t be set by an external script.

While I was at it I created a new video for the asset as well as a cut down free version of the asset. You can get the “Lite” version on the asset store once it’s accepted or until then you can download it here. The full paid version is free for my Patrons (wink wink).

9th Grade Math to the Rescue

With summer here and my day job being a teacher I have a lot more time on my hands all of a sudden.

Nobody has told me to show up for work, so I haven’t gone for a while.

I’ve also intentionally taken a little break from cranking out YouTube videos. Lets be honest the $8 a month I’m pulling in on ads isn’t paying the bills or a reason to flirt with burnout.

This is letting me spend more time working on my personal project. Right now the game is functional, or rather it fluctuates between functional and broken as I write more code, but that’s a not the story I want to share.

At the moment, I’m in the middle of iteration 2 of 37 in terms of polishing and refining the game mechanics. I’ve been squashing bugs left and right while making bits smoother and easier to use.

As part of those iterations, I’ve been working on the UI. Trying to make it less ugly, which is very different from trying to make it look good, and adding “juice” where I can. The ugliest of all the UI at the moment and roughest in terms of functionality is the “combat selection” panel. I want the player to be able to click on a “tournament” and have that tournament be centered in a scrollRect (Unity). So, I did a little playing on my own and it “worked.”

I sure am liking quotes today…

But reaching for a slightly higher standard than just “working”, I decided to use the google and see if other folks had a slick way to make it work. I found posts and discussions, but it all seemed overly complicated. Why is this hard?

Okay yes, Unity’s UGUI system can be pretty opaque at times… but again that’s not the point. Stop distracting me.

And then! Just like each morning during the school year… I remembered that I teach math. And this is just a math problem! I also teach physics. So I figured I’d gather some data and model the situation

9th grade math to the rescue!

Whoa! A real life use of a linear equation.

The complex problem quickly showed itself to be just a linear equation, the position is based on the number of children (tournaments) in the scrollrect, which is fixed, and the index of the child I wanted to center. This is of course based on the children all being the same size (width in my case).

For those following along, yes, I have three variables so no it’s not “linear” but lets not get too picky. Nobody likes to sit next to that guy at the party so don’t be that guy.

And yes, it’s very ugly, but it works. That’s good enough to call it a win!

Such beauty!

This was a good reminder, that as helpful as the interwebs can be sometimes the solution you find is a hammer and your problem isn’t a nail. A couple deep breaths, a few trips pacing around the living room like a crazy person and you can often find a simple(r) solution to your problem. I’ve found that showering and pooping also work, but I didn’t need the big guns this time around.

Introducing My Next Game (Video DevLog)

After my last game project was shelved, I started working on prototypes for a new game. Having learned the lessons of not just making prototypes but meshing those prototypes together early I built up the core mechanics of my next game over the span of a few weeks (just a few hours a week).

This was many times faster than my previous project.

I had the basics functioning and even better the prototypes were playing nice together. Seemly the next step was to starting building out content with, of course, lots of iterations of redesigning and refining.

As I made progress I could see that the amount of content that I needed to create could easily get overwhelming and potentially stick me back in a spot I didn’t want to be in. Designing and balancing content with little to no feedback seems like a poor choice and one that I want to avoid it if at all possible.

Learning from past mistakes, I knew that I needed to trim the game down. I needed to focus the game. I needed to get something playable and testable ASAP.

I’m looking at you my ugly ass combat system.

As I worked on the basic combat structures and mechanics I started to see that if the combat was refined it could do a lot for the game as a whole. If the combat is interesting and holds the players attention that would in some ways that take pressure off the other mechanics. Or more optimistically it could keep players engaged and maybe give the rest of the game time to mature as I build out content.

To take this one step further I saw that the combat alone could possibly make an entire game. Or at least a “mini game.” So I decided to take a horizontal slice of the game, just the combat, and do my best to polish and turn it into (potentially) a stand alone game. It seemed like a good idea and several months later it still does.

So enough typing, here’s my first DevLog video introducing the main idea of the game and the (very) rough prototype scenes.

Programming Challenges

Without doubt and maybe not for the better my focus has shifted from working on my game every night to trying to edit a video. Work on the game continues just slower than before… My fledgling YouTube channel continues to grow albeit at a limited pace. I’ve seemly snatched the “Bolt” niche on YouTube for the time being, but that’s a limited population and is likely to stay that way.

It’s time for something new.

With one part “hey this is cool” and one part “maybe this will expand my audience” I’ve launched Programming Challenges that can be completed in any programming environment or language used in Unity. This is something that I did with my students this year to help get over the significant learning curve of Bolt - and by most accounts it really helped. So why not bring it to a larger audience? If nothing else maybe it’ll help me refine my the challenges for my students.

The goal is to give short programming challenges that can be done in an evening or certainly without a huge time commitment over a weekend. The target audience is beginner to intermediate programmers and likely folks who are picking up Unity as a hobby and want to learn more.

But isn’t that what game jams are for?

For sure! But a lot of us can’t devote huge hours to a game jam on any sort of regular basis. And for those at the beginning of their game development journey creating an entire game (even in a month) can be intimidating.

Now I’m quite sure that there will never be the “perfect” challenge. Some will find a challenge far too hard or so easy that it’s not worth the time to fire up Unity. All the same this seems like a niche that is unfilled on the greater interwebs and continues the larger goal of giving back to the community that I learned from.

With that said, this last weekend, I launched the first challenge. The challenge is to create a dynamic grid of objects. It’s not a game and its not intended to be, but the programming used to “solve” this challenge is something that could easily be used in a game.

I’d love to hear feedback on the idea or this particular challenge. If you’ve got a suggestion for a challenge I want to hear that too.

Something New - Asking "What Can I Learn?"

I’ve continued to make progress on my game, but admittedly my YouTube channel is taking up a significant chunk of my time. The channel continues to be a fun and rewarding, but the growth has slowed. I’m not sure why…

Did I do something wrong? Did I change something? Did YT’s algorithm just decide to spread the love to other channels? Or maybe I’ve captured the Bolt niche and it just isn’t that big?

It’s probably a little of all of that.

So I decided to try something new. Something that I’ve had in the back of my head for a good long chunk of time. That being trying my hand at game analysis. Not game reviews. Not creating “Let’s Play” videos. Much more of asking the question, “What can I learn from a particular game?”

For my first attempt, I choose the game Equilinox. A game I found the thanks to YouTube suggesting one of the devlogs. It’s a “small” and “simple” game - and I mean that in a good way. So enough typing, here’s my video…

Did you make it past the video? I’d love to hear feedback and thoughts!

A Growing Channel and a New Tutorial Series

Work on my current game project continues, but I’ve also been busy creating a new set of videos and tutorials for the game development class that I teach. This year I made the decision to drop Playmaker, the visual scripting tool I’ve used for the last three years, in favor of Bolt. I’m three months into the class and I’m very glad I made the switch.

If your curious why, I put most of my reasoning into a video that looks at the pros and cons of each platform.

I’ve had great fun learning the new platform and creating videos to support my students. Since Bolt is fairly new its a bit short on tutorials, especially compared to Playmaker.

This shortage of tutorials made it pretty easy to push my way into the scene and start to create my own little niche in the larger YouTube community.

Let’s be clear! My channel is tiny. My channel started as a place to host a game trailer and evolved into an attempt to support my class.

When looking at the analytics it’s pretty clear there’s an inflection point in the traffic stats when I released the first few Bolt videos.

I leave out the actual very small numbers…

And again! My channel is tiny. The view count is laughable. I gain fewer subscribers per month than many sites gain in a day or an hour…

But still.

It’s fun to watch. It’s fun to create. And it’s fun to think about how far this trend might go. The question that keeps nagging me is whether the graph is linear? Or could it be curving upwards? Can the channel sustain the recent 25-30% month on month growth? Can the subscriber growth continue at 40% per month? Can I continue to create weekly content that’s engaging?

I’ve seen spikes in the channel stats before, but this time feels a bit different. And this time I’ve started asking a different question.

Two years worth of data. The trend becomes a little more clear.

Could my channel help support my game development?

I don’t mean that next month I quit my job, but if that graph is curving maybe in 2-3 months the channel can cover my Unity subscription? If it continues to curve in 6 months could it pay my monthly internet bill as well? And then…?

And if the graph isn’t curving? If it’s straight as an arrow? Or if starts to curve towards horizontal? What then?

Then I’ve had fun and given back to a community that taught me how to make games.

---

So… If you’ve made it this far then why not go one link further? Come check out the channel? Maybe hit that subscribe button? And check out some of the videos and the coolness that is Bolt visual scripting…

View fullsize

Screenshots from the next handful of tutorial videos.

Procedural Spaceship Generator

I find myself short these days. Short on patience. Short on time. Short on words. Just short… So here’s a short post and a quick video.

All the same I’ve been finding an hour here and 30 minutes there to slowly make more progress on my game. Yes this is the new game. The next game. If you missed it, you can read all about why I had to shelve my last game. This game is strongly influenced and inspired by the class BBS game Trade Wars 2002. I’ve been coding up a procedurally generated universe, fleshing out an inventory system and scripting the backbone of an economy.

With those pieces working, I sat back and looked at what I had. It’s not bad. It’s rough. But doable. The problem is still that to get something “shippable” or at least in the hands of testers and there’s a lot of content to create. So I had an idea…

What if I could produce a mini-game? What if I could take chunk of the big game, polish it, refine it and publish that? This would cut the immediate project size down significantly, result in quicker feedback from players and give me a second published game. So that’s what I’m doing.

The “game loop” will consist of building a ship, battling an AI ship, earn/collecting a reward and then starting the process over again. It’s simple but seems like it has potential.

I had the basics of a combat system already working so the next big piece was to develop a procedural generation script that could produce the AI ships. And that’s what I’ve been working on the last few weeks. I put together a short video showing the work.

Hope you enjoy and I’d love to hear your thoughts. You can play with the ship generator here - it’s an html build nothing to download just run it in your browser.

Implementing SFX in Unity

Every year I have to work and work to convince my students to add SFX them to their games. They resist and see it as a waste of time. They value graphics over audio. But when they finally add the SFX - it's magic! The "plunk" of an object being placed or the "click" of a button adds so much to the game!

Implementing SFX can be a messy process. I'm pretty confident that I DO NOT have the best solution, but it's a better solution that I had a few years ago. So I thought I'd toss out some info out to the winds of the interwebs on my approach to adding SFX within Unity.

View fullsize

SFX options in the Unity Inspector

I'm not procedurally generating sounds or anything half that interesting. I'm just playing clips but doing so with some variation in the clip, volume, and pitch. I do this with a custom class (not a monobehavior) that allows easy and quick adjustments in the Unity inspector. 

The image of the inspector is from my current project and uses Odin Inspector - which is why the list looks different.

The code for the clip options is pretty sort and sweet. I've added two functions to clean up the implementation for when a clip needs to be played.

View fullsize

SFX options code.

The "PlaySFX" function has two parameters, the first is the AudioSource of where the clip will be played and the second is a boolean that prevents or allows the current clip (if any) to end and the new clip to be played. UI sounds interrupting other UI sounds is generally okay but sounds such as explosions getting clipped by another explosion tends to breaks player immersion.

In some cases, I have created or cloned AudioSources to allow as many concurrent SFX as needed - but that's a whole other post. It's actually not too hard either.

View fullsize

Defining SFX classes

Within the function the volume and pitch are both varied randomly. So no two button clicks (or other SFX) are identical, but if the variation is kept small they also sound similar avoiding possible confusion by the user that a new event has occurred. 

New instances of the SFX can then be created for different actions. I keep mine private and call them via event, but allowing them to be public could work as well.

View fullsize

Calling the "PlaySFX" function for different actions.

Next, I create a private function for each type of action.  This private function will get called by an event. 

Each of these functions can then subscribe to events that are called on other objects.

While this does require a bit more coding, it makes for a very clean and non-spaghetti like code base.

You can check out my full script on PasteBin.

View fullsize

Subscribing and Unsubscribing functions

Prototyping Something New

After the demise of my previous project I've taken some time off from active game development. I've been doing a little soul searching, a little research and as much learning as I can squeeze into an already packed schedule. 

Feeling like I had an idea worth exploring, I've spent the last few weeks working to prototype a new game idea. It's an idea that I've had bouncing around for a few years and is heavily inspired by one of the first online games I ever played. And no. This new game will not have multiplayer - I've learned that lesson (I hope).

With my last project I was nearly a year into it and still didn't have a real working prototype - I had built prototypes of systems but that was it. So this time around I was determined to do things differently. I wanted something that I could prototype in a few weeks, maybe a couple months at most (real life can get in the way). 

Despite looking like a folded protein structure, it's a bunch of star systems with mapped out connections.

So... Where is it at now?

In a about ten days, I was able to code the "procedural" generation of the world. It's not perfect, but it works. And that's all a prototype needs.

A few days later I had the player's navigation working along with some ugly but functional and relevant UI. 

The project was checking lots of boxes and doing so quickly.

The game will be a "space" game. You know planets, stars, laser beams and plenty of spaceships flying around.

So the next chunk I wanted to implement was shipbuilding. I want the player to customize their ship and design it around their desired play style.  A few days later while sticking to primitive shapes (programmer art) I had the basic code functioning. Even spent some time working on visual feedback...

View fullsize

Prototype of the ship building function - the camera auto centers over center of mass.

That was a few hours work that didn't move the prototype forward. Oops.

I'm pretty happy with the results. It's simple and not as smooth and polished as it needs to be, but it works. Again it's everything the prototype needs (and just a few bits more). 

With the ship building complete I had two major features that were going to need work. The game is going to be based on trading and combat (shocking I know). So I needed an inventory and shop system. 

Nothing much to see with the shop system and it's probably the part of the prototype that I'm the least happy with. But! It works. I need to revisit it, to make it "feel" good as it will likely be a central part of many player's experiences. That will come later in the production.

As much as I dreamt of making a "violence free" game with my last project, I can't imagine this game without some lasers, a healthy dose of explosions and maybe a few space pirates. Which means the last piece to build was a combat system.

I know. I know. It's a masterpiece!

The combat will be very stylized. You're won't be piloting your ship dodging asteroids or incoming missiles. Rather you'll be creating a strategy to counter a single opposing ship. You'll be able to pause the game, think, plan, act and then watch it unfold. And yes, the system is pretty heavily inspired by a  popular rogue-like minus the parts that I didn't like and hopefully with at least a few new ideas. 

Even for a prototype, the beginnings were pretty rough.

Once the code was functional I wanted maybe even needed to make this part of the game "feel" good. If I can't make this feel good, then I may need to re-evaluate the design?

I spent a few hours on the UI, a bit on the visuals and a few more on some basic AI. The results? They aren't horrible.

Clearly, there is more work to be done. 

So is this my new game? 

Maybe it is. Maybe it's not. But I'm getting close to committing.  

When to Shelve a Game Project?

I write this post to help me process as well as to share the journey of the last few months as I have realized I need to put my current project on the shelf and take up a new and simpler project. This is not an easy thing to do. Even as I write this I can hear the doubt whispering in my ear...

Like so many of us, I too had a dream of what my next project could look like. I had learned so much from my first published game and I was excited to start my second project making use of all that experience and knowledge. My coding was better. My design was better. Even my art had improved significantly. 

I was ready and excited to not make the same mistakes that I made on my first project. And so, no surprise, I proceeded to make a whole new set of mistakes...

View fullsize

Not bad, right?

I approached the design of "Game #2" much smarter this time around. Rather than just jump in and work on the next thing that came to mind. I laid out the design in layers with discrete chunks that could be prototyped. With each completed prototype I became more excited and more hopeful. I was making it happen! 

In early 2018 I started to put the prototypes together. I started to build the game world and  began the process of weaving together my creations along with a few third-party tools (that's a whole other post). I was creating art assets and the world was starting to looked "not bad."

And then it happened...

What "it" is exactly I'm not sure. It wasn't a singular event. It was more of a dawning or realization. I think most simply put, it was the realization that this project was simply too big and too complicated. If I look back on the development process this was no surprise. I knew it was ambitious. I had been fooled by the success of each prototype. Each step forward gave me hope. But when all the prototypes came together I could see that what I had was, frankly, a mess. 

The spaghetti code that haunts Fracture the Flag and led to so many bugs had been replaced by chunks of code that individually were reasonably well put together, but when connected made for a not so tasty pasta dish. I could see the writing on the wall and I was headed towards another bug riddled project. 

Added to that was the knowledge that I'd broken a cardinal rule of game development, especially indie development. I had over scoped the game. I knew it from the beginning but had run headfirst into that all too common trap somehow believing it would be different this time. I had a plan. It was going to work.

Fuck.

How'd this happen? 

Pretty simple really. I'm an idiot and I ignored my own advice let alone every blog post, article or book I've ever read about designing a game.

I know better than to design a large game. I have discussions multiple times a month with students (I'm a teacher) about the scope of games and what a single person or a small team can accomplish. I preach simplicity and then I ignored my own advice. 

What a dumb ass.

Beyond dreaming too big, it was super easy to get lulled into a false sense of confidence by the Unity Asset Store. I learned long ago that most of what is published there is not as good as advertised and especially to stay away from assets that will be in the final build (as opposed to editor extensions).

A slick inventory system saved me weeks of work...

I picked up an exceptionally well-designed (truly!) behavior tree asset to be able to program my AI...

Other assets allowed me to quickly sculpt terrain and procedurally add scenery...

To be clear the assets I was using are in fact very good and they did save me time. That is until I needed to tweak them or until my vision didn't match the traditional vision of the asset developer. To stand out as an indie or even have a few people notice a game there needs to be something special about it. It needs to be different. You need to twist the boundaries of a genre or at least employ a new mechanic. So rolling someone else's tool that is based on past games and established mechanics is not be the best plan and frankly I'm not sure it even qualifies as an "okay" plan.

View fullsize

This has nothing to do with the article. Just felt like I needed a picture... maybe the confusion of the chickens is a metaphor?

This all helped to create a fiction that I, a solo hobby developer, could greatly expand the scope of my project. Each of the assets could potentially save hundreds or even thousands of hours, but that masks the hundreds of hours required to use those tools to create content.That's no one's fault except my own.

My stupid, overreaching, dumb ass self. 

Aside from my stupidity, part of the realization that I needed to shelve the game came from my day job's seemly unending ramping up of demands. This is usually my easy time of year, but instead I've found that I'm busier than ever before. The chunks of time where I used to be able to stream my game progress are gone. The easy afternoon where I could find 3-4 hours to code, model assets, or just dream about game design have turned into 15 minutes of down time between meetings. Ugh. 

I'm not planning on quitting my day job to go full time indie developer. Given my current game based income, that it would be a particularly bad idea. However, a career change is needed and it needs to happen sooner rather that later. In the next 12-18 months I will likely be looking for something new. I would love to publish one more game before that shift occurs. Not because I think I'll produce the next Stardew Valley, but because maybe I could sell 10,000 copies and maybe that could justify taking a couple years to build a third game and then a fourth... 

Limitations Lead to Creativity

It's so easy to get carried away with game design. After all you can make anything that you can imagine. You are LITERALLY writing the rules of the world you are creating. With this comes the danger of not having limitations. One good idea leads to another and another. Take a second to breathe and your scope is stupid big.

Don't believe the lies. It's not the first time this has happened... And yes, it happens to everyone.

View fullsize

Screenshot - Fracture the Flag

When I was creating Fracture the Flag I had this vision for dealing with player territory. I was going to split the map in to distinct chunks that the players would fight to control. I spent a few days working on several different solutions, but nothing was working or even getting close to working... That was the genesis of the flag mechainc. Why limit the shape of territory? Why presume to know a good way to break up the map into chunks? My limited skill set forced me to be creative and I came up with a simpler and far better solution. My constraints had led me to a creative solution that became the namesake of the game.

By over scoping my game design I have applied almost no constraints. As a result I haven't really forced myself to think creatively. This has put me on a path where I doomed myself to struggle with weaving all the different systems and mechanics together focusing on  the question "can I do it?" rather than "how should I do it?"

As a solo developer I won't be successful by copying or mimicking other designs. If I have a chance to be successful, it will only be possible if the game is fun and not if it's complex. The two are not mutually exclusive, but complexity has been know to stifle fun on more than a couple occasions.

I think this might be the best and most important reason for needing to set aside the game. The game design has become it's own burden. It's weighing me down. It's slowing me down. It's stopping the creative flow.

Sometimes the band-aid just needs to be ripped off.

If you are sitting there saying that I just need to stick with it, I just need to keep going, or others have done it so you can too! Maybe you're right? But this business is tough. Working hard, having a good idea, and executing the design well are not enough to find success.

If you haven't watched this, then you should. 

Sure, there are examples of indies working for years slaving away and then making it big. But for every success story I bet there are ten, a hundred maybe a thousand stories of indies working for years and hearing crickets when they release their work. Go dig into the new releases on Steam if you don't believe me.

Admitting I've gone the wrong direction and restarting is painful and hard to process but it is a far better option than stubbornly staying on the same path. Even if that means a year's work is going to be shelved. That's better than putting in another 1-2 year's worth of work and having a only a steaming pile shit to show for it. Still, as I write this I have a hard time truly saying "it's done," because there was so much good stuff in the game

The Hardest Question

View fullsize

A GIF of a very early System Prototype

What's next? I love making games. I really do.

I've allowed myself to pause the development of "Game #2" for the last several weeks. I had hoped that I could redesign the game to have something that I could still release. I saw several hurdles in the development process, so if I could design around those then maybe the months of work would still result in a game? While I haven't totally given up on this, the simplified design looks too much like what is already out there. Do we really need another resource management game? It's a popular genre, but isn't it already a bit too crowded? There are systems that I have I built that could probably be reused. If I was more creative I could probably split Game #2 into 3 or 4 smaller games all based on a single mechanic or system. 

During this "pause" I've been playing with a prototype that I've worked with off and on for the last couple of years. It's an idea that I've had and I chip away at from time to time. In a few weeks of (very) part time work, I've managed to cobble together a nearly working prototype. This prototype is just the first layer of the design, but it's taken me more than a year to get that far with "Game #2." From that alone, I know I'm far better off pursuing this new idea.

Hard to take pictures of a game that's about darkness

I also quite liked the results of my Ludum Dare entry. It's not unique, but it was fun to play. It potentially allows for players to create and share levels - always a good thing! (I wrote a script that converts a png file into a playable level.) It was a top down shooter that tried to use light and lighting in new ways. So while the top down shooter genre maybe not be as crowded as the platformer genre I still wouldn't call it an under served genre. 

I feel the danger in wandering through the desert for too long searching for the perfect idea. I can waste just as much time looking for the perfect project as I could trying to keep a bad project moving forwarad. So where to next?

I'm still working on that.

State of the Game - Episode 3

This week I released the third episode of the "State of the Game" devlog. The focus of the past month's work has been to add new art assets and start to build up the world. All with the continued goal of producing a playable Alpha Build.

Check out the latest developments in this months video development log. I show off many new art assets plus new NPC jobs such as farming, mining, logging and a few more.

Got thoughts or comments on the development of the game? Join the conversation on discord. Visit discord.onewheelstudio.com or click the button below.