Blurry, stupidly sped up, and crazy alt tabbing so you can’t see anything. Enjoy.
Blurry, stupidly sped up, and crazy alt tabbing so you can’t see anything. Enjoy.
This is the time lapse of the full 48 hours of development, trimmed slightly so you don’t have to wait 30 seconds while I’m sleeping.
I like the concept of a timelapse, it makes it look like I know what I’m doing when I code something, as opposed to making it up as I go.
And again, if you could please play and rate my game, as well as leave any constructive criticisms, that would be greatly appreciated. Thanks
The last man on Earth sat alone in a room. There was a knock on the door…
When I heard Alone was chosen as the theme, a set of bizarre ideas immediately appeared in my mind. I really wanted to explore about the feeling of being alone, about the psychological effect of it. Also, I had read The Knock recently so I wanted to explore more about that subject.
The tools I used included:
The art is rather simple, I took some photos of my house and I asked a friend to model for me. We did some shots of him walking, but because I lack equipment (tripod, marks, etc) the result looks a little bad. I did my best to correct the photos in Photoshop. The room is a part of my house, that isn’t even a room, but I couldn’t take a picture of a real room because the camera angle was too short. I applied Exposure and Posterize to all the images.
The programming was done entirely in ActionScript 3, using some features of my own library, but the vast majority was to be made from scratch. I used Flashdevelop because I’m really fast with it… Just press Ctrl+Shift+1 and it’s like magic!
I think I’ll work more time on this game. I’ll add more puzzles, make an easy mode, add language support, and maybe more rooms to explore, or explore more about the story. For example, what happened upstairs?
This was my second time on Ludum Dare, and I think it was a really good experience. I don’t think there’s something that went wrong, maybe next time I’ll add more features to my framework, like effects, sound support and embedding support; but at the end I managed to do what I intended to do.
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.
“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.
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
You can find ALONE with K.I.T.T.I. here: http://www.ludumdare.com/compo/ludum-dare-22/?action=rate&uid=7263
What went wrong?
There was an unexpected family emergency that took up the better part of 10 hours. The emergency was unavoidable, and unforeseen. It was unfortunate, but I absolutely do not regret missing the 10 hours.
That said, 10 hours is a lot of time in a 48 hour competition. After sleeping for about 10 total hours and the family emergency, I was left with about 28 hours of total work time. Not bad, but it was not evenly distributed, requiring some energy drinks and long periods without sleep. If I had had the 10 hours, about 4 of it would have been for sleeping on Saturday night, and the rest would have been time spent on polish.
My first time sync when working on the project was going with the sprite.js library — it’s an amazing library, but I hit a wall when I realized the support for Tiled, which I was banking on, was not really all that complete. I was going to use melonJS from the outset, but then a couple of days before the competition, I decided sprite.js would offer a better experience. I had tested it out before the competition, and thought I could get everything to work based off of one of the libraries examples, but you know how that goes.
I ended up switching everything over to melonJS, which has faculties for reading Tiled maps directly. In the end, I think this was beneficial to the overall project, but it did eat up time. If I had just used melonJS from the beginning (like I had originally planned), I would have had at least another 3 hours of work time.
My second time sync was maps. I initially built a small test map, and iterated features over that map. The test map was an excellent strategy I think, but coming off of that I jumped into a really large map — bigger than I needed by several factors. I wasted a lot of time just trying to fill it in and make it playable. I eventually shrunk the map down, but I spent an awful lot of time with a map that I ended up throwing away.
I think if I would have just did a little more level design up front on a piece of paper, I could have avoided this time sync, and probably got several more hours to work on polish and other levels.
More experience with the Tiled editor would have helped to, but it’s pretty easy to pick up.
What went right?
The things I didn’t know well were sprite.js, melonJS, sfxr, Tiled and the music generating python script that GreaseMonkey posted about: http://www.ludumdare.com/compo/2011/12/13/if-you-find-it-hard-to-make-music-read-this/
However, I did practice using these tools before the competition, so I was comfortable using them, and they didn’t offer any surprises, or set backs (other than plain inexperience).
melonJS was fantastic to work with, and really easy to pick up with the great examples on their website.
Tiled is an amazing editor — combined with melonJS I think it really saved the project after the 10 hours I spent away from the competition.
And, of course sfxr really added a little something to the game. I’m no sound engineer, but having absolutely no sounds in a game is almost as maddening as eating at a restaurant without background music. sfxr is amazing. On top of that, it’s really easy to use!
And the Autotracker-Bu script from GreaseMonkey gave me something I thought I wouldn’t have. Perhaps the music isn’t perfect for the game, but it does add something.
My experience? Positive. I’ll definitely be doing this again. Next time I’m going to hopefully avoid emergencies, pass on the energy drinks, get some nice evenly distributed sleep, and know exactly what my libraries/frameworks are capable of going into the competition.
Happy Hacking, and I’ll see you all in April! (and possibly before that for the MiniLD’s!!)
I had a lot of issues since the end of the 48h challenge and the game wouldn’t work correctly for obscure reasons. But now it does.
You can play it here: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=6638 (I strongly recommend Firefox to play it best online)
This was my first Ludum Dare and I must say that I enjoyed every moment of it. I rarely see my projects through to the end so having a time limit and some competition was very useful for motivation.
What went right?
What went wrong?
Overall, I’ve learned that difficulty is not a good substitute for longevity and that believing my programming skills to be god-like is never a good idea, especially before I attempt to make something against the clock and something that other people will play.
That was a blast! This was my first Ludum Dare, but will defiantly not be my last. Thank you to everyone involved.
Before the competition started, I had designs in mind, wrote some stuff down, and was testing out a million 2D platform game mechanics. I’ve been doing primarily 3d stuff over the last year, so I began to question why I was entering a realm I wasn’t comfortable with for a 48 hour competition. At the last minute I decided to switch to a 3D approach.
The whole process was really organic, I let the game design itself. I didn’t take time to write out a plan or design document. Design documents are great, and serve their purpose… but they are no fun to play and I can use that time to add cat powered mega bullets.
What went right…
I got the full support of my wonderful and loving family. Every minute I wanted to work on the game, I had, distraction free. Can’t express the importance and appreciation of that small fact.
I completed the game. By using a definition of ‘complete’ that really only applies to games made in 48 hours. There is a hint of a story. Win/Loss conditions, mechanics, sound… The basics are there.
The game is fun. I enjoy it at least. Once I turned it in last night and the LD website went kaput, I spent a while playing it… not play testing it, but playing it. It was nice.
I believe I did a really good job with my coding time management. I worked a short time on each mechanic then really took a step back and decided if it “just didn’t feel right”, or flat out just didn’t work. Rather than beat a dead horse, I was able to drop them and move on to the stuff that did work. What I was most concerned about, generation of the antagonist and controlling it’s growth actually just worked out with minimal issues. In the beginning, it reproduced so fast it would kill the framerate after a minute or two playing… I ended up calling that “hardcore” mode, with a warning, but optimizations and balancing added later killed the fun in that
The hardcore mode “bloom attack”. The visual and sound… It just works for me.
What could have gone a lot better
I resorted to lazy coding a bit too quick. Played the “public” and “static” cards way too early. Some last minute bug fixes were a challenge, (and there are still a few minor ones lurking that I believe are tied into the above).
I got in a good chunk of time in to work on balancing and difficulty levels but it wasn’t nearly enough. A few more hours to work on balancing would have helped a lot.
The “art”, if you can call it that needed some more love. Some may find the color shifting thing a bit obnoxious… but then again, others will want more. All the modeling was done in code and consists solely of cubes. Some more interesting powerup and bullet shapes would have been nice.
Some of the sounds just don’t work for me. Except for the “bloom”… did I mention the bloom? I like the bloom.
The jealous side of me is trying to decide if next time I should go for a web game. Probably going to lose a lot of plays and votes for being a Windows-only application. Lose several more for XNA’s outside requirements. It may not be right, but it is what it is.
In the end though.. I didn’t do it for votes… I did it for the fun and the experience. And by those measures, I already won Ludum Dare.
Well, Finally got the video all rendered up! I hope you enjoy it. I certainly enjoyed the 29 hours of it! ;’D
Ok so I crashed for some sleep after submitting my compo entry and I figure now is the best time to do a postmortem.
In traditional game projects people usually go off on vacation or put off post mortems long enough to forget about the details
Forever Alone Kitten
Play / Rate it here:
Made with: Unity3d / Photoshop / BFXR / Maya
Points of frustration
Things I was happy with
In reference to point #4 above, I call my rapid code prototyping style ‘Freestyle Spaghetti / Chaos Coding’. People that care about ‘coding style’ or ‘designing clean systems’ will be outright offended by what they see here haha
The basic rules of ‘Freestyle Spaghetti / Chaos Coding for rapid prototypes+game jams:
Things that took more time than I expected:
Things to do next time:
I may not have been able to put in all the things I wanted to, but it is a game and it has an ending, so I’m pleased with it. The most fun I had was creating the death animation/sound/messages, so if you have some spare time try to get all the different deaths. I’ll add a proper postmortem later, and put up a timelapse when it finished building. And check out the entry page here.
So, what is my secret? Or how did he do it? Well, Read on. This log tells about how I designed and created my 48 hour game and what choices I made.
I started by brainstorming on a piece of paper and with a good breakfast (soup and bread). The brainstorming resulted in a large web of words and lines. Afterwards I started to scrape all unrelated words and lines until a small part was left. From the readable words I picked the best and started sketching. The concept ended up being:
The player is stranded in an unknown world (other dimension?) and needs to get away before he dies from starvation. While doing so he should try to contact others while being annoyed by robots/drones.
The sketching brings us to the game design. I started with a simple sketch and made it into a 3d design tool. The sketch ended up with showing a dessert with a crash landed space ship. The main objective got: Activate the beacon (middle of image).
But the question remained, how did the player get there? To solve this, the player doesn’t know either, she just wakes up. To give the game more feel about the strange place I created two separate environments. The player would wake up in her own bedroom and once she gets outside the room, there is no hallway but a dessert.
So the level and setting where done, the only thing left was the robots and drones. Trying to keep it simple I choose a floating sphere like drone who float somewhere around. It was time to think about the technical design. I worked in C++ using the tool Irrlicht and Irrklang. So I opend Visio and started to place the objects I had: Drones, Level, Beacon, Player and the scene itself. It resulted in this:
Ofcourse, much is changed during the game development, but note, this is a useful “work to” point. I ended up with:
I started to develop the things I sketched and put them together into a simple game. The prototype was done before the 18 hour mark. The prototype seemed good but lacked a bit of humor and feeling.
One of the results of the prototype showed that the game lacked humor and that one machine to activate was too easy to handle. The extra things I planned for the game itself became:
A very important step! Think about how to test your game before you finish it! I used Visual studio so I was able to do variable manipulation, but, otherwise I would have added cheats. Make sure you can easily test your game on bugs. Watching a story over and over again is awful, settings states and recompiling is bad, real bad. So, make a plan, how do I test the start, middle and end? (without replaying the game every time). I just manipulated the games variables with the Visual studio debugger, changing enumerations and time variables.
On 22:00 CET I started with the game. The first things added where voices and sounds to the drones, a background music track and recorded some sounds for the power generator. How did I record the sound for the generator? Well, quite easy, taking my microphone and putting it behind my computers fans, lowered the pitch and lowered the speed and viola! Done. In the prototype, the bedroom and spaceship were left without detail, it was awful. The ship had to look broken, to do this I first modeled the ship and when that was finished I broke it. Cutting holes, lines and adding more panels. The advantage of doing so is that you have a good looking ship. Breaking it and adding debris is a much easier process. When the new models where done, I just replaced them in the prototype. The same detailing process is done for the drones, power generator, debris, terrain and the music track.
I kept track of 2 folders, one for debugging and one for the release and I setup special defines for the debug and release. Once a debug version was bug free I tried the Release version in the release folder. The source code was placed inside a separate folder. At the end, I was capable of just clicking the source and release folder for archiving them. On monday 02:40 CET ( 20 minutes before the deadline) I submitted my work. Barley before the site went down! Got lucky Time used: 32 hours Sleep: 15 hours Tools:Autodesk 3dsmax, Adobe Illustrator, paintToolSai, Audicity, Anvil Studio, Visual Studio 2010, D3d MeshViewer, Irrlicht and Irrklang.
Thank you for reading the “How Did I Do it”.
To continue with tradition, I made a game for this Ludum Dare named Leave me Alone!! (sadly, it seems like there are 3 or more games named that way).
I had little time to spend making the game so I targeted a simple game with almost no graphics nor sounds but fun.
The story behind the game is, you have to isolate a particle from other particles to keep the world safe, if they make contact then the world explodes in a mega hyper super duper explosion (use your imagination).
Here is a screenshot:
And here is a gameplay video.
I decided to be lazy and write it only once, so come see it here.
Proud to have submitted my second Ludum Dare entry tonight. Thanks everyone for such a great community and for building the enviornment for such a great experience. So much fun! Anyway, this time around I created a timelapse of development for my entry. I hope you all enjoy. If you are interested please feel free to play or rate for my game!
Congrats to everyone who has submitted an entry!
Damned Unity first bluescreened my laptop, and then hung while trying to make last-minute text tweaks. After the second reboot, I found that the hand-sculpted terrain data had vanished. I am NOT BEST PLEASED.
Luckily, I had a test submission build, which is functional…but missing the majority of the flavour text and a proper ending. I’ll upload the source assets (sans terrain) in the morning when the rage has subsided.