Ludum Dare 23
Ludum Dare 22 Warmup
Ludum Dare 21
About Tulrath of Lakehome Games, LLC (twitter: @tulrath)
I make computer games. I show others how to make computer games. I'm a bit strange.
Tiny Gods took a total of 19 hours to complete and was made entirely from scratch.
What Went Right
Schedule. Planning out my time worked well again, I spent a total of:
- 2 hours on initial concept, core mechanic, core mechanic consequences, game design
- 4 hours doing artwork
- 2 hours in core game code (movement, physics, messaging, enemy AI, world-state managment)
- 3 hours in the level-complete and level-transition logic
- 1 hour GUI programming
- 2 hours on music and sound effects
- 3 hours coding the ammo – planet influence feature
- 1 hour creating level (again, not nearly enough time here)
- 1 hour packaging-up entry, submitting entry
Total Production Time: 19 hours
Things I wanted to spend more time on: the artwork, the GUI, more levels, and a final boss battle
Tested Pipeline. Being familiar with all my tools helped tremendously — I’ve used this toolset (Unity, GIMP, GraphicsGale, Audacity) before, so I had a well-defined pipeline. I knew exactly what formats to use and I knew exactly what settings I needed to get everything into Unity without any issues.
Prefabs. In my first LD48 (#21), I burned a lot of time trying to figure out Unity’s physics engine, but now I use a “cheat sheet” to tell me when to use: Triggers, RigidBodies, Kinematic RigidBodies, and under what conditions OnTriggerEnter() works and when it doesn’t. Using Prefabs for everything worked amazingly well and saved a ton of time. I was surprised (and pleased) to find that instantiated prefabs (that were already saved in separate levels) would receive updates when the original prefab was modified. Near the end, I was adding AudioSource components to my single Planet Prefab (the shotgun reload sound) and every planet in every level got that update. I had always thought that level data really was just a set of metadata pointers, and this really confirmed it.
Early Artwork. Doing the Artwork first was a boon to my productivity — it really kept me motivated. I was able to use a single prefab for the player, monsters, bullets, and planets and then code around that. After words, it was just a matter of making more prefabs (or extending the code) for variations and then adding them to the collection in the WorldManager. Having a central “WorldManager” class worked really well too – this managed the game state, and managed most of the communication with other classes – this allowed me to have “lose coupling” because no class needed intimate knowledge of any other class. Using the SendMessageOption.DontRequireReceiver for all messages also allowed me to easily work from either the top-down or bottom-up and when “ends met”, it all worked out as planned.
Formulas & Binary Math. To determine an enemy’s strength by level, I used binary math on the level to pull out 4 qualities for its health, the amount of damage its attacks do, the speed of its bullets, and the frequency at which it shoots bullets. This worked out amazingly well, as the difficulty of the enemies has good variation (lots of ups and downs in the qualities per enemy), but also overall increase in difficulty. A simple set of formulas takes care of it, which saved having to enter and maintain all that data.
What Went Wrong
Pre-Dare Prep. I didn’t start my pre-dare prep early enough, so ran into extra work I needed to do on my personal website, plus extra work I had to do with my LD WordPress account, and lots of other little “odds and ends” that needed to be cleaned-up. This led to a lot of stress the night before the dare. Next time, I’ll start all my pre-work at least a week ahead of time.
New Untested Features. This time I wrote some features that I’ve never done before — namely the influence of the planets on the player’s ammunition type. This didn’t amount to a lot of lines of code, but it did result in lots of thought-time spent in trying to figure out, “oh, just exactly how am I going to do that?” I finally figured out that this just amounts to the planet sending out a Broadcast message to any “Player”-tagged object while that object is within its OnTriggerStay() — but figuring out that solution took three hours. Three hours for this one feature alone is FAR too much time when you only have about 20 hours total to get something done. My plan for resolving this in the future is to start maintaining “Unit Test” projects again (I used to do this extensively in DarkGDK) for ideas I come up with, that way I’ll be have a good idea how to code something up before being in a compo.
Just barely getting in under the wire this time, but 48-hour compo entry “2 Tiny Gods” is done!
You can play it on the Web, Windows, or Wine in Linux — check out the comp entry for full description and details:
Tiny Gods is almost done…
What if your ammunition decided it didn’t like you?
What if your ammunition decided it no longer held the same beliefs as you and began following different gods?
What if your ammunition was also your power, your strength and your life?
The ancient gods are not pleased with your recent apotheosis and endeavor to bring about your Fall. They send wave after wave of evil beings to destroy you – but they’re attacks are coordinated, and surprisingly effective. The ancient gods are not usually this coordinated in their efforts.
Something is directing them. Will you survive long enough to uncover the truth?
Tiny Gods is my interpretation of the “Tiny World” theme for LD48. Tiny Gods is a 2D “Bullet Hell” game in the style of 1995-1998 SNES games. In Tiny Gods, you are a new demi-god, but your powers are not yet stable and are easily influenced by the followers on all the Tiny Worlds your find throughout the universe. As a demi-god you can absorb Tiny Worlds to give you ammunition to defeat your foes, or you can stay close to worlds that give you power. You must constantly balance staying in the proximity of tiny Worlds (to absorb their influence) and consuming Tiny Worlds (to give you ammunition). But don’t stay too close — the attacks of your foes will damage worlds as well, changing them into Dead Worlds where the people follow the gods of the underworld – Pluto and Proserpine.
Perhaps today IS a good day to daré. Also, I’m in…
It’s the usual suspects: Unity3D, Gimp, sfxr, audacity, anvilstudio. If I have time, I may break up sprites into parts and try out Spriter
With just 6 hours left, I’m way behind schedule and I’m not going to make the LD48 deadline. Here’s what went wrong – hopefully for others (and myself) to learn from:
- I did the warm-up, but didn’t go far enough. I really should have gone further and tested every system possible.
- For this LD48 I wanted to use more robust, and more flexible data management than my previous LD48 entry. A few of my systems I thought I could build quickly with JS instead of C#… How wrong I was. Unity’s slight differences to canonical JS became a major pain when I started using more advanced techniques. When it was time to build on those simple JS frameworks, it just turned out that they just couldn’t do the job. Ultimately I had to use System.Collection.Generic lists for everything, but I lost about 4 hours overall figuring that out.
- I opted to use a 3rd party library for sprite management in Unity. The library worked perfectly, but I just wasn’t familiar enough with it to use it correctly the first time out. I kept running into what I thought were “issues” — but they weren’t issues at all, it was just my own lack of experience with the library. LD48 is probably a bad time to be learning how to use a new tool.
- And finally, (IMHO) the artwork that you need to do a 2D game can actually take significantly more time than a 3D game — it’s more difficult to represent 3D objects in two-dimensional space. Gradients and shadowing can help, but those are extremely manually-intensive processes. I’m pretty good with Blender, so in the future I may actually build simple 3D objects and just take snapshots of them from different angles to create my sprites.
This is my 2nd Ludum Dare — I thought I’d be skipping this one, but the kittens are dragging me back in!
Engine/Code: Unity, C#
Music & SFX: Anvil Studio, bfxr, Audacity
If I have extra time after the coding and testing, it’s all going into artwork. Going to try my hand at animated sprites this time
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…
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.
- Catch insects for food
- Spin webs to stop “bad guys” (bad insects?) from fleeing, or from attacking something or someone else
- Collect DNA from insects they catch
- Catch bad dreams
- Collect nanites, grid-bugs, software bugs?
- Web is destroyed by… fire, rain, people, wind, other insects
- Web decays over time
- Spider dies from hunger, or runs out of webbing
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.
Next I started to think about rulesets. Which came up with this list of rules:
These are the ones I was able to implement:
- You win each level by collecting all the insects before you run out of web strands
- Your web strands do not carry-over from level to level, but are refilled when you start a new level
- You lose a level if you are unable to catch all the insects with the strand allotment you are given
- Levels can be replayed if they are lost
- When you lose a level, your strand allotment and all the insects for the level, are reset
- 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
- The story of the game is told through dialog, that is “unlocked” as you complete each level
- 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
- 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.
- 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.
- Create “safety” bonuses that you can catch — like water. Water and other bonuses could be caught and stored for later use.
- More of all of the above, but with other opposites. Might be quite challenging to get the right combinations.
- Mutations! Each bug represents a different DNA code, catch the bugs in the right combination and your spider gets a temporary mutation.
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).
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.
I’m in the middle of writing my Stranded Post-Mortem, and unintentionally created this – I knew people here would understand
perma-link and larger version here: http://twitter.com/#!/tulrath/status/112004655785050112/photo/1
I’m planning on releasing an updated version of Stranded called “Stranded Again” that will include a lot of the suggestions I’ve been receiving from the Ludum Dare community! This release will be free, and will include all the original content, plus episode two, and more puzzles and more fun gameplay. The original Stranded was made for the Ludum Dare 21 (48 hour compo), so there’s really not a lot there right now — I want to fix that and bring a lot more of the story to the community.
Here’s the deal – I’m new to Twitter and I’m trying to build up followers who are honestly interested in unique, fun, challenging games; and have strong opinions on game design that they don’t mind sharing. I’m sure I could find a few people that fit that description somewhere around here
Let me know that you want me to keep working on Stranded Again by following me on Twitter @tulrath
The more followers I receive, the more features I’ll build into Stranded Again:
- 50 Followers: Episode Two Story, improved game graphics, new backgrounds and effects
- 75 Followers: Everything above plus Enhanced Puzzle Mechanics for the core gameplay
- 100 Followers: Everything above plus Additional Puzzle Mechanics for the advanced game play (100 Follows is my goal)
- 125 Followers: Everything above plus 3 Mini-Games that can be played at specific points of the story (once unlocked, can be played at any time)
- 150 Followers: Everything above plus Achievements System with at least 18 Achievements that can be earned
- 200 Followers: The 200th follower gets to CHOOSE what he/she wants added to the game from this list: 2 Additional Mini-Games; or 10 New Achievements; or 2 New Enemies of your own design; or 5 New Story Branches that provide more back-story around the core game story.
48 more entries viewed tonight, trying to do 2 pages a night
So far I’ve tried 21 of the competition entries — I’m going to try to play everyone’s entry at least once. Lots of good entries, even the “partially finished” ones.
Gameplay video of Stranded, my Ludum Dare 21 competition entry
Compo Entry Here:
Play it Now Here: