From a comment on bashplore’s page:
“dertom says … Hehe,…a game in bash. That is really hardcore ”.
YYYYYYYEEEEEEESSSSSSSSS It is, but it adds a lot more fun!

What went right:

- bash it’s good, i like its feeling
- bash can do stuff for you
- save/load it’s super-easy
- bash teach you tricks, a lot of tricks! :p
- bash is great for roguelike
- bash give you sound for free!!! [got no time to add some, sorry]

What went wrong:

- bash rendering it’s slow
- bash doesn’t have data structure
- bash syntax it’s a pain
- bash it’s a iper-pain for non-roguelike game
- I was not so good at bash to write a game

Final thought:

- if you want to use bash for a roguelike game, that’s fine but you have to prepare some good utility function BEFORE the 48H.
- if you want to make games other than roguelike, then DON’T USE BASH, NEVER THOUGHT ABOUT BASH!!!!
- if you want to have a great fun makeing a game, just use the strangest programming/scripting language, that’s worth the effort.
- never forget to add graphics using color in the terminal
What next time?

I’ve already some very very sick yet fun idea in mind and i’m already coding something. Keep an eye on samel’s perversion 8)
c-ya next time!

Topsy Turvy post-mortem

What went right:

* The concept. I’ve had the idea in my head for a while, and I’m very glad that I used the competition as an excuse to make it rather than forcing myself to think of a game idea inspired by the theme. And the game ended up pretty much how I imagined, so that’s good too.
* Inkscape as level editor. AS3 has some rather lovely XML-parsing abilities, so reading the SVG file was surprisingly simple. It’s very much hard-coded to the specific output that (my copy of?) Inkscape generates, but it should be fairly easy to fix if it ever stops working.
* Abstract graphics. I am not an artist, so I decided to save time and just draw everything out of lines. I think the results fit the game fairly well, even if they’re not actually good.

What went wrong:

* The goal. I added the collectables to provide an incentive to get to the more difficult areas and also as extra landmarks for getting your bearings. Unfortunately, with time running out and no win conditions implemented, I made the decision that you would win if you could collect all of them. In hindsight, I should probably have added a level exit instead.
* Difficulty. The game is ridiculously hard. I knew I wanted to have some areas which would be tricky to get to, as a challenge, but when the goal became “collect everything”, those areas suddenly became non-optional.
* First day motivation. I wanted to have all the basic game mechanics done by the halfway point, but I was just procrastinating like crazy. I’d come to the conclusion that it just wasn’t technically interesting enough to hold my attention, but then on Sunday morning I added death and respawning. Suddenly my game idea was in front of me and I could start constructing devious routes through the level, and I spent the rest of the day excited by it.
* The name. It actually changed name twice between starting and submitting, and I’m still not really happy. Currently thinking about maybe renaming it “Jump-Zap-Flip”.

Lessons learnt:

* Get death/respawn implemented earlier in future
* Think of a win condition as part of the design process
* Don’t make ridiculously hard challenges required to complete the game

What went well:

• Obviously I got good game idea
• Physics turned out well
• Game mechanic was fun
• Interface turned out to be simple, not buggy, etc. For 12h spent it is weird

What well wrong:

• Failed to make more complex graphics because most I tried made it lag fast
• Made mistake of making game time constrained. Should have been some ind of resource constrained. Thing is that most fun is aiming probe well and exploring planet or even few in one show. Time constraint rather made you shot a lot of average shots instead of aiming really carefully which is bad.
• Probably 1/3 of time spend was spent on things that did not work… Would have been good to spend it more on polishing core mechanics and game aims.
• I added only a mouse-wheel based zoom. That was a mistake as Mac users have problems in Flash with that (tough I head Flash player release on 9 December 2009 should have fixed that, can’t confirm)  Also users playing on notebook without mouse had problems too…

What now:

• Well firstly I think I will make one more version of it removing time limit and adding some “probes per planet” limit. Should make it more fun. May be I will try adding a little bit more graphical things.
• As for large game based on idea I think I will but it on hold. Needs a lot of content and thinkering on technical sides of it(there are some). Exploring idea for enemies and war, AI, etc. I have some other game ideas that have less of such complications so for time being I will not make it in to a full game. In time being I welcome anyone to try and make their versions of the idea Just bother to send me a note/mail. Would like to see it  and play it
• Need to add alternative to mouse zooming.

Longer version of how it went

Day 1.  Well woke up and read the theme. Started brainstorming for ideas and (more…)

LD16 was a lot of fun, despite continually running into killer bugs that took ages to fix.

What went well:

• I managed to pull it all together in the last couple of hours and actually end-up with a game. I very nearly didn’t.
• People seem to like it, too! Didn’t expect that one.
• After releasing, I managed to locate and destroy one last memory leak. Otherwise it would have been unplayable.

What went badly:

• The aforementioned bugs.I probably spent at least a third of the time I was working on the game trying to fix memory leaks, infinite loops, and the like. These were often related to…
• I didn’t prepare. DESPITE knowing very well that I needed to get a basic framework, in the end I was just too lazy, and started the compo even without most of the libraries I needed.
• I didn’t spend enough time at the start thinking about what my game would be. Instead, I charged ahead with a turn- and tile-based engine, assuming I’d think of something later. Fortunately I did, and the idea was reasonably fun.

What I would improve:

• There are still a couple of glitches – one is that sometimes monsters manage to get on the same tile as you and you can’t attack them – not sure why.
• The view is too small. This is mostly so I could avoid trying to do any ray-casting and what-have-you. Though since I let you see monsters for an extra tile away, you can still see through walls. Whoops.
• You automatically climb down ladders, which isn’t ideal. In fact, I think I accidentally left it so that you’ll go down a ladder if you attack a monster which is standing on it. I ran out of time, and it was easier to code like this. Sorry!
• I had ideas for more things you could ‘explore’ and earn XP from – such as each time you come across a new animal or plant. But I never got time for it.
• The difficulty increase is really naff. Or at least, what’s meant to increase the difficulty – each time you go down a level, the monsters get +1 to attack, defence, and hp. But each time you level up, which can occur 2 or 3 times per level, you get +2 max hp, are fully healed, and your attack and defence increase by 1. So it’s very, very easy to quickly outpace the monsters. I didn’t take the time to balance it, as it was about 1:30 am by then, so yeah.

Final notes:

• I do have some ideas for expanding it, and I hope I actually get around to doing so this time. I think I will do, as I’ve wanted to make a roguelike for a long while, and after I lost all the code to my other one (Nooooooo!) this is a good opportunity to get back into it.
• Hanging out in #ludumdare made the whole thing a lot more fun, even when it seemed I would end the competition with only a mediocre level-generator.

This was my first Ludum Dare, but have been following the competition for the last couple years if not longer.  I did not manage to finish my entry in time, but did really enjoy the process.  Having family time at the weekend is very important to me, so my coding time was limited to around 5-6 hours over 2 days.

Time lapse:http://www.youtube.com/watch?v=KeIedoXsfIQ

Game play: http://www.youtube.com/watch?v=ALXlAzhhi30

Download Game: http://blog.codheadz.com/file.axd?file=2009%2f12%2fJungleExplorer.zip

Download Source: http://blog.codheadz.com/file.axd?file=2009%2f12%2fLDExplo.zip

To run this you will need either the XNA studio 3.1 or the XNA redist from the link below:

http://www.microsoft.com/downloads/details.aspx?FamilyID=53867A2A-E249-4560-8011-98EB3E799EF2&displaylang=en 

What did not go so well

• Did not finish the game to a level ready to submit before the deadline
• No sound
• No prepared engine, other than XNA
• Lack of time
• Giving up with an hour to go, when so close

What went well

• Keeping the concept as simple as possible to give me a hope during the very short amount of time available
• Coding with high velocity freed from my usual constraints of IOC and unit testing
• Ignoring my ball of mud engine and coding from nothing
• Getting 90% of it done

Here’s looking forward to the next one.

View my Timelapse.

What went well:

• Finished a game!
• Learned Lua and LÖVE inside and out.
• Made some decent (by my standards) looking pixel graphics.

What could have gone better:

• Had to scrap most of my planned stuff in order to finish on time. Originally Missing was going to be a survival game with a lot of roguelike elements.
• Spent way too much time making a procedural maze generator, which didn’t end up being important to the final product.
• Didn’t have enough time to add gameplay, ended up adapting the planned food/water element of exploration into a collection game.

The Good
- This is the first time I’ve been using OpenGL and SDL for something that is more than just a techdemo and I have to say the transition from plain SDL to SDL + OpenGL went quite smoothly
- The core gameplay elements made it into the game
- This is the first time I’ve been using Lua for scripting in a game. I wanted to use Lua more extensively, but it’s just a small part now, still I’m quite pleased with that element and how that went without any problems along the way
- Graphics and music are mostly how I imagined it, I also made some sounds with SFXR, but those didn’t make in the final game
- Basic AI: That’s really awesome, it was implemented like 30 minutes before deadline and it’s great that it works

The Bad
- I almost slept 24 hours of the time (my alarm was not working) and was too tired from staying up so late to get up early
- There was generelly a lack of time, for example, there were some things to be done for college and I discovered Mass Effect, which was a really bad idea to double-click the Mass Effect icon, it was time-consuming and took a lot of will power to exit the game and get back to coding
- I almost went with Unity instead of my own framework and the decision took a few hours
- There were some issues with my camera, that’s why there aren’t any deskphotos or foodphotos from me
- Since I’ve been using SDL + OpenGL for the first time for a real game that has actually been finished, some parts of my framework are still in its infancy (espacially the texture loader routines), that’s why there are some problems with washed-out textures and memory leaks

I’ve uploaded the linux port and there’s now a gameplay video on youtube. The timelapse video is coming, don’t worry.

Now I’m looking forward to try everyone’s entries.

Wikiventure went far better than I was expecting. Mainly because I wasn’t expecting anything remotely interesting. I’m still working on it, in fact, adding new things – just today I added user-input via a text-box and tags which react to that input, and score and cash variables that can be checked and modified. I’m really enjoying it, and plan to add a basic battle system like in proper game books.

What went well

• The basic game, taking pages from the wiki and letting you travel between them, was very quick and easy to set-up. Then it was just a case of feature-creep for the rest of the weekend, which was perfect for me!
• People took an interest and wrote some content for me!

What went badly

• Spent rather a long time at the start battling with C++ libraries before moving to PHP. Though that did help me come-up with an idea.
• Also spent rather a long time at the end trying to fix an infinite loop, but managed to do so before the deadline, so no real bad points.

What I would do differently

• Plan-out code structure before writing it. I spent quite a while on the Sunday rewriting all the tag-parsers to remove a lot of repeated code. There’s still a lot now.
• Put time into writing content! I only actually created two areas, as a test right at the start before I’d added any tags, and then I kind-of expected people to write my content for me. Which some people did, but it was horribly lazy of me.

Things I’d like to add

• Cookies or some other way of keeping things persistent between sessions. Could tie it to user-accounts on my site.
• Combat system, mentioned already.
• More levels of persistence than ‘IFVISITED’ and ‘IFNVISITED’, so that the player wouldn’t necessarily have to follow the same set of actions multiple times.
• Any other stuff I happen to think-up.
• Content!1!1!!1!!!

So yeah, it went pretty well. I’ll keep working on it and maybe it’ll become something really interesting.

This was probably the best Ludum Dare weekend I’ve had.  My game was more than just a tech demo or an ‘unfinished’ idea.  Of course, they never are truly complete after 48 hours time; there is always something else that can be tweaked or added.  When all was said and done, however, my entry was a playable game.

Background

The theme was not one that I had put much thought into before it was announced so I really had zero ideas at Go time.  One thing that kept popping into my head was the Kroz series of games by Apogee software back in the late 80’s/early 90’s.  They’re all pretty much the same engine with a new collection of levels, but one was called Caverns of Kroz.  The object of the game is to take your hero through twenty or thirty levels to find or capture some relic.  Along the way you had to run, whip or out-maneuver swarms of monsters and solve puzzles.  I had always thought those games were neat, and it would be interesting to try and ‘recreate’ some of that nostaliga.  Caverns of Kroz didn’t have anything special that made it more caverny than the rest in the series, but I thought I could do better with actual graphics instead of ASCII art.

Graphics

One of the first things I do in a LD is grab a piece of printer paper and start sketching some objects.  More is better, even if I think I may not use them.  For LSC, I sketched a few doodles and scanned them in.  The designs were done in homage of the original ASCII characters and colors.  For example, my monsters look remiscent of the Ä, Ö and Ω characters.  The first problem I had to resolve was how big to make the map.  Kroz uses something like 60×24, but I don’t really like how smushed that is.  I wanted a square ratio on an 800×600 pixel window.  This led me to pick 16×16 as the tile size, which seemed small to me.   For the first couple tiles, the floor and the walls, I used 16×16 image to create them.  That went OK.  Next I took a look at my scans to turn them into tiles.  I did an overhead view of the player, basically just a head and shoulders.  I created the tile originally as a full 120×120 image with margins.  I colored him yellow and red like the Kroz hero.  I copied the merged image and pasted it into a new document that I then resized to 32×32.  Inside the drawing routines I have it again resized on the fly as 16×16.  The reason for this was that I may want to add a ‘zoom’ feature to the game in the future and it would be great if the images didn’t get pixelated.  I followed the same procedure for all the rest of the tiles.

The style of the art is not much different than the other LD entries I’ve done.  I don’t try to draw the straightest or the best.  I just draw to my ability.  Those are then scanned in and then modified in Photoshop.  Since I shrunk these down, you don’t see the imperfections as much, and maybe that’s better?  I don’t think some people ‘get’ that the imperfect art is part of my style and I think I get marked down for it sometimes.

Coding

This is the fourth time I’m using the same general base code for my LD entry.  I think it shows because I have a hang of it’s abilities and limitations and I can get what I need to get done faster and more efficiently.  Also, each LD I add more basic functionality to it so I don’t have to reinvent the wheel each time, as they say.  Additions this time are an unfinished menu system and a tile/map data structure.

Most everything that I coded worked fairly soon thereafter, even the changes that take 30 minutes in between builds.  I think I had only two major problems: monsters moving over walls and monsters not dying when they move onto the player.  The first problem was because I couldn’t figure out why my collision detection logic was failing for monsters.  And it wasn’t.  I had an errant semicolon tagging along the end of an if statement.  My logic was fine and the if was completing an empty statement.  Then the next line moved the monster anyway.  The second problem was weird in that the monsters would sometimes die when they moved into the player, but not always.  A majority of that problem was due to how I keep track of the monsters.  I have two references for them.  One is in a two dimentional array similar to the tile map.  Either the cell has a link to a monster, or it’s null.  The second reference is in a linked list.  The grid is used for monster-monster collision detection since I only have to check the cell next to the monster for another monster.   The linked list is used when I have to traverse each monster object and is faster than checking every cell in the grid.  It’s actually a great idea but I was trying to solve the monster-player collision problem without actually having a fully implemented monster-monster collision.  It turned out that the monsters were moving into the same spot and the second monster was overwriting the first monster’s entry in the grid.  It was weird but once I finished implementing that code the rest fell into place.

These two problems cost me about eight hours split over Saturday night and Sunday morning.  If I didn’t have those problems, then my game would have been that much more complete.

I didn’t try to do anything too fancy in my code.  I could have spent more time doing things in a more efficient way for the future, but instead I hardcoded some functions just to get it done.  For example, I have eight different functions for the different directions in many parts of the code.  Those could probably be pared down to one in each situation if I passed some variables in.  I’d also like to combine the collision detection and movement between the player and the monsters.  Maybe base them from the same Mobile class or something.

What I did Wrong

Other than those two issues that I mentioned above, there wasn’t a whole lot that I did wrong while coding.  I did have a few too many distractions over the weekend.  My folks came over on Saturday to swim (which is great because it was triple-digit weather) and have dinner so I lost a few hours there.  That by itself wasn’t a problem but when I was actually coding I had the TV on which split my attention.

I also forgot to tie the score in with anything being done by the player.  Not a big deal, since score isn’t really much in the game yet, but it should have added some points for killing monsters and grabbing gems and whips.

Apparently my sounds were a bit harsh.  I used DrPetter’s sfxr to create them, but I must have used some weird settings because they sound fine through my 5.1 speakers, but they are harsh through headphones.  I guess I’ll have to do sound through headphones next time and hope that translates through the speakers.

What I did Right

I think I was helped by trying to emulate the Kroz series of games and it wasn’t because I had a model to ‘copy’ from.  I think the key was that the limits on what I was setting out to accomplish were already fairly firm.  I didn’t have to try to build in some weird functionality for the future, since I already knew where I was ending up.  The other LD weekends started with an idea that was to be flushed out later.  The only problem is that later usually doesn’t come and I am stuck with an incomplete game or a complete ‘thing’ that isn’t fun.

What I Wanted to Do After Last Compo

I wanted to work on my basecode after LD48 #14, and I did that.  I also wanted to scale down my goals, and I think I was able to manage my goals this time around by not setting them too high.  I think it’s a win.

What’s Next?

I’d like to continue with this project and there are a few obvious things I can do.

• Make the code more efficient and easier to read
• Profiling execution.  I haven’t tested lots of monsters or animated tiles yet, but it will probably suffer from performance issues.
• Level editor
• More objects and tiles
• Better level file format
• Continue adding basic functions to the basecode

So Mortem?  This thing’s just getting started!

So! I didn’t finish my entry. I submitted it, but it wasn’t finished and I can’t help but feel a little defeated. The levels needed more design and more content, I wanted to add a jetpack (mobility enhancers are mandatory in metroid games ), 2 more guns, at least 2 more types of enemies, a boss fight, and narration. I’d have been happy to have gotten there, but looking back… I was pretty screwed.

So I’ll start with my mistakes, first:

- Not the base code I wanted: I had planned on prepping some base code beyond Flixel (perhaps even writing my own flash game engine), but didn’t get around to it. This alone isn’t a huge deal, since the starting point I had is still quite good.

- A bit lost: Not much dev experience with the sort of game I was trying to build. Coding wise, it was mostly pretty simple 2d logic, but if I had had more experience, I would’ve used (or created) a level editor and I would’ve gotten the characters up and running much faster. Not to mention I would’ve prioritized dev for gameplay features a lot better. At least I learned a lot!

- Bad planning with my time: On top of mistakenly thinking I had 2 hours longer than I really did, I wasn’t really in gear on Saturday, yet Saturday accounted for more than 1/2 of my dev time. I still got a lot done on Saturday, but I left a lot of important stuff for Sunday, stuff that would’ve allowed me to begin designing levels much sooner.

Point by point:

- Gameplay: I wasn’t trying to do anything particularly clever, just good fun sidescrolling, action/adventure gameplay. I do like what I got, but it was a shadow of what I wanted. Unfortunately the game is such that more gameplay depth requires a fair amount of new content, which is time intensive, which makes it a bad fit for LD. Still, of the stuff I did get around to adding,  I feel like I got it right.

- Art: I’m really enjoying drawing sprites, it’s not something I normally do. I love the walk animation on the guys! I might try drawing some sprites in my free time now. With some more practice, I think I could put more detail into my characters.

- Graphics, tech wise: My shadow implementation could be way better, but despite this, I was able to make it look okay. It tripped me out when I realized I was placing static lights in my levels as decoration! The fx and such were okay, but now I want to make a serious fx-oriented particle system.

-Sound!!!: This one really tore me up. I wanted to use pretty realistic sounds and couldn’t bring myself to use sfxr. That left me in a pretty bad spot, so I just gave up. Lame!

Overall? I like it. It can be played and enjoyed. But it’s clearly unfinished. It makes me want to work on it more.

And a parting thought:

I didn’t realize this at first, but looking back, I clearly approached this LD as an excuse to prototype a game – but not necessarily finish a game. Next time I’ll be seriously considering going for a smaller game design.

I’m pleased I managed to finish this. Here’s my post mortem.

I spent most of my first day wrestling with a bug in libnds associated with the way it calculates sprite addresses in VRAM. I managed to fix it, but by then I’d lost all motivation for working with the console.

That’s when I started to get a bit … creative with the theme, and really got my teeth into it (no more, I swear). I really wanted to make something that wasn’t cave-based, so I contemplated other things that might be considered cavernous, and thought of mouths.

Gameplay

Overall, the gameplay was close to my original vision. The core gameplay of shooting and healing is all there, I just would have liked to put some more extras into it, like the ability to level-up lasers. I also wanted to make it a lot more silly … but I might do that sometime post-compo.

I quite like the input scheme of mouse-look and X to walk, and C for jumping instead of the more ‘traditional’ WASD. I wanted to make the dentist walk more like a person and not a usual platform-game character – he can’t walk backwards or change direction mid-jump. Some people will hate this, but I thought it suited my theme more at the time.

Coding

I used BlitzMax for the game, which I don’t use very often. However, it was a perfect choice, given the limited time available. It has an incredible range of features built-in, and I doubt that I’d have been able to make the deadline if I’d have to write all the graphics and sound code from scratch again. (Also, SuperStrict is cool.)

Graphics

Using Illustrator for the graphics was an enormous help; I used it to mockup the design and then was able to make sprites from the different visual components. I’d definitely recommend using some sort of vector editor for quickly prototyping visual styles. The only drawback with using Illustrator was the need to manually find the origin of sprites, which was time consuming.

Sound & (lack of) Music

sfxr is really useful for deadlines. I originally wanted to put in some cheesy sounds of pain, but time prevented it. Music was a complete non-starter.

Overall

Although I probably won’t win anything, I really enjoyed my first Ludum Dare. And that’s what it’s all about!

Here’s my post mortem…

Darkening

I wasted a lot of time trying to do something which I thought would have been easy with pyGame. I was trying to draw the wall sprites darker the further away they were, to give the illusion of depth. I’d assumed it would be one function call to do this, especially as Allegro has a function to do it draw_lit_sprite (though on reflection, that’s using a colour table in 256 colour mode) but I had no such luck. Blitting a transparent black rectangle to the sprites didn’t help either, because I needed to preserve the transparent pixels of the sprite. In the end I gave up trying to darken the wall graphics but I did waste a lot of effort here.

Artwork

I chose to paint all my graphics in GIMP, which was a marked deviation from my usual comfort zone of pixel art. As such, the artwork probably took longer than it should have and looked a bit crappy to boot. That said, I do think that my tablet skills were improving over the course of the weekend. It’s certainly made me want to practice drawing more.

Text / Graphics Hybrid

My game was a strange combination of text and graphics. I wanted to do the whole eye-of-the-beholder-type first-person view thing, because I think they’re cool. But I also wanted to make the game a text adventure because I thought I would be able to inject more gameplay elements into the thing without having to generate graphical resources to accompany them. But by the end I realised that it didn’t quite work out like this. For example, I wanted to have the player looking around and finding items on the floor, text-adventure style. But I couldn’t get away with this without drawing said items to display in the graphical viewport, because otherwise there would be nothing to indicate their presence and the player would have to use the “look” command on every square or something. Maybe with a bit of tweaking I could have established a system where I could add features without having to back them up with graphics.

Text Input / Output

I was somewhat delayed due to having to roll my own text input and output in pyGame. I had to write my own word-wrapping and stuff using the character width information from the font metrics. As for input, I had to manually map key events onto the letters they should represent (hence the lack of uppercase). The more I think about it, the more I think that maybe I should have just gone with a plain old console-based text adventure and scrapped the graphical part.

Perspective

I made a bit of a goof when I was planning out the first-person view. Somehow I ended up with something whereby the graphic for the square that the player was supposed to be on ended infront of them. That is, you could see the front of the block instead of being inside it. I realised too late that possibly the row of squares at the same depth as the player were probably a special case which needed to be drawn differently and I couldn’t get away with just scaling the same graphics. As a workaround I chopped the sides off the viewport so that the graphical mistake was no longer visible.

Combat

With around 4 or 5 hours until the deadline, I decided to throw in some monsters. I drew a bat and a skeleton and threw together the worst combat system known to mankind. This was a stupid decision in retrospect – the game didn’t need it, and its presence worsens the overall game experience. I was going to have a “sleep” mechanic whereby the player could sleep to regenerate their health, and a maybe a time limit to reach the goal so that there is a downside to sleeping. Not to mention some kind of experience and levelling system. I didn’t have time for any of this, so there is actually no point in fighting the monsters – the player doesn’t gain anything from it. So what we have is some monsters that keep turning up to annoy you that you have to keep running away from. It was pretty hilarious to see a skeleton appear while talking to a dwarf, though.

Puzzles

I started hacking together the puzzles and map with around 3 hours to go. At this point I was tired and my enthusiasm was dwindling, and as a result my imagination was just plain broken. I could have done more interesting things with the puzzle system I’d put in place and I wish I’d made more time to do so.

Overall: Playable

I finished a game! Well, at least in the sense that I got something to the point where there is an attainable goal, and it provides some kind of challenge along the way. After my last 2 ludum dare entries not going anywhere and being totally unfinished, achieving something playable this time was a nice thing to accomplish, at a personal level. I think it’s restored faith in my own game-making ability. I didn’t have time for sounds or any kind of proper intro or ending. But then again, I never do! I must leave time for polish next time…

This was my first LD, and it was a lot of fun. I’ve learnt quite a lot from it I think, and I don’t think I’ve ever got so much work done on a game in such a short time-span.

I used C++ with several SDL libraries. Graphics were created in the GIMP (and Paint…), and the sounds were created in about 10 minutes using SFXR.

I did briefly consider using GameMaker instead, and at several times I thought to myself ‘All I’ve done so far I could have done in GameMaker in a couple of hours!’ but I’m glad I didn’t. It would have felt like a cop-out really. Not to say that anyone using GM was a cop-out, but I’m glad I took the challenge of using C++.

What Went Well

• I got an idea fairly quickly, and actually managed it in the time frame (I would have liked to add more stuff, but at least it is a game).
• I had a horrible, game-breaking memory-leak but managed to fix it in very little time.
• I knew my way around the GIMP enough to animate Ted using layers – I’m always very frightened of having to animate things.
• Mostly, it all works. The collision-detection between moving things and the ground is pretty random and bizarre, so you can climb walls much higher than planned. The dinosaur movement was put in in about 10 minutes at the end when I realised the game was impossibly easy. The game is hacky, but it’s pretty close to what I wanted.
• Click-to-shoot! Wow, I was pleased when that all came together. The bullet heads toward where you clicked, and always at the same speed – at first I got in a complete muddle as to how to do this, but then it was really simple. I like it. The whole ‘click, shoot, bullet hits wall, rock breaks off and falls’ thing works really well I think, and I’m pleased with it.

What Went Badly

• That collision-detection is awful. Checking collisions between the ground, which is a grid where 1 across = 1 tile; and the coordinates of everything else which are 1 across = 1 pixel, was tricky and horrible. I did it badly. When I eventually gave-in and added proper box collisions for the interactions between player, rocks and dinosaurs, it was instantly much better.
• The levels aren’t interesting. I hadn’t originally intended it to be an infinite, random tunnel, but I hadn’t originally had much idea of how it would be a game. I just knew “Shoot rocks so they fall on dinosaurs”. One, random level seemed much easier. The first area is fixed, then the rest is generated as needed, one column at a time. I tried several ways of having each column based off the previous one, but slightly altered, but they all went wrong. So I got it to generate a random number, and pick a pre-defined column from a list based on it. Less interesting, but at least I could guarantee that you could actually get through the cave.

What I Would Do Differently

• Prepare in advance and get a basic… I can’t think of the word. A basic code-base which has drawing and tiling stuff already there. I spent far more time getting that set-up and working, and repeating code that I could have used a base class for.
• Framework! That’s the word.
• Get more sleep the night before it starts. And, in fact, several nights before that! I kept making silly mistakes, like copying code and forgetting to change x to y in the copy, because I wasn’t firing on all cylinders.

Things I Didn’t Have Time For

• Graphically, the cave looks pretty horrible. I’d hoped to get time to have a tiling system based on what was around each tile: so a piece of rock hanging from the ceiling would look like a piece of rock hanging from the ceiling, and not just a square block.
• I’d also hoped to animate the dinosaurs. Just didn’t have time.
• It would have been good to actually show Ted holding a gun, with bullets coming from it. With the image flipping though, it would have taken time I didn’t have. I wanted several animations for Ted, but like the dinosaurs, it didn’t happen.
• Improved collision-detection! It’s abysmal.
• Particle effects! Another thing I’d hoped to have time for.  Would have made it look less boring, possibly.
• A proper menu. The menu in the final thing is the one I bunged in as a placeholder because I realised it would be handy to have later.
• The text-drawing function I used has an awkward quirk in that it always draws an opaque background. I got it from the internet a while back, and though I tried fiddling with it, I couldn’t make it transparent. Makes the menu look even worse.

I may well make a post-compo version with lots of these things added-in, but then again I’m incredibly lazy at this sort of thing. So maybe not. Still, I’m pleased I managed to do it, even though I’m not going to win any prizes.

~AtkinsSJ

I think that the stuff that happened behind the scenes this time were rather interesting, so I decided to write a post-mortem.

The compo began at 6:00 AM our Finnish time, and when I woke up at 11:00 AM, I instantly began to work on my (first) entry. I had had 2 ideas from which to choose from, but the theme wasnt’ really fit for either of them. Anyway, I decided to force the theme a bit and insert my frog-with-a-sticky-tongue-idea to the game. I also realized that I want to do a time lapse, so I downloaded Chronolapse and set it running.

The first few hours I spent by playing around with the physics and testing different tongue methods. A silly bug that was “hard” to notice took a bit of time, but not too much. It was harder than expected to get the frog look right, and I tried several foot and ‘arm’ sizes, ending up with quite big legs and no arms. The silly eyes were a part of the design right from the beginning. I went for a long walk with our dog Turre, took about 2 hours. And ate pizza. Smoked Salmon Pizza. yum.

After that I started pondering about the method for creating the background and walls. It was clear that I’d need several different sorts of angled walls, to make the physics interesting. After some (lots of) pondering, I ended up with using a list with the wall-creation commands, so that I could easily change the layout. After even more pondering I decided to load the background ‘art’ externally, which was the easiest but also a bit stupid way to do it. I had to code a separate editor for the levels (may sound normal, but is actually quite rare in MMF2). I wasn’t exceptionally happy with the simple look of the game, but the engine seemed to work fine.

At this point I started doing other things for a while, such as posting the food picture and reading some MSPaint Adventures. Not much has to be said about that. After getting back to work I decided to start adding other features, such as ‘enemies’ (spikes), and insects that you could eat. I really liked the effect I got to the insect-eating. but overall the score system made out of that was a bit random, considering the actual game was turning more into a puzzle (how to swing that tongue next?.exe).

When I had the basic engine ready, score system running and the game overall working, I started adding new levels. I had spent about 8 hours with the game, and started wondering why it has taken such a short time.

I didn’t feel overall that happy with the game, it was a bit too simple and random for my taste. Also, after seeing screenshots from games like Dock’s entry, I started worrying that the game wasn’t good enough. Anyway, I decided to finish the game I had started. Somewhere around 00:00 I had all the levels ready, and made a very silly ending screen. Fixing the last bugs and such took an hour more, but after that and after submitting the game, I wasn’t really happy with the game; all the others seemed much more interesting. Also, I realized that there was something wrong with MEncoder and my timelapse didn’t work! ;_; Anyway, went to sleep.

(You can find the Cavefrog download link from the bottom of this post!)

The Next Morning – The next game

I woke up at 11:00 AM, and started quite much instantly to ponder about the compo. I had had this over-ambitious idea of a settler having a mining site and exploring the underground caverns, actually even before Spelunky. Anyway, at 13 o’clock I went for a walk, during that I thought of the possibilities I have, and also my own capabilities. Seems like I was in a good mood for thinking, because after some dozens of minutes I had the main idea and item base of my ‘other’ entry ready. A rather sudden rainstorm interrupted my walk a bit, and I got really wet. It was kinda fun, actually.

I calculated that I had around 9 hours to work on the game that day, so I decided to be quick and controlled with the creation (oh yeah, that’s easy to be said). The 5 hours I worked before leaving for piano lessons were quite hectic, and I also forgot to timelapse the creation (;_;), so there isn’t much to say about that. The game progressed surprisingly well, and what’s even more unexpected, no game-breaking bugs showed up! There were some annoying phases though, getting the underground world to be created and then adding the enemies there – I had at first set the enemies appear before the actual caverns, which led to some hilarious scenes. I had chosen the graphical theme mostly because it was the fastest one to do, but also a bit because I like Atari 2600 and C64.

After returning from the lessons at half past 7 PM, I had still lots to do: adding 2 new enemy types, having treasures appear underground and creating the glitchy loose blocks, along with actually making the game over/winning screens. Somewhere during this phase I suddenly realized that I could make the game require more tactical thinking by adding the rising lava (yes, there’s rising lava!) to the end. That’d make the player hurry a bit, and possibly have to think a bit about the route back onto the surface. I was continuously unhappy with the enemies gathering into huge piles in some small gaps, and trying to punch you from too far away. I didn’t manage to get all of this away, but probably most of it. I’m still kinda unhappy with how the projectiles work though.

I went over the time I had planned by 1½ hours, but that time was really needed for adding sound effects and squashing bugs. When I finally sighed after working for 11 hours on the game, I was really happy with the result. Though I had a schoolday tomorrow, so I had to send the entry without checking if it’s actually beatable. I feared a bit that the lava’d rise too quickly for the players. Luckily my fears weren’t needed; though I’ve yet to see someone apart from myself who can beat the game.

I will probably make a Deluxe version out of this sometime later, and I must say that I enjoyed this ludumdare very much! Especially when I finally found the IRC channel. I’ll sure e participating next time, whenever that is. I can imagine items like stun gun, umbrella and electronic drill. Perhaps even a jetpack!

Pros & cons on the creation and game overall:

+ I think the graphics fit the style rather well. I like the look of the player itself, and also the grin on the face of the health meter.

+The game isn’t too easy. Granted, some of this is caused by bugs, but I like how you have to think a bit how to move while descending deeper.

+The game is surprisingly bug-free. There are some bigger and some smaller nitpicks, but overall I wonder how there weren’t any worse bugs around.

- The bugs that are around are quite annoying. The most notable glitch is the one that happens when you jump on the corner of a loose block: You slide horizontally and technically fall through the block. This bug is even more annoying because I can’t understand what causes it.

- The game became a tad too confusing. I think my choices of buttons are somewhat logical, but I can see that especially the ladder will take some time to get working correctly.

-The dynamite is unuseful. No-one wants to explode huge areas, not in this game, because they block easily your path further/back.

-The game became a little too much like Spelunky. I don’t know if I should be happy or sad when people say that the game is a Spelunky ‘demake’ or something like that, because the base idea is a lot older. However, I think I unconsciously took some design choices that make the game resemble Spelunky, starting from the outlook of the player!

Overall, I really enjoyed this compo! Thanks guys and gals! Sorry for the lengthy post-mortem.
Download Cavefrog through this link!

Well, couldn’t get a demo working in time.  This is my second LD and my first fail.  I’ll try to take away some of the sting by detailing what went wrong!

I wanted a procedurally generated cavern that you could climb using a grappling hook.  I wanted the grappling hook to be modeled as realistically as possible, so it would react like real rope and not stretch much, wrap around corners, etc.  Turns out this is a pretty tough thing to do

I used the Bullet physics library because I’ve messed with it before, and also because I saw a demo for Softbody Rope which seemed exactly what I needed.  Unfortunately, like EVERYTHING in that library, the rope was very sparsely documented.  It took me almost 10 hours to get it working.  This was something I hoped to get done in an hour or so.

Finally, at the end of my first day I got the rope behaving somewhat how I wanted.  Good enough to proceed at least, so the second day I focused on cavern generation.  I wanted to be able to create interesting geometry out of a huge block, so I decided to implement the “marching tetrahedrons” algorithm for turning a volumetric dataset into polygons.  This took longer than anticipated due to a silly small mistake that was hard to track down.  It didn’t help that I was already bummed about losing so much time due to the rope issue

So after finally getting the rope working and a basic cavern generated, I tried to add the cavern mesh to Bullet and get some collisions going.  Unfortunately this is when the deadline snuck up on me, and despite coding furiously I couldn’t finish in time.  I do think I’ll continue with this concept until I get something playable.

Despite the fail, I had a great time as usual.  I’m happy about finally implementing the marching tetrahedron algorithm, as I have a few project ideas that will definitely benefit from it.  And as much as I want to hate on Bullet right now, it is a fun library to play with.  Just not the most fun when there is no documentation and precious little time to comb through source files trying to figure out how something works.

I’ll end with some random shots of things going wrong

I’m “done”

“Done” as in, some stuff left to do, but I give up. The game is playable and submitted. People can play it. I will release a Windows version tomorrow-ish. (The XP laptop is asleep and I don’t want to wake it up and start downloading files)

(more…)

Well, as I’ve been working on it throughout the week, I’ve been putting a lot more effort into it, and it’s been going way past the original 48hr game concept, hehe.
As such, I thought I’d post up a post-mortem on what went wrong in the 48 hours, and what went right.

The Good.

The theme was great. I love sandbox style games, be it sandbox in a “giant world to do as you please” sense, or even in a “here’s a puzzle, figure it out as you like” sense – as Little Quirks was to be. So that got the creative juices flowing, so to speak!

My concept was very simple – basically a Lemmings clone where they can crawl up and along walls and ceilings. The art was nice and simple too, fitting with the cute aesthetics as well.

The engine was in better shape than last time, after being used in another couple of projects since LD11 ( Plight of The Weedunks being one of the most well known – yes, this is basically the same engine, minus the 3D layer! ) and I got something up and running very quickly, and only took an hour to upgrade the engine to do dynamic colour replacement.

The Bad.

Hard drive hiccup. That wasn’t fun, especially seeing as I’ve just recently replaced one of them. Losing several hours of work is a killer, and more so when you’re in the middle of an SVN commit to an external server to try and avoid losing too much. Moral of the story, save and commit often!

Sound. Or lack thereof. I actually factored no time in for sound. This may have went against me if I had actually finished within the time limit. Something to be wary of for LD15; making time for everything is quite tough, but then that’s half the challange of Ludum Dare!

The Ugly.

Tilechecks are quick, and for the most part work very well. However, when there’s a lot of logic behind what your entities are doing (crawling around any side of a tile), those tilechecks quickly spiral out of control. I really should have been doing pixel checking with a hotspot being at the bottom of the sprite. Then again, I was able to get a ludicrous amount of them squirming around, with a full Lua-based state machine for each of them which a more expensive pixel check routine may not have allowed. A puzzle for sure as to what would’ve been better

What Next?

It’s become apparant that there’s actually a bit of depth in this concept while I’ve been continuing it after work, and it’s been slowly going beyond just a 48hr game. I’ve decided to continue working on it on the run up to LD15, as it’ll let me see what my engine still requires, and fix some of the hideous bugs I’ve uncovered along the way.

I’ll still be releasing the game – source and all – when it’s done, and probably post it up here complete with final tag … more than likely 48 days after MiniLD11 rather than 48 hours
The game was also designed for handhelds ( GP2X, Wiz, and Dingoo in particular – click for image – ) so you’ll probably see it on one of the sites for those hand helds when it’s done too

Sort of a postmortem for my game, Heart. I don’t know, I just wrote about the process and a few later thoughts. You can read it in my blog.

Also, the game is finally finished. Play the release version.

DoomCake was my first LD entry.  It was developed in Lua, using the LÖVE 2D engine.

In making this game, I learned a bit about Lua, and a lot about cake.  Read on to find out what a sugary zombie invasion might look like…

(more…)

If you did not play my game “The Final Solution”, you can get its win32 binaries and source code from my previous post.

This is my first LD.

I recently attended Global Game Jam [1], which was another 48-hour game competition held in 53 places around the world. We were 48 developers in Ankara divided into 13 teams/individuals, working like bees in our cubicles. My two friends joined separate groups and I started to make a game myself.

Having people around to test your game really changes the development process, as in the case of Itchy! in GGJ [2]. However, as LD is a solo competition, and I wanted to allocate my full attention to it, I did not see anyone during LD, and did not go outside except for getting food.

To mention a few lessons learned in LD;

(more…)

So, I decided to try LD out. I actually found it while looking for “more cowbell” pictures to put in a slideshow at school, and found a screenie of jovoc’s Cowbell Hero. I noticed: Hey, it’s going to start soon! So I decided to join.

Introduction

So, I think I did fairly well. I picked an easy way out, in my opinion: I was actually thinking Rain would win the theme (although I didn’t particuarly want it), so I came up with an idea of acid rain falling from the sky, and using moving platforms to keep the rain from hitting you. But instead, Advancing Wall of Doom won. So I came up with a quick idea: You run across randomly generated terrain (2D) to avoid some wall of sorts. I wrote some code for the laser of doom (the wall), and created a little black ball with 3 frames of animation: one with ‘J’ written on the ball, one with K, and one with L. The idea was to press them in that sequence to move the ball foward. I ran into a problem: I couldn’t get the ball to act correctly to the terrain. So, I scratched the random terrain idea and went for something much simpler: a platformer game. I got the JKL movement idea from a game called “Dick Chaney’s Sky Patrol” whereas one level you were in a wheelchair, and you used IOP to move foward. So, I made the character a wheelchair. I’m a horrid spriter, so I didn’t put a person in it. Thus, Uber Unmanned Wheelchair Delxue was born.

The creation proccess

I was currently making another game to pass the time while waiting for Ludum Dare to start. It had autotiling. So I made some quick autotiling for the walls, getting the idea from the Dream Sector in Jumper2. I also made some other colored walls.

Then, I made sprited movement. You might not be able to see it in-game, but the wheel actually “spins” when you’re moving, but it stops when you stop moving. Genius!

Then, I programmed a quick platformer engine. Nothing special, although I did everything in the “step” event instead of keyboard events, because keyboard events like to conflict with one another. Which means that you would stop for a short amount of time when you jumped. Kinda inconvenient, considering how chaotic this game is.

Next, I began level design. I made a quick introductory level, featuring 0 moving parts. A lot of people had problems with this level. Failure, because you have to beat it to play the rest of the game (non-linear level path: level designer’s worst nightmare). As a result, people didn’t like it. I thought it was rather easy, although having played the game untold amounts of times, and having 3 years of platformer-game experience, that probably wasn’t a very good judgement difficulty-wise. I also made a wall tileset so platforms wouldnt’ just float there (although they do in later levels ).

The next level introduced a gimmick used throughout the entire game: spinning sawblades! Whee! I tried to “time” the sawblades so you came up to them when they were out of the way, although this proved to be a difficult task because I could only start them at 90 degree intervals. Also, so that the sawblades wouldn’t spin off of an imaginary pivot point, I made a tileset that allowed me to make pipes. Snazzy!

The third level was an attempt to introduce the third wall color (by the way, the wall colors don’t mean anything), and the concept of waiting. Waiting. Yep, while a giant randomly-generated laser is steamrolling toward you, you have to wait. As a result, there are a few close calls. Also, the last part is kinda hard to jump over. :/

Fourth level: Giant wall of sawblades! Whee!

The fifth level introduces the pause item, which will slow down the steamrolling laser to a mere tenth of it’s original speed.

Then, the ‘game completed’ screen comes up. Party! You made it this far.

Hopefully, you didn’t quit there.

The humor proccess

At this point in making the game, I was feeling pretty worn out and silly, wanting to crank out some random gimmick, causing humor. So, I took some inspiration from Karoshi 2. If you have never played that game, go Google it. Anyways, if you have played that game, you know its random style of throwing in little injokes, or continuing the game when you try to quit. So, if you check the password box, you may notice: “Hey, I don’t remember that password being for any of the levels! So you click OK. And it goes to level six.

Level six is an abusage of pause signs. You have to go uber-fast on this level, because if you aren’t fast enough, you have to wait for the sawblade to get out of the way, and so the laser blocks off the exit. Level failed.

Then, it tells you that it’s really done now.

But it isn’t. Go check the passbox, and it’s a new password!

I had a lot of fun with this level. The original level didn’t have a pause item, yet it was still beatable. Barely. This was one of those moments when I decided to actually give the player a break.

Lookie, a new password!

This level was based off of the idea of having to backtrack a bit to make a jump, and backtracking again to win. Most levels are RUSH RUSH RUSH RUSH RUSH RUSH OMG THE LASER IS CATCHING UP OMG OMG WOAH I MADE IT HOLY CRAP, but I decided to put in a little variety.

Now, it tells you there is no new password. Don’t beleive it? Go check the password box. See? same password. You must be done now. So quit.

Yeah, I felt like being a jerk.

So, this next level is based off of waiting. The jump is kinda hard to make.

Now, for the final level. This one took a while to make/beat, especially with the sawblade at the beginning. Then, I had a lot of fun with the next part. Not only is the laser on your butt, but the sawblades are nigh-impossible to navigate. A fitting last level.

Then, it thanks you for playing and says you’re done. Trust me this time, you’re done.

What I did right

I made a game.

I made it within the time limit.

It had a main menu.

I personally think it turned out really well, for a 7-hour game.

What I did wrong

Too hard!

Not enough stuff

Inconvenient menu

Lame idea (in my opinion)

Conclusion

I think I did well for a first time, especially considering the small amount of time I had to work on the game.

In my game I had some problems with gosu’s rendering of tiled graphics. jlnr was so kind as to quickly fix some bugs, so here is my updated LD14 entry:

Download: Evacuation v1.01 (Windows binary + Ruby source code)

Bugfixes include:

• background and road tiling
• bunkers no longer getting placed under houses so villagers can’t enter
• sound glitch when game is won

Bummer, too late for the binaries torrent

Dinner last night was Chinese.

Clockwise from upper left: cold dish platter (chicken, roast pork, char siew and jellyfish), diced duck in lettuce wrap, roast chicken, tofu mock-meat with veggies, dessert (hard to explain unless you live in Asia), fried shrimp in wasabi sauce, steamed fish, and noodles in the centre. Not pictured: Peking duck and one other dish which I forget – probably veggies of some description, if memory serves.

Hooray for crappy photography skills and almost-as-crappy cellphone camera.

Actually, this was my grandmother’s birthday. Dinner took 4 hours, which kind of put a ding in my development time. Food was good if somewhat “innovative” (roast chicken on top of fruit salad?).

Well, on to the post-mortem.

What I did right:

- I was using very familiar tools.

- Tools were mostly in place before development began.

- I deliberately left out 3D skeletal animation from my toolset. Integrating it would have tempted me to make animated 3D characters, which would have killed the project due to the time required.

- Character sketches at the start gave me a very clear direction.

- Chose to hard-code my level rather than making a more open framework.

- Froze development half an hour before the end of the compo, to avoid running out of time.

What I did wrong:

- Not enough practice with composing music. The first song took 2 and a half hours. The second was half-done in about half an hour. In the end I scrapped music because I couldn’t finish the boss fight theme in time.

- Didn’t build my toolset with quick development in mind. Some features which would have been useful were left out, like sprite animation and object state-management.

- Included toolset features, like lighting, which pushed the game’s specs to a point where some people couldn’t run it.

- Edit: Made the game too hard. I forgot that most people are not shmupfans.

- Attended the birthday dinner. I kid, I kid – making Grandma happy is usually a good thing, and I got a nice meal out of it too.

Some time has past but I still wanted to finish my LD13 project. Maybe some of you remember the big 3d-bug I published! Hehe…well the game is still not very intuitive but I added instructions, fixed lots of bugs added some graphics and models! I would say it looks almost like a game! And that was my task! I learned a lot as it is my first game I finished.

Have a look here:

http://thomas.trocha.com/wp/?page_id=19

plz read the instructions in the game before starting!!

Here is a video-tutorial how to survive the first three levels. Maybe that will help to get a clue what the game is about .

http://thomas.trocha.com/wp/?page_id=88

Now I can start finishing my miniLD Cryptogame! (On LD#14 I will finish in time! I’m sure )

CU, ToM

PS: I want to thank everyone who tried to figure out what the first version was about! I know that must have been a hard time that surley was followed by massive nightmares!