After my less successful attempt at LD25 I am in to try again. I’ll take a different approach than last time, where I started coding before I had a clear vision of what I’m going to create. This time I’ll work on a complete concept before writing any code.

My tools will be

If I’ll implement some server-backend I’ll use Node.js or Flask (Python).

Edit: May I’ll add bfxr to the list of sound tools, especially if I’ll run out of time.

I made some progress, less progress than expected but the controls are working. Next step is to integrate the core gameplay elements.

I managed to finish some more objects. When they all are completely working I’ll go for menus and level design.

It seems like I’m done, the game is working and looks … okay. I ran out of time (again) before I could go like crazy with level editing so the game comes along with only 5 nice levels. I recorded the whole two days so I may make a Timelapse in the next few days.
I’ll pack the source tomorrow, the source on the play page is not obfuscated in any way.

Web (HTML5)

The Run is done for a few days now so I’ll better write my post mortem before I forget the small hurdles. First, let me introduce The Run shortly.

You are playing a small slime and your goal is simple. Get to the rooms exit by walking on floor, walls and even the ceiling. The facility your trapped in is in a bad state so be aware of toxic liquids. Be also aware of traps, since defense systems will detect you after 10 seconds in a room and will be trying to stop you from reaching the end. Though, it is possible to finish the levels even when the 10 seconds are over. How fast can you beat all five rooms?

Play and rate now

What went right

• Head first
  I started this Ludum Dare game by doing most of the game-design before writing any code to save me from thinking about basic decisions during coding. This worked out great and I could focus on the code while coding.
• Doing pixel art
  Doing 8×8 pixel art again was the best thing I could do. I finished the assets pretty fast and I’m pretty happy about how it turned out. With more time for preparation I’ll may try WebGL next time.
• Fixing the screen size
  Not having to care about dynamic screen resizing like in my LD25 game was a huge simplification since I could expect a fixed resolution when coding. Next time I’ll may be flexible again but for this game it was perfect since the screen size equals the size of one room.
• Gameplay decisions
  One hing that was clear to me when I started working on this games code was that I didn’t wanted to make a hard 10 seconds limit. That’s why I implemented the traps. The original goal was that every room has a prisoner that you CAN free for the price of losing time and having to get around the traps. The prisoner was later replaced by bottles since I ran out of time for doing their sprites. The controls were doing well except of relying on physic.
• Flexible input system
  I’m happy with the way I implemented the input handling. When a key is pressed or a button on a known gamepad (and gamepad mode is enabled) these are mapped to actions like “left”, “right”, “jump” or “use”. So the entities don’t care where the input come from or how it is proceeded, they only need to check if they need that action. This would allow touchscreen controls as well.

What went wrong

• Leveldesign in the text editor
  My biggest mistake was to make no ingame level-editor. To edit a level I had to Alt+Tab to the editor, change a letter and Alt+Tab back to the browser and reload the whole game. A simple toggleable editor mechanic would’ve result in much more levels. Another problem was that I started doing levels 3 hours before deadline.
• Rely on physics
  When I decided to do the whole stick to the wall mechanic I did not thought it would be this hard. I had to rewrite the players physic three times before it got kinda bug-free. I also made the mistake not to give it away to players early. Thus some players had problems with the controls I didn’t see.
• Redoing the basics
  Another mistake I did was to implement the state manager and thus the menus and screens during the last six hours. I also missed the chance to do a real statistics screen (with death counts and such) simply by losing time due to the initial plan to not use libraries covering the basic stuff like bitmap fonts, state managers and controls. I’ll either use an existing library or do my own next time.
• Not finishing features
  The game has basic support for XBox 360 controllers, though this requires manual activation. It would’ve been much better if I had integrated game controls selection into a start screen (“Press space or start…”). Same applies to some in-game features like death counting by reason and the collectible bottles that have basically no use at the current state.
• Keeping it silent
  One major mood breaker is, that I didn’t create any soundtrack to the game is completely silent. A little loop would’ve helped the game to build a more intense atmosphere.
• Naming
  The Run is too unspecific for this game, since the character is a slime without legs. May I should start naming my game next time not in the very last hour.

Tags: post-mortem

I’ll do it again*. This is my third LD compo and I’m pretty excited about it. I’ll try to improve my skills in terms of sound (both previous games have been completely silent) as well as keeping an eye on mobile (if the theme allows such a gameplay).

Oh, and I’ll do the #NOKILL challenge as well, including not killing the main character if my game will have one ;).

My Ludum Dare history

• Space villains (LD25)
• The Run (LD27)

I’ve announced a post-compo version of both of the games but currently none is released. I’ll do a full release of The Run at some point but I’ll need to invest lots of time into it and had so little spare time this year.

My tools
For coding I’ll use VIM, for music LMMS, for sounds Bfxr and for graphics Gimp. If it’s nessesary I’ll use Tiled for level design (but I’ll try to do something procedual).
My framework of choice will be HTML5/JavaScript/CSS3.

*if the theme is not Bieber 4Evar!

Tags: #NOKILL, html5

Dumb Treasures was my this LDs compo entry. Planned as a “You only get one unit” turn based strategy game, it actually turned into a small “collect all 16 treasures with the only solider remaining in your army” micro-adventure.

It is the story of a countries army. The country Bla went bankrupt and only a single soldier remains. This soldier is then send to a treasure island where he has to collect 16 treasures as fast as possible. The whole island is save, since there are no dangers.

The stort is simple, so is the gameplay.

Play and rate now

What went right

• Restrict my colors
  This time, I used the NES color palette as found on Wikipedia to restrict my options. This worked great since I didn’t have to find the one color out of 2^24.
• Using bfxr
  Having sounds improved the game a lot, even though there are only two sounds.
• Simplify early
  When sunday afternoon arrived and I had only worked 6 hours on the game in total I decided to drop all my plans (enemies, traps) and focused on implementing a really simple gameplay but doing it nice aaaand doing a whole game. That results in having a nice start screen, an introduction and a result screen that makes the game look much more polished.

What went wrong

• 8 hours
  Should I really say more. Due to unplanned events I had much less time than expected.
• Not using a framework
  Again, I had no time before to prepare a framework with common used code like state management. I haven’t lost much time to it but some.
• Focusing on graphics
  I spend way to much time on the floor tiles which are nice and probably save my a** during the voting but may I should’ve spend that time on implementing some game elements like traps.
• Not providing alternative controls
  I absolutely regret not implementing the Gamepad API everytime I see that cheap SNES USB gamepad clone on my desk. I’ll may integrate it in a later version.
• Not providing a leaderboard
  Dumb Treasures has no deeper meaning or big challenge. The only challenge is the countdown. I should have spend ten minutes to implement serversided leader-boards in the dirtiest way possible. That would’ve improved the players involvement a lot.

Tags: post-mortem

This weekend, I’ll be participating for my fourth time. I hope everything turns out well and I’ll have enough time to create something nice and playable. This time I’ll use coffeescript, but I will stay within the browser. If I can come up with some nice “touchy” gameplay I’ll try to release it touch ready.
Since I suck at sounds, my game will either stay silent or use some generated sounds. So may I’ll use bxfr or some procedually generated sounds based on this document maybe?

Yet again, the first hours are reserved to make a more or less detailed plan of the game to avoid feature creep.

Editor: Sublime Text 2
Language: CoffeeScript
Graphics: Gimp
Sound: bxfr, LMMS (if I have plenty of time left)
Debugging: FireFox, Chromium
OS: Linux Mint (my Arch Linux pc is broken ATM so I needed a fast to install reliable replacement)

Konami code included

Tags: coffeescript, html5, konami code

After a long night, I finished the major features for my game, portals and reversible gravity. The core idea of the game is, that you can (and sometimes have to) proceed beneath the surface.

My entry finally has a name: Go Below (Preview)

Stuff that is still todo:

• a goal 😉
• a level (currently only a ingame editor)
• a character!
• music
• sounds

I finally found the time to write my entries post mortem. My entry is a platform game called Go Below with a pretty nice game mechanic. If you can’t proceed since your path is blocked, you can continue beneath the surface.

Go Below – Play and rate now

Before we start, my favourites

Senilescape is an awesome platformer, where you need to escape from a prison and flee from the guards. I didn’t get very far but I tried over and over and over and over so it seems to be very good.

Beneath the Surface is a disturbing, creepy text-based experience where you get send into a bunker and need to kill the big red. During the game play you have some options to chose from, but I don’t think you can finish the game without feeling bad.

Gun Bat This game requires headphones. You need to resist against enemies that you don’t see. It uses audio to give you an idea where you have to shoot.

What went right

• Nothing
  Just kidding.
• Create an ingame level editor
  This time I started coding the game with the ingame level editor. This saved me a lot of time, especially since I could test jumps and alike directly after editing. The levels tiles were then saved in the browser (using localStorage), so I could reload for changes without losing the level. When I was done I used a little console stunt to export the level. The editor can be enabled in the source (class World, property editing).
• Using Coffeescript
  Coffeescript is awesome. It allowed me to focus on the game logic without setting up the prototype chain and stuff on my own. The syntax is so much nicer than pure JavaScript.
• Handdrawn style graphics
  This time, I’ve gone a different route than usual with my graphics. Instead of pixel art, I used the brush tool of gimp to create graphics that are looking like drawn by hand. The process to create those was really simple so I consider the style for the next Ludum Dare.

What went wrong

• No music
  I tried to create a soundtrack with LMMS, but I have not learned usage yet so I skipped it. A little background melody would’ve helped atmosphere so much.
• Not using a framework
  Like at all the other LDs before, yet again I had not prepared a framework. The basic setup always costs worthy time so I will use a framework next time (hopefully).
• Level design
  The level is with a playtime of avg. 3 minutes quite short. On the one hand this is nice, since it allows the people who rate my game to beat it before rating. But too many seconds get wasted for simple walking and less puzzle solving. Especially in the middle of the game there is a pretty long walking part.

Finally, thank you to all those who commented, who created all the awesome games and to Jupiter_Hadley and shubshub for their videos of Go Below.

Tags: post-mortem

I had to skip the last Ludum Dare but I am back for number 31. This is going to be my fifth LD.

I’m going to use one of these hip frameworks and not pure JavaScript this time for the sake of development speed.

Editor: Sublime Text 2
Language: Haxe
Framework: OpenFL, may with Haxepunk
Graphics: Gimp, Inkscape
Sound: bxfr, LMMS, MilkyTracker, whatever I can find
If I need some server-sided backend, I’ll use PHP. 😉

Tags: haXe, openfl

So here we are again, it’s always such a pleasure. Another gamedev weekend is approaching fast so it’s time for another obligatory “I’m in” post. Not much has changed in my toolbox since last LD so lets list it shortly.

Toolbox
Editor: Sublime Text
Language: Haxe
Framework: OpenFL (may with openfl-bitfive)
Graphics: Gimp, Inkscape
Sound editing: bxfr, LMMS, MilkyTracker, Caustic
Planing: notebook and a pencil

Goal
This time, I’m going for a complete experience. I don’t want to make the same mistakes I made in my previous attempts and create a somewhat playable prototype but rather a game that feels good to the player.
I’m probably stick to 2D top down or even a flat puzzle game this time to avoid coding broken platformer physics yet another time.

Good luck and lots of fun to all participants.

PS: No bonus themes yet?
PS2: Technically, it is my “I’m in” post #5. I didn’t wrote one the first time as I started in the middle of the weekend back then. 😉

Tags: haXe, html5, openfl

Just a quick screenshot post for my entry. The basic idea is, that your weapons are your minions, that also construct your base and capture points. For a battle, you have only one way to damage the opponent, by making one of your minions explode. Pretty unconventional, I hope.

I have a basic world generation as well as pathfinding working (my very first A* implementation, whooo!). Rendering works pretty good so far. Next step is a way to make the minions explode (and an explosion tilesheet) followed by the enemies AI.

PS: The name is totally WIP, I hopefully come up with something better in time.

It’s time for another weekend of pleasure, fun and unhealthy food. My awesome wife will take care of all the tasks that normally eat up my weekends so I can spend the whole weekend on creating something. This something hopefully becomes more like my older entries and less like my more recent ones.

I’m switching back from Haxe/OpenFL to CoffeeScript/HTML5 since I had problems the last attempts deploying to the web. Since I don’t want to write all the scaffholding in the worthy 48h time window, I’m going to prepare a boilerplate using pixi.js, howler.js with Grunt this time. It will contain no code aside from a completly empty coffeescript file and a basic HTML file that embeds the two libraries. That way I can start coding the game and creating the art without needing to worry about minification, deployment and all the other fun stuff.

Toolbox
OS: Arch Linux
Editor: Sublime Text 2/3
Language: CoffeeScript
Libraries: pixi.js, howler.js
Graphics: Gimp, Inkscape
Sound editing: bxfr, LMMS, MilkyTracker, Caustic (any of these hopefully)
Planing: Pen and paper

Just kitting, but they will have a meaning in my game. 😉

Ludum Dare 33 was an awesome event and after cooling down for a few days and playing some awesome enties, I’d like to give a postjam update.

Underbed Monster – Play now

About the Game

Underbed Monster is a stealth game, where you have to get to under peoples beds without being seen. You can also eat kittens, so the game can’t be that bad!
I actually think this is my second or third best entry in Ludum Dare so far. As opposed to my previous two attempts, it is actually a completed game and not only some broken prototype.

What went right?

• Working with the theme
  Before the jam, I hoped that the theme You are the monster wouldn’t make it because it felt too similar to LD25s You are the villain to me. But when it was announced I had to work with it and I think it turned out great. Next time I won’t have any prejudice against specific themes.
• Using Pixi.js
  While I had some difficulties with Pixi.js (I haven’t figured out sorting yet), it allowed me to iterate faster and to focus on content, less on rendering optimizations. The scene graph allowed me to create scene transitions, a simple effect that makes the game feel way more polished.
• Using Tiled
  When I had the initial concept written down I noticed that this game would require me to build quite some levels. Since I didn’t wanted to spend time on a level editor ingame, I started Tiled that I had installed but hadn’t used before just to check it out. As I’ve seen that it can export .csv-files I immediately started using it for constructing my levels. It is an awesome tool I’ll have in my toolbox for the next LDjam.
• Doing the dirty things
  This time, I forced myself to write the most dirty code possible without any clear structure or “If you do it know you can later…”. You won’t. Due to this the source code of the game is a mess (you can take a look), but it worked and allowed me to get things done faster.
  That also included that some of the “game logic” is actually included in the levels. Walls are not solid because they are walls but because they are on the wall layer. Same with balls/boxes and alike. This allowed me to pixel some new stuff, place it on the wall layer and et voilà, a solid object.

What went wrong?

• Not finishing my toolchain
  I’ve setted up a grunt-based toolchain with automatic CoffeScript to JavaScript compilation including minification but it hadn’t included other gamedev related tasks like spritesheet construction nor image optimization. That should be included in the toolchain for the next time.
  I also plan to include a distribution process for the next LD so I didn’t have to extract all the necessary files manually but get them packed nicely by grunt.
• Not finishing features
  The initial idea for kittens was, that they make noise when they notice you so the people run there. That would’ve allowed to use them as a distraction but that would’ve meant I need to implement pathfinding. Thus I dropped it and made kittens an eatable gimmick.
• Not testing a last time completely before submission
  It seems like I introduced a bug during the final hour before submission. Whenever you get caught by a person, the level should simply restart but actually it resets the game and shows the end screen. That should’ve been corrected before submission.
• Not making music Music
  Yet another silent Ludum Dare entry made by me. I’ll probably never learn.

The future

I haven’t yet started on expanding it due to long working hours but if I get into making a postjam version I’ll post on my Twitter account and may here in the blog. May I never start expending it, who knows.

Thanks

Thanks to all those who commented or lets played my game and to all those who will. It makes me smile if I see people are enjoying my game, preferably with some kind suggestions that would improve the experience.
And a huge thanks to my awesome wife, who has supported and fed me the whole weekend (kinda). 😉

PS: I’d like to suggest a few other games. Misunderstanding for the depth hidden behind some nasty bugs, Poust because it’s awesome and The Slimy Jumper because I know the dev in RL. 😀

Yet another copy and paste “I’m in” post. If nothing goes horribly wrong, I’ll participate in LD34 compo as usual. Once again, my awesome wife will take care of the common weekend tasks, so I can focus on creating a game. I hope I can continue the success of my most recent entry and deliver another almost polished game.

I continue what I did last time. Preparing as much of the non-game work as possible. For this reason I continued expending my boilerplate project with on-the-fly code compilation, asset packing and optimization. May I’m going to implement the base classes of any game (state management, renderer setup etc.) before LD starts but if I do so, I’ll post a short release notice, so anyone can use it.

May I’m going to stream the whole process, but I haven’t checked if my current workstation can handle it.

Toolbox
OS: Arch Linux
Code editor: Geany
Map editor: Tiled
Language: CoffeeScript
Libraries: pixi.js, may howler.js
Graphics: Gimp, MTPaint
Sound editing: bxfr, jfxr, LMMS, MilkyTracker, Caustic (any of these hopefully)
Planing: Pen and paper

Finally I can post the "I'm in" post for my ninth (:scream_cat:) participation on the new site, thanks @pov.

I had to skip LD entirely last year and now I want to start with something new. Previously I used Java-/CoffeeScript along with plain HTML5 canvas and Phaser.js as well as Haxe with OpenFL. This time I want to focus more on the game design and less on the code so I'm going to use the Godot engine.

Good luck everyone.

Tools

Engine: Godot
Code editing: Atom
Image editing: Krita or Gimp
Music editing: LMMS
OS: Arch Linux
Planning: Pen and paper

My game The Bugs World still needs four more votes so I guess it's time for the post-jam update. This game is a simple but fast-paced RTS game without base building but with bugs. To win you need to destroy all your enemies bugs. Collect food and deliver it to your nest to produce more bugs.

Please play and rate

What went right

This time I decided to use a full-featured engine instead of the various frameworks and libraries I used before. Due to it's open-source nature I went with Godot and I'm glad I did so. Considering this was my first attempt on a serious game using this engine things went pretty well.

What impresses me the most is how reusable Scenes in Godot are. When starting a running game is shown as an (failed) attempt to explain the gameplay to the player. You see two teams collecting food and destroying each other afterwards. This scene is constructed using the same nodes that I used for regular level creation. The biggest difference between this scene and a regular level is that this scene don't contain a human interface scene but two AI player scenes.

What went wrong

As usual during Ludum Dares I tend to spend my time on the wrong aspects of the game. This time the menu got a lot of polishing while some major problems weren't fixed. Thus the jam version didn't contain highlighting of selected bugs nor a complete explaination of the games gameplay elements. I tried to explain the gameplay by showing a AI battle on the main menus background but didn't notice that this would require understanding of some of the games rules. Basically I lost my focus on the later player.

The game also lacks gameplay elements that allow variation of the gameplay flow. The player can only win when collecting much food before attacking. It lacks strategic options. Neither helped the fact that I released the game with a broken damage system so bugs insta-killed opponents.

I tried to create some background music this time but haven't liked what I created so I got rid of it entirely in the end. A nice melody could've improved the ambient of the game a lot. May one day a game of mine will have sounds.

The future

I'm still working on some fixes for the game and I'm going to release those when the voting is over. The postjam version will add the bug selection and some other improvements.

I'm considering flat colored isometric vector art for a possible full game release but I haven't decided about that yet.