I’m in.
There, I forgot to post that.
Now that that’s out of the way, let’s talk games.
This is my first Ludum Dare, and I went in with a few ideas that fit some, but not all of the themes, not knowing if I’d actually go through with it if the theme didn’t fit. I waited up, and got progressively more eager as the unveiling came closer, and once it dropped, I knew there was no chance I’d go sleep like a sensible human being (unveiling was at 3am). I knew right then, I was making a bare-bones RTS.
“Whoa, hold on there”, I here you say, “isn’t that a LOT of work to do in 48 hours?”. Nah, not for a rookie like me; we love to bite off more than we can chew. And so it was that after 25 hours of continuous work (that’s about 42 hours awake) I took my sleep-brake with a mediocre prototype where rendering and controlling units (or, the white dots representing units) was just about all that worked. I had put a lot of time into the back end, making sure it was properly made, relatively fast, and had few hacks in it. I had also made a lot of stuff that I wouldn’t need until later, or is useless.
Day 2 was all about getting something, anything, ready for submission. I had gotten units working (although buggy), base capturing and attacking/damage registered as it should. Graphics-wise it was still very rough, and there was no sound, but those are easy problems to overcome. One that isn’t is the fact that an RTS without an opponent is about as fun as hitting your toes repeatedly with a hammer, and I had neither AI nor net-code. You could collect cash, buy units, take over bases, commit harakiri and destroy the enemy’s base, and all the while he did nothing. Not fun, and there was only half an hour left…
Submission hour is a great thing. I stopped working on features about 5 minutes after I decided to submit the prototype; I just added a scoring system and some constraints to end games. Well, that and to add menus, so I guess it was more like 25 minute, but either way, all that was really left was to make it run properly. And it turns out, since the code base had left prototype-land a dozen hours ago, it was no longer quite fit to run it. New features had been added, and things weren’t quite as consistent as they should have been. At 3am sharp I zipped up the files, uploaded them to my server, downloaded it to a new folder, and ran it. Well, tried to. It wasn’t responding. I admit it, I fixed game-breaking bugs after the deadline. They were all big bugs, and it wasn’t for much past 3, but I made some changes. There were also bugs that weren’t big enough to warrant a re-upload, such as turning off zooming/panning (which is useless in the prototype, and is a prime example of a feature that worked once, but through evolution of the code base was now entirely broken). My local version has it turned off, but I want to follow the rules strictly, especially now that I already haven’t.
TL;DR So far: Overconfident, not even close to finished and lacking sleep.
The game it self is fairly simple. As I mentioned, I wanted to make a Real-Time Strategy game. The idea was, there are bases, of which you start with one, and warp-things, although it makes more sense in the context of being Routers(bases) and Internets(warp-thingy). Each internet will, at fixed intervals, spawn packets(resources) that are intended for a single other internet, or a router in our space. Routers will also spawn packets intended for (a single) internet. You job in the prototype that ended up being the game is to guide them there. This includes selecting them, and issuing move-commands to the corresponding internet/router. The faster you get them there, the more points you get, but packets that leave the space or are routed to the wrong place are lost (most of the time). Turns out, this is quite stressful if there are enough packets…
The RTS would build on this, as what I’ve described so far is essentially the resource-gathering element of the game. Here, only packets intended for routers currently controlled by you can be routed, and only they give points. Points can then be used to spawn units and cappers. Units are either ranged or melee; meaning they either head into things and explode to deal damage, or head afer/around and shoot. Cappers are quite like the engineer in the old C & C games; you send it into a base (a router in our case) and it will slowly take it over. The more there are in a base, the faster they take it over, and if the enemy also has cappers in there, they cancel each other out. Essentially, there is tug of war in the neutral bases until one team takes it over. It can now be used to spawn units and gather resources (you now have double the potential income, although the exact factor is something to be tweaked for better gameplay later on). Now, you can’t capture a base controlled by the enemy directly. You first have to destroy it (make it neutral again), and can they start the tug of was anew. The goal is quite simply to make your opponent base-less.
The first intention was to make this part based on a simple AI for LD, and then build a multiplayer version if it was fun. My intention, at the time of this post, is to write an AI in time to submit the RTS for the jam. It doesnt’ look like that much work since much of the framework is already built into the code, but I’ve said that about a lot of things this weekend that turned out to be a LOT of work. Multiplayer is further off, but not impossible, as netcode is never a quick thing. On the other hand, and RTS of this style is event-based, and I have already implemented event history, for some reason…
TL;DR Second part: Wanted to make RTS, made only resource-gathering part in time. RTS might be coming in time for jam.
So, the interresting bits are left. What have I learned from my first LD?
First off, don’t make something where the initial design notepad-document needs vertical scrollbars. Keep it simple, and keep the number of ways to influence the game low and to-the-point. All points on which I failed horribly. If you have a simple idea of some single gameplay mechanic you want to make and showcase going in, it’s much easier to build onto it or polish it up to a game in good time before the deadline. Think of it as building a house. You’ll spend time building one brilliant floor, and then build a couple more rugged ones on top of it as you polish it up. Your ground floor likely won’t hold too much on top of it, but enough to make for a nice looking house. On the other hand, if you have this medium-sized intricate web of ideas and mechanics (as I did) going in, you know you’ll need a foundation to support the weight of the awesomeness you have planned on top of it. But you’ll spend a vast amount of time building that foundation, only to realize you’ve run out of time before reaching street-level. Maybe, as I did, you’ll be able to close the hole and build a tiny entrance to at least showcase your wonderful basement, but you’ll never get the skyscraper done in time!
Secondly, it’s a great way of learning the intricacies of a language or framework, but basics should be there once you start, otherwise you’ll spend 15 minutes banging your forehead into the desk because there was a header include loop hidden away somewhere.
Thirdly; sleep! No, that’s not a misuse of the exclamation mark there, I am ordering you to sleep. I didn’t, and the code I produced in my “tired period” (35-38 hours awake, after eating dinner) was both bad and completely foreign to me the next morning. I couldn’t remember writing much of it, but that is hardly surprising knowing that I actually well asleep on my desk at one point. You will get over the hump if you power through, but as the stretch gets longer, meals become sleeping medication. And you have to eat!
My final lesson was of how saddened I was every time I checked the LD IRC channel by all the people progressing, chatting, and having prototypes with better artwork than I’d ever be able to produce. Don’t get me wrong, I loved lurking in the channel, there was great stuff being produced and at times engaging conversation, but I knew I had picked an Idea where time was a luxury, and I couldn’t enjoy it. Ludum Dare, for me, turned into proving that I could finish my game (and failing) more than having fun creating something, and that was my biggest mistake. The next time I participate, I’ll be forcing myself to have fun during the competition, and relegate the end product to secondary. I’m competitive of nature, so that won’t be as easy as it sounds…
TL;DR Lessons learned part: Read it if you want to know…
As a final point, I want to run through the stuff I’ve used to make things this weekend.
SFML (C++)
MS Visual Studio Express 2010 (C/C++ edition)
The Gimp
Chronolapse (Timelapse is coming once I create it (probably after the jam deadline). Spending some time pause at key moments etc. to make it worth watching)
bfxr (The last thing I did, feature-wise, was include sound. Very quick with this!)
I wanted to write the game in pure C (for fast build times, practical for iteration and tweaking, and to better get used to a non-OO language), but couldn’t get CSFML 2.0 working (linker errors with the RC SDK, build error with source from git), and 1.6 doesn’t have shader-support. Since I am much more coding-monkey than artist, shaders are key to my polish; all animation would have been be done there (if I hadn’t run out of time).
Ludum Dare 23 Metrics: 38 files containing 20 classes and 5392 lines of code (3303 statements).
Almost forgot, HERE is the game…
Linux version (and possibly OS X, if I can get my hands on a mac) will be made, at some point, but probably not until after the jam deadline. Priotities atm. are jam -> timelapse -> platform porting -> finishing the game.
-Thynnmas
