This is a gameplay video of the game I created for Ludum Dare 20!!

If you would like to play it – follow this link: http://www.mediafire.com/?ax2fze2fiue729l

Please comment and let me know what you think!
It will mean alot!!

5 hours left!! still some time before releasing the playable version of our game . Everyone’s a bit tired and we skipped college today so we could finish it xD but it’s doing pretty well .
- Our char is all done .
- Traps are about to begin the killing in about half an hour
We won’t be able to post the project as complete as we intended to  .  It will contain only one level for now , unfortunately, because our programmers are depending on the internet to work on the code together, and it’s been crashing the whole day. We’ve actually moved from one house  to another to get the internet working for us. That delayed our progress by a couple of hours :/  but what we already have should be  enough to show the game’s idea . We definitely intend to keep on working on it along this week, making more levels and turning the game into something actually challenging and fun , we’re all pretty excited about this game :]
here are some screens and another animation ( wich should clarify a bit about the gameplay now ) , hope you enjoy!

To view the previous posts about this work, here it goes :

http://www.ludumdare.com/compo/2011/05/01/soul-keeper-updating/

http://www.ludumdare.com/compo/2011/04/30/soul-keeper/

http://www.ludumdare.com/compo/2011/04/30/work-in-progress-3/

Instead of a timelapse, here’s my now-traditional series of progress shots. Due to timezones I basically get two days split evenly (assuming I go to bed at 3am on the first day. Which I did).

I think this was as far as I got on the first day. It’s a bit blurry in my head.

I think that shows quite a nice progression. The last picture was no-where near being complete, as I hadn’t done any of the actual levels by that point, but visually it was basically done. I think the only visual elements I missed were the power cores (just a simple object) and the game over and success screens (which I deliberately didn’t post so that people can see them for the first time in game).

Watch it on youtube:

>>The World Above – Timelapse<<

TL;DR: I like making games and hence created Cuboc for LD20. <3

Design Phase #1 and Prototype

I read about the theme of the LD20 about 6 hours after it was announced. My first thought “woah, companion cube”. For me it signifies the one thing in game history that really fits the theme “it’s dangerous to go alone! Take this”. The word “alone” signifies to me that what you receive is actually something that is a companion, not just a mere tool like a gun or a shovel. The companion cube is both a tool and a “friend”. A silent friend, but a friend never the less.

The overall idea would be to have a companion cube (yes, how original) but deviate from the formula in Portal. While the cube serves pretty much the same purpose as in Portal, you are also able to control it directly. That makes for some interesting game mechanics atop of what we saw in portal. It’s also a way to ease the burden on the programming side as the cube would automatically follow the player which would mean a good path finder. Something i didn’t have time for.

Given this idea i settled for a puzzle platformer, where the protagonist was accompanied by a cube which he can control and anchor in the world for a given time. From there on i tried to come up with game mechanics. I spent 6 hours implementing the basics (protagonist movement & collision detection, cube following) to get a feel for everything. For this i had to settle on a unit system so i can give my game objects proper sizes and positions. I settled for the following:

• One unit in the world equals one meter. The protagonist called Bob is 0.8×0.8 meters in size (comic like proportions). The cube is the same size.
• The viewport into the world (the porition that is visible on screen at any one time) is 24×16 meters wide. Why? Because it is easily mappable to pixels as you’ll see in a bit.
• I settled for a mapping of 1 meter == 20 pixels. From this and given the viewport of 24×16 meters i derrived my target screen resolution, 480×320 pixels.
• With these measures i started pixeling the tile graphics, Bob’s animation cycles and the cube, all arranged in a 20×20 grid so i can adhere to the sizes chosen in world coordinates easily (e.g. 0.6×0.6m ~ 12×12 pixels etc).

I implemented Bob’s movement (acceleration + damping makes for some nice movement) as well as collision detection. The later turned out to be a problem and took me 4 hours. Once Kivan told me an easy way to handle it in my setting i was able to completel scratch and rewrite it in 20 minutes. The more you know.All in all i spent around 6 hours for this first phase.

In terms of language, tools and so on i settled for the following:

• Java plus libgdx. I wanted to eat my own dog food
• Deployment would happen as a single self-contained runnable JAR file. Easy to distribute, no installation required, the closest you can come to an executeable in Java
• Eclipse, cause it’s what i know best.
• For graphical asset creation i used Paint.NET. While i really like Gimp, it’s interface still turns me off and i find it a lot easier to work with Paint.NET’s more streamlined (but less capable) interface. Sadly it’s only available for Windows (not a problem for me).
• For the tile maps and object placement i also turned to Paint.NET. Objects and tiles are color encoded in a bitmap. Objects that span more than a tile are represented by a pixel indicating their starting position only. The rest is constructed during run-time.

Downtime, trying to give up

With this prototype i ended the first LD phase. I had a feeling that there was not enough time left for me to fully finish a playable game. I started on sunday, 1:30am GMT-2, so there were only ~27 hours for me to work. My woman and I planned to go to an HR Giger exhibition the same day. Let’s say she was surprised to see me awake at 8am in the morning in front of the netbook. I went to bed at around 8:30am and got up at 1pm. At that point i gave up on LD as i figured i’d only have 8 hours when i come back from Vienna (trip was estimated to take ~6 hours). Some impressions from the exhibition (couldn’t photograph the actual artwork).

The toilets in the Hundertwasserhaus are especially artsy fartsy.

Aliens with Penises and Tits, Phase #2

On our way to the exhibition we talked about the game in the car. For 2 straight hours. Steffi wrote up all the ideas we talked about. When we arrived in Vienna i had a full fledged game design in my pocket. I was psyched. I knew with this in my hand i could easily finish of a basic version of the game in the remaining 8 hours i had when we came home at 8pm. Here are the notes in German:

Translation:

• Chambers
  • Entry/Exit, use cube to open the exit.
  • One or more cube dispensers/respawn points
  • If there’s not cube in the scene, the last touched dispenser generates one
  • Cube follows automatically
• Controls
  • Keypress activates cube control via usual means (w,a,s,d)
  • Pressing the same key while the cube will return control to Bob, the cube freezes for n seconds and is collideable (useable as a platform). Once the time is up the cube follows Bob again.
• Obstacles
  • Bob can die in which case he respawns at the last touched dispenser. Same is true for the cube
  • Spikes – kill Bob
  • Lasers, vertical and horizontal – kill Bob, can be blocked by cube
  • Moving Spikes, vertical and horizontal – kill Bob & Cube
  • Homing Missles – kill Bob, blocked by cube
  • Robot – kills Bob on collision, no effect on cube
  • Shooting Robot – kills Bob on collision, shots blocked by cube

A sequence of levels was also losely defined:

1. Introduce dispenser, cube & exit
2. Introduce jumping and cube following
3. Introduce spikes (no help from the cube needed)
4. Introduce moving spikes
5. Introduce non-shooting enemies
6. Introduce spike pit only traverasble via the use of the cube mechanic
7. Introduce shooting enemies and corresponding cube mechanic
8. Introduce Lasers and corresponding cube mechanic
9. Introduce homing missles and corresponding cube mechanic
10. Be creative with the elements from here on
11. …
12. EOL!

Back home i looked at this and was excited. I had 8 hours left, a very simple prototype and a full-featured plan. I started by prioritizing game elements. The doors went the way of the Dodo, they didn’t add anything to the game play. While they would be a motivator to keep the cube alive they were ultimately point-less: you can always get a new cube from the last dispenser, the only effect would be that you have to replay the level from start without any real benefit. Frustrating!

The enemies were cancled as well. I thought the other game play elements (spikes, moving spikes, homing missles and lasers) where interesting enough. I was also confident i could implement them all in the remaining time.

After some reordering of the level sequence i decided to have a single big level with multiple dispensers. Sort of like in VVVVVV. Continuous level for the win.

The level itself would be tile-based as said earlier. Objects would be encoded as pixels with specific colors, e.g. a dispenser would be red (0xff0000), a laser cyan (0xffff00) and so on. An object’s pixel would only signify it’s position in the world, not it’s extend. Lasers and moving spikes span multiple tiles in-game for example. I could easily derrive all properties during runtime given only their position, e.g. their direction and so on based on their surrounding.

With all this ready i started hacking again. And hacking i did.

Hackaton, Phase #3

Everything went a lot better then excepted. I added one game element after another. I set a time-frame for each feature and a sequence of implementing them. 7 hours to go!

• Cube control & following with Collision detection: 30 minutes, code is basically the same as the one for Bob in the prototype
• Spikes and collision detection & response: 60 minutes, this included respawn points, animating Bob’s death
• Homing missles: 45 minutes, this included spriting the rocket and an explosion plus the usual physics/logic implementation
• Moving spikes: 60 minutes, a simple afair of figuring out the direction based on the position & surrounding of the spike in the map as well as collision detection with the map and changing direction in that event
• Lasers: 80 minutes, basic setup as with moving sprites (figure out direction and end position of laser) plus some more involved collision detection with the cube (blocks the laser mid-way) and Bob. I knew this could get hairy but it turned out better than expected
• Screens: main menu, intro screen, game over screen: 30 minutes. I decided to go with a rather “make-your-eyes-bleed” single image per screen style which could be implemented quickly.
• Exit & Gameover state: 30 minutes. Another simple afair, just place the exit somewhere in the level and trigger a screen transition to the game over screen
• Level Design: 80 minutes. I wanted to have one continuous level. For this i made a special respawn object that let’s me test different chambers immediately on the go. This system let me test a specific chamber immediately. I just moved the object around the map when i created a new room. This way i could generate a level that takes an average player (Steffi) around 6-7 minutes to complete. Not a lot but enough for my needs.

As you can see in the timelapse i could stick to that schedule pretty much 100%. The final packaging took about 5 seconds. Export -> Runnable Jar.

I delivered the submission at pretty much excatly 4am local time, a spot on submission so to speak.

What went Well

• The decision to use a bitmap to encode the level information was a good one. I did not have to battle any editor i wasn’t familiar with and could make up new encoding rules on the go. Previewing was also painless and always only two keystrokes away.
• Since i decided to eat my own dog food in form of using libgdx for this i was curious if our design decisions would hold up in an extreme situation like Ludum Dare. Thankfully the framework never got into my way at all. Everything i needed was in place, from input handling to rendering and some math & collision helpers. Of course, the game is pretty simple so i did not have to make use of any of the more advanced facilities in the framework. Never the less it turned out to be extremely simple to work with.
• Having a full design is something i can’t state the importance of enough. Seriously, if you enter something like Ludum Dare, spent enough time to make everything watertight. It’s so much easier to work from a design then to make up shit on the go. Of course i first prototyped before i went full-design-metal. Once you know your prototype works start designing, not coding!
• Paint.NET is a joy if you know all the keyboard shortcuts. I was able to pull of all the asset and level creation in no time.
• Having ~20 people in our IRC chat was valuable as well. I had some test slaves and some of the folks could even give me tips on how to approach the fsm damn initial collision detection problem (never did a platformer before…). Thanks Kivan!
• The schedule was also very helpful and allowed me to make the deadline. It would have been very easy to get sidetracked with a small detail otherwise. Keeping my eye on the clock was a “good thing” and mostly responsible for me making the deadline.

What went Wrong

• Having done some rather elaborate math and computational geometry in the past i thought that the collision detection for a simple platfomer would be a piece of cake. Not so. I spent full 4 hours out of the 13 hours total to get Bob to correctly react to his surrounding. That was rather embarassing as i thought i was knowledgeable about most game development stuff. The more you know! A humbling experience.
• Due to me starting on the second day and spending a good 7 hours on none Ludum Dare related things i was really short on time. I think i could have created something a lot bigger if i’d used the full 48 hours.
• Sleeping for 4 hours is useless. Sadly there was no other option. I really wanted to see the Giger exhibition and spent quality time with my woman. Note to self: sleep at least ~8 hours before and dacuring Ludum Dare!
• I did not have time to include sound effects. Which is funny cause i really think sound makes up 30% of a game easily in terms of immersion. I’ll do better next time (sfxr & my own sequencer to the rescue!).
• The level design is very basic. I underestimated the time needed to come up with something fun and engaging. I think the basic game mechanics and elements would allow for a pretty decent game. 80 minutes are simply not enough to explore the full potential of the game. Spent more time on this item the next time!
• The game is controlled by w,a,s,d and e. It was my goal to keep the controls as simple and intuitive as possible. To bad i forgot to add an option to “unfix” the cube. At the moment it will stay fixed for 5 seconds which can disturb the overall flow quite heavily. I didn’t think of letting the user press e when the cube is fixed so it starts following again. Oh well

Conclusion

I haven’t written a single “real” game in over a year. The three games i wrote for the book felt a lot like work due to the time pressure, so i don’t count them. Hacking away on libgdx, while game development focues, is not the same either. I nearly forgot how enjoyable game development can be. So, thanks Ludum Dare you reminded me why i do this

My Ludum Dare 20 Entry

Source Code

Playthrough (Warning, Spoilers. Or so…)

Wrote a short post mortem on my project at my blog, you can read it from http://www.oletus.fi/content/ludum-dare-20-lasers-are-dangerous . Overall, I’m quite happy how the game turned out, though I ran into a few bumps along the way too.

I’ll probably get around to rating other people’s games tomorrow or day after tomorrow – already played a few on the weekend, and there seem to be plenty of fun ideas around at least.

Since I think the game might be too tricky for many, here’s the full game (along with a snazzy timelapse):

I finished editing together my timelapse video. Its on youtube here:

I didn’t leave it running overnight, so there’s a jump halfway through between day 1 and day 2. I’ll write a postmortem tomorrow.

Originally Atomic Pinball was a platformer. It was actually quite interesting, as it had an unusual character (an atom) with some decent movement mechanics and unconventional obstacles. Unfortunately, one of those obstacles specifically worked very badly.

Observe this random platformer (or something) image from the media library:

As you can see, to get anywhere the player must move through air. Unfortunately, when you are a hydrogen molecule, each oxygen molecule is 16 times heavier than you and if given energy may also cause you to explode. In the platformer, you never really got to wherever it was you wanted to go before some giant bloody wrecking ball knocked you right back to where you started. More thought is needed to turn this from an awfully inconvenient issue to a fun game mechanic.

I’ve uploaded mac and linux versions of my game now, as well as the submitted windows version. They’re the same code just with different launchers for easier running.

LD20 Entry here.

Even without Pedestrians, I might have implemented one of the items on the list since I wanted to change the behavior of package passing.

Now when a package is being shoved down a chain, the last courier in the chain receives the package. Technically, the only entities that would break the chain are the VIP and the Enemy Agents, so it should work once Pedestrians are in. I won’t scratch it off my list, however, until I code up some Pedestrian entities and test it out.

I’m getting concerned that my game world is too big. As I playtest, I realize that I’ve never made it all the way across to the VIP before the agents intercept my couriers, and it’s kind of tedious to click click click to get there. If Pedestrians make it take even longer to get to the VIP, I might need to shrink the plaza to avoid player tedium and RSI.

What’s left:
- moving the agents towards the package holder
- win condition check
- lose condition check
- allow multiple couriers to move during move phase
- shove passes through chain of couriers to last courier instead of next one
- shoving package through pedestrians
- adding pedestrians
- moving pedestrians

5 hours left to go. Who wants to go for a stroll through the plaza?

Wurrums.

Play here: http://www.ludumdare.com/compo/ludum-dare-20/?action=preview&uid=1884

You may notice a similarity to the game “Worms”. The difference is that you can also add land, as opposed to just blowing it up.

I just had to make a version of this game with character sprites and music, so while the competition version is still sitting there on my site for the voters to play, here is a newer version for the jam that I put up on Kongregate:

Waterfall Rescue

I’ve got a working bundle for Mac (64-bit), and builds for win32 and linux up now. In addition, there’s a source pkg with a standalone cmake file which should build easily on all platforms if you want to compile it yourself.

The goal is to protect your sun from invading enemies by firing missiles and building turrets. The enemies come in waves and shoot at you or your sun, whichever is closest and in range. Survive as many waves as you can until you get bored.

The item you get because it’s too dangerous to go alone is a shield that is active while you hold down space bar. It loses energy while in use and even more if it gets hit by enemy fire but it slowly recharges while not in use.

And today after work I made a gameplay video.

<?php wp_oembed_add_provider( '#http://(www\.)?youtube.com/watch.*#i', 'http://www.youtube.com/oembed', true ); ?>

The game can be played here. Now I’m going to play some of the other entries.

Made title screen on Flash cuz it was faster and looked better than Photoshop

Timelapse

Download and play it here!

LD 20 was really fun. I used half the work hours than last time, so everything was more relaxing and I could work on some better graphics and other stuff.
If there’s something I learned from past LDs (aka LD 19) is that you should not spend too much time working on some engine that is not important to your game. Last time I spent hours and hours just to implement a simple shadow system, while the main focus of the game, a battle system, was postponed for the second day.
This time I set my goal and by the first hours I already had a running engine and was ready to start making some graphics and levels.

My friends helped with testing /o/

I don’t know where the idea to make a puzzle came from, I don’t usually make puzzles. Actually the last one I tryed to make was a big failure (days and days to make an engine that was buggy and unstable)
But I’ve probably learned something from that, and this time I worked on a simple system that was fun at the end. Also the built-in physics system from Construct helped a little when making the pieces fall ^^

Level design was simple

What went wrong:
This was the first time I used the built-in transitions on Construct. And I must say, they are buggy. Next time I create my own transitions
Music was also a big fail. Next time I look up for some free music on the webz

What went wright:
My game is not a zelda clone \o/
Work was not overwhelming and I got to have some good resting time

What I’ve learned:
Use some time to think about what you gonna do and stick to that. It’s not worth to start working on something right away just to find out your idea is too complicated.
Don’t waste time working on small things, the main game engine is what matters the most!

Clean work screen on construct

Moving multiple couriers was a little tricky, but it was mainly because I didn’t realize what exactly I was supposed to be checking in my code.

I originally created a mapping of Courier pointers to bool values to represent whether a courier has been moved already.

std::map<Courier *, bool> m_couriersHaveMoved;

At the beginning of the Move phase, all of the values are set to false. When you select and move a Courier, its value is changed to true to indicate that it has already been moved. This way, during the Move phase, I can highlight only the active Couriers and prevent inactive Couriers from being clickable. As Couriers are moved, they become inactive and ineligible for later selection during this Move phase, and when it is time to move the Couriers again, they are reset to being active. Great!

The problem came when I tried to abuse those values to check if the move phase was completed.

It made sense at first. The Move phase is over when you have moved all of your Couriers. Checking if the Move phase is over was as simple as checking if any of the existing couriers had an associated false value in m_couriersHaveMoved.

Except there was a problem. If a courier COULD be moved but can’t due to the fact that all adjacent tiles are occupied, the Move phase would wait for you to click on a Courier, but none are selectable, so you wait forever, or at least until you pause the game and click “Return to Menu” to start over or quit in frustration.

So I tried to make sure that blocked couriers were considered finished with their move. Unfortunately, this had the side effect that if a courier is blocked at some point during the Move phase, it can’t be selected and moved later even if an adjacent tile opens up. Well, that’s unintuitive for the player!

Eventually I realized that I was trying to use the wrong solution to the problem. The actual problem I’m trying to solve is knowing when the Move phase is completed. The solution has nothing to do with whether or not all of the couriers have made their moves. The solution is to check whether or not there are any tiles adjacent to ACTIVE couriers that are empty.

So now I have the ability to move multiple Couriers in the same Move phase, and I solved the new application-hanging problems that cropped up involving the difference between an inactive Courier and an active Courier that just happens to be unable to move at this time.

What’s left:
- moving the agents towards the package holder
- win condition check
- lose condition check
- allow multiple couriers to move during move phase
- adding pedestrians
- moving pedestrians
- shoving package through pedestrians

Shoving is broken. It has been broken, but it wasn’t until I was able to use it more often that I can see what’s wrong.

Basically, shoving works fine if you shove a single Entity into the next empty square. There’s a potential bug when you shove entities into other entities. If an entity later down the chain can’t be shoved, it won’t be. But the entities earlier in the chain are still shoved, so it looks like one of the entities eats the other.

I need to do a complete chain check first before a shove is allowed. If the check says it is not possible, whether due to the existence of an unshoveable entity or the border of the game world, then no shove happens. If the check says it is possible, then the recursive shoving algorithm can go forward without a hitch.

Also, since shoving is how the package is passed off, I’d like the package to also shove through to the end of the chain if it is possible. Right now, it only passes to the first entity being shoved.

So with 7.5 hours left to go, I’m fixing shove mechanics before adding Pedestrians to make the game more interesting. After that, I suppose I would have time for sound effects and polish, but I hope to submit this game to the Jam long before the deadline so I can get back to actual work. Besides, it is Monday, and “Chuck” is on tonight.

Asteroid Explorer by McFunkypants

A Molehill tech demo programmed in 48 hours for the LD48 game jam.

Featuring high-poly Flash 3d hardware acceleration, .obj file parsing, heightmap terrain generation, terrain “splatting” multi-texturing, cube-mapped skybox, mp3 engine sound with pitch-shifting, rigid-body car physics simulation, flash sprite 2d overlays, and Molehill (AGAL) vertex and fragment programs.

This game requires Flash 11 or the incubator beta version which can be downloaded here:
http://labs.adobe.com/downloads/flashplatformruntimes_incubator.html

Please visit my blog: www.mcfunkypants.com for more games, music, art and code.

I warmly invite you to follow @McFunkypants on twitter (I *only* tweet about game development)

Play the game here:
http://www.mcfunkypants.com/LD20/

I would LOVE your comments and feedback:
http://www.ludumdare.com/compo/ludum-dare-20/?action=rate&uid=2297

Final Version: