What went right
Models & Animation
The previous Ludum Dare 23 was the most experience I’d had with creating 3D models for games, and even then there was no animation (everything moving was done in Unity with code).
This time, the main character has a handful of animations (idle, walk, & jump), and I used Blender animation in places where I could’ve coded it in Unity, but it makes sense for them to be animations instead (spinning & bobbing of evolution pickups, spinning lights on the enemies).
It wasn’t knock-out quality, but I was happy with with the “time taken to result” ratio, as I didn’t spend very long on it and they came out passable.
Texturing is usually a weak point in my projects (*cough* fire planet *cough*), but this time I used NeoTextureEdit to generate some passable textures. Their usage really didn’t do justice to how good they looked in the editor, but it’s definitely a mark of progress that I was able create from scratch some textures I was happy with.
Fun fact: this is the first time I’ve made anything in Unity that involved any camera movement of any kind. Everything else up to this point has been single-screen “arcade” style games, where all the action takes place in a static environment. I wasted most of Friday night and Saturday morning playing with the camera snapping & following (and discarded quite a bit), but I’m happy with how it ended up. The there’s a delay with the camera moving so it doesn’t snap jarringly, but it still keeps up with the player ok.
What went wrong
The theme was “evolution”, which really didn’t click with me. Evolution doesn’t inspire gameplay ideas to me, and I couldn’t get thoughts of E.V.O. out of my head. I had originally thought of doing some kind of RTS-style mechanic, but kept adding more Pikmin-style puzzle solving until finally trimming it down to only controlling 1 thing, leading to the game that I made.
I’m not happy with the lack of originality to the game. None of the mechanics are anything that haven’t been in games since NES times, but I just couldn’t come up with anything I would be able to implement for the weekend challenge.
I ran into a problem with this that I had with my last LD too – people didn’t understand what controls were possible, or understand the results of their actions. For example, people would pick up the shield and not know when they were shielded; they’d press 3 and hear a sound, and think “ok I guess I’m shielded?” and then get squished.
This is a common failing of Ludum Dare games, where the authors spend so much time neck-deep in the game, things that appear obvious to them isn’t actually obvious. “Of course you aim with the mouse!” The fact that I fell into the same pitfall as last time bothers me more. You can be sure I’ll be watching out for this next Ludum Dare.
Even though I was able to create animations, I wasn’t quite able to make things do what i want. The biggest hurdle seemed to be the rigging. I had wanted Squishy to stretch and lean forward a lot more, but he just didn’t deform right when I tried pulling on the skeleton, and I’m not familiar enough with vertex groups and weight painting to get it set up the way I wanted. The bottom 3 bones were basically useless with the automatic rigging, but I need to learn more about the process before I can correct it.
Some Features Incomple
I also lost one of the biggest advantages of my preivous game – it felt complete. It had a title screen (this didn’t), it it had basic story (this didn’t), it had music (this didn’t), etc. My lack of familiarity with the physics system in Unity and creating an explorable world ended up taking more time than I’d hoped, so I lost out on a lot of the polishing I’d managed to get into the last game.
Despite having more experience, this project definitely left me feeling less satisfied than the previous venture. It was still a great learning experience, and I’ll definitely be combining the lessons from this and the previous one in my future endeavors!