About Red Mike (twitter: @MikeRedhorse)


Ludum Dare 28
MiniLD 46
MiniLD 45
Ludum Dare 27
Ludum Dare 25
Ludum Dare 24
Ludum Dare 24 Warmup

Red Mike's Trophies

Red Mike's Archive

Merry Ludum Dare, and to all a good night!

Posted by (twitter: @MikeRedhorse)
Sunday, December 15th, 2013 12:36 pm

My game is finished, and I am satisfied with it, give it a try!


LD25 Postmortem

Posted by (twitter: @MikeRedhorse)
Wednesday, December 19th, 2012 6:42 am

Now that it’s all over, and comments are still rolling in, it’s time to figure out what went right, what went wrong, and just what I’d change. All of these things are things I will change for this coming year, and my New Years’ resolution, One Game a Month. They’re basically the things I will focus on, one or two at a time with each game. As my LD24 resolution was ‘Next time, I need to focus on making a fun game, and one that works from a technical standpoint.’, this resolution will be longer, and aimed at making me a better game developer overall, rather than just a better game jammer. This’ll be a bit of a long post.

What went right:

  • The idea(s): I managed to come up with a simple idea for each theme in the final round of voting. I didn’t stop there. When it was announced, I forced myself to come up with another two ideas I liked. The first was an Evil Genius-like game, which basically everyone came up with. The second was so unmemorable, I’ve already forgotten it. Out of the three, I decided the early one and the first one were the two I liked best. Out of those two, I went with my keyword: “Antibition”. Rather than go with the ambitious dungeon-building game that involved lots of mechanics and was considerably more impressive, I decided to go with the simpler idea, but polish it a lot more. The choice was a good one, after seeing how many people came up with dungeon-building games, and how few people came up with railroad-type games (one, that I’ve seen)
  • The tools: Starting out, I decided that I would have to choose between C++/SFML, the hard option, and Python/Pygame, the familiar option. ‘Hard’ in the sense that I was unfamiliar enough with the library that I wasn’t confident I could make a full game, even if I could make a tech demo. If I hadn’t felt confident I could at least make a tech demo showing off the mechanics (but not including any user friendly interface, animations, etc), I would have chosen the familiar option and researched SFML more before next time. C++/SFML was immensely more powerful than Python/Pygame, less problematic, and a lot more easily packaged.
  • The progression: My initial milestone was making a working representation of a railway system, with junctions, with no train. The second milestone was getting junctions (or actually, any tile) to have a mode, which toggles the direction of travel when coming from the right direction. The third milestone was representing a train that exists on rails and moves in a pixel-based fashion (this failed, and was replaced by..). The fourth milestone was getting a node-based graph back-end to the railway, created when the level is initialised, and on which the train exists. The fifth milestone was getting the train to respect junction modes, and to have a variable speed. The sixth milestone was being able to toggle junctions (by mouse callback, which then calls an internal function that the AI also calls when changing junctions). The seventh milestone was allowing the AI to turn you around, and adding cooldowns for all these abilities. The eighth milestone was getting the cooldowns represented onscreen as the HUD, as well as the current speed. The ninth milestone was getting a working menu system to choose between two levels. The tenth milestone was getting an instructions menu. Those I had established beforehand. Once those finished, it was all polish, reworking graphics, failing to add audio, etc.
  • The updates: In case you were reading my site, you might have noticed what were basically hourly updates on what I’ve been doing, following all those previous milestones. These were a bit of a nuisance for a particular roguelike news aggregator picking up a dozen updates in a day, but were useful both for me and for people to see my progress in somewhat real-time. Next time, I might attempt a livestream, or, if not possible, a timelapse. At the same time, I’ll attempt to be more active in IRC next time.
  • The endpoint: Finally, I called it quits when I should have. Finishing the core gameplay and milestones less than a day in, I didn’t decide I should give in to feature-creep and keep adding mechanics I wasn’t sure about before. That, most likely, would have had me at less than five hours left with no polish and half the mechanics broken and unbalanced.

What went wrong:

  • The graphics: I’ve mentioned I’m not fond of the graphics in it. The animations are horribly choppy, and the train is a classic example of programmer art. I’ve never been properly artistic, or at least artistically creative, and I feel this shows in the way I tackle graphics in most projects. I’m capable of producing half-decent art for things like backgrounds, terrain, mechanisms, etc, but I’m really bad at detailing them properly, animating them fluidly. This is something I know I can improve, and I will improve, however my resolution for this is another. I will attempt to collaborate with artists more, for game jams especially. Not having to deal with the graphics would basically free up half of my core development time to spend on gameplay, and almost all of my polish time to spend on bugs, balancing and interface work. Speaking of..
  • The interface: This is basically a remnant of my progression as a programmer. I started out with Visual Basic when I was very young, which is fine, but it was way over my head at that point. Followed that up with Pascal, but stayed well away from any of the graphics bits in it, and worked solely with text/file input/output. Veered into C/C++ at one point, steering straight into user interfaces and OpenGL, and gave it up when it turned out they were difficult. Moved through various languages, always managed to stay with text-based interfaces, attempting tutorials on graphics-work every so often and giving up once the projects got big enough to be useful. Settled on Python for a long while, and after a long time, decided to turn my roguelike work into simple graphics. Gave it up once again. This year, I finally decided to stop being a baby and tackle graphics properly. In the month or so I worked with OpenGL, I managed to get to a point where I’m no longer scared or confused regarding graphics, 2D or 3D. In fact, I’ve even got 2D perfectly under control now. However, my interface work is still horrible. By which I mean, menus, widgets of any description, buttons, windowing systems, etc. Sure, there’s GUI libraries out there, but I need to go an use them. My resolution is to make a game with a proper windowing system, and an interface that works, feels nice to use and has no bugs.
  • The audio: Something I wasn’t happy with was the lack of audio in the game. This was because of two major reasons. My electric guitar and preamp decided that they should be noisy as all hell when plugged into my computer, to the point where I could not manage any sort of clean recording, and my dorm is also noisy as all hell, to the point where any attempts to record my acoustic guitar were foiled by people shouting, dancing, singing off-key and yelling at one another on the hallway just outside my door. There wasn’t any sort of clean recording in the whole two hours spent attempting to record. To that end, my resolution, which is unrelated to game development in itself, is to attempt to pick up a piezoelectric bridge for my acoustic to allow me to record on my acoustic properly.
  • The intuition: To start off, I know I’m not the most eloquent person. I definitely know I’m bad at explaining things as well. I also know that most things that seem intuitive to me are plain ass-backwards to most people. I’ve had this pointed out to me what feels like half my life so far, and accept it, while attempting to improve it. I already knew before-hand that I need to consider everything in my game as unintuitive as possible to most people and attempt to explain it as well as possible. I managed to fail to consider junctions as a potentially unintuitive element, and have also managed to fail to explain the AI’s abilities properly, or make intuitive enough that it requires no explanation. Out of the ten or so real live people I’ve had test my game (while of course offering no assistance or comment besides the ones given in game, translating for some) only two thought the junctions were intuitive, three spent over five minutes attempting to make a train turn in a junction in a way it isn’t possible for it to, eight didn’t understand how the cooldown meters for the player worked, and nine were annoyed when the second ability for the player showed up. Five of those nine considered it a bug, despite reading about it in the instructions. Out of the other four, three said it makes the game plain impossible, and refused to believe me when I demonstrated how to win, claiming I had changed it somehow since I was the developer. So, my resolution is to make mechanics as intuitive as possible, not only easily explained, but to require no explanation whatsoever.

That’s basically it. A long post, but I hope it provides some insight into the process of finishing a game jam, for me.

LD25 Progress Report #13 — END

Posted by (twitter: @MikeRedhorse)
Sunday, December 16th, 2012 8:06 am


Have a download page. Comments are very much appreciated!

LD25 Progress Report #12

Posted by (twitter: @MikeRedhorse)
Sunday, December 16th, 2012 7:34 am

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.


LD25 Progress Report #11 — Alpha Test Build

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 1:10 pm

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.


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.

LD25 Progress Report #10

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 11:37 am

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.


LD25 Progress Report #9

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 10:58 am

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.


LD25 Progress Report #8

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 9:15 am

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.


LD25 Progress Report #7

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 7:50 am

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.


LD25 Progress Report #6

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 6:30 am

First off, an addendum to the last report.


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

LD25 Progress Report #5

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 5:33 am

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.


LD25 Progress Report #4

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 1:09 am

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.


LD25 Progress Report #3

Posted by (twitter: @MikeRedhorse)
Saturday, December 15th, 2012 12:28 am

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.


LD25 Progress Report #2

Posted by (twitter: @MikeRedhorse)
Friday, December 14th, 2012 11:48 pm

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.


LD25 Progress Report #1

Posted by (twitter: @MikeRedhorse)
Friday, December 14th, 2012 10:52 pm

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.


Once more unto the breach, dear friends

Posted by (twitter: @MikeRedhorse)
Thursday, December 13th, 2012 2:15 am

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.

[cache: storing page]