She handles like a lethargic sloth on narcotics
I was very happy with the control & “feel” of the planets, which was pretty much the only goal I had set out for myself at the start of the competition.
In the game, you’re controling a tiny ball on a fixed screen that has horrid accelleration & low top speed. However, the combination of the buildings on the planet to give scale and the parallax scrolling background to imply the motion of hurtling through space gave enough sense of weight to the planet to make the control feel natural rather than sluggish.
Strike a pose
This was the first time I’d modelled anything in blender (besides the square card for “pick a card”), and I was very happy with how the buildings turned out. I was able to get the angles right on all the duplicate buildings so they’re “sprouting” out just like I wanted. It’s a special kind of awesome when you envision something in your mind, and are able to produce exactly that.
To pew, or not to pew
It’s small in the long run, but the screen where you choose which planet you want had quite a bit of thought put into it, and I’m very happy with it.
- How do we let users know that clicking on the planets can have an effect? Moving your mouse cursor over either planet zooms them slightly, giving an indication that further interaction with the mouse may be possible.
- How do we let users know clicking had an effect? One thing I definitely DIDN’T want to do is have clicking on a planet confirm that choice, and move on to the game. Users often click to see what happens, and taking that as their choice can move things along before they’re ready.
We still want to let them know clicking has an effect, though. This was done by adding a yellow “halo” effect to the planet that was clicked, letting them know that it’s the “active” selection.
One of my goals as a UI designer at work is to make hints for direction subtle enough that users don’t even realize they’re there; I think this choice screen worked along those lines.
While the modelling of Mechania was passable, Conflagus looks awful. I was attempting to add swirling clouds similar to Jupiter, but instead it looks like someone smeared Elmer’s glue on a superball. I had planned on adding some modelling detail to the planet like Mechania, but I ran out of time.
Part of this was the constraints of the Ludum Dare Rules. Everything has to be made from scratch by the participant – models, textures, etc. Normally I would’ve just grabbed a planet texture from somewhere, but that wouldn’t fly here.
This is an explanation, not an excuse. While I’m skilled at GIMP with content editing, I’m horrid at content creation. I just can’t create textures from scratch, and really need to work on it.
Yeeaaah. Sorry about that.
I knew I wanted to get music in the game, and Musagi certainly LOOKED easy to use. It wasn’t.
After 30 minutes of fiddling (and with 1 hour until submission deadline), That bassline and simple drumbeat were all I had managed to squeak out. I do believe I’m capable of creating much higher quality music, but in the future I’ll familiarize myself with tools long before-hand.
I had the time per stage set extremely low during development, so I could easily test getting to the later levels without taking a long time (with hours before submission, taking 3 minutes to play through to stage 5 adds up FAST).
I lenghented the stages some, but the final release definitely didn’t have stages as long as I had intendted. It turns out it’s not even possible to lose during the first few stages because so few meteors actually make it to Bulbous during the allotted time.
Time management is a common sticking point in these crunch competitions, but I think went well for me. Often people bang away for 48 hours and end up with a very nice game engine and level editor – and nothing else. For the final 8 hours, I continually asked myself, “what do I absolutely, positively need to have in the game that I haven’t implemented yet?”
This led me to delay some things I really wanted to try but weren’t absolutely critical (new model for Conflagus) and implement things that I HAD to have (title screen, multiple levels, health/progress bar, etc). As much as I lament not revisiting Conflagus, I’m glad I didn’t. It turns out I I DIDN’T have time to do all of the above, and I couldn’t imagine sacrificing any of the later for the former.
Tools & Tribulations
This is still a learning process for me. I’ve gained a lot of knowledge from my previous forays in Unity, and this weekend I spent less time trying to figure out how to use the tools and more time on actual content than previously, but I still ended up spending quite a while figuring out just how to make things worked.
I had a number of false starts. For example, I tried doing the health bars via:
- Line Renderers, but the longer “background” lineRenderer always draw on top, and pulling one out in front with a Z depth caused noticable skewing in the sizes/positions.
- Then I tried a GuiTexture-based solution, and gave up on that after a bit of banging my head against the wall (everything’s specified in coordinates between 0 & 1 instead of actual pixel numbers)
- Finally figuring out how to use GUI.DrawTexture successfully.
All told, I probably spent about 2 hours futzing with something that, if I had to do again now, I could accomplish in about 10 minutes.
That’s is how it works, though. I’d preveiously spent most of a day playing with & tweaking “click selection” with my RayCast Selection project; for Ludum Dare, I implemented it quick & without a second thought. Raycast Selection had been a tool in my belt before Ludum Dare, now GUI Textures sit beside it. My toolkit will continue to grow as I gain experience, which is exactly what I wanted to get from Ludum Dare.
It was definitely a fun learning experience overall. I’m going to keep cranking out tiny, stupid game concepts in the meantime, and I look forward to participating in future Ludum Dare competitions.