Posts Tagged ‘tips’
The amount of games with only WASD keys to move is too damn high ! ^^
I suggest to add this in the competition tips : “Some persons have QWERTY keyboard and others have AZERTY keyboard. So let the player choose his own keys to move or just set W AND Z to move forward, A AND Q to move to the left, S to move back, D to move to the right. Or, use the directional keys.”
I figured I’d do a writeup of my results for Asphyxia . I wish I could put these ratings into a sexy graph, but seeing as it was my first ludum dare that wouldn’t be very interesting
#20 Mood – Nice, the game was obviously aimed at the mood and there was some though competition in this category, with masterpieces like rxi’s game. Some described the story as very sad, others as a punch in the stomach (the ending) and some as intense, it’s nice to have been able to put some mood into it (which is a first for me).
#35 Audio & #118 Graphics - Surprisingly high, the music in the game was the first I ever created, so this result very awesome to see! I’m definetely no artist, so for me this graphics rating is a nice proof that even a programmer can score moderately high without talent if you put effort into it (first time I’m putting anything other than programmer art/primitive shapes in a game).
#131 Overall – I was aiming for top 100, which I didn’t make, but I suppose that goal was a bit too high for a first ludum dare. 131 is still a very nice result regardless!
#415 Fun, #494 Theme, #546 Humor - I think this game was quite the opposite of humor, but still an average score of 2.13? Strange As for fun and theme, it was not very original in the theme category (one life in story) and funwise, it was way too hard.
Alright, so much for the ratings, they’re not what LD is about, it’s more about what you learn.
Here are some tips for next jams that I have learned along the way in this jam, I tried to add those that I don’t read in every other tip list (eat and sleep):
- Your game is probably too hard. As the maker of a game, you are much more skilled in your game as you know exactly how it works and have played it a whole lot. Have your game playtested, even in a jam, and scale the difficulty down.
- Add story skip functionality. Add skip functionality to intro’s and parts of the story (if your game has one). In my game the intro was not skippable, which was a big, big mistake.
- Add level skip functionality (in my game I had a button show up after X failed attempts). This allows players that are struggling or simply don’t have the time to try many times to see the story/ending of your game regardless. This is not that hard to add and in my eyes is a must in story-driven games.
- Add sound. Any sound is always better than no sound, if you are not an audio pro, consider recording things around you with your crappy microphone or generating sounds with bfxr. If you do it really well, it can make for a great experience all by itself, see Atmospherium‘s game.
- Do one thing well. I often end up over-scoping in jams, it’s not so much that I didn’t put in every feature I wanted, it’s that the game does not do one thing very well, but does a lot of things. I think this problem is especially present in the programming-end of the game developer spectrum.
- Don’t finish with programmer art. Making art is not impossible for programmers, do plan to span some time on at least reasonable art.
- Build for Linux too. I’m not a Linux user myself, but many of jammers (especially the veterans (who vote on a lot of games and give great criticism)) are. There is no Unity Web Player for Linux, so build for Linux!
- Put instructions in the game, when the player needs it (first) . In my opinion this is so much better than putting a list on your submission page or at the very start of the game. Here are some examples of how it can be done.
- Watch a stream of someone playing your game (or an IRL person). This is basically how I learned most of this, post-jam there a bunch of people streaming games, it’s a great opportunity to see someone struggle with things that you thought were intuitive/easy.
Hope this helps some of us ;).
I’ve done several Ludum Dares in the past, and the one thing that I’d recommend to anyone is to always remember, you’re doing this for fun.
- If something comes along that sounds more fun, or is more important, go do it.
- Take breaks. Go on a walk. Get away from the computer. Draw inspiration from the world, or let your subconscious tackle a tough problem while you enjoy yourself.
- Don’t get stuck. Use a tool like Stutter to force yourself to bounce from art to programming to design to playtesting. (Yes, this is a shameless plug.)
- Sleep (or, at the very least, powernap). A tired developer is a sub-optimal developer. Four hours of peak development is worth much more than 16 hours of mediocre development.
- Eat. Food is fuel, and fuel, like sleep, is required to perform at peak.
- If you want to dominate your Ludum Dare (or appear to), don’t learn your tools while you work. Decide upon your arsenal now, and learn as much as you can about them.
- Revision control is your best friend. Commit early, commit often. If you’re doing it right, you’ll be committing way more than you think you need to, and this is good. Reverting fifteen minutes worth of bug code is better than spending another fifteen debugging. (Don’t forget to master revision control before the compo!)
- Submit your shit. Does your game crash? Submit it. Does your game suck? Submit it. Is your game so awful it’s embarrassing? Submit it! Once you’ve submitted it, realize you’ve completed a Ludum Dare, how awesome that is, how many people wish they were you, how attractive you are, and how much better you’ll do next time!
- Have fun. Have I mentioned that you’re doing this for kicks? If you’re stressed, worried, bored, upset, or tired, you’re doing a bad games make job. Have fun, goddamnit.
Several days after the end of the jam, it’s time to write a short (now that I finished to write it, it’s not short) post-mortem. People who tried my game seems rather satisfied and they have enjoyed the game. I’m globally pleased with the result of my work too even if all isn’t happened perfectly. You can try my game if you want understand what I’m talking about : The Curse of Chronos.
What’s went wrong
Gameplay : I decided to spend my first two hours Saturday morning to find an idea and create a short game design document. My first idea was to create a game where you play a terrorist who trigger bombs and have ten seconds to back off before the bomb goes off. Another idea I had was a hero who has the power to see the future ten seconds in advance and can use it to change it. These ideas were ok but I wasn’t completely satisfied and I had still one hour of thinking.
I finally decided to create a rogue-like where the player has only ten seconds at the beginnning of the game. Each action like walking, talking to an npc or fighting costs time and there’s also objects which can increase hero’s amount of time.
I worked on this idea and Sunday evening, the engine was over. The hero could walk, pick-up objects, kill monsters. At this time, I noticed the gameplay of my game was rather poor. The only thing the player could do was moving as fights where automatically resolved. At the end of day 2, my rogue-like was became a simple exploration game without I notice it.
The game is not bad but I’m a bit disappointed because I’m sure I could do more interesting things with this concept. And I don’t know why but I find definitely that the gameplay of my game is poor.
Time management : I was really well at the end of day 2 concerning the deadline. I had still a lot of things to do on day 3 but I had the time to do it. And one day later, I published my entry 3 minutes before the deadline after 3 hours full of stress and tension.
I was really pleased at the end of day 2. I had a good game with good graphics and music. I think I was a bit less focus during the third day. I spend one or two hours to do other things than working on my game, thinking that the biggest part of the job was done.
At midnight (3 hours before the deadline), I begin to be a bit worry because I had still a lot of work to do. I was forced to work fast and therefore not really well. I give up to create a second music track and I hadn’t the time to balanced really well the difficulty. That’s also the moment where I begin to detect some bugs I haven’t noticed before, still increasing the amount of work to do.
I had been forced to work hard until 3am after a really long day. It was not really good especially because I could avoid it if I had keep focus during the day 3.
What’s went right.
Keep healthy habits and sleep well : In France, the Ludum Dare begin at 3am Saturday morning. For my first Ludum Dare in April, I decided it was a good idea to go out Friday evening and go back home at 7am completely drunk. I began my game only at 5pm.
I manage to avoid it this time and I take a good sleep Friday evening to be ready and fully well-rested Saturday morning at 9am.
I also take 8 hours of sleep each night. I take the time to take a shower and prepare some good dishes for my meals. It seems obvious but it’s really easy to stay focus during seven or eight hours in a row and burn out before the end. It’s truer for the jam which goes on for three days. To my mind, these moments like take a shower and eat good meals are really important to take a break and keep your body and your mind healthy.
It took more time than drink sodas, coffee and redbull during 72 hours, but I think it’s better at the end. Furthermore, it’s often after this sort of break that your succeed to fix this damn bug which annoy you since one hour.
Audio : I use two hours to produce the only track of the game. It last just one minute. I thought it’s a bit short. I was afraid that players find a bit repetitive to listen the same music during all the game, that’s why I would like to add another track. After all, it’s enough long to avoid this problem and nobody seems complain about it.
There are several sounds in the game to accentuate some actions done by the hero like pick-up an object or kill a monster. They are ok and rather effective, I think.
Graphics : I’m really pleased of my tiles and sprites and players who tried my game seems too.
Dialogs in English : Dialogs are really important in a game like this. I write the dialogs during the third day, so very fastly. It’s a bit difficult to write all these dialogs in a language which is not yours because you’re not always sure to use the correct word at the correct place. You also cannot always faithfully transpose what you would like to say. So I tried to keep the dialogs simple and used stereotypes and humor. Old men who are only obsessed by fishing, guards who are all
I’m satisfied about the result even if I could do better if I haven’t wasting time during day 3 as I said above.
Theme : I was pretty disappointed when I know what’s the theme was. I thought that the only sort of game you can do it with it was : you have ten seconds to do that, you have ten seconds to finised this level, you have ten seconds to…, and so on.
I tried 60 games until now and some of them follows this scheme. My two first game ideas was like this too (see above) but I manage to find something different and I think it’s the challenge when you have a theme : to see the theme in an original way. Among all the games I played, my favourites was those which were able to use the theme in an original way and don’t stop at the common solution which everybody will find.
Scenario and quests : I find the scenario really early when I was still thinking about game mecanics during the first two hours. Chronos, the god of the time put a curse on the hero and left him only ten seconds to live. The goal of the hero is to lift this curse. It’s quite simple but it’s enough to make a good main quest. The challenge was to use cunningly the dialogs and the settings to guide the player without he noticed it too much. The common mistake in this sort of game in open-world is to completely direct the player and he has absolutely no freedom.
Except at the beginning, where the player is a bit directed for the tutorial, I think I succeed because the player can do absolutely what he want, in the order he want but he is not release in the world without any indications. He can even go directly to «final boss» even if he will have difficulty to defeat him. Side quests are optionals but help a lot to do the main quest.
I’m really happy of what I did and players who played my game seems enjoyed it. I will know continue to try games of the Ludum Dare. I’m doing my best to try games of all the people who left a comment about mine.
The theme is Minimalism, yeah? And I think I’m not totally irresponsible for this.
Two weeks ago I finally decided to enter the next LD, I thought about how I could make a game from scratch which would be awesome despite my programmer art.
So I decided I submit “Minimalism” as a theme idea, because then I would have an excuse for my bad art. And having all those time constraints of a weekend and stuff I thought it would be easier to finish the game. Thought and done.
Well, bad idea. I only later found out, that Minimalist already has been the theme of LD11, which made me dislike this theme. But I thought, well then nobody will up-vote it anyway…
Well, I was wrong, faster than I could see it got into the final round, well sh…
Then I also talked with some of my friends about the LD, and they didn’t mind joining me in my quest of making a game. So I decided to join the jam instead of the compo and we could make an awesome game together. And now I have people who can make art and sound and stuff, and what is the theme?! MINIMALISM! I could have ripped my ass out when I saw it (if that’s even a thing).
But (as others already said) don’t try to think of it as something that constrains you, as I did first. Simply see it as another challenge to the LD.
So now I’m sitting here trying to come up with an idea for minimalism that allows us to create a great game. The thing is: what you usually want with games is richness in graphics, sounds, effects and gameplay, but applying the theme to one of this things leads to exactly the opposite, it seems at first. But you could say that it also leads to pureness and more focused content (as long as you don’t cut on the essentials). When particles are important for your game, then simply include them. Don’t just draw rectangles, maybe try out circles instead. Ok, maybe not like that, but you get the idea.
So maybe we will do something that has just a story, revolving around minimalism, but not on too minimalistic graphics, gameplay and stuff.
And I’m really sorry, if the theme really scrapped your LD. It scrapped mine too.
(And don’t forget to include a potato)
Since I know myself enough, I also know that I will start panicking about three to four hours in and willing to throw everything in the bin and go play some Deus Ex. So, I though that a list of some anti panic suggestions maybe will help me (and hopefully inspire others) to get my game done before the 48h limit.
- Start with a small idea, something I’m pretty confident I can do in two days, then halve that. This way I’ll get a tiny idea: my objective is doing something even tinier. As everything in life, starting is easy, but ending is EVERYTHING. A simple finished game is always better of a half finished prototype of an amazing idea. Why? Because the first one is a game, the second one is not. The first one can be sold and distributed, the second one can’t. And the fastest and easiest way to finish a project is: start small.
- Focus on what you can do best and do it. Get the rest done as quickly as possible. There are a lot of categories your game will be competing into: it is best to focus on those you will do well in instead of trying the best game overall (unless of course you are a ninja that can make a masterpiece in a weekend, you know who you are!).
For me, this translates as focus on MOOD. As i wrote in my first post, I’ll be using Ren’py for making a point and click game. My engine and genre choice won’t allow much innovation on the mechanics so the selling point of my game will be what I can focus the most on: music, graphics and writing. Setting the right mood is both what I can expect to do right and what I’m willing to do well, so it’s a good compromise.
- Details are EVIL. While this is my first attempt at making a game, I’ve worked on enough other projects to know that perfectionism is my number 1 reason of giving up. In the specific, focusing on non-fundamental details too soon is the worst disease to ever plague a project. As said in point 1, finishing is everything: this means that the fundamental stuff should be THE priority over any other tiny detail. No one will care if the tiles of the floor look like crap if they can’t even finish the first level because of a game breaking bug. Get your priorities in the right order first! Make a list of the game you will need, and cross out everything you know won’t be fundamental to the game. This is the list of stuff you’ll need to implement in the next two days. Now sit down and get your work done!
Ok, hopefully these reminders will prevent myself from bonking my head on the wall in regret too much. Rev up those fingers cause the time is near!
EDIT: thanks to Osgeld for pointing out some confusion about this post.
After seeing a post asking for tips on participating in Ludumdare as a team I was inspired to write this. I’ve successfully participated in three global game jams with in person teams, the Boston Festival of Indie Games, and Ludumdare(with St0ven), so I have a bit of experience with jamming as part of a team. There are plenty of other posts that cover the basics of participating in a game jam on your own and many of those suggestions still apply. Here are a few examples:
I’ve tried to keep my tips specific to a team environment, so without further ado, here they are.
If possible, form your team ahead of time
This way you know who’s doing what and what style they’re most comfortable with and what they are capable of. There’s nothing worse than trying to find another artist or programmer at the last minute and finding out that the tools they are familiar with or the style they use is completely incompatible with the game you are making. This also helps prevent the problem of too many chefs in the kitchen. If you form your team ahead of time and realize that you have four programmers and no artist then you still have time to split into two or more teams.
Minimize overlapping responsibilities
If you have multiple programmers you should try and break things up so that you aren’t working on the same code. You want to spend your time creating, not merging and bugfixing. If you do want to have multiple programmers working on the main gameplay components then have someone define interfaces early on. This way it’s really easy to drop in new code or change existing behaviour. For artists this may mean having one person do all character art and another do environments or UI.
Reduce bottlenecks and get rid of interruptions
Ideally create a way for artists to add content to the game without having to go through a programmer. Create placeholder assets(empty sounds, blank sprites) that can be easily swapped out without programmer intervention. This allows you to focus on making the game work while they can focus on content and aesthetics. Spend a little more time on making it easy to load in lots of content(It will pay off in a team environment). This also saves you or somebody else from interruptions where someone is asking what they can work on or to add their new content to the game. Make sure that each person has multiple things that they can focus on so that if they can’t progress on one they can switch over to the other. There are always going to be scheduling issues, you may have artists working on stuff while your programmer is asleep or vice versa and you don’t want that to slow down progress. Finally, if you need an uninterrupted block of time to work on something then be clear about it. Make sure that any questions or requests are written down for later or sent via email. I go so far as to sign off of IM/IRC and not check my email if I’m cranking away on something.
Someone should be calling the shots
This doesn’t mean that you need to be a ruthless dictator or that other people can’t make creative contributions but at the end of the day somebody should have an idea in mind for what the final game is going to look like and they should help guide people in that direction. Whoever takes on this role should be capable of understanding what is feasible. As a programmer I find that I am not great at estimating artist workloads and I have to assume that the reverse is true too. Also keep in mind that it’s a 48-72 hour game jam, it’s not the time or place to demand perfection. I always try and encourage people to do their best work and I find that I’m constantly surpirsed and inspired by what they create. If you find yourself in this role make sure you get estimates from the people who are actually doing the work and always be conservative with your estimates. If somebody else is organizing the game then don’t be afraid to say no to them, in the end everyone will be happier with a finished game than an unfinished game that was a really cool idea.
Use source control. If everyone is at the same physical location or on some sort of instant messenger then drop box or a network folder can work, but it’s not ideal. You want to spend your time working on your game not mucking around with version control so stick to what you know and keep it simple. Make sure that it’s something that you are familiar with. If you don’t know how to use git or svn then now is not the time to learn it, you’ll just end up frustrated when you try and do anything more complicated than simple commits. If you don’t know a source control system I would recommend using drop box with a backup folder in it for old revisions. If your artists don’t know your source control system but your programmers do then consider using some sort of hybrid where your code is in source control but your art assets are uploaded to dropbox. Recent builds should always be available to everyone on the team. Source control is what allows you to add potentially game breaking tweaks at the last minute without fear or to spend an hour refactoring things to add a new gameplay feature that may or may not work.
Pick an idea early and run with it
This isn’t nessecarily team related but it’s exacerbated in a team environment. It’s easy to waste time trying to come up with the perfect idea. Pick something early on and keep the scope small.
Plan for people to drop out or have other commitments
Focus on the most important parts of your game first so that when somebody can’t continue to participate you can still salvage a game out of what you’ve got. Animation and polish and menus are nice to have but leave it all for the final day. Unexpected things will come up, in fact I don’t think there’s been a single jam that I’ve participated in where everyone has been available for the entire time. If something comes up and you have to take a break or drop out then you should let everyone else on your team know that you can’t participate and if you’ll be back later.
Have fun making games,
Back in October 2012 I had the bold idea of taking part in Ludum Dare’s October Challenge. Having done game engine and game development projects in the past I knew what kind of huge challenge this was going to be. Nonetheless I still knew I wanted to do it.
Already being in a game idea research phase, after having completed the circle of my last game Pop Corny, I comforted myself by thinking that this was a cool way to take one of the many ideas in my head and really try it out. The worst thing that could happen was to add one more idea to the “crappy game ideas bin”.
What I had was a game idea and a custom game engine. I arranged a meeting with his majesty Thanasis Lightbridge (the mastermind behind the Dol Ammad and Dol Theeta bands), and convinced him to take on the graphics, music and sound design of the game. How little he knew of the horror and torture I was going to put him through for the next 30 days!
With no time to lose I described the idea of a sandbox type game, where you can freely combine simple gadgets to create elaborate flying machines. Before the day was over and through a crazy brainstorming session we were able to find a theme to dress this concept, and that was how Mr. Herbie, the male ladybug, was born. We were going to make a game for a lazy, chubby, ladybug that is too bored to fly with its own wings. Perfect…
Having high standards and only one month is never a good combination when making a game. What most people don’t understand is that games are not created in a linear fashion. You don’t start with an exact game design in your mind, you write it down, split it up in tasks, make a list, start checking out entries on it, and when all are checked publish your game. Game designing is more of a tree building that a list building. You start with an idea and from there you have a number of separate ways to go on. Each one of these ideas then give you more ways. So this way you build a huge tree with branches about every aspect of how the game can be. If we had infinite time, it would be possible to go down every single different path in that tree and actually find the game that works best for us. That is never the case in the real world, and definitely not the case when you only have one month to do it. It is obvious that the key to success in such cases is having a good “greedy algorithm” (as it is called in computer science) that will decide early which way down the tree is not worth going -and be mostly right about it so you don’t miss the next big thing in games-, and being quick to iterate implementing ideas. This is important since you will have to go down to branches only to find out that it will not work. You should be able to quickly backup and try another branch. Yes, the games you play are what is left after you distill all the ideas that don’t work.
That was exactly what I did. I chopped ideas as early on as possible. When an idea seemed worth trying out, I did a quick prototype of and tuned it until it was good enough. If it felt wrong it was dropped and I back tracked to other ideas. The chopping of ideas is mostly a craft and I can’t really tell you how its done. Its mostly about experience that is gained the hard way. The quick iterations on the other hand are a combination of discipline and having the right tools.
Discipline is about being able to focus on what you really want make, not being distracted and being ready to dispose hard work when things don’t turn out as fun as intended. And that is harder that it seems, because as humans we have a tendency of thinking better of things we worked for. It takes great discipline to also cut the feature you think is uber awesome but you probably can’t make it in time and you will have to cut down other features of the game, resulting in a grand total that is less of what it would be without the uber awesome feature.
Having the right tools is greatly important. How can you quickly iterate when your processes take hours? You need to find ways to make iterations as efficient as possible. I live in a different city that Thanasis, so what would happen if every change had to be transmitted by email? You easily solve that with dropbox for example. But we can do better than that. For example I had build a system that was constantly deploying (incrementally) the game through dropbox to any number of computers. The game engine also supported hot loading of game assets and scripts. I could actually press save on the script editor and the change was effective immediately on all testing devices running… anywhere in the world. Action games require a lot of “tuning” to achieve the maximum fun effect, and doing it through a build-run-test cycle is not going to work. You will either not tune it, or it will take you enormous amounts of time. Both bad.
Doing this really allowed to save time for the artwork to get prepared and to try out lots of things. It wasn’t until the last 10 days that the game was exactly as I wanted it to be for a months project. All the fun parts of creating your flying machines and crashing them to the ground was there. In the last 10 days we had all the stuff around that made. The leaderboards, the settings, the menus, the gameover screens, item unlocking and progression, etc. Artwork finalization also took place during that period, along with the final sound effects.
The final weekend to the release was crazy. I probably slept for 2-3 hours, fixing the final bugs and glitches. It was then that I had to cut one of what I considered a major feature of the game. The flight replay. It was a long shot because determinism is a delicate thing, and requires paying a lot of attention while developing the system, which was clearly not an option during one month. The system was not 100% correct at that point, and I had to cut it during that phase. It was stressful. Lots of work had gone into it and I had to cut it. Thankfully not completely as I was going to revisit it after the original release when there was time. So I did and now flight replay is supported and you can even share replays with friends.
The development was done on a BlackBerry PlayBook at the time, as I needed a very stable platform. I knew I didn’t have the luxury of trying out different screen resolutions etc. The PlayBook was ideal as it was a very specific system with an app store and many users willing to buy a good game. Don’t forget that the October Challenge requires that you make a buck out of your game!
Also during that last days I prepared the ground for the coming of FlyCraft. I setup a website announcing the release and setup a mailing list for those interested. I created a teaser video and made a post about it on Ludum Dare website. People seemed intrigued…
The game was submitted for review and got available on the BlackBerry World on October 30th, where it sold about 700 copies at $1.99 that single day. Users really loved it, and 5 star reviews were hitting the store constantly. The game being a BlackBerry exclusive also got the attention of BlackBerry oriented press that covered the event as something extraordinary, bringing in more traffic and sales. It even managed to be voted “Best new game” in Crackberry’s Readers Choice Awards for 2012. The October Challenge 2012 was a success for FlyCraft! But things didn’t stop there, as fate had more for Herbie. FlyCraft was mentioned in BlackBerry’s Developer Conference in Amsterdam during the keynote. I think that this was the biggest highlight of FlyCraft’s path. Alec Saunders in the keynote stood up in front of a huge video wall with FlyCraft on it and he talked about the game and the story behind it. I honestly don’t know how I am going to top that in the future!
Looking back at the challenge and the events that followed, I often try to fully grasp the benefits of this competition. I now believe that learning to self constrain yourself is one of the major powers you can harness for getting better and achieving your goals. Ludum Dare teaches you exactly that. I really believe that without the mental goal of the challenge FlyCraft would have taken longer to complete (if ever) and it would be a lesser game. Big part of FlyCraft’s excellence comes from its simplicity and focused execution. That would surely be missing without the challenge.
[This post was also posted on my blog here]
Happy New Year, folks!
I thought it’s time to write a postmortem too. For those who haven’t seen my game yet, you can find it by clicking on one of these conveniently placed handcrafted icons:
And now without further ado, here we go:
Some things went wrong
Yup, I’ll make that the first section. I think the game turned out pretty well all in all, so I’ll let the best come last!
Not everything went right though. First and foremost: It took me hours and hours to get motivated. Motivation is my biggest problem when I work alone. I’m not too good with game design, and often I don’t see if a game can be great before it becomes great – which seldom happens in the first few hours. There are many moments on the first day where I wanted to give up. What helped me was to remember that I’ve felt this way before with other projects and they turned out great! And now I have another one of those.
What didn’t help either is that I have no definitive base code library, I extracted my base code from another project and had to delete stuff that doesn’t fit. And then post it here. It takes time, and I don’t feel too good about it as it goes a bit against the Ludum Dare spirit. I’ll take care of that soon and will have one for the next LD!
Unsurprisingly, the clock wasn’t kind to me. Two of the levels were created in 10 minutes before the deadline. The first level is my “easy” test level, and the fourth level is my “hard” test level. I didn’t even have time to test the two in between. The third level works quite well, the second is awful but at least it’s beatable in about 1 1/2 minutes…
The music doesn’t sound stealthy at all. I am no musician, so this is no surprise. I’m not sure if I want to put enough energy in this to get better just for the LDs, so I guess I’ll just have to deal with that. I should have added an option to turn it off though.
Some things went right
Probably the most important thing: I wrote a to-do list before I started. This is so incredibly helpful and I hope all of you are doing it. For those who are not, here are the benefits of doing it:
- You think about the code design along the way. It’s not as exhausting, restricting and time intensive as doing a full-blown software design and it still gives you a general sense of what you need.
- You can always look how much you still have to do and how you’re doing progress-wise.
- Most importantly: It keeps you from digressing. At least that’s what it does for me – every time I feel like I’m lacking clear directions, I check my to-do list. Works without fail.
I had a level editor at hand. Mind you, it’s nothing fancy – it couldn’t be easier actually:
Yup, it’s just TextPad – with an XML file, shown with a slightly modified version of the Laser Systems font. It’s dead easy to parse. I’ll surly have something fancier in the future when I’m more established with games that actually need an editor, but for now its service was perfect.
It was 10 hours before the deadline. There was no time to be wasted. Yet I was idle browsing the FlashPunk forum without anything specific to look for. And guess what I found: TileLighting [1.0.1], made 6 days before the Ludum Dare. On an impulse, I spent 2 hours to integrate it. Here is the result:
Is there are lesson to be learned from that? I have no idea. All I know is that it made the game SO much better – it basically gave the game one of its major mechanics.
Speaking of major mechanics, I was 8 hours before the deadline and I had to decide which single feature on my huge to do list I wanted to implement – all others were to be discarded. I decided on lock-picking, and it turned out great. After the light became such an essential tool in the game, I decided to link the lock-picking to the lighting level – just how it would be the case in real life: The more light you have, the easier it is to do something hard. This feature received the most praise in the comments which makes me pretty happy!
Another important thing was that I focused on what I can do best: Gameplay. I could’ve spent more time on the graphics, but then it still wouldn’t look good and be much less fun. I think the abstract graphics are working well for the time being.
Another good thing was that I inserted sound effects and music. They might not sound as well as in other games where the developers actually know what they are doing, but it’s still a vast improvement to silence! I think I did both in 1 1/2 hours. With 48 hours in total, there is no excuse not to add them.
Here’s one more on gameplay: Enemies don’t have to be intelligent, they just have to work and be fun. I thought about implementing pathfinding, but took a far easier route in the end and I fare just as well:
- Enemies just patrol a straight line.
- When they hit a wall, they go left or right.
- When they scrape a wall and find an opening, sometimes they enter it.
- An enemy that spots a player goes to where he saw him last, then follows the player’s trail a few seconds:
And yup, that’s it. Just going straight for a point, then following a trail the player leaves. It’s was rather easy to make and is a lot of fun to play against!
I have no idea how much impact the fact that I made a gameplay video had, but I think it was a pretty good idea. It can give people a sense of the game if they don’t have enough time or incentive to play it and it can provide basic instructions for those who don’t like to read and can’t figure it out by just playing. It’s not hard to make, it doesn’t take much time and you can do it after the deadline: You should definitely make one too!
Some things were learned
A few lessons learned/tips:
- Don’t like the theme? Neither did I. Deal with it! You can still make a fun game. It’s not like you have to design your whole game around it. Sure, that would be cool – but having a game that will get 1/5 in the Theme rating is still better than having no game at all because you gave up before you even started.
- Keep calm and carry on: Never give up while there is still time! Maybe the game isn’t great now and you don’t have any idea how to improve it, but if you carry on, inspiration will hit.
- A to-do list helps to keep you on track. It also helps with the design. And tells you were you stand progress-wise. Write one before you start developing.
- Focus on what you do best. For me that’s gameplay, and that’s why my game isn’t as pretty to look at as other games, but it’s a lot of fun.
- Add sound effects and music. Even if you’re not good at it, I guarantee that your game will feel FAR better with them, and with good tools, it won’t take you long to make and insert it either. (In case of doubt, just add an option to turn off the music.)
- Sleep. Yeah, 48 hours isn’t much time, but if you’re fresh you work better. And who knows what kind of ideas you get when you’ll get your subconscious some time to rest?
- Music for Programming is pretty cool. Especially when you’re having a hard time concentrating.
Some features were discarded
Are you interested in what I wanted to implement, but ran out of time to do? Here is a quick breakdown:
- Level / Gameplay
- Treasure makes you slower
- Treasure: Weight (can only carry certain amount)
- Step-on mines
- Alarm Level
- Enemies shoot
- Vanishing / Hidden after time
I don’t want to elaborate on these, just give a quick impression, but it’s such a pity that some of them are missing! I wanted to have lasers as obstacles, maybe switching on and off, traps to force you to have a higher light level (and maybe a trap disarming mini game), an alarm level slowly escalating difficulty when you’re seen, enemies shooting at you, and my favourite: Dynamite to break walls, but alerting every guard even if they can’t see you.
But well, you can only do so much in 48 hours. All in all, I’m pretty happy with the result. It’s a very good feeling I did that all on my own, and I am glad I participated!
Some thanks are offered
Thanks to the Ludum Dare organizers and to the great, great community! You guys have made a wonderful thing here and are doing all of this in your free time and it is so much appreciated! I cannot believe how many games were made, and how many kind comments I got on my game – I’ve seldom experienced such a friendly community. I had a great time and I will definitely participate again!
Do you have any questions I didn’t elaborate on? I’ll happily answer them in the comments! And you could leave a little comment if you enjoyed reading this or what you rather wanted to read.
Apropos, one last thing: Thanks a lot for reading this postmortem! It hope you enjoyed it as much as I enjoyed writing it. (And it’s probably pretty obvious, but maybe you want to follow this other conveniently placed link and rate my game? Your feedback means a lot to me!)
I know it’s a bit late to get the nice after competition statistics, but if you haven’t been doing so already, you can use bit.ly to gather a small extra bit of statistics for your download/click-through information on your game. The service is free; and the setup is as simple as pasting in your current URLs and using the bit.ly shortened URLs instead.
Then, you can track your stats by logging into your bit.ly account, clicking on your “bitmark” for the other URL, clicking the little i, and then the other little i next to your simple stats. It then breaks down your click information by time, referral website, and location.
If you provide bitmarks for all of your various versions, you can see the popularity split among the different platforms as well.
It’s a neat little free tool that I hope people can use to their advantage.
In this, my 6th Ludum Dare, I had yet another fairly unique experience, encountering both new and old challenges and successes:
(Repeatable) Stuff That Went Well
- My code was organized. In the past, I’ve written all the code for the game into the main function. This made it difficult to have more than one level and made it painful to add, for instance, a starting screen. In general, it let me make more content than usual.
- I got feedback from people (well, one person), then implemented it. I did this early, leaving me time to do a good job implementing it and still leaving me a whole day for assets. The comment really helped me though, giving me an idea of what would make my game fun.
- I left a lot of time to make assets after finishing the game. I spent the second day solely on assets.
- Based on my own playing of the game, I refined the balancing of the game to draw more attention to the special mechanic I’d added to the game.
- I chose an easily attainable goal and then built on it. I had somewhat of an engine done within the first hour or two. From there, I was able to add more stuff and polish.
- Certain bits of polish were really helpful to the game. For instance, the sword in my game was pretty sweet.
- I stayed motivated. In the middle of this competition, I kind of hated my game, or at least, I didn’t put much faith into it and didn’t really know what to do to fix it. However, I pushed on, doing what I did know how to do (assets) and then revisiting the gameplay later and finding that it was not really as bad as I’d thought and that I did have solutions for it.
(Avoidable) Stuff That Went Poorly
- My code was spread out. There was no single place I could do all the balancing from, so it was a huge pain to do so. Also, I made too many tabs on Processing, so I could only see the names of 3 or 4 at a time, which made it hard to find any specific class’ definition.
- I didn’t put much thought into what sort of mood I wanted. Resultantly, I didn’t exactly create any cohesive mood.
- My art still wasn’t terribly good. I think I could have used more animation to make the top-down thing more convincing, but I don’t know. I wish I were better with this sort of thing.
- The controls may not have been the best choice.
- I don’t often play games based on action or on being quick and not so much on decisions. I therefore found it difficult to capture that sort of gameplay well.
- The game concept isn’t wholly original. It feel more like a variation on some sort of shooter game – the majority of the game (the shooter part) has been done before. Only a small aspect (the part about summoning enemies by taking stuff) is really new. Then again, people keep saying they like the idea, so… maybe it’s a good concept.
- I did not proofread the title page. It has a lot of typos. Like the good player of a game that I am, I never read anything in my game and just clicked on stuff.
Also, if you are one of the >1000 people who haven’t tried my game, you can click here. (P.S. I love comments on my game – it’s one of the best parts of the dare for me)
Hey there developers and gamers!
I had a lot of fun with Ludum Dare last weekend. It’s always a blast to make a game that turns out pretty good!
What went great:
– The theme.
I feel like the theme gave me a lot of room to be creative and come up with something the rest of the developers didn’t. I love the freedom of that. Kudos to the Ludum Dare team for making that possible
I know what I’m doing when I’m in Flash. I spent half my life learning Flash xD
It crashed twice, but thankfully it has autosave, and I didn’t lose too much. Tip: The debugger decides to crash every few tests…
– Not using a chunk engine.
It’s true. The original engine I made had the start of a chunk engine. It didn’t make sense. It was awful!
I LOVED streaming, not just because it motivated me, but because I got to meet some really neat people in the chat. I listed everyone I could remember in the “EXTRA” section of my game menu because it was so fun.
– My idea.
I had a good idea right from the start. It’s really important to get the basics down in your game before you go and add goats or something. That’s what I learned from this experience. As quickly as I could I built a working game with a unique concept and simply gameplay. Afterwards I added all the less-needed features, like music and a menu…
– Time management.
48 hours to make a game. It seems impossible, but when you start doing it, it’s surprising how fast you work. At least for me. I was able to get done what I had to get done in the time I had to get done doing it (twitter reference).
What went not-so-great:
– The details.
It’s not really expected to have a detailed game during Ludum Dare, but I feel like the features I did have weren’t pushed to the right spot. The regenerating stamina was too slow, the leveling up was boring, and some other things (like the particle size). I’m sure it would make the game less glitchy if some of my rendering wasn’t messy too. Hopefully I’ll get around to fixing it up and making it a finished game!
Overall I think I did a great job, and I had fun! I like a lot of the games I’m rating too! Great job everyone else
Here’s my submission: Dragon Boss
So, I’m done and dusted – first LD is completed, and I’ve built my first game in the process. I’m immensely proud, but also a little sad – I made some real rookie mistakes, and I think I could have produced a far, far more polished game with ten or so more hours and a little more motivation. So instead of the traditional post-mortem, here are what I’d tell my pre-LD me, if I had the good fortune to send him an inter-dimensional time-travelling message.
1. Learn your weak areas, and focus on them
I did this mostly right – prior to LD, I read a few tutorials on creating good programmer art, and those were invaluable. Sadly, I didn’t also realise that I didn’t know the first thing about making music, so had to figure it out as I went along. I lost a fair few hours figuring out whether I wanted to use SunVox or not.
2. Define your mood early, and stick to it
I knew pretty early on what I wanted from The Fix – the feel of 1940s New York underground boxing, with black and white pictures, quiet piano music, and a small crowd. What I hadn’t really figured is that I really don’t have the skill for that. I can’t draw boxers for crap, let alone make good piano music. Had I taken that into account, and gone for a more cutesy aesthetic, I would probably have ended up with a far more coherent game with fewer stick figures.
3. Think of which features you’re willing to lose
Early on, think about what’s core to your game, and what’s superfluous faffing around. Think about what you can lose, and what you need to implement – and get that done early. My game would have been massively improved with a rudimentary betting system, but I was just so out of motivation 2 days in that I didn’t get it done. That’s a huge shame, in hindsight.
4. 48 hours is actually damn long time
I assumed, like most people do, that I might fail LD because due to running out of time. I was nowhere near that happening – 48 hours is a huge amount of time for a basic game. What’s far more likely to kill you is burning out and running out of motivation. So take some time off: go outside and enjoy life. I spent all of Sunday morning outside with my girlfriend, and had a really, really productive afternoon.
I think that’s all for now. If you’re reading this and considering jumping into LD, then the most important tip of all is this – don’t worry too much. Enjoy yourself, build something that works, and finish it off. There are plenty more jams in the future. I’ll definitely be back for another
Don’t have a sensible workflow for creating movement paths? No problem! Just make a mesh in Blender that’s a long chain of vertices where you want something to move:
Export that chain as a .obj file. That format is an easy to read plaintext file, with each vertex’s position given by a line beginning with “v”.
Just grab the vertex positions from that and you have a path to walk along. You can even copy-paste the vertex positions into your raw code if you’re in full LD panic mode.