I’ve had the “change color to go through walls” idea for a bit, so I thought this would be a good chance to put together a prototype and see how it worked.  The general idea is that you’ve woken up inside an alien artifact filled with color-based challenges, with said alien narrating your progress (or lack thereof) like it was studying a rat in a maze.  I wanted it to seem like it was examining humanity through the concept of color, so it would try and “figure out” purple, or put together challenges with regards to mood and atmosphere that a color invokes.  Red lasers, big blue crystalline structures, smooth white alien surfaces.

I didn’t really have a chance to flesh out this narrative much except for the opening text (which in all fairness could be taken as anything really).  The final scene, when you finally exit into blackness at the end of the ordeal, I wanted sparks to fly out in the character’s various colors only to fade to small white stars.  The view would slow spin until you’d see yourself floating away from a massive, smooth alien cube with a little pin-prick door where you came out.  Maybe other doors on the surface would hint that there were other mazes, other experiments going on.  I wanted to evoke an ambiguous escape, like you escaped only to…what?  Float out into the abyss of space?

Anyways, without further ado…

The Good

1. Unity
I had some second thoughts about going with Unity again this time around for a couple of reasons.  In the last couple of competitions, I’ve gotten lost in the details and not come out with anything.  It doesn’t have any built-in support for 2D sprite animation and the nice libraries for handling that are commercial so I can’t submit the source required to enter the competition.  Finally, I can’t produce 3D assets quickly enough to make it feasible in the time limit of the competition.

I had decided that I’d probably just be jamming on an existing Unity project unrelated to the theme anyway though, so when the theme clicked with my idea and I decided to switch gears I decided to stay in the Unity groove despite my hesitation.  This actually worked out great this time around because it gave me a huge leg up building the environments.  Which leads me to:

2. Hand-Crafted Levels
I love procedurally generated content.  I love playing games like that, and the siren’s lure of cheap, infinite content is oh so attractive when time is so scarce.  Unfortunately, most times I run into Doull’s Law and before you know it all my time is gone and I’ve been staring at my algorithm trying to get just the right random levels.  This time around, with the core mechanic being a puzzle platformer, I broke out my sketchbook before I did anything else and I scribbled out eight or ten “rooms” that I could string together.  That done, I took the first and simplest room and went to work putting it together in Blender.  Unfortunately, I had a lot of trouble getting the results I wanted out of Blender (due to my own inexperience, not for lack of capability from the tool) and I was starting to second guess by decision to stick with Unity and the third dimension.

Then I had an idea – Unity 3 introduced a great little feature that when you hold down the ‘V’ key while moving an object, you’ll grab the actual mesh vertex under your mouse and it will snap to the closest vertex while you drag it around.  My environments were already super simple, so I dumbed them down even further to be constructed of nothing but transformed cubes.  Cubes for walls, cubes for floors, cubes for stairs – everything.  Unity has a default Cube prefab that you can drop into your scene, and this combined with the vertex snapping let me put together a primitive room like building with Legos, much faster than I could fighting with Blender.

3. Priorities
This time around, I made much better decisions about how to prioritize my time to tackle my game idea.  In the past, I’ve been bogged down with anything from reorganizing my code to trying to get the perfect particle effect (god I hate Unity’s particle system, but that’s a different topic).  This time around, I had my sketches first so I knew exactly where I was going.  I knew how the first room was set up, and it was simple to help introduce the player to the core gameplay mechanic of changing colors to change surface solidity.  This gave me an early goal to shoot for – get the entire game running in the first room.  Get the room put together, get the player controllable, and wire up the color changing controls to the logic that changes the environment accordingly.  I didn’t start work until Saturday around lunchtime and I had a fully functional system in place by the time I want to bed.  I rounded out some issues when I start up again on Sunday but then all I had to do was start implementing puzzle rooms.  I could work for as long as I wanted to and when it was time to be done I’d just tie off the environment and we’d be set to go.

Of course that’s not really the case most of the time.  In the end, I finished the rooms I planned on for my entry (four distinct areas) with a “win” state.  Towards the end I realized I wouldn’t have any time to work on it during the last day of the Jam so I decided to round out the experience by adding the necessary death/respawning and call it finished.  I don’t even know where to go with sound so there’s nothing in it (not even some nice sfxr effects).  Now that I’ve got “finished my gameplay” entry under my belt, I think I’ll need to get some practice doing rapid sound engineering so I’m ready next time.  The key though is that taking a bite-sized chunk of my game and getting everything working in it gave me a good sense of what worked and what didn’t, and it gave me the warm fuzzy of seeing it all in action that probably carried my through the rest of the weekend.

The Bad

1. Primitive Environments
This is the double-edged sword of using Unity’s cubes as my only building block.  All right-angles and flat surfaces, it’s close the the alien environment I was looking for but it’s a little too angular and there’s not a lot to indicate the way forward and draw the player in that direction.  There are plenty of spots crafted from a bunch of cubes that really should be a single piece of geometry (like the stairs in room two).  This is okay for the white always-solid portions of the room, but it causes weird artifacts where semi-transparent colored regions overlap.  If I was more comfortable with Blender, these object would be made there and I’d be able to add a little more variety and at the same time have more complicated geometry as a single mesh.

The other side of the primitive environment is the lighting.  I don’t really have a strong grasp of lighting a scene well and this, combined with all the boring lines of the cubes, made the rooms look really flat and dull.  I originally pictured the environment stark and harsh and geometric with lots of ambient occlusion (leveraging Unity’s lightmapping) to give it more of the look of The Witness or Mirror’s Edge’s time trial DLC.  Unfortunately, with the poor lighting and the lack of interesting detail, it didn’t look anything like that.  At the last minute, I added the grainy noise filter and the “your suit is broken” conceit to cover it all up.

2. Controls
This one comes in two flavors:  movement speed and color switching.  Several of the commentors complain that the controls are off and that movement is too slow.  I agree, and I played some with the settings for the FPS character controller script I used from Unity’s standard assets.  Moving any faster made things feel too slippery for a game where I’m asking people to jump onto floating platforms.  In reality, I think maybe the starting rooms were just too big.  Unfortunately, building them all out of cubes as described above makes it really hard to shorten a room.  My guess is that would have been easier to do in Blender, and I could have tweaked the size of the various rooms to give it a little more flow and make the player feel faster without actually speeding him up.

On the other hand, color switching was a big question mark in my mental model for the game.  I had the idea of changing colors to move through obstacles, but I had no idea how to actually let the player do so.  In the end, I sort of punted and used classic FPS weapon selection with the number keys.  More than one person had trouble with this configuration though, and it’s made worse by the fact that the puzzles I had in mind asked the user to switch colors on the fly (in mid-air in the case of the final room).  Switching had to be easy enough to do it quickly and accurately, but also required instant access to all possible colors at once to allow any color-to-color transition.  I briefly looked into a linear linked list where the player could only transition from cyan to magenta to yellow and so on to loop around to the beginning.  This didn’t work since reflex-based puzzles were completely out of the question when there was n possible colors in between you and the one you wanted.

3. Too Many Colors vs. Not Enough
This brings us the the color selection.  The final jam entry only has three (plus the “all off” white color).  I originally included red, green, and blue as well, but I didn’t have a chance to build out more environments to use those colors so I pulled them out (this is a sideways compliment about Unity as well, as my color-switching component can have new colors added and removed right in the inspector without any other code and the UI and the world respond accordingly).  I’d like to include more colors since the environment’s palette is essentially bounded to this list.  Too short a list and you’re environment is boring.  Too long, though, and you exacerbate the control problems with color switching, as well as making colors less and less unique.  I think the three worked for now, but my guess is I’d feel pretty constrained in the art department if I could only use those four colors.  Who knows, though – I’ve seen some games make great use of a limited color palette.

4. User Feedback
I mentioned I hate the Unity particle system, right?  Yeah…it’s a time-sucking black hole of configuration options that never seem to give me the affects I’m going for in my head.  Conceptually, I wanted to send heavy sparks radiating out from the player in the color the user changed to, but I could find a good looking way to get the glowing trails that you’d expect form actual sparks.  It’s made worse by the fact that they emanate so close to the camera so you get these big, ugly blurry blobs for particles.  I got distracted with the sparks though (as I’m prone to do with the damn thing) and never got around to adding other feedback so there’s not a lot of action cues other than the UI to tell the user what color they are.  I’d like to change the lighting of the level to whichever color the player is, but I’d have to experiment with how that changes the player’s ability to know what color other surfaces are.  In the end, there’s just not a lot of feedback from your actions in the game, so everything feels a little static.

5. The Final Puzzle
The last puzzle as put down in my sketchbook was completely unworkable and I didn’t realize it until I got to implementing and testing it Sunday evening.  The original plan didn’t have the walls in between the platforms, with the intention of only forcing the player to switch to the next platform’s color mid-air.  The problem, though, was obvious once I’d died once – I’d given the player the ability to switch to the color white, which in effect makes everything solid.  Dying automatically resets the player’s color to white and I was faced with a broken finale where the entire path to freedom was solid before me.  I needed to salvage the room as best I could though rather than coming up with a whole new puzzle – the time it took to put together a room from start to finish was more time than I had at that point.  The walls were a way to force the player to change their color into a non-white option, bringing us back to the original intent of the puzzle.  It’s a little more complicated since it’s not exactly obvious that the platform on the other side of a transparent wall is itself transparent until you get over there (and fall through) the first time.  In the end, though, I’m glad it worked out and the solution is learnable so I don’t feel it’s necessarily outside the bounds of fairness.  Maybe not the final design I’d go with, but it worked for the weekend.

The Future

I think the core mechanic has some legs on it, and I think that the mental picture I have of the atmosphere and narrative might make for an interesting place to play for a while.  The biggest hurdle really is the controls but it might be fun to build out a more fully-fleshed proof of concept and try out some different control schemes.

Also, I’m not sure how you make a game that’s so purely about color accessible with regards to color blindness and other related issues.  A yellow wall doesn’t have any form to alter, no texture or other cues besides its color.  I’d have to do some research to see if other games have solves similar problems and if there’s a way of handling it gracefully without breaking the art direction I’m aiming for.

Finally, some other random concepts to add some variety to the game, in no particular order:

1. More Hazards
Spikes, Lazers, different substances.  All or most of these can be specific colors so that the player can nullify their effects with a strategic color change.  Combining these with navigation might make for some fun (or frustrating) combinations.

2. Slopes
There needs to be more variety in the environmental architecture for sure, but I always loved the sliding sequences in Mirrors Edge where you’re coming down off the side of a skyscraper.  I love that sense of barely-controlled momentum, and I thought I could use something similar to introduce a timing aspect to some puzzles.

3. Paint Gun
All that geometry makes for a clean, alien environment, but that can be a little boring sometimes.  I thought it’d be a fun idea to have a gun that you could hose down surfaces with that would splatter paint all over it so you could essentially walk through the splatter as door using that color.  I thought the organic look of the paint splatters and the ragged “holes” they would make would be an interesting contrast to the environment as a whole, but the technical implications put it out of reach for the competition.  Maybe something fun to play with later though.

Thanks for playing folks!  I had a blast working on it with all of you.

Tags: post-mortem, postmortem

This has been my first LD. I've managed to complete a game and the whole
 weekend was a nice experience. Here's what I've thought...
 
 Before LD21
 
 + you can't possibly make interesting levels by hand in whatever little
 time you have left after finishing the engine and art, therefore you need
 to make a game that doesn't rely on levels
 + you can't make decent 3d games in 48 hours
 + you can't balance a game in 48 hours
 + libraries are for lazy programmers

After LD21
 
 + you can make interesting levels because developping with libraries saves
 you lots of time or you could make a level generator
 Astar
 Hell fortress escape
 
 + you can make nice 3d games in 48 hours with the proper tools
 Stratus
 Under a watchful eye
 Prelude of the Chambered

+ libraries are mandatory if you want something more complex than a tic-tac-toe like game
 Gather 10 keys to escape

+ mining games are pretty damn popular
 Lost in the shadows
 Caved in
 Tea powered escape!

+ 48 hour entries can provide an interesting atmosphere
 Escape from the labytinth
 AWOL

+ you can write a story-based game in 48 hours with superbe pixelated graphics
 A tale about life, death and a loser

+ WordPress hates me

It’s been a good set of days with Ludum Dare, and aside from one incredibly annoying and potentially ruining issue it has been a great learning experience. It’s been a lot of fun and I hope to compete again in the future.

The Good:

Entire game got completed, without too many hits (except for the one mentioned above), it’s been a blast and in general I wouldn’t have anything bad to say with it. Programming was difficult at times, but it helped me push out more and further my little experience in that field a lot more.

The Bad:

 Work on the Music took a lot longer than previously desired, but more-so than that it seems the game is working out to be a bit hard for players. I wish I had placed the controls information inside the game, as this generally would clear up that holding X makes the character run a lot faster and in general makes for easier platforming. It -is- playable, but this is where the ugly comes in.

The Ugly:

This is where it gets really nasty. The original upload I made for the contest had everything working, everything, except -one- item, which is crucial to completion. The reason why this wasn’t in the original upload? On zipping the file I must have done something horribly wrong which wrote those rooms as completely blank. In my source outside of the zip everything was fine, but with the zip bundled and such, I didn’t notice this error till later. I reuploaded another zip with the correction made, but if this invalidates the entry then I’m willing to roll with that blow; I’d much rather a game that was complete and made in the spirit of the contest rather than try to rush something out just for the whole idea of “winning” something. Hopefully though, this shouldn’t cause any problems.

Summary:

Incredible learning experience through and through. I had originally intended to make an RPG with a basis engine beforehand but the time frame for that does not fit very well for a 48 Hour contest. I’d like to attempt it someday, but maybe for the Jam as opposed to the Compo. I really look forward to the next Ludum Dare and as usual check out the other entries submitted. There’s some amazing content up!

Till next time~

This was my second Dare, and it was just as fun as the last one. I learn a lot from this process, and I am proud of being part of this incredible welcoming community.

The concept
The game is based on an idea I got a few months ago. I’ve wanted to try out this idea for a while, just to see if it would turn in to an enjoyable game. After seeing the end result of the voting rounds, I immediately thought that this would be a good opportunity to try to implement this game.

The premise of the game is simple: Wolfenstein converted into a turnbased puzzle game.

What went right

1. The engine
An engine like the one used in Wolfenstein is quite easy to implement using the technology that exists today. Back in the days you had to implement it all in software on hardware that merely were fast enough to draw graphics at that speed. I went for a really easy approach where I simply put a lot of textures cubes on the screen. This works fine as long as the maps arean’t big enough. Using this method, it was easy to implement a simple tilemap loader that put the cubes at the correct position in the world with the right texture.

2. Known library
Unlike my first Dare, I used a library I’ve used before. I used the same library as I used for my entry for Mini-LD #28, Three.js. This turned out well, as I could be productive from minute one.

3. Level editor
In the middle of the implementation process I figured out I needed some way to define the levels. I figured I did not have time to write something myself, so I checked out a few tilemap editors I already knew, but none of them would export to a javascript-compatible file out of the box. Some of the editors support writing custom exporters, but I didn’t feel like brushing up on my Lua experience. I therefore went for an easy middleway where I used Mappy to build the levels. I then exported them to text format, and copied part of the text over to a custom made fileformat using json. This solved my problem completely, and worked well for my use.

4. Browser standards
For this entry I used some of the latest HTML5 technologies. It’s suprising how well the standards are defined for both WebGL and HTML5 Audio. When I’ve implemented the engines using Chrome, and then tested it using Firefox, it seemed to work with almost no changes. The only change I had to do, was some error checking for loading audio for Firefox.

What went wrong

1. Postponing sound
Once again I postponed the sound and sound implementation to the last minute. Sound creation went fast as always with the mighty powerful BFXR. Earlier I’ve used a sound library that uses Flash for sound playback for maximum browser support. But I figures as I’m using WebGL, I could as well use HTML5 sound, even though it is not that well supported yet. I’m pretty sure that if your browser supports WebGL, it will also support HTML5 sound as well. Problem is, I’ve never used HTML5 audio, so I needed to learn it as well. Turned out that is wasn’t that hard, and within an hour I’ve made a very simple sound engine for my sound and music needs. Before the next Dare I should probably create a sound library that I can use instead of having to struggle with sound once again.

2. Lack of artistic skills
This is a general problem with my entries. I lack the artist gene, and is therefore not able to draw pretty pictures. This is shown in most my entries, where I try to minimize the damage done using as simple as possible drawing. This time I needed to draw a simple character, and it turned out ok, but I think I should stick to mechanical constructs ahead to avoid having to draw organic objects. The same goes for music. I found this really nice tool before the competition that I thought I should be able to use to make simple music with, DrumCircle. When I sat down with it, however, I could not create anything that sounded like music, even though I succeded using it a lot before the competition. I therefore ended up using elevator-music generated from Wolfram Tones.

3. Difficulty level
I really misjudged how hard it would be to play the game without a minimap. I intentionally did not include a minimap just to give the game a little more challenge. After reading comments and seeing friends play the game, it seems like a minimap is a must for this game. It is also har to judge how far you’ll step using a single arrow because of the lack of a visible grid. This was also caused in part by the lack of variation in the wall graphics.

4. Level design
I had no clear idea how I should design the levels, and how I should design their challenges. With that in mind, I ended up using scare-tactics as a gameplay element. The challenge of the game became the avoidance of the guards. I initially intended to add sophisticated shooting-mechanics into the mix, but it turned out that running away from guards was enough.

5. Rough introduction
There was no tutorial in this game. You was thrown right into the frying pan, causing all kind of confusion because the player had no idea on how to play it. This could be solved by having a more sandbox-like first level with some popups appearing when the player walks over given points. As it is now, the player is greeted with a wall of text at startup, and you cannot really play the game without knowing the bare basics given there.

6. Irritating UI
I implemented the UI using JQuery and JQuery UI. These libraries aren’t really made for games, and it shows in this game. I wanted a queue of commands for the pleyer to execute. This queue could become taller than the height of the screen. Instead of allowing full window scrolling I made a smaller area with a scrollbar. It was then possible to rearrange items in the queue by dragging each command up and down. The problem with this approach was that it was possible to scroll past the horizontal and vertical edges of the queue, which made it quite hard to predict what would happen if you dropped an item at times.

The future

If I get the time, I will try to improve on the game, and maybe even add a few features.

1. Minimap
I would like to add a small minimap for the players to easily orient themselves. I’m not sure if I should place enemy markers here. I should at least mark their position if they catch you in case the camera is not in the correct direction. I should probably change the camera angle in any case.

2. Level grid
A visible grid that gives an indication on far you will step if you add one more move action to the queue.

3. Less annoying interface
An execution queue that does not scroll at its own will. I will probably implement this using a canvas where I calculate the position of the individual queue elements myself as well as accepting the input.

4. Speed of execution
Buttons to control the speed of playback. Too often it feels like it takes an eternity to make the player avatar move.

5. Conveyor belts
This is a new gameplay element. I was thinking about adding conveyor belts that you could push crates onto. This would give the possibility to kill enemies by pushing them with the crates. This idea came from reading about the board game Robo Rally.

Tags: postmortem

Someone playing Elastic Prison

Alright so here go my final thoughts.

Game Mechanic:

I’m pretty happy with how everything went. The first day I spent a lot of hours just brainstorming, trying to come up with a really cool and simple concept. I’m a big fan of generated content and simulations that give the player something interesting and new to play with. Something that encourages the player to experiment instead of just running through everything completely deterministic. And I came up with a concept that was just way too abstract, and I wasn’t able to fill the blanks with working/realistic ideas. So about 10 hours in I somewhat hit a wall and was feeling quite stressed out. So I remembered to keep it dead simple and came up with what turned into my final entry. Elastic Prison, a game where the player controls a ball that is attached to an elastic band that keeps pulling it back to the starting point. And for the player to free himself, he has to cling & swing himself from one floating hook/ball to the next to maybe reach something that will remove this rubber band.

First I focused on how the player controls this ball and how the elastic band attaches itself to these hooks. I had something running pretty quickly and felt satisfied with the controls. Then I started to focus on the actual level creation. I knew there needed to be some variation so I created different kinds of hooks. I also put a few minutes into improving the performance so I could just throw everything into one big level.  The next step was creating the level. I did so by making one challenge at a time for me. Every time I tried to make it different from the previous one, or even so that it builds on the skills that were acquired earlier. I tried to make later parts of the game really hard as I hear people are complaining a lot about games being to easy these days. So I could just barely play through these final stages that I created. Still it’s not impossible and after uploading my submission I recorded a 12 minute play through.

Tech:

Using LWJGL was a pretty straight forward decision but looking back it might have been smarter to choose libgdx because it’s LWJGL + more nice stuff (mp3 support). It’s been smooth sailing with LWJGL though. Currently I’m working on porting my game to libgdx to maybe have it run on android or as an applet.

Sound and Artwork:

Those were the things I was most confident about and surely enough I was really quick. Ableton and Photoshop did their job well. The sounds turned out a bit quiet though.

Feedback:

I have to say I was quite surprised with the feedback. Yes people liked the concept, art and sound but had a gripe with the controls, expecting them to behave differently and not really being able to figure out how to master them. And they were quite frustrated about how checkpoints work, as they won’t keep  you forever from going back to the beginning. Well I can see now how people expect the controls to work and it’s too bad that I didn’t hear that kind of feedback before I uploaded my final submission. While working on it I was told it is hard but fun, which is what I was going for. Now to the checkpoints. I guess the problem here lies completely in not communicating well enough how they work. The funny thing is that it is a really simple concept. Every hook behaves the same way. But some might hold you longer, depending on their size. You won’t end up at the beginning if you understand this concept and make sure to reattach yourself to these large hooks again when they stop glowing.

Once you get it it’s a challenging and interesting concept. And I thought it goes quite well with the theme. The player is trapped and tries to escape. Once he stops struggling he is in danger of being back where he has started.

Future:

I look forward to the next Ludum Dare. I’ll make sure to get more feedback while working on my game, and to keep it simple straight from the beginning. As for Elastic Prison, I’ll make it available as an Applet and maybe do some more with that concept sometime in the future.

My Entry

Tags: java, lwjgl, post-mortem

Hi there, LDs over for a week and I got many people to say, that my glorious (ahem) piece of work isn’t beatable at all.

So, I beg to differ 😉

http://www.youtube.com/watch?v=U-RNWmPBj00

Yes, you’re absolutely right, it’s hard as hell, there’s no introduction or tutorial at all and you’ve to have a lot of luck to get a starting position where your ship isn’t blast into pieces after a few seconds.

But it works.

Ok, I’ll try to learn this lesson once and for all (my LD 19 entry wasn’t nicely to play, too) 😉

After finishing my game I noticed that I had plenty of spare hours left so I decided to add a scoreboard. Unfortunately that meant communicating with a web server, which to my knowledge meant I had to sign the thing.

Signing applets involves some console work, but most importantly it involves an annoying popup asking people to let the thing run. In my mind that’s nearly as bad as a installer and I didn’t want anything of the sort, besides I tried that on a previous project (which come to think of it was also a 48 hour game) and that resulted in people not playing it a all.

From some android work I’ve done I remembered I can call links to pages even if the app has no permissions(the browser handles the links), and I wasn’t too surprised when I found out that an unsigned applet can do the same.

Basically what I did was call

link(“http://example.com/scores.php?name=Andrew&score=asdfg”);

(processing function, no Idea if it’s the same in reglar java) where ‘asdfg’ was an encrypted version of the score.  This coupled with making each score unique prevented floods on the scoreboard.

The function spawns a popup window, and I’ve noticed that even if chrome blocks it, it still preloads the score page causing the score to go through. This may or may not be a security issue.

If anyone knows a better, or just different way to have an applet share its internal data I’d love to hear it.

VIEW GAME PAGE

Tags: applet, chrome, java, processing, security, unsigned

I’ve released an update to my Ludum Dare game Captive. It fixes the peskiest bugs, adds a bit of polish, and a tiny bit of new content. Of course, the original compo release is still available as well.

Here’s the changelog for this most recent version:

-Added a few tiles to some rooms to make them slightly less dull.
-Fixed a music bug with the red terminal (for real this time)
-Added a secret 4th Boomka game you can unlock after beating the red terminal.
-Added a “portal” object to a single room. It’s related to the secret.
-Made it so that checkpoints remember what key cards and doors are open when you save (as well as other variables, such as the music playing). This prevents you from grabbing a keycard, getting killed, but keeping the keycard after respawning.
-Added sounds for the fireballs. -Randomized the fireball-pipe’s first alarm a tiny bit.
-Fireballs now destroy when they fall off the edge of the screen.
-Made it so that using a terminal will reset the “used” status of checkpoints, so you can save again if you’ve just played a Boomka game.
-Removed a couple of very frustrating spikes.
-Moved around and added a couple of turrets, as well as some fireball-pipes.

Play it HERE!

It’s already been a week since I submitted my first entry into LD. Been reviewing quite a few games and am impressed with the sheer amount and diversity (and similarity ;)) found in the competition. Truly an inspiring place to learn from others.

My game “Still Dreaming” has been reviewed by lots of people. I’m overwhelmed by the amazing feedback I’ve received. Thanks everyone for playing & enjoying the game. Main point of criticism has been it’s shortness which I completely understand. I’d love to keep this game growing over time and add more puzzles as they come to me.

I spent some time today tidying up a few things in “Still Dreaming”. Mainly there were a few visual aspects I wasn’t completely happy with.

Screenshot above is from the “improved” level 2. Check out the enhanced version here: Still Dreaming – Enhanced

Cheers,
Bach

Hi.

If you read french, or if you’re fine with google translate, you might be interested.

I’ve started on my blog Oujevipo a Ludum Dare Review Marathon, the objective is to review a maximum of LD#21 games before the end of the voting. Of course, I’m not alone and a lot of nice people are helping me. Thanks to them.

Maybe will you find your game in there, maybe you’ll discover some games you still haven’t played…
it’s here : http://oujevipo.fr/index.php?option=com_tag&task=tag&tag=ld21

My puny game is not, by any means interesting in terms in gameplay. Main character only walks to the left or right direction, and he does not even jump once. But, it has nice art style, and somewhat interesting, although short story.

That’s because I’ve decided to use and exploit my main skill – drawing. And focus on story and idea. Because my programming skills are rather shabby and rusty, even though I have some, but they clearly not as good, as some of you guys have. I can’t say I was working really hard in this 48 hours, in the first day I have created simple graphics, and for second I’ve made simple and cheap animations and wrote a simple code.

Idea of a game looks kind of like russian matreshka doll, you keep escaping from different places. I have added places that I could remembered as often used in sci-fi and adventure literature.

I should say, this was fun, since it felt really good when I finished it and submitted. It’s great to be part of such a nice event as Ludum Dare, and I want to thank everyone who participated, and especially people who made it possible. Thanks, guys.

I’ve added an updated version of my entry, fixing some of the problems with the competition version. Please don’t vote based on this version.

These are some of the changes:

• Added minimap
• Grid on the floor
• Rotate avatar towards enemy on collision
• Change movement speed
• No more horizontal scrolling in sequence list
• Added an easier introduction level
• Added loading bar

Play the updated game here:
http://www.ludumdare.com/compo/ludum-dare-21/?action=preview&uid=3796

Tags: post-compo, update

I was talking with my friend earlier today and I was wondering what is the most important thing to focus on a game (after functionality): is it graphics? Innovation? Audio? Something else entirely?

So I wrote a quick script to show the correlations between all of our statistics and overall. The script is here.

The correlations are (lower is more correlated):

{'Humor': 179, 'Innovation': 66, 'Community': 158, 'Theme': 107, 'Graphics': 73, 'Fun': 23, 'Audio': 251}

Fun is obvious. If a game isn’t fun, then it’s not going to be good overall. But fun is also pretty vague and hard to define – it doesn’t give much more information than ‘overall’.

Innovation and graphics come after – these are things that are more understandable. So, conclusions: work really hard to come up with clever ideas, and spend a lot of time on the graphics.

Pretty sad to see audio come in dead last, since that’s something I worked hard on

Postmortem time!
This was my first LD and i have to say that i really enjoyed it, with all the blog post, chat and Streaming i didn’t feel alone last weekend. Thanks for that.  long post ->

About the game, my first objective was to have a game working, in that i success even if all the things i wanted in it is not like enemies (but i like my evil space mouse so i’ll do it).
I was preoccupied all weekend about the feedback other have from my game. I wanted a game a little frustrating for the player trying to escape the falling ground while looking for the Exit.
If you played my game you probably notice that “little frustrating” don’t fit well to my game, i spend so much time playing my game that i master it and i wasn’t able to find why people found it that hard.

The major feedback i got was the camera Perspective giving wrong info about distance for jumping. Here is my biggest mistake. When the idea of the game came to me, I saw it on a 3disometric view and make it but it didnt feel right,
so i make it a perspective camera keeping the iso orientation, the game wasn’t really playable and finally came to the cam i have in the game, 45° in 1 axe. i don’t found it perfect but that was ok and move to something else.
After that i didn’t touch the camera tweaking jump to make it easier but with the bad camera the game never feel right.

What i should do : I don’t really know, probably trash my cam and start a new one, behind the player but that’s not really the vision i got from the game.
so i have a question for you friendly dev people what do we have to do when we don’t find a solution that fit your idea?

Actually i redo the camera but don’t know yet if this will correct the problem. now the camera zoom in from the levelmap to the player so you know where the exit is. you can make a new zoom out using token you got in the level. For the perspective problem, now you can rotate the camera with the B and N keys.
when i finish this i’ll post a new version on kongregate and redirect the link of my entry to the original hosted by me.

And tonight i’ll doing a Walktrough video for my game, because i supposed that not a lot of people saw the 3 levels after the tutorial.

Sorry if this Text is unreadable it is written in Frenglish.

The good things :

– I finished it
– The idea worked early the first day
– I code things i didn’t think i was capable of
– The creativity from LD blogpost/chat/streaming help a lot
– Pretty Happy with the result

The bad things :
– Having an idea don’t say it’s a good one
– Making art take time, especially when crashing
– Lost Motivation on day 2 afternoon
– Panic about panicking
– Tweaking take time and feedback need to be undersood
– Unable to read Irc Chat
– Look at how frustrating is your game

Timeline (approximative):

Day1 :
9h00 : Woke up, look at the theme while Breakfast
10h00 : panicking because i vote for the theme and have no idea about what to do except crappy 2d plateformer
12h00 : lauching Unity to try an idea about falling ground
12h30 : walking on the falling ground seems fun !
13h00 : idea pop!
15h00 : first prototype on the web
18h00 : spend some time tweaking the game, from 2 friend feedback
23h00 : spend night making better texture for the blocks, you can find different ideas with the sources ( even PSD files)

Day2:
10h : 2nd prototype on the web
13h : made concept for the character, tweaking game, not really motivate
14h : Bumper Cube added
15h : Yay! my computer crash while making the uv of the character, of course no save at all…
17h : Character finished no one can play the level except me…
19h : Spend time to make the character rotating, too tired to do a easy thing like that. I found the game have good controls but other find it way too hard, Tweaking…
02h : Until Submission ( deadline 3h here) : Making The tutorials, menu, last tweaks… so tired

I like making charts, it’s a… thing. So I took some time to see how coolness is spread out over people, and how many ratings each person received. I might make updated versions on the one week mark and when it’s all over. Also I might make something regarding ratings received/coolness, but for now I got my fix. These values are from sometime today.

CLICK TO SEE

Tags: charts, coolness, ratings

So first and foremost, I have to make an apology. I wanted to spam the LD community with tons of blog posts during game development, but I wasn’t able to. Why not? Well… (apart from the website crashing and all that… )

Python, it turns out, is an amazing language to code games in. The greatest part for me is that the iteration process from code to test to code is incredibly quick, and error fixing is a breeze. Contrast with languages like Javascript where you often have to spend comparatively more time tracking down bugs and correcting for silly errors you made (like accidentally adding an integer to a string instead of another integer).

What this means is that I was flying through code. I think that in the first 6 hours after I woke up I had written about 500 lines of code, which is an astonishing rate for me. But then I stared to notice that my wrist was starting to hurt. I kept going, figuring that it was probably nothing, but then at about 2pm I realized I needed to stop coding because my wrist was killing me.

For the first time, I had reached my limits. I had never written so much code in such a short amount of time.

This was actually really terrifying for me, and I had a ton of thoughts fly through my head. I was worried that I wasn’t going to be able to finish my LD game because my wrist was going to slow me down immensely. I was worried I was going to develop RSI or carpal tunnel. I was just generally freaking out since nothing like that had happened before.

So I took a break. I went to eat lunch. Then I went and picked up a guitar and played the song you hear in the background. Then I realized my wrists still hurt, so I worked on graphics for a few hours. Then I did some google searching to see what people do in problems like these. Turns out that these kinds of problems are why people invented those weird looking ergonomic keyboards, and I conveniently had one lying around, so I used it.

That keyboard was the saving grace of the project. It is much less intensive on the wrists for some reason I can’t quite figure out – your wrists don’t move around as much for some reason. Without the keyboard, I probably would have gotten stuck halfway through, which would have been really depressing!

On the other hand, I did lose about ten hours of time that I could have really used to improve my game further. It’s a shame that it happened, but I’ve learned from it, and it’s also a mistake I won’t make again.

So, tl;dr: If you’re a coder, I highly recommend getting a split keyboard to code with, especially during competitions. Save your wrists from pain!

Finally, if you want to see what I suffered through pain to bring you, check it out: Escape Artist

This entry was posted on Sunday, August 28th, 2011 at 5:05 pm and is filed under LD #21. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

I guess I’ll write a little bit here about how my game turned out. Here is a screenshot as a reference.

Entry: http://www.ludumdare.com/compo/ludum-dare-21/?action=rate&uid=4628

This was my first Ludum Dare and I’m glad I participated. My game was originally intended to be a reverse tower defense game but it didn’t really work out exactly like I would have liked it to. I wanted it to be a frantic run through a bunch of randomly put together rooms with a bunch of towers shooting at you. I had that working about 24 hours in, but I came to the realization that it wasn’t fun at all. I contemplated quitting at that point because I was frustrated and a little angry that my game wasn’t fun. I ended up salvaging my game by reducing the number of followers the character has and trying to make the player be strategic with the way he navigates through the rooms in order to protect his followers. I’ll be honest that my game still wasn’t very fun, but I’m glad that I stuck it out and finished.

What went right:

• I finished!
• I liked the follower mechanic.
• I think my in-air spinning knife animation was pretty awesome.
• I tried something different. (As opposed to the type of game I would normally make)

What went wrong:

• Music. I have no musical talent at all, but sometimes I manage to get lucky and make a good track. I tried, but I failed.
• Game wasn’t fun.
• Lots of the code was poorly written.

Takeaways

• Awesome knife animation…
• Various future game ideas
• Motivation
• Experience

I really enjoyed participating and I definitely plan on participating in future Ludum Dares. The community here is awesome and I am very thankful for the people who work hard to organize this and keep everything running smoothly. You are doing an awesome job!

Tags: escape, LD21, postmortem

My Entry into Ludum Dare #21 was Untitled, a Abstract (non-Objective) platformer game.

Before I go into what went Wrong and Right, I just wanted to mention my workflow, and how many hours I had to work. My college classes started up the week prior to Ludum Dare #21, so I knew going in that I didn’t want to pull any All Nighters. I think that the only thing All Nighters do anyways is make your decisions bad ones. So Friday night I waited around for the theme to be announced, then once it was I just about dropped out, Escape was not a theme I wanted, and not one that an idea came to me right away for. Before I dropped out though I decided to write down a few ideas, and see if any inspired me, and what do you know, one did. I got started that night, and knocked out the player controls, as well as level generation (for the most part) before going to bed. Over the next two days I refined what I had, and added to it. I had to force myself to not over complicate the game, else it wouldn’t be finished. In any case, it was finished, and I am happy with the way it came out. I view Ludum Dare as a chance to prototype a game, that I may not otherwise make. So rather than trying to make a finish game in 48 hours, I aim to make a decent prototype of a game I’d like to make.

What went wrong (because I’m a Pessimist):

> Music, I really can’t find a way to like, or even work with LMMS. Its outside of my range of talent. I have found a few tools from reading others Postmortem Posts that I can work with, and that I will be using next time. But for LD21 I decided to leave out the earplug inducing garbage I made in LMMS.

> Some (many?) people didn’t understand where the theme came in, to quote a reply I wrote to one commenter: ” The “escape” theme is more conceptual, and I don’t expect it to click for everyone. Basically I took the though of playing a Abstract Painting, and the fact that Abstract paintings are designed in a way that continually draw you back in, and meshed the two together. There are many different times and experiences when I have seen people stare at an abstract piece, attempting to come to a conclusion, when the piece more than likely has no logical conclusion, abstract art just is. So maybe they were playing some kind of game instead?”

> The Controls, I don’t know why I went with push button controls for changing your color, it was a bad decision. Many people have brought up the controls being an issue, and that they would have liked to have a visual representation of the keys used. While I’ll agree that is one solution that would work, I knew from the start that I didn’t want to have a GUI mucking up the visuals. That’s the reason the scoreboard was at the bottom, and your time isn’t shown.

What went right:

> I felt that the scoreboard was very effective, it fit in with the game I was trying to make,  and I’m not aware of anyone not understanding what was the score, and what was filler text.

> The GIMP once again worked out great for me. I have never had a problem using GIMP, and have been using it on a daily basis for five years now (processing digital photography). I think I’m just used to were stuff is and how to work in GIMP now. I actually prefer GIMP over Photoshop now, from when I have had to use Photoshop for a class it has  been painful and I find myself constantly hitting the wrong keys.

> Construct Classic since Ludum Dare #20 (the first LD I participated in) I have worked to farther my understanding of Construct. In LD#20 I wasn’t really happy with Construct, I failed to understand how certain functions worked, and thus had bugs and problems with my entry. This time Construct worked really great, I really like that I can drop in the resources and have a game quickly. I also like that I still have almost full control of how objects behave, and what functions I need or don’t need.

> sfxr worked great as always, I was able to generate some fitting sound effects for my game quickly.

> Overall game play and look I though worked really well, sure it needs refinement in some areas, such as the scoring, and the controls. But I believe it is fun to play.

Whats coming next:

I really like the idea of the game, and what it could be. So I am going to continue working on the game, adding and revising features.

> The controls were first on my list, I have changed the controls to use the Mouse, you Left click on the colored object you want to pass through, and right click to unselect colors (makes them all solid). The new controls are tons better, and have made playing the game faster and in my opinion more fun.

> Scoring, I liked the idea of the scoring in the game, but it fail short in a few places. The first was the difference between scores, there was a really small difference (100 to 200). I have since revised the scoring to add in a Multiplier, collection 5 of colored pickup with give you a bonus. I then added additional bonus multiplied that you could get, such as getting to the bottom of the map within 20 seconds, or changing colors less than five times. Overall the scoring is working alot better now, you can score anywhere from 400 to 5000 points. Best of all there is somewhat of a balance between pickup hunting, and racing to the bottom.

> Music, I have actually been working on music most of today. I used Otomata to create a number of songs that are different but all fitting for the music that I wanted. I wanted a kind of ambient music that was just there. Ototmata allowed me to generate music that fit my needs.

> I’m adding more modes/difficulties/colors that will be configurable, as well as changing the look a bit.

> Online High scores table, I’ll be adding a rather robust Online Highscore board, that you will be able to sort by name, score, date, time, pickups collected, clicks (color changes), and a few other details.

> More help, for the Ludum Dare entry I kept the How to Play information in game really general, and it wasn’t particularly helpful. Now when you first load into the level the game starts paused, and shows more information that goes into a bit more detail.

Testing

I’m not sure when I will have a download out for the new version, it will be when I’m happy with it, and I have the features I want in. I have setup a page on Indie DB that I will be posting additional development details on.

Tags: postmortem

This is kind of a port-mortem of EscApe (there’s another game with same name, it’s not about that one :)) but I’m going to focus certain design choices I did in the 3 hours I created it.

Massive spoilers below, so if you intend to play my EscApe, go do it now!

“Your game is just a crummy monkey in a badly drawn cage”, you say? Perhaps, but there’s still more to it than meets they eye. Continue reading!

I’ve found two other games that are exactly the same as EscApe, except that they look and play quite differently. There’s The Power of Escape by BurnZeZ and BATHOS by johanp. I’ll use them to point out some differences in game design, which might sound like I’m trying to bash the other games, but that’s not my intention. Read it as constructive criticism.

The basic concept [of all 3] is of course to present the player with a room, which is impossible to escape using methods normally available in computer games. Not until the player starts thinking outside the box (or tries to quit the game, as we’ll see later), and takes what’s printed on her keyboard literally, she will escape the challenge. If executed correctly, this puzzle actually takes place in your room, rather on the computer screen.

Now, what did I try to do with this? My goal was to give as many hints as possible, without actually revealing the solution. I wanted the player after figuring it out to think “omg, why didn’t I think of that from the beginning?”.

Starting at the title, there’s a big green hint all over the screen. But I tried to draw your focus away from it, by making the game about an ape. You see, the title only says “escape” with “ape” highlighted.. or does it? To put even more emphasis on this I added the text “Can you help the ape escape?”. There’s actually one more thing, which I didn’t think of until later, that APE is written in a slightly stronger color than ESC, but I think the difference could have been even bigger.

Still at the title menu, at the bottom it just says ENTER (the compo version had more text, but I thought it was distracting so I changed it). This is also a hint, actually. You see, I don’t give any exact instructions on how to play the game – I will return to why shortly – you have to figure it out yourself. As I mentioned the solution is to read the Esc-key literally, and for this to work, all keys have to work in the same way. You enter the game by pressing the enter key. Simple enough.

Lack of instructions, yes? The reason is of course, that only thing worse than giving no instructions at all, would be to give partial or faulty instructions (without telling the player that they are faulty). So either you tell players what all keys do, which would spoil the puzzle, or you say nothing at all.

(BATHOS – not made by me)

As you can see BATHOS looks nothing like my game, it has much better graphics (and sound) and I thought it was incredibly funny as well. But the other Johan seems to have done the opposite in just about every choice I’ve described so far. In fact, it even seems like he knowingly tries to lead players in the wrong direction  By giving instructions, there’s nothing in the game – or deducted from experience of playing 100s of other computer games earlier – saying that there’s another unmentioned key that is crucial to winning. Further, if Z means “jump” and X means “pickup”, then Q might as well mean “escape”? IMHO it’s a little like playing Super Mario Bros and having to figure out that you have to press the reset button on your console to press to find the princess. Though BATHOS has a lot more comments and ratings than EscApe, so maybe this is what people wants

Back to our poor, caged simian. My idea here was to print out the key you pressed in clear text, so you would get the connection between its literal meaning and what goes on on screen. Initially I was going to make it more passive, so that pressing left would only make the monkey look left for example, but I ran out of time sooner than expected. People ought to figure out soon enough that moving around in the cage won’t help you, so I’m not sure it made any difference. Hopefully after coming to that conclusion, all the previously mentioned hints have trained the player enough to start pressing other keys to see if anything happens.

Due to this lack of time, there is a crucial part of the game missing; There should be more keys with functions in the game to lead the player from using the direction keys to thinking “aha! I need to press Esc to escape”. Not only would this help bridge the logical gap, but also add a little bit more fun to the game. These were some I thought of:

• Space – Launches the cage into space or something. Maybe the monkey just thinks about space. However, it is a very important key, as it’s likely one of the first ones the player tries pressing (partially because of its size and location and partially because of its use in other games).
• Shift – The ape shifts its weight around.
• Home – Text: “You can’t go home”
• Enter – Text: “You’re already inside”
• Dash (well, it’s technically a minus sign, but they look similar enough) – Quick sprint in either direction.
• End – Popup saying “Are you sure you want to end the game?” with possible quit.
• Backspace – Printed as “Back (from) space” and returns to the jungle. Maybe too far fetched.

So why am I ranting about all this? Because gradually training the player to adapt to your game’s rules and mechanics is how you write modern games. No game designer ships their game with a printed manual these days, and if they do, nobody is going to read it Another central concept of modern game design is to make player feel like they’re doing exactly what they want to, while they’re doing exactly what you want them to. This makes the player feel incredibly awesome and is a lot more rewarding that simply following a heavily scripted story. Ok, so EscApe isn’t Half-Life 2 (Valve are good at this), but maybe it’s a little bit more to it than you initially thought? 😉

I wonder what would happen if the next LD theme was “space”…

Tags: escape, game design, post-mortem

Hi there. Here’s the games downloader I’ve mentioned in an earlier post and on IRC:

https://gist.github.com/1178530

Check line 76 of the source code. There you can change the platform you want.
Note that this script won’t download files hosted on file sharing sites (mediafire, megaupload, …).

Also, feel free to patch it, use it and abuse it… (Ok, not too much abuse or else the LD site pays it :P)…

Have fun