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

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. 😀

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 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.

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. 😉

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. 😉

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

(more…)

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

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.

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

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.

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!

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.

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)