Skip to main content

Solve For The Actual Problem

Recently I posted about how I created a finished game loop right away for my side game project.  I have continued to work in the same way I talked about then and have had time to reflect on why this is working for me.  Simply put I solved my biggest problem first.  Everyone and every game has different problems, but sitting down and being honest with myself at the very start allowed me to address this right away.

As progress moves forward I still maintain this reflective thought process.  I look at what is actually stopping or slowing down my progress and then I solve that problem, in the most simple way as I can.  That means I solve only that problem and not problems that I think will arise down the road.  These are also tending to be my workflow problems so completely unique to my current situation.  For example when I completed the finished game loop I had a few different game objects like triggers to enter new rooms, player spawners and dart traps.  When I made these objects they were put together in the most simple way as possible so I hand built each and everyone of them and just duplicated them around the room.  Then in a new room I would hand build them again and repeat.  This only took a few minutes to do and for the finished game loop I only had two rooms, which was the bare minimum to solve the problem I was working on at the time.

Then when it was time to add in some more rooms I found my self slowing down.  I would think of an idea I wanted to see and start hand building the objects.  While this only took a few minutes after about two rooms I was starting to get bored with doing this over and over.  It was tedious and repetitive work and I didn't want to do it.  So I spent the time thinking about how it was taking time away from actual design work.  So I took the time and built some quick macro like buttons to just give me each of my game objects already setup in a single button click.  Then I only needed to hit one button, and place the object where I wanted.  Automating even the short setup like this also meant I removed any human error from the setup process.

I found my self trying out more gameplay ideas quicker then before and more willing to throw out the work completely because it now took no time to start building it up again.  I was in the iteration loop of actually working on gameplay.  I had solved my actual problem.  Now that I was able to make rooms faster and easier I hit the next problem and it was one I had not even thought about.  While I keep making new rooms the list of rooms is growing really quickly.  The room transition triggers use this list to select the room to transition to and wit the list getting bigger it is harder to make sure I pick the correct room to transition too.  This problem is only going to get worse the larger the game gets.  I had a new problem.

Just like before I thought about the actual issue and how to solve it in the easiest way possible.  I thought, well if I am tagging the trigger with the room why can't I add a button right there by the room tag that takes me to that room in editor.  It was simple enough to put in, only a few lines of code that took me maybe 5 minutes.  A side effect of this is I can easily follow the flow of dungeon that the player will take in editor using the actual game data so I don't even have to leave the editor to make sure the room links are linking to correct rooms.  Now I can quickly make new rooms with new gameplay, link them together AND quickly test that they link together correctly.  

So simply put having this kind of honest conversation with my self during the development cycle is a huge productivity booster.  It is also exposing the actual problems that need to be solved right then and there to move the entire game forward, not just a single part of the it.  It is about being honest with your self and looking for the actual problem in that moment in time that you are facing.  Each problem I encounter is unique to my game, my tools, my data, my setup and my workflow.  So spend the time working to help yourself during the development cycle and spend the time to think about the problem and how to solve it, it will speed you up the long run.

Popular posts from this blog

Plunder Bunny | Flash Game Character Mockups

Another collection of design/mockup sheets for a personal project.  The game was a very simple 2D platformer in the vain of Super Mario.  I got pretty far with the game but ended up getting busy with some contract work and the project feel into the ever growing abyss of personal projects.  When I get some more free time I'd like to try and re-visit it.

The visuals were really fun to work on.  Inkscape was used to flesh out my initial sketches.  Each character was broken up into pieces like a paper puppet.  After Saving the pieces out at high resolution they would then be put back together in Blender 3D where they would be animated.

Mega Cow | Video Game Mockup

We All Have Crazy Game Ideas...This Is Just One Of My Own

Yup its a giant mutant cow... Using Inkscape I made this game mockup after watching some MST3K late one night.  I thought it would be fun to play a game where you were the giant creature causing all of the destruction.  That is the reason the giant cow is on the right of the screen instead of the left. The player would move through the level from the right to the left, the opposite of pretty much every scrolling game... looks good in my head but might not work in actual game play.  Below are some images showing the progression from rough sketch to final mock-up.

Random Level Generation

The level generation system in This Is Dungeon uses a few different ideas to produce the final levels but I'm just going to go over the first right now.  Levels are generated using the Dungeon-Building Algorithm by Mike Anderson.  This algorithm is very simple to implement and gives really good results.  The levels generate very quickly and the player is guaranteed to be able to reach every room of the level.

After playing around with the generated levels in game I started wanting to be able to break the map up into multiple sections.  Since the features are built one at a time from a previously built room I realized I could just tell the generator how many sections I wanted to break the map up into and divide that by the number of rooms it was trying to generate.  The result being the number of rooms that should go into each section.  With that info you just keep track of the rooms already built and when that number equals the number of rooms per section pick a wall tile that ca…