I’ll be participating in the competition, hopefully finishing as well. Depending on what the theme ends up being, I’ll be using a subset of the following:

• Language: C++, Python, C#.
• Engines: Unity3D, OGRE, Pygame, none.
• Content creation: Paint.NET, GIMP, sfxr, Audacity, my guitar.
• Food and beverages: Adrenaline energy drink, lots of cookies, coffee, dark rum for the end.
• Devlogs: Here, as well as on my personal site.

Good luck to everyone.

Right, missed the start by a couple of hours as I got some needed rest. Turns out, the theme is the one I really didn’t want, on account of me fooling around with genetic algorithms earlier. <strong>Evolution.</strong> Genetic algorithms, unless done better than I can probably manage, are bad for gameplay. Not really intuitive, very limited, and not exactly robust.

I’ll be using Python, with Pygame. Paint.NET for graphics. Possibly sfxr for sound, and my guitar + Audacity (hopefully).

To that end, I looked into implementing the theme into the story/progression, rather than the actual gameplay. That just made me want to cringe on account of knowing the really basic biology needed to understand the huge period of time over which evolution occurs, and how Spore-like cell evolution is horrible. So, obviously, a mix of the two.

Hopefully, I can pull it off. We’ll see whether it actually works out. The biggest problem is likely to be the art, really. To lessen the impact, I’ll try and go for a minimalistic abstract style, with few colours. Have a dev picture, that looks horrible and will in no way reflect the final product.

At this point, I have finished 4 of my 10 steps to success (to be posted later): display framework without animation code, input framework, map loading/rendering, simple plaftormer physics/gameplay. Next up, adding some sort of UI that will mostly consist of start/end menus, and some sort of in-game dialogue boxes.

Another small break, for now. Doing my own art is quite hard, and I’ve scrapped quite a lot of designs so far. I’ll leave it at that for now.

In other news, I’ve got the animation back-end in, and the little guy nods his head slightly every 60 frames now. Besides that, I’ve added loading levels from JSON files, with dialogue boxes to appear in every level. The level format is your basic run-of-the-mill pixel-in-image-encodes-pixel-traits-in-game system.

Oh, and this is what happens when you accidentally flip sprites the wrong way.

Last break for today, still not much to show for it, on account of graphical design being so awkward to me. At the same time, I’ve got a very simple first introductory level almost done. Decorations and dialogue boxes I’ll be working on now.

I should mention at this point that I’ve already had a tough decision to make, when I noticed that my game was using almost 1GB of RAM. The reason for this was the way I’m loading the map into the memory, and storing every pixel as a different element in a huge list. This is obviously not very efficient, and not what I would’ve chosen for a proper game. At the same time, I’m not rewriting everything. I cut the maps in half, and it’s now using around 400MB of RAM, up to 500 during a level transition. That should be fine.

I also attempted recording my guitar for use as background music, but that didn’t really work out. My desktop mic catches too much noise, and not even Audacity can properly filter it out. I’ll give it another try tomorrow.

I’ve also got a tiny problem, in that my game currently plays exactly like one of those ‘artistic’ games, in that right now you only need to hold the right arrow key. Need to fix this for following levels. In the meantime, have a photo that hopefully won’t represent much of the actual game.

Very short break while I consider the direction I’m taking this. I’ve got two levels more or less designed. The only thing I’m lacking is three dialogue boxes and one enemy design. This design means both graphics-wise and game-mechanic-wise. I’ll consider it a while more.

In the meantime, my bad choices at the start are really affecting me now. Performance is an issue starting/restarting/finishing a level, and the memory use is a bit high. Next time, I’ll prepare a real system instead of hacking something together. A little bit of time spent in the beginning, while the idea is still morphing in your head, is much better than a lot of time spent fixing further along. I thought I knew this lesson before, but as it always happens, this creeps up on me.

Have a teaser picture of the second level. Think the theme linking is too ham-handed?

And…finished. Lots of work gone into this. Solely because I was an idiot and chose badly in the beginning. Still, I’m happy it’s at least done.

Overall, I’ll say this. I’m not pleased with it as a game, since it’s…not very fun to play. As a story, I’m glad that it at least doesn’t go the ‘eat food, gain trait’ way. Technical-wise, it’s horrid. An abuse of PixelArray and pygame, everything built on workarounds.

BUT HEY, it’s done. So here we go.

A Cycle of Ages (The most pretentious name possible.)

It also has kittens. Have a picture, and the download link.

RIP. Well, that was fun. And horrible. But still fun.

Good decisions:

• Deciding to not use the same silly mechanics everyone was using, on account of being certain I couldn’t pull it off better than most of the others.
• Choosing to go with a completely monochrome art style, on account of not being very good at art, myself.
• Sleeping for at least 6 hours in the middle of the competition.
• Dropping the target length of the game when it became apparent the performance would go down massively.
• Recording my own guitar melody on my awful microphone, and using Audacity to somehow clean it up enough.

Bad decisions:

• Using a single image file for each level, with the three channels describing each pixel in the game. See addendum 1.
• Using Pygame. Over half the time was spent searching through the documentation or source code to the library due to odd errors I got.
• Deciding to not create a robust framework, and build it on workarounds and hard code, on account of trying to stay in the timeframe.
• Not taking a pre-emptive analysis break. See addendum 2.
• Not posting quite as many developer logs I was hoping for. 5 is good, 10 would have been better.
• Not setting up either a recording method to record videos to show people, or a way to stream my screen.

Addendum 1: The way I organised each level wasn’t really up to par to the huge size each of them had to have. I tried to go with the method I’ve seen used for tile-based platformers. Each level is a single image, with the RGB channels encoding information about each tile. For example, red being 0 means solid, otherwise means pass-through. This works well with tiles because you’re unlikely to have a level be more than, say, 1000 tiles by 1000 tiles. On the other hand, my game had levels that were 20000 pixels by 5000 pixels. Encoding each pixel as a pixel in the image means, yes, a 20k x 5k image. Pygame, for one, can’t load images past a certain limit (20k x 10k I believe?), and it has, second, a large overhead when reaching that limit. And I mean exponentially increasing. That’s the reason my game freezes as you move to a second level. The culprit is a single line of code, so I could have done two things: split the level into multiple images and load and stick together, or rewrite a bit of the pygame library. I wasn’t going to get either of those in the 5 hours I had left, so I left it at this, with a warning.

Addendum 2: This is related to addendum 1. What I should have done, rather than plow ahead only playing the occasional attempt through the game to check for massive errors and obvious bugs, is take a break six hours in, or even every six hours, and just play through what I have intently. Figure out if I like the direction it’s going, check for performance issues, fix everything then and there. I basically piled myself a ton of performance bugs as I kept coding, then had to fix them all at the end. Considering that, for example, if I were to fix the first bug I’d have to rewrite a good deal of the game that would have meant bugs 2, and 3 wouldn’t have popped up. However, now that bugs 2 and 3 have workarounds, fixing the first bug while keeping the same outcome would mean even more work. Basically, early playthrough-and-fix breaks, or often if possible.

Overall, I’m happy with what came out of this. To use the Ludum Dare scoring system, this is what I’d give myself objectively:

• Innovation: 2/5 — It’s just your basic sidescroller, after all.
• Fun: 1/5 — Not much else to do, other than follow the story.
• Theme: 5/5 — The theme really was the focus, even if through the story and the mood.
• Graphics: 3/5 — I like to think the graphics weren’t that awful.
• Audio: 2/5 — No sound effects, just a single backing track.
• Humor: 1/5 — Not much humor in it, after all.
• Mood: 4/5 — I like to consider that with the writing and the art style, I managed to set a mood, even if a bit offset by technical issues.

Obligatory ‘I’m in’ post.

Tools of choice:

• Language: C++ or Python
• Libraries: SFML or Pygame/Pyglet
• Graphics: GIMP and Paint.NET
• Music: Acoustic guitar (and a bad microphone) and electric guitar with a cheap distortion pedal.

Tags: ld25

Tilemap array initialised and basic loading code added. Advanced loading code added, basic track sprites added, no transitions yet. Small test to make sure map loading is working, and it works! Still trying to get through my first cup of tea, stomach issues and game-making marathons really don’t mix.

Tags: ld24, ld48

Shower taken, two more ideas (other than the one I had when I saw the theme in the last voting round) whipped up, same two ideas discarded, sketch done. Project in C++ created, SFML2.0 included and linked. Simple first sprite drawn.

Tags: ld25, ld48

Starting to add junctions. There we go. An intentional omission is an X junction, because it’s un-toggleable. Fixed some issues with the sprites, missing planks and rounded up corners. Next up, coding an actual train to follow the tracks, initially ignoring junctions.

Tags: ld25, ld48

Simple train placeholder added. Aligns according to tracks, and moves forwards according to direction of travel. Incomplete, tile transitions need to reverse speed according to side of tile entered. Can’t think of an elegant way of doing it.

First major scrapping of code. The initial movement code was shoddy, at best. The train had pixel-based position, and the terrain was tile-based. Having this inconsistency made it really hard to actually do junctions and turns. Rewriting the track system into a node system, where each exit is a node, and movement is done as a simple linear interpolation between the positions of the two nodes that are connected at one point.

That took longer than expected, around two hours per total. Junctions have also been worked in properly, with the train currently toggling the junctions as it passes through them.

First off, an addendum to the last report.

Second, added a damsel in distress, and mouse-based toggling of junctions.

Tried to make a better looking train, and animated this time. Just as much of a failure, but meh. Programmer art it is. Damsel being run over now causes an end-game screen to pop up. Next up, adding the actual hero attempting to sabotage our fair villain’s plans.

This coming animated gif might not make a whole lot of sense, but basically, the AI hero now looks at where you’re heading and attempts to rearrange junctions such that you won’t hit the damsel. This can mean anything, from throwing you in a tiny loop such as the one in the image, or simply changing your course completely. This action is on a two-second timer so far, as will your own power to change junctions. This will be the tactical bit of the game. I have plans for another ability for the AI, and one for the player. To come soon.

Added final two abilities. The player can now select one of four speeds to travel at, and the hero can now decide to turn the player’s train around suddenly. Via magic of some sort, I expect. I’ve also added the start of a rudimentary HUD. This HUD will contain the present speed valve, and an ACME remote control showing the hero’s cooldowns, and the player’s cooldown.

Final bits of the interface added. Two two-part bars showing the state of the hero’s abilities, and one one-part bar, along with an associated LED, showing the state of the player’s ability to change junctions. Hopefully the programmer art isn’t too bad. This is also the first full-size picture I’ve added, and shows the actual screen-space the game will take, although of course the levels will be bigger as well.

Alpha build successfully created. The menu system is in place (although currently the options do the same things on account of not having done the levels yet), the interface is working.

Controls: ArrowUp/ArrowDown to control speed, click on junction to toggle it. The AI will also be toggling junctions, so in case it seems like your click has had no effect, the AI immediately re-toggled it, use it again when it recharges. Enter to select menu option.

LD25_alpha2

Any comments on the game so far are appreciated. Please leave them on this post or hilight me on IRC.

EDIT: Fixed build so it is no longer dependent on VCredit, hopefully.

The end is near. Possibly even already here. After a good ten-hour sleep, I wasn’t very coherent, so I haven’t actually posted incremental updates the way I did yesterday. Still, I was very productive. To start off, I implemented the bits behind the scenes for the menu system, an instructions screen, and designed two levels.

After that, I attempted to record the planned music with my acoustic guitar. No such luck. My dorm is noisy as all hell, and I could barely manage to get a clean enough recording for myself to listen to and recognise, definitely not clean enough for me to make anyone else endure. Thus, the music was scrapped. Moving on, I decided to retouch most of the graphics. First the terrain, since it was so plain. Followed closely by the HUD. Then, touched up the train a bit (it’s still a wonderful case of programmer art) and added a small ‘HELP’ sprite next to the damsel to make it clear what this is about.

Have a picture, and, soon, a release.