Posts Tagged ‘LD22’
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?
- Time. I had plenty of time to work on this game, an empty house and no plans for the weekend meant that I could dedicate every moment I was awake/not eating to working on the game.
- Pre-planning. I planned every aspect of the game on paper and planned out exactly what order I was make everything in before I wrote a single line of code. Not a single feature in the final version wasn’t planned on paper first, a lot of features from my original plans were removed though.
- Knowledge. Every feature in my game had been made at some point or another, in some form or another, by me. The problem was trying to remember how I made them and then put them all together into a game that actually works.
- Notch. That man’s livestream had some great music. Plus, the rhythmic tapping of his keyboard was great motivation to keep typing.
- Gameplay. The idea was that my game would be hard. I wanted people to feel under pressure while they were trying to disarm the bombs, I thought that the time-limit, lack of a reset button and having to start the game from the beginning if they failed was a good way of achieving this. Plus, if no one can finish the game, no one can complain that it’s too short.
What went wrong?
- Gameplay. Apparently players don’t like to be infuriated by high difficulty levels and over-the-top punishments for making just one mistake, who knew?
- Over-estimation of my programming speed. A lot of stuff from the original plans were never in the final game, this is purely because I didn’t realize just how long it takes me to code even the most basic of features.
- Lockpicking. As a result of not having the foresight to realize how long these features would take to add, lockpicking wasn’t started until a few hours before the deadline. This resulted in lockpicking turning from the Tetris style puzzle that it was originally supposed to be and becoming a “Bash the buttons as fast as you can” minigame with awful graphics. It also meant that the option to place a previously disarmed bomb in the lock to explode it open, had to be cut completely.
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
- Indecision about Dialogue/Story, after the theme was announced I was at a loss for what to do. So I went through the motions of creating the game engine shell while being nagged by this. I originally wanted to make a shmup, but tried to do something moody to fit with the ‘Alone’ theme and sort of flailed around for several hours trying to define it.
- I’m still new at learning unity and wanted my entry to be made with it, so consulting the documentation repeatedly or trying to figure out proper script code to control material properties or other things slowed me down bit.
- No time for visual polish/build a proper environment. At the end I lied to myself and said its supposed to look bleak and empty anyways.
- No game restart. I realized early that worrying about adding/testing restart functionality would have slowed me down considerably, so I abandoned it even though there is some fragments of it in the game.
- Based on the player input, its possible to not see all the game narration paths, so if someone plays it only once, there is stuff I put time into that they may not see and the length or mood impact can vary. The lack of #4 (restart), or communicating that there is ‘another path’ in the game content is also problematic. This is why I don’t like permanent branching games as a game player, and prefer ‘networked world’/sandbox games because all content is explorable at anytime or multiple times. I’m not convinced story heavy games really hold up to replayability since they all seem to suck at this issue (you played this before, but this menu option here will show you something different, a hint like that would be kind of spoilerish or break immersion).
Things I was happy with
- I learned a lot. I’m a ‘learn by doing’ type of person, so forcing myself to deliver something in 48hrs made from scratch in the time limit = learn + do fast. I used version control even for this short-term project so i could document its construction in the commit messages and would stop worrying about ‘accidents’ where i would lose work or mangle things so badly and could rollback.
- Some people commented on liking the mood in the game, which is what I decided to focus most on. Someone despaired that when they played there seemed to be no “happy ending”. My goal of toying with the player’s emotion = ‘mission accomplished!’
- I came up with a neat little forcefield behavior around character that affects the things that swarm and come for you, the enemies still face+approach you, but when the shield is up it holds them back and they get pushed around fairly smoothly when you forcibly move into them. I’ll have to re-use that for another project….
- Although the code is absolute spaghetti, there is alot of it with some lengthy comments sprinkled in it so I could remember what I was doing along the way, so its not a complete throw-away game shell for something in the future. For the curious: Link to source/assets/unity project are here: http://db.tt/eJOJT6Dx
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:
- Extra Comments, you need them. You need more comments than you think you do. I write comments as a way of ‘talking out loud’ about what i’m doing. It makes things more clear, and when I come back to the code later, I can more easily remember where I left off.
- Extra Verbose variable/object names. you want every variable name to make it painly obvious as to what its scope and contents are. Between #1 + # 2, I rarely ever need to step through code using a debugger because I can work out what is going on following these 2 rules.
- New ideas may often come to you while writing code for other things, jumping to act on that new idea is okay, as long as everything still runs you’re cool. Unfinished things = comment verbosely what is going on. Before you jump to the new thing, always write a note in code about what you were just doing+need to do next there, then jump to the new thing while the idea is fresh to you.
- Everything can look to a base (GameBase.cs) to figure out what is going on (access a global value state) to gate/ungate a script that doesnt work or isnt complete.
- Take the path of least resistance in implementation. Data driven? Code Driven? Do I need a tool? Do I need a file format? Could you just hack it in code and be done with it?
- The person playing your game doesn’t see your code when they play it. Stop worrying about what your code looks like and focus on the results that people will play. You can pretty up your code and ‘refactor it’ later if you need to build on it.
Things that took more time than I expected:
- Audio – I spent a lot of time with bfxr trying to get sounds out of it that matched the mood I wanted (trying to get a sad kitten+spooky type sounds out of a synth). There’s a lot of extra sounds in the source that I didnt use which fit the mood target but i didn’t get to implement due to the time limit+needing more supporting graphics+code to go with them.
- Art/Tweaks – I went crazy with the particles. I liked the square/fine grain look of the particles so i kept the particles untextured to save time. I fussed with the colors of everything several times to keep it the right ‘mood’ as well as all the other particle effect sliders. I lost time modeling a few other things that didnt make it into the game and realized that there wasn’t going to be enough time to texture+rig+animate them so I trashed that given the time pressure.
- Dialogue/Narration – changed multiple times after playtesting through it over and over and over…. Having a premade system to handle complex dialogue/interaction would have been much better. hacking something from scratch+testing it with time pressure was painful.
- Setting up+modifying my game in unity. To save time I did some things in the unity editor instead of explicit code, which i’m still getting the hang of. The editor workflow method has little quirks like nuking connections or values on scripts if you change the variable name in the class to something new ended up biting me several times, breaking the game. Trying to find a balance of initializing/setting script values hardcoded or in the editor view on an instance of something with a given script slowed me down and I should have more clearly defined this.
Things to do next time:
- Setup and do a timelapse next time. In retrospect i’m even more sad I didnt do this. Ideally I would do record this for 3 screens since I work across 2 screens on my mac (playtest+code+ photoshop on cintiq), + geo modeling pc.
- Do something that doesn’t waste so much time with unique dialogue flow with one-off internal triggers/unlocks that the player might not ever trigger.
- Continue to write code fast+freely for the sake of progress, and don’t be so worried about what people think of your code that you hacked together over the weekend. (I write much better code for normal games I swear! )
- Build out a more of traditional game to play?
- Worry less about story/playtesting dialogue flow. Focusing the first half of the compo time on this was good/bad since it ate up a ton of time – it was uncharted territory for me in terms of content+code implementation.
- Better schedule my time and set time limits on doing a feature/asset.
- Start visual polish phase and test deployment earlier so there is less of a frantic rush at the end.
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:
- Player must survive (he always survives)
- Player must activate the beacon
- Player must keep the drones away by picking them up and throwing them away
- The beacon is activated by clicking on the launch button.
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:
- The beacon can be activated after the power generator is activated, activate by clicking on the launch button.
- The power generator is activated by clicking on the launch button.
- The Drones make a noice when picked up
- The Drones receive damage after being thrown, after which they move slower and start to smoke
- Adding more subtitles and “ particles! “
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.
Tips and do’s:
- Set up 2 folders, one for a clean release test, one quite clean for debugging.
- Write down the games basics and rules,
- Sketch the technical design
- Build a simple prototype on which you can later improve the games visuals.
- Take regular breaks! Work 60~90 minutes with a small break, like: running through your house, going outside for 10 minutes, they improves your motivation and precision!
- Always make sure to write it down, it makes it easier to decide if its possible
- Chat on the IRC channel with others, use your time and chat later, in small breaks or afterwards.
- Sleep less, when you have less sleep it will lower your creativity, bug tracking and other skills.
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.
I have successfully finished my very first LD game, The Last Man on Earth.
You play as the last survivor of an alien invasion, your goal is to avenge your species by clearing out an alien spaceship.
It is a pretty hard game, but please don’t get mad at me – I had no time to balance the gameplay.
The game has two endings… and a kitten.
It has been great fun, I would love to participate in the future, too.
- Visual Studio 2010
- XNA Game Studio 4.0
Yep Ive bombed out. Got to the point at 4am last night where I realised I more than likely wouldnt have a game worth submitting by todays deadline.
So thats a bit dissapointing. But it was still a good experience. Im determined to work on everything that let me down for this LD (ie time managment, planning and doing things which are too complex) in preparation for the next LD.
Slight malfunction with the space station
So yeh, I at least have a brand new game concept developed, with a great story I want to tell, so Ill more than likely get serious about these leftovers from my LD attempt of a game and make it into something better and an actual game.
I look forward to playing a bunch of games over the next week or so however, to see what all of you successful LD guys have come up with, let the voting commence and Ill be seeing you all again for LD23 in a couple of months
Finally done my first Ludum Dare game. Didn’t get off too the best start, I hated the theme and couldn’t think of any ideas, then I came down with a terrible fever, so I’m happy to have finished anything at all.
Looking forward to the next competion, hopefully I won’t be so under the weather.
Yay, like my fourth time competing in a Ludum Dare and I actually submitted something this time. I had more plans I couldn’t act on, but at least I got something done this time. So, what did I learn from all of this?
- Don’t change the base idea of your project the last day…
- Planning everything ahead of time to make things simpler on you later will not prevent you from cutting corners like crazy when the deadline looms and writing code you will not be proud of
- Kittens, while not the BEST theme, probably wasn’t the worst one either…
- There are no good free music generators that you can find for free easily.
- Converting a MIDI file (from Wolfram Tones) to an MP3 is much more difficult than it should be
- I am very very rusty at pixel art
Still, I am happy to have gotten something running and submitted, and do plan on adding the rest of the features I didn’t have time for and cleaning up the code so I am not ashamed of it anymore in the upcoming days after the deadline is up. And hopefully by LD23 I will know what exactly what all I need to bring to the table.
Sell it to the butcher at the store…
Hey there, I’m Nik, and I’m a Ludum Dare first timer!
I had no idea what to do, at first. So I started to plan. The best thing I came out of was something to do with God, as he’s alone. So I emptied my mind into Game Maker, and created… a thing. This thing is called The Almighty Annihilation. It’s a 8-bit styled game where you have to wipe out the entire population of Earth with Meteors and Lightning Strikes. Sounds fun, right? Please tell me it is.
I made the game in 21 hours, with lots of frantic rushing and developer’s block. I know it’s not the greatest, and it seems very basic, but please. I am slow and can’t be bothered most of the time. I made a game. Enjoy.
Here’s a brief synopsis of how “There’s Waldo” came to be. Some LD guys and I were in a google hangout, and I bounced a bunch of ideas off of everyone, one real good one was a reimagining of “Where’s Waldo” with none of the people except Waldo, and when you click him, it says “there’s waldo” as if you didn’t know. The game is completely defeated this way, but I think it says something about “alone” vs. “not alone”, besides being hilarious. So anrdres and I bring you ‘There’s Waldo’, thanks to everyone who helped put this together so quickly and for the chat.
Another idea we had was to make a big splash screen for a multiplayer game, and then have it say “couldn’t find friends to play with” and it just shows you sitting there at that screen. I figured this was a modern way to show how alone affects gameplay in some games… if you can’t find anyone to play with, the game is totally useless. Also batted around were things like playing a team sport as the only player on the field, the score still moves and you have the ball but that’s it.