'Web of Flies'

Paul: As you may have seen, James and I both took part in Ludum Dare a few weekends back, where James made Web of Flies, and I ‘Escape from Flatland: An Romance Adventure of Many Two Dimensions‘. It was an adventure of coding, design, learning new things, and crazy shape (James: and spider web!) physics. It was the most fulfilling 48 hour game challenge either of us have done (this was James’ 2nd LD and my 4th), and the resulting games speak to that.

'Escape from Flatland'

In this postmortem, we didn’t really want to make lists of what went right or wrong, so instead we’ll lay out some rules we each felt were important going into the weekend (whether we followed them or not), and then talk about how these aspects affected our games.

Seeing as I’m introducing this sucker, I’ll start first:

Rule 1: Gameplay in 6

This, in my opinion, is the most important rule of 48 hour game dev: have gameplay in 6 hours.

‘Escape from Flatland’ had gameplay in 7 hours (so slightly late), which gave me a huge amount of time to tweak and fix the gameplay within it.

So what is ‘gameplay’ in this case? To me, it’s the core mechanic, that thing that your player will be doing most of the time: whether that’s running and jumping, shooting, answering, or (in my case) splicing shapes. The key here is that you should rush towards the most important gameplay feature of your game.

I think it’s important to mention that you really don’t need to have a perfect grasp on what your game is going to look like in order to get to this first gameplay stage. At hour 7, i knew that the player would be a triangle, and that they’d be splicing other shapes… and that’s about it. I didn’t know what a level would look like or what the player goals would be, but I knew that splicing shapes would be key.

James: So, yeah… I kind of failed with this one. Gameplay in T minus 6 hours?

I guess I have two excuses. Going in, I had no real intention of actually competing (it was the same weekend as PyCon AU 2011, and a dozen other things), so I’d mostly just resigned myself to helping host our little LD party, whilst doing other things all weekend. Of course, enthusiasm is infectious, and I was soon caught up in the action. It didn’t excuse me from my other commitments though, so it ended up being a rather fractured weekend with me dashing off every few hours to a concert or whatnot. Self-sabotage at its finest.

The medium I chose was my other real roadblock. Last Ludum Dare, not being a Flash developer, I decided to write my game in JavaScript, using SVGs for the graphics. I quickly found myself hooking into the SVG’s internals more and more with the JavaScript though, and before long I realised it would be easier to just script the SVG directly. Soon I was enthralled by the idea of a single SVG image being a game, and it became a personal challenge to make it happen. Unfortunately I was a little overambitious (I’d never actually looked at the internals of an SVG before, and scripting them is a bit quirky), so that weekend ended up just being a very fun, very steep learning curve. I was more successful this time around, though there were still plenty of “Aha!” moments.

I also had a lot of trouble coming up with a game idea, so I started out just implementing all the basic stuff that comes free with other development platforms (player movement, translation between world and screen coordinates, etc.) It was only after about nine hours (while sitting in a Schubert concert), that inspiration finally struck, and I raced back to uni eager to write some spider web physics. The idea was deliberately simplistic; I wanted something small and shiny that would show off the unusual medium, and that I could actually get finished. I could always add to it if there was time (and there wasn’t, turns out simple was hard enough ).

Getting to gameplay in six hours would’ve saved my game from the parameter-tuning problems it currently has, but I guess this time round I just a bit too disorganised, and still adapting to the challenges of the new medium.

Paul: And challenging yourself is really important in getting the most out of Ludum Dare, so much so that I’m gonna go and make a new heading…

Rule 2: Challenge Yourself

This is, to me, the most important part of Ludum Dare: it’s an opportunity to try out new technologies and gameplay types, and doing so is incredibly rewarding.

This time, I went into Ludum Dare with two goals: to learn the Facebook Social API and play with the idea of asynchronous co-operation; and to learn the basics of Ruby on Rails while doing it (more on that one later…). Having this goal helped me to focus my work, forcing me to get to the basic gameplay and design quickly so I could attempt the ‘something more’.

More importantly, the social aspects of the game, more than anything else, have given me a plethora of ideas for my other projects. Trying new things and expanding your horizons will help your game design and development in general.

For me, this rule goes hand in hand with another, and seeing as James has already talked about challenges, I’ll move onward to…

Rule 3: Make Trade-offs

If you’re going to challenge yourself, you need to make trade-offs. If you don’t, you’ll find yourself trying to do far too much in not enough time (see my last Ludum Dare game, ‘The Way Home’, where we tried for an art game which combined and synchronized two completely different gameplay modes… it was a bit of a mess).

If something isn’t necessary for your game, cut it or strip it down. Play to your strengths.

One decision I’m grateful I made with “Flatland” was that I wouldn’t put much effort into graphics or sound. Graphics would be all drawn in-game without sprites (and so any interesting effects needed to be emergent from gameplay), and I’d use Wolfram Tones and maybe some effects generated from sfxr (I ended up not doing this). As soon as I made this decision, it engendered a specific graphical and audio style which can (and did) work really well without much effort.

James: Yep, being able to make tradeoffs is really essential. My original gameplay idea was much more complicated – the web was going to be much larger, a single breakage wouldn’t end the game, and there’d be much more of a focus on strategic repair and pathfinding. By the last six hours though, I was pruning away features left and right, and with not enough time to implement the extra mechanics and physics I had planned, gameplay underwent some fairly radical simplifications. It was painful to do, and resulted in a less exciting game, but there wouldn’t have been anything to submit otherwise. Thankfully my running buddies came to the rescue here with their cool, logical advice; it was time to just admit defeat and polish up what I already had.

Paul: That actually reminds me of another tradeoff I made later on in the development. Initially, I’d decided to do all my serverside scripting in Ruby on Rails, which was partly ‘challenge’, partly ‘a single 2-column table will be pretty easy in rails, and probably quicker (even considering I’ve never coded in ruby) than php.’ Which, let’s face it, is true.

What I didn’t think about beforehand was that setting up Ruby on Rails on my computer meant rebooting into osx (my flash dev was done in windows) and wasting half an hour setting it up. What I concurrently failed to think about was that setting up on a server somewhere would probably waste the rest of the weekend. Thankfully, I only wasted 1-1.5 hours on that particular tangent before coming back (quite literally, as I actually left our dev site to do this) and doing php (which made me a little sad, but was thoroughly worth it).

Rule 4: Turn your limitations into features

James: Paul’s kind of already covered this one with his graphical design, but for me, it was the guiding principle in the design of my game. Last LD it quickly became apparent that I wasn’t familiar with any of the standard technologies used in game development, and so I had to work with what I knew. A JavaScript web game quickly morphed into a scripted SVG image, and I realised that this was a rather cool feature in itself – an entire game in a single image! From that point on my lack of Flash knowledge was no longer a limitation, it was the catalyst driving me down an entirely unexpected path. Of course, this time round was different – I deliberately imposed the SVG/JavaScript-only restriction on myself – but it shows how easily even a serious limitation came be turned around into the defining feature of your game.

Obviously this only works to a point though. There are going to be many limitations that are difficult, if not impossible, to dress up as a feature (buggy game logic, poorly balanced gameplay, etc.). But it’s worth a shot, right?

Paul: It’s definitely worth a shot, and to me, it’s rather necessary. If, for instance, your controls are difficult to learn, it can mean one of two things: you need to fix it or you need to feature it (and by that, I mean admit it’s hard and make that part of the challenge, and probably tutorialise it). That isn’t to say that my game’s controls would have been fixed by featuring them (you can only feature so much, and they actually needed some thought put into them), but it’s a good illustrating example.

As James mentioned, my limitation here was my choice to simplify my graphics. Deciding to go simple on the design could have been a huge drawback in terms of look and feel, but then I spied my copy of ‘Flatland’ on the shelf. Suddenly, I had a way of turning this drawback into a feature, by setting the game in the world of Flatland.

And with that, I’ll awkwardly segue into the next rule…

Rule 5: Release, Playtest and Tweak

So I got two out of three of these, so it can’t be that bad, right?

In actuality, I kinda lucked into playtesting my game. I needed data in my database, and so released a half-finished version and asked for people to play it. And got awesome feedback in the process. I then made some of the tweaks from feedback, but failed to get them all (those awkward controls in the game? unchanged since about hour 4).

Now, I should have known better… I am, after all, a huge proponent of playtesting. And I should really have done a release a bit later on when I had a few more levels, to test out difficulty etc. (as I didn’t really polish this aspect, and there was a bit of sloppy level design going on. Also, some playtesting would have made it clear that social aspect wasn’t all that clear).

All in all, I could really have done more tweaking of my game. In the last two hours of the comp, I didn’t really get much done, and a bit of tweaking would have gone a long way (or, you know, fixing the sound so that the music I’d gotten off WolframTones actually looped rather than playing once and then stopping). In my own defence (against my own accusation? this is getting a little gollumish) I’d slept for 3 and a half hours in 2 days and was in a somewhat delirious ‘holy crap I got that much done? that’s awesome! It’s totally finished’ mood (for instance, the idea that the last level might be too ambiguious didn’t actually enter my mind).

In the end, I’m really happy with what I made, but you never forget those couple of things you ‘coulda, shoulda, woulda’ fixed.

James: Well, yeah, I was an all-round failure here.

Releases? There was one. About 10 minutes before the end of the comp.

Playtesting? Um, I checked that things moved?

Tweaking? Again, nowhere near enough. Parameters like the spider speed, fly strength, and web repair rate were never really tweaked beyond their original values, and while that might’ve been okay for what I’d originally planned, it certainly isn’t optimal given the direction I ended up going.

In fact, I pretty much gave up on tweaking entirely. In the last half hour when I had a mostly playable game, I started work on cosmetic improvements (making the spider’s legs moved as it walked), rather than paying attention to the (probably more critical) playability issues. It was an awkward trade-off, but one I’m not really too upset about. I received a lot of positive feedback from friends regarding the attention to graphical detail, so I guess I’m just glad it didn’t go unnoticed.

Paul: Yeah, the moving legs were pretty awesome.

I think we’ve gone through the things we wanted to, so I’ll leave it there. Thanks to all those who’ve given feedback for our games. It’s been pretty amazing to be part of this LD48, and to be two of the (patently ridiculously) large number of entries.

From James and myself, thanks to everyone who organised it (and got the server back up and running!), and bring on LD22.

Since this is my first LD, I’ve been thinking a lot about my post-mortem, plus I’ve been working on “Stranded Again“, that’s going be my enhanced version of Stranded with improvements as suggested by the LD community.  Plus my Twitter Followers count is going up steadily, so I’ve been keeping up the pace

WARNING!  Some minor story spoilers ahead…

The Idea

When the list of theme topics was down to 20 or so, I got out a notebook and came up with single-sentence game ideas for ALL of them.  My idea for “Escape” was:

Escape: You are tiny brown spider, trying to escape from a research lab.

After doing this for all 20, I went back and came up with a list of Actions and Challenges.

Next, I asked myself, well what exactly do spiders do?  Thinking about Actions, I think,  is a good way to create core game mechanic ideas.

1. Catch insects for food
2. Spin webs to stop “bad guys” (bad insects?) from fleeing, or from attacking something or someone else
3. Collect DNA from insects they catch
4. Catch bad dreams
5. Collect nanites, grid-bugs, software bugs?

1. Web is destroyed by… fire, rain, people, wind, other insects
2. Web decays over time
3. Spider dies from hunger, or runs out of webbing

 

 

The Story

Then I took all this and wrote a tiny Story.  Every game, at its core, must tell a Story – no matter how simple it is.  This one I thought was about as simple as I could get.  I didn’t know this at the time, but keeping the Story simple made the programming much easier as well.

Escape: You are a tiny brown spider caught in a research lab.  You can collect DNA from insects.  Collecting DNA in the right sequence gives you special, but temporary, abilities.  There is a girl trapped in the lab too.  The girl is “dangerous” and “different”, but you don’t know why.  THEY have taken DNA samples from her too.

“I can’t leave here without getting them back — I can’t collect them all in time, but I know a little spider who can.”

I actually thought, of all my ideas, this one was  really  s-t-r-e-t-c-h-i-n-g  it to match the theme – probably the worst match-up of the 20 — and the LD community echoed these sentiments, but not in a mean way — the whole community has been awesome.

The Ruleset

Next I started to think about rulesets.  Which came up with this list of rules:

These are the ones I was able to implement:

1. You win each level by collecting all the insects before you run out of web strands
2. Your web strands do not carry-over from level to level, but are refilled when you start a new level
3. You lose a level if you are unable to catch all the insects with the strand allotment you are given
4. Levels can be replayed if they are lost
5. When you lose a level, your strand allotment and all the insects for the level, are reset
6. You will always have at least 1 more strand than there are enemies, but the ratio of strands to enemies gets smaller as you progress in levels
7. The story of the game is told through dialog, that is “unlocked” as you complete each level

1. Change the ball colors and the fly colors so that you would have to jump from ball Blue to ball Yellow to catch Fly Green
2. Create bonuses that you could catch that would change color of the ball you are either jumping from or jumping to in combination with 1 above.
3. Create obstacles that you don’t want to have your web touch — like fire. If your web touches fire, the fire goes back and disintegrates the ball you just came from.
4. Create “safety” bonuses that you can catch — like water. Water and other bonuses could be caught and stored for later use.
5. More of all of the above, but with other opposites. Might be quite challenging to get the right combinations.
6. Mutations! Each bug represents a different DNA code, catch the bugs in the right combination and your spider gets a temporary mutation.

What Worked

Prioritizing the rule-set from the design above helped tremendously.  When I initially came up with the list of rules, they weren’t in the order shown above.  It took about 2 hours to work out all the inter-dependencies between them all.  Each time a rule was identified as a prerequisite for another rule, it got a +1 — the rule that it relied on it got a -2.  When I sorted this list from highest score to lowest score, I had my to-do list in order of functional dependency.  This really worked because at each step of the way I had a “working game”, so I could stop adding features almost at any point in the list as soon as I ran out of coding time — which is exactly what happened.

Creating a schedule in a spreadsheet ahead of time and marking off hours for “sleeping”, “eating”, “family time”, etc…  I had one row for every hour of the compo, and for the most part stuck to that schedule.  My development time went into just a little bit more detail (but not much more) and had rows for “Game Artwork”, “GUI Artwork”, “Sound Effects”, “Music”, “Coding Win/Lose Conditions”, etc…  I also had two hours each day (one in the afternoon, one in the evening) allocated as “DO NOTHING” where I had to get up from my computer and take a break.  That had a HUGE positive impact on my productivity, my mood, and I think I solved a half-dozen coding issues “in the back of my head” each time I did this.  Also, writing down any “hairy” coding issues during the day and then reviewing them before I went to sleep really worked — I woke up knowing the solution

Leaving LOTS of time at the end.  I left a full 6 hours at the end to run final bug-testing, upload my game, ask friends and family to play to make sure it worked, make any last minute fixes, write my forum post ahead of time, write my entry, announcing via all the social media channels, IMing with people about it, etc…  I think those last 6 hours were the most busy and I may actually allow myself more time in future compos.

Using classes for everything.  I have a class for “spider”, another for “bug”, another for “strand”, etc…  I used my UML/OOP books as guides and came up with a complete list of objects I’d need for the game, and then attached all the methods to them as I went along.  This worked exactly the way it’s supposed to and it made the actual coding a breeze (which in total I think was only about 8 hours).

What Didn’t Work

Thinking that GUI programming would be easy.  It wasn’t!  GUI programming ended up taking nearly 4 hours more time than I had initially thought.  And in the final product you can see that there just aren’t a lot of GUI controls to help with gameplay.  There’s a reason why most AAA game studios have entire teams dedicated to GUI programming (even when using a “GUI engine”) — it’s very tedious work.  Unity GUI makes it as easy as it can possibly be, but it still just takes a set amount of time to create all that GUI functionality — GUI systems are inflexible in their time demands.  In the future, I’ll be able to estimate this better I think.

Using the dialog system as a means to control the game progression.  Such a bad idea!  This is where I really fell down in my technical design.  I should have created dedicated and separate classes for “game” (to control the game state) and created instances of a “human” class (one for the male scientist and one for the female scientist).  I realize now that I was so focused on the game mechanics (which mostly involved the spider, the strands, the anchors, and the insects), that I simply forgot about these classes.  I ran into some problems about mid-way through that I solved with a “gameManager” class that contained all the variables and methods to handle the gamestate and dialog… but it was all mashed up together.  In the future, I need to be more thorough with my technical design.

Not leaving enough time for additional levels.  The final product has 6 playable levels (and then a 7th level that can be replayed as much as the player wants).  Seven levels might seem like a lot for a Ludum Dare compo entry, but in my case, levels only took 5 to 30 seconds to solve.  So, all-in-all I had maybe 5 minutes of gameplay — that is IF the player stopped and read the dialog    I should have done those calculations ahead of time to know how many levels I would need to create.  Originally I wanted to provide about 30 minutes of solid gameplay.  So using that calculation, it should have told me that I would have needed 60 or 70 (!!!) levels.  That, of course, would have been a big Red Flag telling me that the gameplay is too easy and goes by too fast.

I’m in the middle of writing my Stranded Post-Mortem, and unintentionally created this – I knew people here would understand

perma-link and larger version here: http://twitter.com/#!/tulrath/status/112004655785050112/photo/1

Rating entries is a damn hard job. I know many of you think very little about rating or even openly hate it, but IMHO this seems to also be an important part of LD. Especially commenting on people’s entries, giving some feedback to the community, some constructive criticism. And yet, I can still see many users with 0% coolness. There are 427 (71.29%) people with coolness under average of 3.523% and 190 of them didn’t rate any games… Why is that? I know everybody has a life and so on, but come on! You CAN rate at least 6 games or so! I mean, I’m not expecting everyone to leave their lives and rate games, but honestly – if someone has found the time to participate in LD, he or she should also participate in the voting (or at least commenting) process, even if just a little.

I spent on this more than a few days already, just trying to rate as many games as I can, because for a few days I’m not going to rate anything, as I’m gonna be without internet access (sounds horrible, I know).

A few days ago I was pretty bored and wrote a small program in Python to analyze stuff and help me pick games to rate faster, as I find the webpage with entries a little lacking. And because I like numbers and plots, too. Since I noticed that many of LD participants still have coolness around zero, I figured I could share this thing – maybe it will mobilize some of them to give some feedback. Or will be useful in any other way.

So, feature-wise, the script parses LD webpage with your ratings and generates a html file looking like this:

Here are the links:

• Windows binary package (py2exe) + source (tested on Win7 64bit) (py2exe site says it probably needs this)
• Python source only (clean Python 2.7.2, only native Python library dependencies)

Usage:

• Login onto the Ludum Dare site, and go to the voting page with ALL entries (not the one with screenshots, the one with all your ratings):
  http://www.ludumdare.com/compo/ludum-dare-21/?more=1&q=
• Save source code of this webpage to file data.htm and save it in the same direcory as analyze script/ binary
• Run the script (see README.TXT for more info anyway)
• Analyzer data is saved to log.html in current directory. Open it with Firefox or something similar
• To refresh data stored in log.html, you need to repeat this process

The Idea:

When ‘Escape’ was announced as the theme I was stuck for ideas. I had my heart set on the theme being ‘Evolution’ and it was hard to shake my ideas relating to that theme.  To fit ‘Escape’ I decided I wanted to do a side scrolling game but I felt that it needed a twist to keep it interesting and differentiate it from being an “Advancing Wall of Doom” game.

I ended up settling on what is essentially a cross between BIT.TRIP RUNNER and HammerFight. The general idea being that in order to succeed the player needed to be able to focus on two mechanics at the same time: dodging randomly placed hazards and using a physics-based attack to fight off bad-dudes:

Visual representation!

The Art:

After coming up with the idea I then set about contriving a situation for the setting of the game and drawing the main screen. In retrospect drawing the main screen first thing was not a good idea, it was time consuming and considering the time restraints  was a bit of a waste.

As I wanted multiple endings depending on how well the player did this was not the last time I ended up making this mistake. Drawing separate screens for winning and losing was far more time consuming than I had anticipated and the actual gameplay sprites suffered as a result.

The bouts of drawing were a welcome break from coding though and I did enjoy putting references to things in these images:

Not very subtle!

The Coding + Design:

Implementing the basic systems such as the running and jumping was relatively easy, I did get a bit carried away with the boomerang sword though. The sword did teach me a lot about how game physics can work though and previously I hadn’t experimented with anything similar in my other projects.

Code-wise I regret not using abstract classes  and deriving level objects from them. I spent a considerable amount of time re-writing functions and properties for each object I could have used to polish the game. This also made the source quite hard to understand and make changes to.

With only about an hour left I was frantically trying to find out why quitting was sometimes throwing an exception. Turns out I had a game-breaking bug that involved the game not disposing of game content properly. Luckily I had set aside some time before submission to find these sorts of bugs.

One of the main things that I wish I’d gotten into the game was a proper sense of speed. The way the background scrolls and the obstacle speed is far too slow as many have pointed out. I considered changing it towards the end but it was a bit of a nightmare just trying to get all the mechanics balanced, trying to change the speed would have meant changing a lot of elements. It seemed like a better idea to have a game that is more fun to play than one that seemed speedier.

Things I learned:

• Don’t get too attached to your initial ideas.
• Know the scope  of your game.
• Prioritise gameplay over art.
• Have base classes.
• Always reserve some time for balancing, play-testing and bug-fixing.

I’ve recently released an extended version of my LD entry SurfN-2-Sur5. It adds practically no new features, but inside it has tons of comments and details on how I actually made the game. The game is made in PixieEngine, an online IDE for creating games, designed specifically for rapid prototyping (ideal for events like Ludum Dare). So if you’re interested check it out and don’t hesitate to ask if you have any questions.

The scope of the game is very small, but that enabled me to finish something playable for the competition. It should be pretty easy to follow and I think that by reading other peoples code we can all learn a little.

SurfN-2-Sur5 Annotated Source

Over at the Beercave blog.

tl, dr version:

Pros – I learned a bunch of stuff

Cons – I didn’t know what the hell I was doing!

In conclusion  - prepare better next time, dumbass.

Finally wrote Room Escape post mortem. Please read it at:

http://rs.gam3dev.com/2011/09/07/post-mortem-room-escape/

And you can play it here.

Room Escape

And it is time for a post mortem, I have posted it on our blog, please read here:

http://rs.gam3dev.com/2011/09/07/post-mortem-avalanche-2/

The finished game

Hello, I have released a post-Compo Beta 1 version of my Ludum Dare #21 Entry Untitled.

You can download it from the IndieDB page:

http://www.indiedb.com/games/untitled/downloads/untitled-beta-1

The changes include:

- New controls, that make the game faster to play, and more immerse.

- New configuration file, that has options of the sounds, music, level generation, and language settings.

- Multiple Language support, there are detailed instructions for translating the game in the ReadMe file.

This is a screenshot of the game generating 9000 pickups, as set in the configuration file.

Over 9000 Pickups

Nobody mentioned it so I thought I would declare it for anyone who missed out (and everyone else) but in my entry drive backwards over your wife for some bonus gasoline. Inhumane? Maybe but the gas is important if you want an edge against the police.

Just Like This

also check out the super cool alternate version I did where you can drive over the police while a man raps about spelling Mississippi. What more could anyone possibly want in anything really.

…er, it would be good for business if I had a business (or ads), that is.

My entry is bringing in quite a bit of traffic (quite a bit for me, anyway). Thanks again to everybody who checked it out.

Click here to play the enhanced version of Glissaria

So for the past couple of weeks I’ve been trying to find time to work on my Ludum Dare 21 entry (Glissaria) in order to improve it for a widespread release. I wasn’t able to put all that much time into it, and I’ve often been distracted as there are quite a few projects I am looking forward to working on, but I managed to greatly improve it.

The original release had all the basic elements of gameplay there, but unfortunately there wasn’t any balanced content to actually play. The game started off incredibly hard, and if you managed to survive long enough, took a turn to incredibly easy (and after a certain point it became impossible to lose). Mostly this stems from the fact that I chose to make a game in 48 hours that was way overscoped, which led to me spend every last minute working on features, and not have any time to playtest and balance.

But with the latest enhanced version, that has changed. There is now an 8 chapter story mode (with an in game tutorial to help ease up the learning curve), and an endless mode where you can try to survive as long as possible. There are also a set of achievements to give you something to work towards, even if you just want to play around. I’ve added new tower types, new gem types, new enemies, improved graphics, and a greatly improved user interface. I’ve also managed to improve a ton of small things that just made the game less fun than it could be.

Before release though, I would like to get one last round of feedback from anyone who has some spare time (which I know is hard to come by around here with all these games to judge!) I don’t plan on making any large scale changes, simply because I am transitioning what I am working on rather quickly, but anything you guys think of that could improve the game (especially around balance and bugs), please let me know, as I will take it into account for any last tweaks before release!

The improved interface and graphics

Thanks for your time! Click here to play the enhanced version of the game. If you want to play the original competition version of the game, view the competition entry page here. But as always, remember to vote based on the competition version.

[Smash Shove Solve] Full Walkthrough
[Smash Shove Solve] Play and Rate It

But here is what I would talk about if I pulled myself together to write one.

- I need to prepare my engine way ahead of time. I wasted 2/5 of the time on bugs

- I need to sleep less. I got my recommended sleep and got less done than last Ludum Dare.

- The graphics went well. Simple sprites takes only minutes to make and look nice.

- The automatically generated rooms worked nicely and really added the most content to the game.

- The game isn’t actually finished. There is no ending.

Anyway here is the timelapse I made

Also here is a link to my entry

It’s vaguely related to LD, but I’d like to share that since going full-time indie last month, Im on the verge of finishing my first game as a fulltime indie – Thelemite.

Thelemite is a fast paced 2D brawler made using FlashPunk. It’s about Melex Archer, a video game programmer, who out of boredom had undergone mdeical experimentation that transformed him into mutant ninja!

Overall it was quite an experience, especially having to undergo a blitz crash-course in pixel art.

Here is a trailer of what to expect:

I’m really finishing, and as I’m done with that, I plane to extend McPixel as my next project.

For a little project I’m working on, I made a flowchart to help with the design aspect of it.  After finishing the flowchart, I realized exactly how important and helpful it is to make one…

A few reasons why flowcharts are good to have in your game.

• You can see how each menu connects to others
• It will allow to decide what to make public and what to make private based on connections
• It shows how the game will flow
• They can look pretty nifty
• It’s something to put in the Bonus Features

The Collapse

After my failed attempt to make a video post mortem (video editing tools are just a pain in the ass) i’ll just write them down in a non-flashy manner.

Can't touch this

So, what went right?

In the given time, i was able to create and design a solid game concept that potientially could be fun. It has a continuous artstyle, although very generic at this point.

The game features a level editor, which actually consumed most time developing. I wanted to make sure to have a solid base to work on the game, which is for puzzle games obviously the level generation. It turned out to be quite useful. You can design levels fairly quick and immediately test them, which eases the level testing and balancing in the long run.

Also i am glad that i was able to spend some time working on a catchy soundtrack, although it is not very long and kind of repetitive.

What went wrong?

THIS went wrong

I got a lot of feedback that the game wont run correctly or crashes on startup. This was a fault in the coding, and still isn’t fixed completely at this point. But it should work for the vast majority currently, or at least i hope so.

Another disadvantage is the design of the levels, or rather, the order i released them in. I was getting used to the controls while developing and testing it, so they didn’t feel too difficult to me. I didnt realise that new players wouldn’t have enough time to get used to the controls and getting frustrated too quickly. Some of the earlier levels require you to control quite accurately, followed up by some rather easy levels.
This was partially due to designing the levels just few hours before the deadline. I should try saving up more time for that the next time.

Another result of the late implementation and testing of levels is the bump sound. At the point i realized it is quite annoying, and bugging at some points, it was too late to fix. However i didn’t want to remove it completely as it is important to have some audible feedback. I should have just made it less loud.

So, what are you going to do with it?

I will continue to work on it. I will make changes on things pointed out in the comments, mostly a more decent difficulty curve for the levels and better controls.

One thing that was bugging me with it though, was the art direction. I kind of like simple minimalist design, and it certainly works for a protoype for a game compo. But to capture more attention it’d need a more artsy design, something that will be recognized easily. So i was sitting down with a friend, who is concept artist, brainstorming about different themes, and he came up with a cool idea.

You will play a bacterium, or virus, and navigate through bovels and intestines. Fighting your way through to that one cell you need to infect. It will receive a new, more organic (quite literally) level design. That, however, requires a complete rewrite of the game, which i am working on currently. That theme is kind of neglecting the Escape topic, but the gameplay will basically stay the same.

I might be able to show some mockup, or ingame wip screens in the next couple of days.

I incorporated feedback, added a new room in the prison, fixed bugs, and more!

You check it out from my page.

Look for the the post-compo version.(in big letters and everything!)

Also, if you haven’t, please play and rate the original version of my game (If you have time. I know some people have lives )