Here you go: http://www.youtube.com/watch?v=30zRwUFP5Ww

Oh, and you can play the game here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=4431

Postmortem of “Lonely Island”, my first Ludum Dare entry.

http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=7542

The Good

I decided before the compo I would not make a game about killing things (having kids changes your thinking).  This helped me come up with something original (for me anyway).  Okay, so you kill the trees and you kill the fish when you cook it but hey, baby steps.

I took lots of breaks, got enough sleep, and ate healthy.  I think this made a big difference in my stress level.  I wasn’t even feeling that stressed when Sunday came and I still didn’t know what my game was going to be about.

I found an animation template that helped immensely.  My programmer graphics perhaps went from fugly to “charmingly ugly”.  I probably would have spend the whole two days just adjusting pixels to make the guy walk without it.

The Bad

I made the n00b mistake of committing my pre-competition thoughts to either Random Generation or Evolution themes, both having great possibilities.  I never thought Alone would win.  So when it did my mind went blank.  “How can I make an original game about being alone?  That’s like 90% of games already out there.”  I spent Saturday just making a generic game and hoping inspiration would hit me.  That might explain why you saw down trees by umm, punching them?

I waited until late the last night (GMT+1 here) to make most of my sounds.  My kids were sleeping in the next room and I was exhausted.  Not the ideal environment for trying to voice hilarious dialog.  Next time I will do this during the day and leave quiet night-time for coding and graphics.

Not enough playtesting. I got my wife to stop rolling her eyes long enough to try the game a couple of times so that helped.  Myself, I only played in easy mode (everything costs 1 log) to test all the features because building the boat over and over got tedious.  When your own game gets tedious to play after just a few times that should tell you something.  I missed the message because building the boat is still tedious.

Got too used to seeing my placeholder graphics for terrain.  The only piece of terrain that wasn’t created in the first 3 minutes of the compo is the freshwater, which is exactly one tile out of 300.  I should have looked at it with a more citical eye.  Spending just 20 minutes on terrain would have made the game look much better.

The Ugly

Not this time.  It was a thoroughly enjoyable experience.  Can’t wait for the next one!

Tags: postmortem

Thanks to WineSkin, I now have a working bundle for osx users to run.  The downside is that it is 155MB, and >400MB when uncompressed, because it contains an entire install of Mono.  Which is really ridiculous.  BUT AT LEAST IT WORKS.  And you don’t even have to install anything!

Linux users, you can also run in Wine if you download the windows version and use “winetricks mono2.8”.  Otherwise, you’ll have to install all the mono + sdl packages and run it the usual way.  I’m assuming Linux 64-bit is still broken but I have no way of verifying this since I don’t have a 64-bit Linux VM/machine.

Main game submission post, again, is here:
http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=7285

It’s a little late but here is the post mortem to my competition entry The Lonely Island, which you can find here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3428 .

The plan.

My plan was to make a bit of a survival simulator where you are stranded alone on an island and you have to slowly gather the resources you needed to make your escape. I wanted to have day/night cycles, mountain areas and loads of different items to find and craft. All this turned out to be a little too ambitious though and I ran out of time before I could add any of these things. In the end I had to quickly implement making a raft and escaping before the development time was up.

Day one

The first day went extremely well. I got the tile maps loading and rendering very quickly and made great progress on the GUI along with some of the more important mechanics. I’m not too familiar with AS3 and Flash Punk but most the things I tried to do either worked first time or worked shortly after trying to implement it. Bug’s didn’t take more than 5 – 10 minutes to fix and it started to look like I would be able to add either everything or most things I had planned on, but I was wrong.

Day two

In comparison to day one, day two was a nightmare. Nothing worked first time and major bugs took what seemed like forever to fix. It didn’t take long for me to see I either wasn’t going to finish on time or I wasn’t going to be able to add many features. I started off the day by getting the map scrolling with the players movement, and this caused a load of problems and broke most of my GUI and I had to spend at least half the day fixing everything. I learned a valuable lesson from this though, get scrolling maps in ASAP in the future. After I finished climbing over that humongous hurdle I didn’t have long left to implement the crafting system. After thinking for a while and the most easy and time efficient way to get crafting in I decided to go with a simple combining method for creating tools and the raft. By the time this was done I only had about 20 minutes to implement some simple sound effects and get my game submitted.

What went well

I have never really tried to make a GUI before so I’m pretty proud of the results, even if it is a little crude. This is also my first game from the top-down perspective, which was a nice change of pace making.

What  didn’t go well

Many things. The art, for instance wasn’t particularly good but then again my art never is, I just wish I had some more time to spend on it.
The scrolling maps, as I stated earlier, didn’t go well while implementing and ate up most my time but at least it got sorted out in the end.
My game also ended up being too easy and lacking in features as a result of various problems and the time constraint.

Most importantly, did I have fun?

Hell yeah I did. Making a game to a set theme in 48 hours is an amazing experience and I learn so much each time I enter. Ludum Dare also has an amazing community surrounding it which I am proud to be a part of.

Click here to play my game: Paper Town!

Developers often do a “Post-Mortem” after completing a project, exploring the things that went right and wrong. This helps them keep track of what they’ve learned and also help other people who are going to try the same thing.

What went right

The Story

“Alone” is really a mood theme, rather than a mechanics one, and that had me a bit stumped at first. All the neat “physics” and “sim” ideas I had in my head needed to be thrown out.  The gameplay was to be a slave to the story, which is pretty much the inverse of how I usually think.

Right from the beginning, I had toyed with the idea that the protagonist is not literally alone — just that he feels alone.  Paper Town takes that the next level and places the player in the mind of someone who is psychologically damaged and is living in a world where he perceives himself to be alone and can’t recognize the presence of people around him who are trying to help.

I believe it’s an idea that can resonate with a lot of people. You may feel lonely, but at the same time you pull away from other people and avoid talking to strangers.  This explores the extreme outcome of that:  The character will in one line of dialog lament the fact that everyone has left him, but in another line of dialog scream “LEAVE ME ALONE” to the nebulous entities that sometimes appear.

It’s through the development of the story via note pickups that the character finally gets a chance to recognize that his solitary universe is self-inflicted and that he can break out of it through a true desire to be with other people.

Unity 3d

For a lot of people, the spirit of Ludum Dare is to build everything from scratch — or as much as is possible without implementing your own programming language and basic library of functions.  However, I very much wanted to build a complete game and starting with a fully functional gaming engine went a long way towards ensuring that.  Being able to drop in primitives and start programming behaviour 5 minutes after deciding on an outline for my game was incredible.  Not having to worry about how to load images and sound, nor do physics, was likewise amazing.  Also, having access to some great pathfinding middleware was also exceptionally helpful, though it brought its own problems (see below).

On the other hand, since my challenge wouldn’t be about the base engine, it means that I had to make certain that my execution of the theme was top notch.  I wanted to tell a complete story, and I wanted to make sure that there was a way to win and to lose the game.  I think it takes about 10 minutes to win.

I didn’t have the time or the ability to do any 3d modelling, but I did as much as I could using pure primitives (cubes, planes, spheres, and capsules).  I’m also pretty keen on my moody lighting effects.

Time Management

While there are certainly things I would have liked to have gotten done if I had more time, I actually didn’t feel very rushed during the 48 hours, and I think a lot of it had to do with having a solid time plan right from the beginning.

The theme announcement and start of the competition was at 9:00 PM my time on a Friday, so that evening was all about coming up with the idea for the gameplay and story, and to setup the initial environment in Unity (terrain, character, a simple building, and the ability for the player to click/pathfind around the obstacle).

Saturday was planned to be “gameplay” day. I generally didn’t worry about the actual looks/art.  The game just had to be playable, and by the end of the day all the major gameplay features were present:

• Randomly generated city, including 4 types of buildings, streets with intersections, lightposts with actual lights
• Enemies that would spawn, patrol around, and chase the player if they saw him — dealing damage if they got close.
• Pickups for the player, which would be stored in inventory
• The ability to create a “paper doll” with the right items. A “paper doll” is a turret that shoot bullets at enemies.

Sunday was planned to be “story development”.  I know it may seem weird to play on having 50% of your time to do all the “real” features and 50% of the time to do “fluff” and polish, but in practice the big features don’t take that much time. They’re often far more straightforward and easier to understand. It’s the fine-tuning that can be really time-consuming, but it’s also the thing that truly sells your product in the end.

I think my final story is a bit cliche and maudlin, but still works to really sell the theme.  This time allocation meant that I was also comfortable spending time making sounds and intro/end screens, which I think are an important part of the “complete” package but often get overlooked in the face of adding more gameplay features.

Things I did on the final day:

• Redid city generation (it was crap and the road/fence were very crap)
• A dialog system, allowing the story to be told during gameplay (and also to explain gameplay mechanics as they come up)
• Added a new pickup type: Notes. These are used for the victory condition and also trigger lots of dialog.
• Changed player to WSAD/Mouse movement
• Fiddled with the pathfinding multiple times
• Rebalanced the enemies and pickups multiple times
• Added a day/night cycle, which looks good and controls enemy spawning
• Intro screen!
• Win and loss screens!
• Sound effects!
• Music!

Food and Drinks

Lots of good, satisfying food at my disposal.  No junk food, and nothing that would leave me with messy fingers. Also, everything could be prepared in just a few minutes, minimizing downtime.

Meal examples:

• Bacon and Eggs
• Avocado with Sriracha hot sauce (sooooo goood)
• Tuna salad
• Leftover ground beef/veggie casserole

Note that these are low-carb, high fat foods that fit into my Keto diet. If someone on a standard diet ate like this for 48 hours, they’d probably feel a bit foggy-headed, which wouldn’t be ideal for the competition.

Live Streaming

This was by far the single best choice I made with regards to Ludum Dare.  Having hundreds of people watching me all weekend kept me motivated and entertained and provided me with a veritable army of beta-testers!  I had to create all the game code and content myself, but having people provide immediate feedback was invaluable.

All the videos from the stream should be available on my Twitch.tv account, starting with this one.

Sound

Many Ludum Dare games don’t have any sound, or at best just include a few bloops and bleeps generated with a tool like BFXR — which was absolutely my plan too.  However, in practice I really wasn’t happy with these sounds. I felt like their arcadiness took away from the mood of the game, and I’d just about given up on the sound (which was already an Final Hour job)…but my stream viewers made a case for the importance of sound and music. And I’m happy they did!

So I went to Plan B for sound, which was simply to use my microphone. Sound effects for item pickups came from flipping pages in a book (Python & XML in a Nutshell), and music came from something I’ve never done before: Me playing an instrument in front of an audience.  I played a few bars of some badly off-tempo blues scale on my harmonica and then slowed down the recording (which also lowered the pitch). The result is a haunting soundtrack (with two songs) that – while far from good – is way better than no sound at all.

What went wrong

Pathfinding

One of the resources that was in my toolbox even before the theme was announced was the great A* Pathfinding middleware by Aron Granberg.  It’s a very simple drop-in solution that makes it pretty easy to add basic pathfinding to a project.  I like to use it by attaching an empty “pathfinding target” gameobject to my units and just moving that target around to make things happen.

Unfortunately, I ran into some limitations with the default way of using the middleware that caused to pretty serious problems and almost wrecked my whole idea.  I wanted a fairly large city for the player to explore, but the combination of a large area with the need for a fairly fine pathfinding grid (to be able to maneuver around furniture around buildings) meant that we were generating far too many nodes and Unity would crash.  After some fiddling, I was able to find a compromise between city size (3×3 blocks with 2×3 buildings each, for a total of 54 buildings) and grid resolution. At that point, things seemed to work pretty well until I started balancing the game.

It quickly became apparent that I needed quite a few enemies to appropriately populate my relatively large city space, but as I increased the number of units my pathfinding system started to lag.  Luckily it’s pretty intelligently designed, so the actual game performance was unhindered, but the pathfinding request queue was taking longer and longer to get through.  This wasn’t necessarily a problem for the AI, since it’s not the end of the world if it takes them half a second to change to a new path in response to stimulus (it just makes them a tad easier to juke).

For the player’s mouse-controls, however, it was a big problem.

Mouse Controls

One of the first things I added to the game was a click-to-move functionality.  Reasons for this were varied, but a big part of it was a drive for simplicity. I wanted a game that was utterly intuitive for anyone to play.

My initial approach was to do a raycast from the screen to the ground when the mouse was clicked, which worked great. Unfortunately, Unity doesn’t provide a simple way to eat mouseclicks when the player hits the GUI, so interacting with it meant the player was moving unintentionally.

The second approach was to have the ground react to OnMouseClick events, which worked just as well but wouldn’t be triggered when the user was clicking on the UI. Unfortunately, it also does not trigger if the user is clicking on another model, including my road segments and building floors, so I had to ensure that my “HandleMouseClick” behaviour existed on all relevant objects, including pickups.  This worked okay.  Until I ran into my pathfinding issues.

During the day, everything was pretty good (minus a little funniness due to the pathfinding grid resolution), but at night when enemies showed up, there was a noticeable delay when clicking due to the pathfinding queue being pretty full.

In the end, I gave up on mouse controls and switched to WASD/Arrow controls, leaving the player feeling very responsive.

Raycasting/Line-of-sight

I’d decided pretty early on to make the building outer walls quite low, that way the player could easily click on the ground inside and also not worry about the player being hidden behind a wall (due to my fixed camera angle). This lead to me having to fiddle a bit with my line-of-sight tests with enemies, because they shouldn’t see the player through a wall.  I had to make sure that my raycast was low enough to be blocked by the short walls, but high enough to not get screwed up by the lip around the road or the strange mesh deformity on the player’s capsule model.  It ended up being kind of fiddly.

It would have been nice to put an invisible wall around the buildings and have them block enemy LOS rays, but between the UI, the “shade” block inside the buildings, and the invisible walls I couldn’t figure out a way to allow mouse-click raycasts to get through while blocking enemy raycasts.

Of course, that was all moot by my switch to WASD/Arrow movement, but that change happened way too late in development to save me any trouble with the enemies.

Randomly generated content

This always SOUNDS so cool, but for a game like this I’m not sure it does anything for the gameplay, nor am I sure that it saved me any time.  Yes, placing individual buildings would have been a pain, but I spent so long having to tweak the system so that the buildings and roads all ended up in the correct location that I think it took longer than doing it manually would have.  And it’s still not perfect!  There’s slightly more space on one side of the blocks than on the other.

Even things like Pickup spawns were totally random at first, but sometimes pickups would land on top of objects and be inaccessible to the player.  Ultimately, I placed empty gameobjects to act as spawn points and that worked so much better (I also did this with enemies).

So if I *did* want randomized buildings, without having to worry about getting my placement math right, I should have manually positioned building placeholders and just have them be populated at program start.

Note that I had intended to make my city bigger (which is why I felt that random generation was the way to go), but I had to scale down my plans due to pathfinding contraints.  I do think my final city is a good size for the actual game.

Paper Dolls

The idea that the protagonist has devolved to making paper dolls in order to combat his loneliness came about very early and was meant to be a major part of the gameplay, adding in a “tower defense” component. However, this never came to be and as a result the act of creating the paper dolls and their use in gameplay is rather secondary.  It’s still better than not having them at all (and having the game just be about exploration and hiding), but I think more could have been done with them.

To a certain extent, the weakness of the doll theme is a result of the time limitations with regards to creating more enemy types and behaviours and just general game balance.  I also think that the dolls are dependent on a certain amount of art development — I think they deserve a cutscene for their creation, to add real emotional depth.

Another contributing factor to not further developing the paper dolls idea was the conflict between static, unmoving, tower-defensive gameplay and the need to explore to find notes to advance the story (and win the game). Making the dolls secondary (and have very limited ammo) turned them into something that was just a tool to help you survive a bit longer and facilitate your exploration (and thus completion of the story).

Conclusion

I consider this project to have been a HUGE SUCCESS! I program all the time, but usually I’m making business-oriented web applications.  I have started many games, but I’ve never finished one before.  Paper Town may be rough, but it is a complete game and that makes me extremely happy.

Also, even if the game hadn’t worked out, we still had a stream that averaged 100 people for an entire weekend.  That’s amazing!

I absolutely hope that I can participate in the next Ludum Dare, but I also hope that I can find more time to make games in general.

Tags: LD22, postmortern

Here’s the actual game page.

What went well?

1. Preparation

I spend the two weeks leading up to LD22 learning how to make simple models in Blender. I’ve never had much more than a passing knowledge of Maya or Max ( I could operate them, but not build anything ). Despite making games professionally for 10 years there had always been an air of mystery about how artists actually realised things in these packages. Turns out there is no mystery at all. It’s really straightforward, that’s not to say I’m a good artist now :-). Anyway, having that experience meant, I knew what I could build and how to build it. So there was very little learning in the 48hrs, I could just get on with it.

2. Knowing the engine

I wrote a significant chunk of the PlayCanvas Engine, so I know it pretty well inside out. Not only that, but the engine is written in javascript, so I could step into it and debug from game-code into engine-code with no added steps. It’s incredibly helpful not to be using a ‘black box’ engine, you can always see exactly what is going on.

3. Tools

I’m very big on tooling for game development, and I think it’s critical to have great tools. The PlayCanvas tools did well despite being early in development. Having simple features like Undo/Redo is such a time-saver.

4. Rapid deployment

I could deploy my game in a couple of seconds and have it ready-to-play by anyone. If there had been an extended packing and publishing stage for me to complete I probably wouldn’t have got it out by the deadline.

What didn’t go well?

1. Physics and Collision Detection

Collision detection and physics is hard, not only is it hard to comprehend, but it takes long time to debug and get stable and working. Trying to do 3D collision detection and dynamics in a 48 game jam isn’t very sensible. Still I got it mostly working. I had to remove some bits where you could jump gaps with the ball because the physics wasn’t stable enough. Next time I’ll either do something without complicated physics, or hope that there is an existing stable implementation. If you’re interested I used verlet integration.

2. Tools

Tools are so important that when they have issues, it can really slow you up. Some features of the tools were slow, and it cost me a lot of time to make small changes when it should have been quick. But on the plus side, I now have a big list of bugs to fix.

3. Audio

No time, no skills, no audio. I really wanted to go out and record some grinding stone noises to add some flavour to the movement, but I just never had the time.

4. Timelapse

I wanted to record a timelapse, I did the first day, and them somehow failed to start recording on the second day, dammit!

Conclusion

This was my first Ludum Dare, though I followed the last one with interest. It was a fantastic experience, I’ll certainly be doing it again, and next time I’ll be even better. Sitting in on the irc channel was also really fun. This is a great community of people sharing, helping and really pushing forward games development.

Also this was the first real test of our HTML5 engine PlayCanvas, and I think it did pretty well. If you’re interested in trying it out I’d love to help you, drop me a mail dave@playcanvas.com.

So I had a lot of issues with the recording… first time I’ve done this sort of thing and all :S

Ended up losing a bunch of the data. Very annoying but ah well.

Check it out anyway! The best bits were the ones that I lost …of course 😉

video link

my entry

until next time!

I really have to say, I had a great time participating in this Ludum Dare, and first of all, I want to say I’m gonna do it again! LD is such an awesome experience!

I was surprised I did not have much problems during the development. I couldn’t code on saturday, but that was not a problem after all.

This game btw

What went wrong:
– Sound. I planned to make a music and add some sfxr’ed effects, but when I was done with coding, it was already monday here in germany, and I had to write a test this day. All in all I got 3 hours of sleep, and did not feel great that day. But I don’t regret anything. ^^ Anyway, sound is something, I would have liked to include. In the post-compo version, I added it.

What went right:
– Planning: I used 6 hours of saturday to write everything on paper. This of course gave me the opportunity to develop with a full concept of how the game should be, which resulted in enhanced coding speed!
– Discipline: I got up at 7 am in the morning, and coded nearly straigt until midnight. But I drunk way to less, just one and a half pot of tea for the entire day!
– Gameplay: The gameplay developed amazingly nice. I did plan how to make the game, how it would be was unknown, in my opinion, the gameplay is quite nice.

I had a todo-list, which gave me motivation, each time I completed a point.

P.S.: Many thanks to Notch for bringing me here with his timelapse videos! (Metagun!!! Breaking the Tower!!!! Bunny Press!!!)

Just like manual PvZ

La instalación fue fácil, sólo apareció en el CD-ROM y hacer clic en el icono de instalación. Después de abrir el paquete de software lo primero que debe hacer es asignar mi tarjeta Digi 001 como la tarjeta de sonido de audio para ser utilizados por Traktor. Artículo recomendado por Traktor

I’ve wanted to do Ludum Dare for a long time, but for one reason or another kept missing it.

This time I decided I wouldn’t miss it, no matter what happened, I would be doing LD22!

And then my brother’s wedding happened to fall on the first day of Ludum Dare.  And added aspect of complication was that I was the best man and celebrant of the wedding.
Initially I thought I couldn’t do it, I wanted to be quite ambitious with Ludum Dare and create something very polished.  But I’d most likely lose most of the weekend to the wedding and planning it.

So it inevitable I’d have to make a minimalistic, simple, procedurally generated game .

Play the game

Rate the game

Intro to First Cell

‘Alone’ is a difficult theme…

because game design is based around interaction with other entities.  It limits the possibilities of your game when you are meant to be alone.
But I also firmly believe that external limitations bring focus and help the creative process.
I was at the wedding when a friend emailed me which theme was announced.  And I had a good 12 hours before I’d be home coding.  But the entire time I couldn’t think of an idea I could complete in 24-36 hours.
But I had a game mechanic floating around in my head for a while that I had never coded, so I thought I’ll work on that idea, and if I can’t get it to work with the theme, so be it, at least I would be productive.

The mechanic:

The columns on the left are before collision, the columns on the right are after collision

The concept behind the mechanic was a system whereby shapes would morph into new shapes based on the number of corners on each shape.
In the diagram you can see that if a square hits a triangle, they simple swap, same goes for a square and a pentagon.  This is because there is only a difference of 1 in the corner count.
At the bottom of the diagram you can see that a square colliding with an octagon will result in both shapes becoming pentagons.

In essence the shapes lose or gain the difference between there corners when they collide.

But I did not know what the game was going to be, a 2d shooter? a puzzle game? an evolutionary art piece?

A similar diagram but in the case of the triangle collisions.

Workspace:

My workspace during the LD22 Compo

A great workspace, I came to visit my parents in the Blue Mountains for the wedding so I set up my computer //Atlas, on their dining table.

You can see the garden as you code, it’s much nicer than Sydney.

Something I ate while doing the compo.

Notes:

When the reception was over I got home and started coding straight away, probably about Midnight.  I decided I’d get shape generation working first and assumed I’d figure out how to turn it into a game as I went a long.

Here is my notepad file which I used to brainstorm as I coded:

-----------------------------------------------------

acceleration increase when collide
 friction over time
 interaction keeps the system going!
 ENTROPY > lonely?
 
 Initially nothing moves, but you bump into it, and it brings the world to life!
 
 mist, and prisms!
 
 darkness, you emit light!
 
 when you accidentally bump into an object, it slightly illuminates and begins to move, but will
 slow down over time unless it collides with something else.
 
 this sets of a chain reation, lighting up everything!
 
 sounds to represent this change!
 
 the shapes change when they collide.
 You need to be a certain shape to fit through certain parts of the world
 
 NO lighting - too hard
 
 just use shades of flat colour.
 
 Lighting actually easier than expected.
 
 1.Wake up your friends
 3.Become a goal shape
 4.Avoid
 5.
 6.Eventually create a fish creature out of composite shapes.
 7.Cell replication?

-----------------------------------------------------

So the fish creature didn’t happen and I had a few problem with collision along the way.
I really could have benefited from setting up a simple simple engine beforehand to save me from figuring out simple issues.  Next time I’ll know and maybe try out Flashpunk or Flixel or lwjgl.

Alone – Aha Moment!

There was a moment where I realised how to make this game that was fairly interesting I literally stood up and did a dance.  It was a great feeling.

Timelapse

can be found here.

Gameplay Video

can be found here.
What worked, what didn’t, lessons learned.

What worked:

I like the aesthetic, I like the game mechanic, I feel the game is really fun.  It is just kind of arthouse and obscures how easy it actually is to play.

I accidentally made the game quite in depth.  Because there is a system behind the game there is possibilities to master that system, and also for emergent gameplay to arise.

Blending modes in AS3 are great.  The red glow has this brilliant effect of creating silhouettes of shapes around you, it’s almost like a sonar.  It dissipates over distance.

I really like the sudden flashes of light at the beginning of each round, combined with the thunder.  The sounds in general work very well, and even though most people didn’t understand how to play(my fault), they all seemed to enjoy the mood of the game.

I showed a few friends, and after explaining to them how it worked they contacted me later saying they have been playing it since and really like it, and that they actually find it quite addictive because it has no precise ending(muahaha!).

Blending Modes in AS3 are really powerful.

What didn’t work:

It is a dark game, it is also not a recognizable genre, it is abstract.  So that means I had to fight for the players commitment.

To see around you all you have to do is move.  The trouble is the timid uncertain players will probably not move.  It is a game where you have to remember where each shape is and navigate there quickly before the shapes change.  But that isn’t communicated, that is only observed after playing a while. If you sit there, everything will go dark and your opportunity to hit the once shape you need will escape.

I don’t like the fact that it isn’t accesible.  A few hours after the submission time I added some in game help and made the glow colour red to help differentiate the player from the other shapes.

But really the nature of the game is that it is abstract, and it is hard to have pure aesthetics and also accessibility.

Lessons learned:

Play testing is actually important?
Submit now, test later?  It doesn’t work.  If you are lucky you will get 10 reviews from users, I had 3 within the first few hours of submission.  Their feedback was great, it helped me make the game a lot better.  But they were judging the game  based on that snapshot.  Probably best to test on people that aren’t going to affect your score.  It’s good to get a friend to ask their friends what they think, they will be more brutal when they aren’t saying things to your face.

In game help is actually important!
Sure have a blurb, on your website, but a lot of people prefer to download the binaries.  People also often skip reading the help, because we always think we will understand things immediately.
Have in-game help and make it unavoidable.  I made my help context sensitive, so if the player was going well, I wouldn’t give them hints.  But I think you can take that a lot further.

Have a tutorial, or some kind of learning curve.
I really really wish I went down the route of levels designed to teach the mechanic and the concept.  I think of the first few stages of Osmos and how short that tutorial and how it so smoothly bleeds into the game.
I also think about Miyamoto saying to never blame the player if they don’t “get” your game.  It is always the game designers job to work around that, to communicate better.

Ludum Dare is more work than just the 48 hour jam.
    I am sure a lot of the veterans know this, but once you submit your game you should rate and review other peoples games.  You should probably have created a time lapse, a game play video.
You have a short period of time where you can make subtle bug fixes, so you are actually working a lot after the competition.  Uploading, testing and dealing with the consequences of doing a 48 game jam.

Assume nothing!
    I assumed that people would just assume (double assume!) that you used the arrow keys to move.  But when I tested some people tried to accelerate with space bar, some people used WASD, some people tried to use the mouse.
So I ended up adding a lot of alternate control schemes.

Uploading takes ages.
Especially  in Australia.  The site couldn’t handle the simultaneous uploads so we were given extra time.  Without that extra time I wouldn’t have made it in time.
I suggest upload your resources and other larger files early on, you will most likely only be changing source code.  Then you can upload a single zip file after the competition is over.  That way you cover all bases.

A lot of my favourite games…

are Ludum Dare games, and as a game development student I use them all the time as game design and code examples.  I tried to encourage friends and other students to participate and maybe they will next time.

I am actually honoured to have submitted a game alongside so many creative and talented people.

Shapes illuminated at the start of a round.

Thanks for reading the Post Mortem, I hope you play the game, and I wish you the best.

Cheers,

Canyon

Play the game

Rate the game

More than 48 hours have passed since the weekend and I think I now have enough distance to my creation to write a post mortem about it. I will look at different aspects of the experience rather than do a general “What went right, what went wrong?” list. So here it goes:

Design Process

Initially I wasn’t very happy with the theme. “Alone” may seem to offer a very deep and “indie” setting for games, but in reality it limits the narrative possibilities. On the other hand, this is true for almost all suggested themes and may be a good thing (see “Lessons Learned”). Anyways, after my two past experiences with game jams, I tried to structure the design process a little. First, I simply wrote down the different meanings of “alone” as well as syno- and antonyms and tried to work from that. Next I compiled a table with “Theme”, “Conflict”, “Core Mechanics”, “Pro” and “Contra” with different ideas. “Theme” would set the general framework of the game, while “Conflict” captured what should drive you to play the game and “Core Mechanic” described in a few words what you should be doing while playing:

The middle contra – “Complex” – should have set off some sort of alarm and it probably did, but I set it to snooze. My next favourite idea “The First(Last) Zombie” would have been a zombie sneaking game where you, the Zombie, would have to get past hordes of armed humans to feed on their young ones. I ditched it because the need for neat graphics, some sort of AI and the overuse of Zombies in general. In retrospect I probably should have sticked to it.

After that, I went to bed (around 4:30 am local time) to let the idea rest. I did not do any code or graphics or sound, which was a good idea.

Code

Overall, I am pretty satisfied with the code. Of course the quality could have been better, but it is amazingly clean for being yanked out in 48 hours. Counting the line of code using cloc reports 1393 lines of Lua or the equivalent of 5572 3rd gen code. That excludes blanks, comments, libraries I used and the code I deleted in the process. I also implemented a tile engine (with automatically computed tile transitions) which I had never done before. This turned out to be a good idea, since it helps speed up the design process a lot, and you can use tools already available for level design (I used the gimp). I will invest some time to learn more about tile engines in the future.

Graphics

Well, what can I say? Graphics are not really my strong point. Diagrams and technical stuff I can do just fine, but anything else is a disaster. Part of it stems from my lack of understanding my tools well enough. I will need to learn how to draw stuff and the proper usage of Gimp and Inkscape (or some other graphics program).

Audio

Audio turned out rather nicely. Though I have no idea how to do music, “Alone” begs for very minimal or even no music. Instead I focused on ambient sounds which I created using Audacity, my crappy laptop microphone and a little bit of bfxr. Making the sounds was a really fun experience, which I hope to repeat next time.

Other Aspects

Because an active mind needs a lot of energy, I tried to eat healthy this time. Cooking the food
also helped to take my mind off immediate problems and to see the big picture. This I will do again. Unfortunately I ran out of snacks pretty quickly. I greatly underestimated the need for this stuff. What I did and probably shouldn’t have was drinking a lot of coffee. It sure helped to focus and stay awake, but once the effects wore off, I felt even more exhausted than I would have without caffeine.

Lessons Learned

The first and foremost lesson I took from this experience is that I need to impose limits. Limits not only on the game design (i.e. make it simple), but also on the inputs and graphics. A LD game should be playable using Gameboy controls, which means two buttons plus 4 movement directions at top. Better just one button and two directions to move. This will have two effects: First, the game needs no real explanation/tutorial, and secondly, the game mechanics have to be chosen accordingly. Graphics wise I will probably use a 16 or less color palette next time. Other lessens learned: Less caffeine; Tile engines are useful; and Sound design is great fun.

See you next time.

Play/Rate

Stray Whisker Here!

When the theme was announced I was lucky to get an idea pretty quickly. Since kittens had been another candidate I had already been thinking about games with cats and so I decided to create a game where a kitten was left alone to fend for itself until the player was able to find others. I started making the game with no idea of how it would actually play in the end. I just concentrated on making the game as fun as possible to just move around and be a cat. I didn’t consider any goals for the player, and even in the finished game I don’t really think there’s really a “goal”. There is an ending. I just wanted to make a game where you could play as a cat. And in essence, that’s what my game is about. It’s about pretending you’re a cat, jumping around like a cat and being a cat. If people find enjoyment in simply moving and interacting with the objects in the world, then I think that the game achieves this aim. In a way, it’s like being a little kid playing with a toy figure outside, except instead of a toy figure, you have a virtual one. You can “win” the game in a very very short amount of time, but I would expect (“hope”) that people would spend time exploring the world and jumping around.

If you haven’t played the game yet you can Play And Rate The Game Here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3289

It would be good to play it first since the following may contain spoilers.

With these things in mind, here is my short post-mortem:

Things that went well

• Graphics and cat animations. I rarely do graphics for my games. I usually partner with someone else and I’m the code monkey. So I was pretty happy with the graphics I did in this game. I started out doing “rough sketches” for the cat and buildings, however I liked the style and so I kept them for the whole game. Many people have asked me what tablet I used to draw the sprites with, but I actually just used my normal mouse. I have a large mousepad so I was able to do large sweeps to get natural curvy lines such as in the trees. I felt that the animations were quite fluid and I’m happy with those.
• Visual ambiance. I wanted there to be a lot of “stuff” to play with in the game and I think there is a fair bit to do such as smashing pots, playing with the ball, wind particles, leaves, grass, water, butterfly, etc. I would have added more of this if I had time (rubbish, rats, more ‘junk’).
• The red ball. I am very happy with the movement of the red ball and I think it’s a lot of fun to play with. Some people do find it hard to move exactly where they want, which is understandable. I find it easier myself because I spent so long playing with it while developing the game. I would have probably tweaked the movement a little so that you didn’t have to throw it around so much to get it to go where you want it. One thing I really love about the red ball is that nobody ever says that you need the red ball. Yet almost all of the players I have seen play my game attempt to take the ball as far as they can to the end.
• The Cat AI. I’m pretty happy with the AI of the cats that you come across. They weren’t meant to follow you constantly, or be completely random, and I think they’ve got a good blend. The AI of the cats you encounter differs slightly (the blue one is a bit more ‘sporadic’) but they both switch between moving randomly, following you and following the ball. Some people found the other cats annoying when you’re trying to move the ball – but I think they’re fun. They want the ball just as much as you!
• The cat movement. I think it’s very fun to just run and jump around, with no particular goal in mind, and that was one of my aims for this game which I think I’ve achieved.
• Level Design. I designed a lot of the game in a way which hopefully also explains the player’s abilities. An example of this is when you encounter the red ball. There is a wall directly in front of it, indicating that the ball can indeed be thrown. I also was quite happy with the placement of certain “triggers” such as when the first cat starts following you. Having watched people play the game, they all seem to do the exact same thing. They stop when they see the blue cat… jump up and down for a bit, trying to get its attention, and when they finally give up and think that the cat won’t follow them, they walk off to the right and the cat jumps down. Similarly the interaction with the dog forces the player to jump over it to dodge it, and the lack of buildings makes it a true chase.
• Focused effort. I put a real good effort into this game and I think it really paid off. I really did spent most of the weekend on it apart from a couple of a parties at night. And I even went crazy and pulled an all nighter on the last day until 7AM in the morning!

Things that could have gone better

• Only one ending. I had originally designed the game for two endings, one with the girl and one with the kitten friends you have made. I was hoping that the player would have then been faced with an emotional decision to choose between the cat friends they had made and the girl, their owner. I wasn’t able to implement a second ending for a couple of reasons: I created the girl’s ending first, and after doing so I found it very difficult to work out where exactly to place the alternate ending. Should it have been when you walked into the kitten den? The problem with that is that then the secret (where you take the ball to the kitten den) would not have worked, as it would have triggered the alternate ending first. The second reason I didn’t put it in was of course, as always, I didn’t really have time to do it. In the end I compromised with one ending and one secret.
• Variety in the backgrounds. I had hoped to have every single object (primarily buildings/trees) uniquely drawn. I did pretty well with making the trees unique, but there were only 3 building types which I duplicated many times throughout the game. Again the reason for this was time, and a bit of effort. The buildings weren’t really that hard to draw but I had to complete other more important tasks.
• Music. There was no music or ambiance in the game. I spent some time (as you can see in my timelapse) mucking around with FL Studio to create some ambient music. I didn’t finish this and I didn’t use any music in the end as I felt that a bad track would actually detract from the overall game. There is one gorgeous track by FearOfDark that would have suited the game very well I think. However since this is LD we of course have to make everything from scratch. The track is here: https://8bc.org/music/FearofDark/Recovery+%28VRC6%29/ Try playing the game with this in the background!
• Sound. I did some sounds pretty well I think but there could have been more. In the end I had jump/land/pot break/pot hit/dog bark x 3/various meows (in retrospect that is a fair few effects )

If I had another chance I don’t think I would have done anything differently (process/time-wise). I would have changed the above problems in my game, but overall I am quite proud of what I made and I think it’s an entertaining little game for 48 hours.

I hope that this post will help others in developing their games next LD!

Please checkout my game if you haven’t already done so: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=3289

Welcome to part 2 in my 3 part postmortem series for my game ZERO2. In this post I’m going to breakdown the creation of a single environment used in the game. But hey, if you haven’t played the game yet please check it out first:

http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5821#LD48

CONCEPT

The first step to creating any environment for me is simply coming up with a concept for it. In this game I wanted to have two main types of environments: puzzle environments, where the player would need to focus on solving some obstacle to progress, and atmospheric environments, which would serve more to set the mood and advance the story rather than offer any gameplay.

For this breakdown I’m going to use my personal favorite environment from the game, which happens to fall into the ‘atmospheric environment’ category. At this point in the game, the player has just passed a fairly ‘scary’ portion of the game, so I wanted this area to serve as a bit of a respite. I also wanted to give the player some more clues about what was going on as well, as the game is purposefully vague and mysterious, not much has been revealed up til this point.

The idea I came up with was a fairly open ‘lobby’ type space, the focus being on a large geometric statue in the center. The implication being that this room is basically a gateway to a new section of this facility, one meant to serve as a thematic representation for the goals of the organization at work here. The twist being that the room is not pristine or brightly lit as one would expect, but flooded, dusty and crumbling.

CREATION

So I started building using my 3d tool of choice, Cinema 4d.

Here you can see the finished environment in the editor. Like all the environments in this game it is comprised mainly of rectangles of various shapes and sizes. The most time intensive element in the whole scene was the construction light on the right which I modeled based on an image I found in a Google search. But what about the statue in the middle you say? Actually, that statue was created procedurally using the Cloner tool in Cinema4d. Essentially, all I created was one of those cubes, then used adjustable parameters to multiply and rearrange them until I found some random combination that looked right!

The other important element in this scene is the lighting. For this game I wanted to use mainly diegetic lighting, meaning that the only sources of light would be ones actually in the game world. To get the most out of this light though, I included a few important components – volumetric lighting and visible noise. This means that the light source would not only illuminate the scene, but that the illumination would be actually be visible in the air. Including noise to this visibility introduces a smokiness to the atmosphere, essential for selling the mood of the scene!

Here’s the render straight from Cinema4d:

This looks pretty good, but it’s not quite there yet. An important lesson for any aspiring 3d artist is that you can almost always improve your renders with post production. So with that in mind, it’s time to move from Cinema4d to After Effects. Here’s a layer by layer breakdown of my post-production on this image:

1. Vignetting

The lighting in the initial render looks ok bit it’s a bit too flat. In order to increase the dynamic range of the scene, as well as draw focus to the center of the image, I added some vignetting to the top and bottom of the image.

2. Lighting Effects

I already spent a decent amount of time in Cinema 4d trying to get the right lighting, but I wanted to effect to be even stronger. Part of the reason I pointed the light at the statue in the first place was because I knew I could get some cool volumetric light rays streaming through the cracks. To amplify this I used a plugin called Trapcode Shine, which essentially fakes volumetric lighting using the highlights (and lowlights) of the image. This also adds a glow effect to the construction light, making it look more obviously like a source of luminance. Looking good now right…? NO WE’RE NOT DONE YET!

3. Color Correction

While the colors in the original render don’t look bad by any means, they just weren’t selling the mood strongly enough. A bit of color shifting can really change the feel to any image, and in this example, the increased sense of yellow-green makes things look murkier and adds to the density of the smoke in the atmosphere.

4. Noise

It’s probably obvious at this point that I’m into what could be described as a very filmic look. Adding some noise to the scene gives the image a sense of texture and density – the other huge advantage is that since the grain has movement to it, when you actually play the game it brings an otherwise completely static environment to life in a very subtle but effective way.

—–

So, that’s it! Easy right? Well, obviously the downside to this little tutorial is that these tools are by no means free or open source. Because I do motion graphics work professionally it’s certainly worth it to me to have them, for the average hobbyist game developer maybe not so much. Still, I hope the core concepts of this breakdown could be useful to you regardless of what tools you use to create your graphics. If you have any questions, feel free to ask in the comments….

And please, check out my game!

http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5821#LD48

Diamond Hunter Download

Diamond Hunter is a 2D Snake Clone.

You must collect so many Diamonds you can.

Its my first game!

Please rate and comment 😀

I finally got around adding a walk-through video for my experimental storytelling game “The Invention of Colour”. Since the game is very much focused on atmosphere and “the experience” you can actually get a very good impression of the game by just watching the video. Make sure you use a good pair of headphones to enjoy this to the max:

Walking into this competition I had one goal in mind: Create something that has a dense, expressive mood and portraits a distinct character to the player. I wanted the player to walk away from the game feeling like he actually got to know the main character’s emotional world by just listening to him for 2 minutes.

I personally find the transfer of emotional concepts to be one of the most challenging for a game designer. Quite often realism does not translate to something that’s emotionally impacting. The current trend seems to be toward hyper-realism. But to be honest I was a lot more emotionally involved in some of the classic games of the 8bit & 16bit era. There’s a huge potential when we leave gaps for the player to imagine things.

What do you think? What makes a game emotionally interesting? How can you involve the player in the world you’re trying to create? Would love to hear your thoughts on this.

Oh and when you’re ready to rate my game click through here: The Invention of Colour

Well, the dust has settled, so it’s time to do the good ol post-mortem writeup for my game, One of a Kind.

I actually have quite a bit I want to say, so I’ll probably be splitting this into two separate posts.  This one will have the basic what went right and what went wrong and what I learned, etc., while the other one will be longer, more ranty, and more of me expaining my development process, how the game came about, and some comments on the levels, art, and music.

Anyhow, without further ado:

What went right

Choosing an easy-to-use framework.
Although actually deciding what to use was a whole separate issue (more on that in “what went wrong”), once I settled on using C# with SDL.net, coding went really smoothly for the most part.  I just really like coding in C# with Visual Studio…it’s fun, there’s nothing that bugs me about it, compile times are super-quick, it makes a lot of sense, and when I screw up and run into a crash, I can debug it in almost no time flat.  It’s just a really nice language to work with.  Granted, I haven’t worked with other things like Python, Flixel, Unity, etc etc much so I don’t know about the other things out there, but I acn say for sure that I’m super-thankful that I chose C# over C++ with SDL, which was another option I was considering.  I’m sure that I would have just run into some stupid thing that would take me a long time to debug, or I’d have to think really hard about how I want to structure my game engine and who takes ownership of the allocated entities and you can’t delete them yet because they still need to do things, blahblahblah.  It’s just simpler in C#.  One small caveat is that I hadn’t actually used SDL.net before this, but luckily it turned out to be really straightforward (90% of the time, at least), and despite the somewhat lacking documentation (compared to vanilla SDL, at least), I was able to do just fine.

Messy Coding.
Now, don’t get me wrong here…I am a programmer who really, really places code elegance above almost all else normally, but when it comes to Ludum Dare, that totally just goes out the window.  The trick is to know what you can make messy and what you should refrain from making messy.  Most things you can safely get away with making messy because you know you’re not going to have to look at that code again.  But things that you -will- have to work with again, shouldn’t be quite as messy.  In any case, I had a whole bunch of public static variables, and even worse, I just intersparsed a bunch of them throughout the class, probably right before the function that uses them.  So it looks kind of terrible, but it streamlined the process and I think I struck a very happy medium where I didn’t go overboard on messiness to the point where it caused any issues.

Mood and atmosphere.
When I saw the theme “Alone” I knew that it was more of an atmopheric theme, and didn’t really give you any game mechanics or anything right off the bat.  And I knew that making a 2D platformer would let me create the mood I was going for, so I did that.  After that, it didn’t take much brainstorming to come up with the core mechanic that would fit the theme.  In any case, even at that point I already kind of had a vision in my head of how the game would look, feel, and sound (this was probably heavily influenced by The Company of Myself).  And everything including the art, music, even the narration of the instructions, was informed by this mood/atmosphere goal.  In the end I think this is the area where my entry shines and it all came together really well.

Time Management.
It was a great feeling to be a couple hours away knowing that all that was left was basically just some more levels, packaging, and some finishing up.  I already had my concepts in, my gameplay in, and even the music and sound and art style was all in.  I had even already programmed the ending in–I just needed a way to trigger it.  So there wasn’t any real rush to finish any features when it was coming down to the wire.  I also found that it was nice to work on level art and such other things while you were stumped trying to come up with new puzzles or mechanics, so you wouldn’t waste time.

What went wrong

Distribution.
Oooh boy.  Yeah, getting this thing distributed was (is?) way more of a pain than I would have liked.  It’s not like my usual C++/SDL setup where I know exactly how to make things work on Windows, Linux, and OSX with the least amount of additional dependencies.  This is C# with Mono, which…well, is already just asking for trouble in the first place.  Even my windows build ended up requiring the .NET framework, so I had to recompile using Mono, and even after that I stupidly forgot to include a .dll file.  The Linux and OS/X battles were much tougher to wage, and even then only partial victories have been won.  I guess I can see why web entries are so popular.  Anyways, the bottom line is that even though I knew that C# with SDL.net would run in a development environment on all three platforms (I tested that as my bare minimum requirement for choosing the language), I hadn’t had any experience distributing using this framework, so that was a pain.  Of course, I could have figured it all out earlier, but…

Being unprepared.
…I didn’t because I came into things just totally unprepared.  My initial ideal plan was to do a warmup game the weekend before LD, use that to decide how good of a framework C# with SDL.net actually was, and figure out how to port it to Linux and OS/X.  If it didn’t work out well, I might even have tried to make a test game in pygame, as that was another one of my possible choices of framework.  Unfortunately, real life, christmas letters, finals, and everything else happened, so I was stuck not having had time to do any of these things beforehand.  I had -barely- done enough work to decide that C#/SDL.net/mono was a “potentially okay” way to go.  On the plus side, I had done some good reading and thinking about fixed timesteps and framerate stuff, so I didn’t waste any time during the actual compo thinking about that (I ended up using a fixed timestep, and not limiting frame rate…I don’t think SDL.net lets you use vsync).

Puzzle design.
This is the one that had me banging my head against the wall.  One bad thing about coming up with a new puzzle concept is that you have no idea how interesting or not interesting it is, and you have no idea what kind of puzzles are even possible, let alone how to design good challenging ones.  So I definitely spent long chunks of time just trying to think of puzzles that I could create using the base mechanic.  And I think this is the weak point of my entry too–although the puzzles aren’t bad, they aren’t -good- either.  I think my friend said it well when he said there were never any “aha!” moments; it was more just going through and deciding what to do next.  I liked the fact that I came up with the reflection concept, but unfortunately that was so late in that I couldn’t really flesh it out with more levels.

Overall, how did I do?  Fantastic.  I’m super-pleased with my end result, and really happy that I was able to actually make a 2d Puzzle Platformer with this kind of style.  It matched my vision almost perfectly, and is just really good at cohesively establishing a mood.  And I love how polished everything in my game is–it doesn’t look like it was just thrown hastily together with simple placeholder art.

What did I learn?  hmm…well I learned how C#/SDL.net/Mono tends to work…easy development, “possible” to run cross-platform but really more difficult than you probably want it to be.  Next time perhaps I’ll try a web game…

Tags: postmortem

The post mortem is on my blog here.

Tags: postmortem

First Thoughts:

This was my first Ludum Dare and I loved every minute of the frantic 48 hours.

The theme fit in with an idea that I had in mind with some changes to make is possible in two days.

The Plus Side:

1. Graphics: None, no graphics made this part easy.
2. Sound: Since the sound was to be such a major part of the game, I was a little worried since I own no sound equipment. Somehow I managed to create all of the sounds in the game from scratch in Audacity (with a small contribution through my laptop microphone).
3. Library: Though I could have done without it, the flashpunk library really helped with the sound panning and entity management.
4. Platform: Flash made it accessible for nearly everyone and I felt comfortable coding in Actionscript. Flashdevelop was a great IDE and never gave me any issues.
5. The Ludum Dare Community: They were a great help in the testing and were very honest in their input.
6. Time: I budgeted my time well with frequent coffee breaks (I worked in a Cafe). The game was pretty much finished with plenty of time and I only had to cut a few features (I never got the kitten easter egg in there).
7. Two endings, three if you count drowning.

The Negative Side:

1. Setting: The island proved to be far too large and made the game quite difficult to finish (Not really sure if anyone actually finished, let alone got both endings).
2. Inventory: or lack of. The ability to hold only one item at a time really increased the difficulty.
3. My atrocious typos that I only noticed after the fact.

FInal Thoughts:

People seem to love the idea and it was a fun game to make. I loved the pressure of only having two days and it really helped to get me motivated.

After searching the #ld48 tag for actual links to LD22 games and reading a tweet about this problem I decided to suggest (courtesy @noragames):

#ldentry

Twitterers, be so kind to use this hashtag for posting your links to your LD entry. Additionally using #ld48 in the same tweet is a great idea! Both makes finding links to LD22 games (they’re 891, remember) much easier.

Si usted tiene hijos propios, puede ser casi imposible asistir a sus juegos o espectáculos musicales. Gestión de la caza y las diversas responsabilidades reunión pueden crear obstáculos enormes en su intento de apoyar a su descendencia. Bill Bruno, por ejemplo, se basa en los asistentes, los administradores del juego, y amigos para ser de ayuda para que pueda participar de las actividades de sus hijos. Artículo recomendado por Gran DT 2011