Since this is my first LD, I’ve been thinking a lot about my post-mortem, plus I’ve been working on “Stranded Again“, that’s going be my enhanced version of Stranded with improvements as suggested by the LD community.  Plus my Twitter Followers count is going up steadily, so I’ve been keeping up the pace

WARNING!  Some minor story spoilers ahead…

The Idea

When the list of theme topics was down to 20 or so, I got out a notebook and came up with single-sentence game ideas for ALL of them.  My idea for “Escape” was:

Escape: You are tiny brown spider, trying to escape from a research lab.

After doing this for all 20, I went back and came up with a list of Actions and Challenges.

Next, I asked myself, well what exactly do spiders do?  Thinking about Actions, I think,  is a good way to create core game mechanic ideas.

1. Catch insects for food
2. Spin webs to stop “bad guys” (bad insects?) from fleeing, or from attacking something or someone else
3. Collect DNA from insects they catch
4. Catch bad dreams
5. Collect nanites, grid-bugs, software bugs?

1. Web is destroyed by… fire, rain, people, wind, other insects
2. Web decays over time
3. Spider dies from hunger, or runs out of webbing

 

 

The Story

Then I took all this and wrote a tiny Story.  Every game, at its core, must tell a Story – no matter how simple it is.  This one I thought was about as simple as I could get.  I didn’t know this at the time, but keeping the Story simple made the programming much easier as well.

Escape: You are a tiny brown spider caught in a research lab.  You can collect DNA from insects.  Collecting DNA in the right sequence gives you special, but temporary, abilities.  There is a girl trapped in the lab too.  The girl is “dangerous” and “different”, but you don’t know why.  THEY have taken DNA samples from her too.

“I can’t leave here without getting them back — I can’t collect them all in time, but I know a little spider who can.”

I actually thought, of all my ideas, this one was  really  s-t-r-e-t-c-h-i-n-g  it to match the theme – probably the worst match-up of the 20 — and the LD community echoed these sentiments, but not in a mean way — the whole community has been awesome.

The Ruleset

Next I started to think about rulesets.  Which came up with this list of rules:

These are the ones I was able to implement:

1. You win each level by collecting all the insects before you run out of web strands
2. Your web strands do not carry-over from level to level, but are refilled when you start a new level
3. You lose a level if you are unable to catch all the insects with the strand allotment you are given
4. Levels can be replayed if they are lost
5. When you lose a level, your strand allotment and all the insects for the level, are reset
6. You will always have at least 1 more strand than there are enemies, but the ratio of strands to enemies gets smaller as you progress in levels
7. The story of the game is told through dialog, that is “unlocked” as you complete each level

1. Change the ball colors and the fly colors so that you would have to jump from ball Blue to ball Yellow to catch Fly Green
2. Create bonuses that you could catch that would change color of the ball you are either jumping from or jumping to in combination with 1 above.
3. Create obstacles that you don’t want to have your web touch — like fire. If your web touches fire, the fire goes back and disintegrates the ball you just came from.
4. Create “safety” bonuses that you can catch — like water. Water and other bonuses could be caught and stored for later use.
5. More of all of the above, but with other opposites. Might be quite challenging to get the right combinations.
6. Mutations! Each bug represents a different DNA code, catch the bugs in the right combination and your spider gets a temporary mutation.

What Worked

Prioritizing the rule-set from the design above helped tremendously.  When I initially came up with the list of rules, they weren’t in the order shown above.  It took about 2 hours to work out all the inter-dependencies between them all.  Each time a rule was identified as a prerequisite for another rule, it got a +1 — the rule that it relied on it got a -2.  When I sorted this list from highest score to lowest score, I had my to-do list in order of functional dependency.  This really worked because at each step of the way I had a “working game”, so I could stop adding features almost at any point in the list as soon as I ran out of coding time — which is exactly what happened.

Creating a schedule in a spreadsheet ahead of time and marking off hours for “sleeping”, “eating”, “family time”, etc…  I had one row for every hour of the compo, and for the most part stuck to that schedule.  My development time went into just a little bit more detail (but not much more) and had rows for “Game Artwork”, “GUI Artwork”, “Sound Effects”, “Music”, “Coding Win/Lose Conditions”, etc…  I also had two hours each day (one in the afternoon, one in the evening) allocated as “DO NOTHING” where I had to get up from my computer and take a break.  That had a HUGE positive impact on my productivity, my mood, and I think I solved a half-dozen coding issues “in the back of my head” each time I did this.  Also, writing down any “hairy” coding issues during the day and then reviewing them before I went to sleep really worked — I woke up knowing the solution

Leaving LOTS of time at the end.  I left a full 6 hours at the end to run final bug-testing, upload my game, ask friends and family to play to make sure it worked, make any last minute fixes, write my forum post ahead of time, write my entry, announcing via all the social media channels, IMing with people about it, etc…  I think those last 6 hours were the most busy and I may actually allow myself more time in future compos.

Using classes for everything.  I have a class for “spider”, another for “bug”, another for “strand”, etc…  I used my UML/OOP books as guides and came up with a complete list of objects I’d need for the game, and then attached all the methods to them as I went along.  This worked exactly the way it’s supposed to and it made the actual coding a breeze (which in total I think was only about 8 hours).

What Didn’t Work

Thinking that GUI programming would be easy.  It wasn’t!  GUI programming ended up taking nearly 4 hours more time than I had initially thought.  And in the final product you can see that there just aren’t a lot of GUI controls to help with gameplay.  There’s a reason why most AAA game studios have entire teams dedicated to GUI programming (even when using a “GUI engine”) — it’s very tedious work.  Unity GUI makes it as easy as it can possibly be, but it still just takes a set amount of time to create all that GUI functionality — GUI systems are inflexible in their time demands.  In the future, I’ll be able to estimate this better I think.

Using the dialog system as a means to control the game progression.  Such a bad idea!  This is where I really fell down in my technical design.  I should have created dedicated and separate classes for “game” (to control the game state) and created instances of a “human” class (one for the male scientist and one for the female scientist).  I realize now that I was so focused on the game mechanics (which mostly involved the spider, the strands, the anchors, and the insects), that I simply forgot about these classes.  I ran into some problems about mid-way through that I solved with a “gameManager” class that contained all the variables and methods to handle the gamestate and dialog… but it was all mashed up together.  In the future, I need to be more thorough with my technical design.

Not leaving enough time for additional levels.  The final product has 6 playable levels (and then a 7th level that can be replayed as much as the player wants).  Seven levels might seem like a lot for a Ludum Dare compo entry, but in my case, levels only took 5 to 30 seconds to solve.  So, all-in-all I had maybe 5 minutes of gameplay — that is IF the player stopped and read the dialog    I should have done those calculations ahead of time to know how many levels I would need to create.  Originally I wanted to provide about 30 minutes of solid gameplay.  So using that calculation, it should have told me that I would have needed 60 or 70 (!!!) levels.  That, of course, would have been a big Red Flag telling me that the gameplay is too easy and goes by too fast.

This entry was posted on Thursday, September 8th, 2011 at 9:48 pm and is filed under LD #21. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.