Posts Tagged ‘bytegrove’
This was my first Ludum Dare, and I was psyched!
I had the days before the competition more or less decided that I wanted to do a 3d-shmup. The theme “tiny world” got me thinking of giant bugs, and all the other stuff I thought up along the way. Now, in hindsight; after seeing all the clever theme interpretations of the other submitted games, I think I’ll devote more time to the brainstorming during the next compo. I had to do a little too much work with the shoehorn this time.
Now, I should warn you, this post mortem turned into a wall of text, but I’ve also made a timelapse video:
I live in Sweden so the competition started at 3.00 am. I got up at 4 and had a look at the theme, and then decided to sleep some more. After some sleep, some breakfast and some brainstorming; I finally got started at around 6:45 am.
I decided early on to try and make the game heavily component based, instead of trying to juggle around with inheritance and whatnot during this short amount of time.
So I began by making a player input handler and a movement module. The movement module for example was going to be repurposed in all moving objects, for instance. And I made sure to keep this mindset when coding the rest of the game.
I then proceeded to make aiming-, mouse input- and enemy behaviour modules. To give another example of the modularity of the project: the enemy behaviour in this case replaces the player input for telling the movement module what to do, and the enemy behaviour uses information from a sight module, instead of relying on mouse input, for targeting.
As I also had health working by now, I added a game over state, as things like end-states and score-keeping should not be saved until last. However, it was still very temporary-looking, and while I didn’t want to put it aside until last, I more or less ended up doing it anyway. Sigh.
I kept working on player-enemy interaction until around 5.00 pm, fiddling around with enemy aiming, adding camera and object shake upon hit(I made the shaking as a kind of transferable effect-module). I also began working on the triple weapons system, and the weapon switching. A module for rolling was added as well, I decided to keep it separate from the movement module.
I had this idea from the start, as I wanted to keep the game on rails; to make the player and all the enemies to follow a path along a spline, thus enabling me to easily make loopy level designs. Implementing the spline and spline traverser was not that hard, but it took me about six hours. And it would prove to be causing a little too much trouble later on, compared to how much use I actually got out of it. However, should I ever decide to make more levels it will certainly come in handy. For the next LD I’ve got to tone down on the long term planning. :]
As it was nearing midnight by now, I decided to call it a day, and went to sleep. I had gotten a lot of the mechanics in place. During day 2 I had to get all the graphics done.
Got a solid eight hours of sleep, and after some breakfast I began creating the player model; the, ahem, Tiny Gryphalope!
It took me until noon to get the mesh done. Although it was fun and a nice change from all the programming from day 1, I still feel like I could’ve put that time to better use. During the next compo I’ll try to make simpler character designs, with less feet.
Screenshots, in chronological order, of the making of the main character.
After I had the model, I began looking into keeping player and monsters from getting to far off the path. This was one of the biggest mess-ups in my opinion, one of the things which I spent far too much time on. I began by trying to make the constraint purely distance based, but I never managed to get it to work smooth enough, so after two hours of failure, and feeling pretty stressed out, I decided to put it aside for a while and start making an enemy model and calm myself down.
I decided not to spend as much time on modeling the enemy as I had spent on the main character. As I previously stated the theme got me thinking of giant flies (for some reason), so I decided to make a fly-like monster. I made it a very simple model, without any legs and a loosely defined, pudgy “face”, based on a quick and dirty sculpt. It took me about two hours to make the model from scratch and UV-map it. An improvement, but oh had it felt good had I only spent one hour instead. xD
After that I went back to battling the problem of making the level constraints. I decided to switch to using only mesh collision as it is already provided by Unity. However, since I had made my movement code completely separate and not based on Unity’s physics engine, I got a lot of twitching and shaking when implementing collision. I had to go back to the collision handling several times for small fixes and fine tuning during the rest of the development time, and I never got it just right before the deadline, sometimes it freaks out. *I think* I fixed it in the post-compo update, but to be more certain I would have to make movement physics based.
I long for the day when I no longer will have any problems whatsoever when implementing collision handling. Ha ha.
I then decided to get the textures for the Gryphalope and the fly-monster done. As I had grown quite weary of wrestling with ill-behaving code, it was a nice change to just draw for a while. I found a really good reference picture on Wikipedia for drawing the wings.
Yay, colours! =D
I now had 7 hours to go, and so much left to do.
I decided I had to start making something that could pass as a level, instead of the randomly placed boxes. The level ended up of consisting of only one mesh, duplicated, rotated and scaled in different ways. I began by making a tube in Blender, subdivided it like crazy and began sculpting tree-like grooves and roots into it.
After one and a half hour of sculpting and painting, I had this:
I then began making some sound effects for the game, using Bfxr. I also started the long overdue task of completing the game over- and victory-states. To sweeten the menus I implemented my own button system, so I could easily animate them and make them compatible with gamepad thumbsticks. I wanted to make the game totally playable using only a gamepad.
When making these end-states I got the idea to present all the monsters the player had killed, by lining thumbnails of them up, kind of like how it is presented in Spelunky between levels. I figured that this could then be expanded into showing some kind of score based on kills and loot. I never got the time to implement more than the line of thumbnails though.
With game over- and victory-screens done, the big crunch began.
During the last three hours I made a title screen, particle effects, rigged and animated the main character, “designed” a level, created music (thanks, inudge), playtested, squashed some minor bugs, and uploaded.
I was pretty happy with the end result, it being my first Ludum Dare, and all. The game ended up with pretty nice looking visuals but suffered from a lack of gameplay. It was great to get such a large amount of good feedback from the community, and it helped and spurred me to make and release an updated version.
What went right
- Going for a component based architecture.
- Getting all the core mechanics done by day 1.
- Reusing the same mesh for the whole level.
- Getting the spline system done pretty quickly.
- Actually managing to make some simple music(first time I made my own music).
- Having some friends over during the compo, kept me sane.
- Right amount of food and sleep. ^^
- Managed to make something playable. Next time: something enjoyable.
What went wrong
- Spent too much time making the main character.
- Spent even more time wrestling with collision handling. >.<
- Ended up not really needing the splines for the simple level that I made. (May come in handy later on though)
- Got some performance issues in the game on some computers.
- Realised after the deadline just how dark the game actually turned out, and how sluggish the movement was.
- Never got the time to make a pretty HUD.
- The project might have been a little too ambitious for being my first LD, it was hard to predict what to prioritise in only 48 hours.
- I should’ve brainstomed some more to make something a little more connected to the theme, and more innovative.
You can visit the entry page here, and play/rate the compo version. Web and download available.
Updated post-compo version
Click here to play the updated version if you’ve rated the original.
All in all, the compo was a great experience and I felt that I learned a lot, and as usual; still so much to learn. =D I’m really looking forward to the next compo!
And this concludes my post mortem, kudos to you if you read it all!
If you still got some energy left, and if I managed to pique your interest, please give the game a go, and I’m very thankful for all feedback and constructive criticism. If there’s enough interest I’ll probably keep working on it.
Thank you for your time.