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

Tags: 7Soul, postmortem, timelapse

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.

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.

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.

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

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

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

Tags: timelapse

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.

Here’s a video of my desktop through almost 72 hours of development of Hot Potato compressed into less than 2.5 minutes:

Tags: timelapse

Watch it on youtube:

>>The World Above – Timelapse<<

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

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! #gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */ oh noes, a barrier :/ ahh…refreshing. omg ruuuuun!!
ta-daah \o :]

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/

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

Ludum Dare 20 was my first. You never forget your first I’m told.

I didn’t get around to posting on my progress during the competition so I thought a quick post mortem to make up for it. At the end of the competition I was pretty upset about how the final hours went, but having slept on it and after getting some good feedback I’m now really glad I did it and with the end result.

Along with the post mortem, I’m thinking of doing a discussion of the game development (How I did feature X, Why I did it that way, Problems found along the way). If people are interested in that let me know, or it will probably just stay on my TODO: list.

Also, If you’ve not played my entry yet, go play it please, its here http://www.ludumdare.com/compo/ludum-dare-20/?action=preview&uid=3842

What Went Well

Tiled:

Tiled is a free 2D level editor that someone pointed out to me some time back. I had never used it before the competition but it looked good. It turned out to be brilliant, its very quick to knock a up level with. Its object system was essental to my game and the ability to add any kind of property to an object allowed me to do some really cool things (but these never made it into the final submission more on that later). It save format is xml which is well laid out and simple to parse. It also handles tile sets very well. If I was to do another 2D game (professional or hobby) tiled would be the first tool I’d download.

GIMP and Graphics Tablet:

Despite being employed as a professional programmer, I did once do an A-level in art. However, I’ve never got along with computer art tools. That changed over the competition. The art work I thought would take the longest to make, but after 30 mins of using GIMP I was flying  and knocking out textures. I’m really happy with a couple of the assets I made. The angry ball makes me smile every time I see it. I enjoyed using my new tablet so much I’m tempted to use drawing to relax.

C++:

I’ve seen some people posting something along the lines of “going old school and using C++”. While I agree that C++ is a pain to work with (a lot of the time)  its the language I work with every day. I was tempted to use a newer language like Python but in hindsight I think I may have stumbled on the language details. In C++, when something goes wrong its rare that I have no idea about the cause. In the end I had very few bugs during development of the game and I think this comes from knowing the pitfalls before hand (Sadly, with C++ there are lots!)

What Went Wrong/Didn’t Work:

DirectX:

As I started from scratch, I had a choice between Direct3D or OpenGL. I, somewhat, regret using Direct3D for two reasons. 1) Can’t easily port the game to other OS’s 2) Direct3D is a ball ache to get up and running. The amount of set up needed to get a triangle on screen is a lot. This is not always a bad thing, but for a 48 hour game making competition it wasn’t a wise choice. Maybe for the next Ludum Dare I should find an alternative (SDL? XNA? Unity?)

Didn’t Focus On Sound:

If you didn’t notice, there’s only one sound in my game. I wrote the code to play sound, it worked and I had a tool to generate sound in a couple of clicks. But I was stupid and left it to the very last moment to do and as an end result the game is lacking some character. I think the lesson here is to make an effort to get most sound in as place holder within the first 24 hours. Once its in it should be easy to swap out old sounds for new ones.

Wasted Time On Feature I Threw Away:

I said before that Tiled rules. It very powerful and in the 48 hours I created a basic system that could link physics objects to others via physics joints. These in turn would link to switches in the level. The idea behind it all was to have things like sea-saw puzzles or joints that could be broken to create domino effects i.e. a switch in level would set off a chain reaction in the physics that opened another door. However, the idea was just too big for the time frame and 7 hours from the deadline I had to drop it all. That was time spent I could have spent on sound :-(. Lesson: Don’t think too big(?)

Product
Overall, I think my product was very good for a first try. While it might not have been polished, it was fairly fun. I was quite critical of myself throughout the entire process – looking at everyone else’s blogs, I noted how much better their graphics were than mine, but I didn’t think quite long enough about that to realize that that didn’t tell me anything about gameplay. I doubt I’ve created a winner, but I think, at the least, I’ve been able to bring a little joy to the people who play my game, which is a good first step. Certainly, it was very gratifying to receive the first few comments, at which point, I knew I’d done something far better than my own views on it (maybe it’s less fun when you’ve played it for hours on end, trying to debug it). The Ludum Dare is certainly more difficult to complete than one would imagine, and it was pretty much intense coding for 48 hours even to get what I got.

Process: Write Once, Debug Forever
On Friday, at 10:00 EST, the theme was announced. Bet you didn’t see that coming. I thought of ideas for about 30 minutes, and then I generated a list of ideas that I had thought of. Really, my two favorites were having the item be duct tape (because who doesn’t love duct tape?) or acid. At the time, I envisioned both being played on a world made of lines (this thought proved to be perhaps the worst thought I had in the entire contest), so the technical challenges of each were very similar. However, I assumed that duct tape would be a fairly popular idea, since if you ask anyone sensible what the single most useful item to have is, they would say duct tape. Also, I think that the acid idea had more potential, although I wasn’t sure.
I spent from then until midnight working on getting circle-line intersections done well. I probably used a bit more wolfram alpha than was necessary, because solving for x in x^2 + (mx+b)^2 = r^2 is not the hardest thing in the world. I also failed to realize that that equation existed originally, and tried using trigonometry to get the answer, to no avail. Looking back, though, I definitely could have done it with trig, so that was a bit of time wasted. I think I also created my character sprites that day. You can really tell that they took me more than 10 seconds to complete.
The next day I worked almost entirely on getting the movement system working. As a programmer, this actually turned out to be my first encounter with numerical stability (or lack thereof). Since everything had to be working on a line, all x-velocities had to be multiplied by m to get the y-velocity, and all y-velocities had to be divided by m to get the x-velocity, and there was some sort of weighting that had to happen so that gravity on a nearly flat line wouldn’t accelerate you 1 m/s downwards, and 100000 m/s to the right. Dividing by m proved to be very troublesome, because it sometimes caused massive numbers to result, and that wasn’t good. I still have such a step in my current implementation, but I also have special cases for everything that could go wrong (almost everything). Once I had finally gotten that working, I had to write the collision code. The code’s algorithm was basically to make the smallest move possible (which would mean that if you crashed into the bottom of a line, you didn’t come out on top – which was a bug that I had frequently very early on) that didn’t upset any other constraints (specifically, it rechecked every other collision box each time a collision moved you, and it made sure that if you were already on a line, and weren’t transferring to the new line, it kept you on the line). This was surprisingly difficult, although I eventually got it with some more math. I also added all the graphics and UI that were used in the game, excluding the title screen & introduction cinematic.
As is evident from the blog, this code DID NOT WORK. It worked sometimes. Not much though. I spent so much time debugging it – it’s a miracle I was using Xcode instead of Code::Blocks, because I really needed a good interface to the debugger. I deleted the code that handled moving around lines twice, and the code that checked collisions once. While it might not seem too bad, each line of code you delete is time wasted. It becomes the LD47, then LD46, and pretty soon, you’re out of time to kill. Also, I had difficulty with OpenGL & SFML, because I couldn’t figure out how to make a texture that had transparent places in it.
The next day, I worked on MORE debugging (let’s face it: the movement code was full of murderous bugs), and added the red line feature. I think that this was a very good decision, because it made the game interesting. It gave the game an obstacle – time. If you don’t destroy the floor quickly, the red stuff will fall, and you’ll die and fail. I also created my level creation tool, which I didn’t release because it’s buggy and unintuitive. I also implemented the system that let me show pictures before a level started (e.g. the instructions presented to you before the first two levels) and let you go to the next level. Most of the day was spent debugging, and I ironed out about 3 major bugs in the movement system (ARGHHHH!!!), and created the system for the title screen & introduction cinematic (which makes it relevant to the contest! XD). Those went without any trouble. I created all 5 levels that day as well. I compiled it on my Windows machine that day as well, and submitted it.

Good Things (Do More of These)

• I stayed motivated throughout the 48 hours. Often I hit an obstacle that seemed insurmountable (See: Movement), and thought about giving up, but I could never put down my computer for more than a minute before I thought to myself, How awesome would it be to succeed on my first Ludum Dare? (Answer: Really awesome)
• Even though I am a very algorithmic programmer, I gave a lot of thought to graphics and audio. Of course, thought doesn’t make it happen, but if I were making a game with a bigger time constraint, they would have gotten done.
• My code was moderately neat! I didn’t really get to use the OOP I love so much beyond having it as syntax sugar (storing two variables, xPos & yPos is uglier than storing 1 variable, pos with pos.x & pos.y), but I got my code roughly organized in a tree, with no cyclic dependencies.
• Stayed focused. It’s so tempting to try being on a forum, twitter, and what have you, while still coding. During these 48 hours, I was either programming, creating content, eating, playing soccer, sleeping, or blogging about programming (okay, I tweeted about blogging about programming a few times as well). I programmed for long stretches of time with no interruptions, and never was doing more than one thing.
• I created a game. Rather than taking my good ideas, and arduously journeying 90% of the way up a mountain, being confronted by an obstacle, and dumping them into a pit of doom, I took a decent idea, and reached the summit.

Bad Things (Do Less of These)

• I chose to use a complex system instead of a simple one. While I could have used a system based on blocks to create my worlds, I chose to use a system based on lines instead. I use the word “chose” lightly, though. I didn’t realize that I could use the simpler system, because it never occurred to me. I need to think more next time.
• I screwed up my timelapse. Yes, it takes a special kind of idiot to do that. Idiot, thy name is Milo Brandt! Oh well.
• I had no audio. This was mostly a time constraint, considering that I was coding up until the moment that I had to stop.
• My graphics were slightly ugly. This probably was also mostly a time constraint issue, but it also stems from my relative unfamiliarity with OpenGL. My relationship with OpenGL is… complicated. I keep dumping it, only to realize that I love it, and to come crawling back.

The Future
Certainly, I stole a lot of experience from the Ludum Dare, as discussed above, but I think that I generated some very interesting concepts during the contest that might be worth pursuing in the future. While the acid idea would probably, at most, yield me a pretty cool flash game (if I ever bothered getting good with flash), I think that the duct tape idea could create a very interesting game, and could also be extended to be a 3D puzzle game, like Portal. While I definitely have ideas I want to pursue more at the moment, I would certainly be interested to see how such a game would turn out. Also, I look forwards to future Ludum Dares! Bring it on!

You play a leather-clad woman who has to survive, alone, against hordes of dangerous kittens.  Luckily, she has an assault rifle.

I’m quite pleased with it!  It’s crazy looking.  You can’t see it from the screen-shot so well, but it has fog-of-war, which I compute with ray-tracing.  That really enhances the fear!

The kittens have little bum-holes too!

It’s written in plain C.  Was good fun to write.  The most C I’ve ever written in 72 hours, for sure!

I’ve only tested it on Windows 7 and Gentoo Linux.  It runs okay for me!  I’d love if people would try it, if you find bugs let me know

I’m going to get some sleep, and then later play a bunch of Ludum Dare games.  Woohoo!

Windows .zip

Source code

Check out the entry here

Forgot to make game / had an AP. Will try next time.

This was my first Ludum Dare competition and I managed to make a submission. I’m really looking forward to taking part again next time.

I can’t say I’m proud of the fun factor/end user experience in my game. In retrospect, I should have spent a bit more time on front facing features (making the world scrollable to enlarge the game world, more varied artwork, sounds). But in hindsight, I’m extremely happy that I was able to get an RPG prototype running in 48 hours.

My submission for LD20 can be found here.

What Went Well

• Python and Pygame was an amazing choice. It’s great for rapid prototyping and shines in LD. But be warned, vanilla pygame doesn’t have menu support.

  My code should be multi-platform as well, which is an added bonus and gave me more time to think about the game ahead of me. I never would have made it this far this quickly using C/C++.

• I took breaks and got away from the computer. While away I would think about the progress made in the game and try to think of features or solutions to problems I encountered. In a few cases I found some good solutions, but I also brainstormed ideas on other areas of the game.
• Test Driven Development: I’d write some code and fire up the game to try it out. I would often start with a class skeleton that would balloon as I added features to it. Often I would start from scratch or extend from an existing class, but on a few occasions I found good opportunities for refactoring. As a smaller project I could stay on top of a lot of the test cases and quickly go through them as I worked on a feature.
• Platform testing. When I compiled the game using Py2Exe I set aside some time to test on a freshly formatted WinXP virtual machine. This is where I discovered Py2Exe depends on Visual C++ 2008 runtimes and I was able to include this in the readme.

  Testing also revealed issues with Py2Exe and buttons in WinXP, and the confirmation that my code worked with Python 2.6 and the official version of pygame (as pygame for 2.7 isn’t available on the main site yet). I didn’t spend much time looking into the issues once I found out the game runs fine when running from source due to lack of time.

• Artwork. Going into the competition, I remembered I was going to have to make my own artwork. I am no artist and my initial posts show the programmer art I came up with. I spent a few hours on Sunday learning how to draw character sprites and managed to create something that was quite presentable.
• Motivation/Attitude. Participating in LD made me forget about pessimism when it came to brainstorming feature work. This made me very productive and kept me motivated throughout the competition. Hopefully I can keep this mentality in mind going forward.

What Could Be Improved

• Gameplay. I had a great idea to tie in the theme with no time to implement the features to support it. As a result I more or less threw the game onto the existing features in the final hours and I think it’s fairly noticeable. Ideally I wanted the player to travel through the world with a mix of enemies, without being able to identity friend from foe when it came to people NPC’s (this would be the tie in to the theme). But without a larger map and non-human enemies this concept is missed.
• Linux: I have a linux VM but I didn’t get a chance to confirm my game worked on it, perhaps after this post.
• Game type: Turn based RPG might be a bit too ambitious for a solo competition, especially when you include graphics and sound. An action RPG may have been a better choice.
• Sound: Sound was also thrown together in the final hours and I’ve never really worked with it before. I also delay button clicks in the battle screen until sounds stop playing. This delay makes the game feel like it’s lagging if the player clicks through menus quickly.
• Combat formulas: Prototyping this at 2 or 3am for an hour in Excel is rushing it a little bit
• NPC speech: Again, something I should have looked at sooner rather than the end.

Well, that’s that. Try out my game and let me know what you like/don’t like. It can be difficult to get third-party feedback outside of competitions like Ludum Dare.