Posts Tagged ‘tips’
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.
So, I’ve gone and produced my warm-up game. It’s called Driver Hunter, and it’s laughably abysmal, but I figured it’d be worth doing just to see if I could actually produce a working executable. Don’t trust that fancy tool you’ve been told does the trick, because it doesn’t. Distributing pygame is like fighting an angry dwarf. In my case, it turns out pygame doesn’t like my system font. Don’t ask why. So my game now uses Arial, because I’m hip like that. If Pygame2exe isn’t working, maybe it’s worth trying for you too.
So yes, lesson 1) check you can actually publish your damn game. Do you want to release to mac? To Linux? To Windows? Try it, and make sure it bloody works.
Lesson 2? Sound. I’ve never done any of my own sound before, but seeing I’m trying to enter the compo, looks like I’m going to have to! I discovered automata thanks to this post, and it worked flawlessly, producing something that was at least barely passable as game music.
Other than that? I’m good to go! Timetable is cleared, tools are ready, fridge is stocked with diet coke. I’ll be producing a timelapse if I can
Well, looks like we have a lot of newcomers again this time!
And as I appreciate all of the new guys, I’ll just welcome all of you! So have a warm welcome and a hug from me!
And now I’ll try my hand at a McFunkypants-style guide, which contains some teaching and hinting and also motivation!:
- To get the most out of the compo, join the #ludumdare IRC channel on the AfterNET IRC network. (You need a IRC client for that. Check here or here or here for these.) – There are tons of awesome, and really nice people there who are willing to help you. If you want to talk to me directly just poke Folis. I’m there very often.
- Generally get involved with the community as much as you can! People love to see photos of your desk, food, a timelapse (you can use ChronoLapse by Keeyai for this), or just a screenshot with some text every now and then. Also, don’t forget to write a post-mortem!
- Check out the LD survival guide by fellow LDer Sol_HSA – It’s a very nice guide that helped me a lot during my first compo! You don’t have to follow every rule, but there are a few I can recommend: Sleep, tool preparation (use the Warmup for that!), and taking breaks. Those helped me the most. You should probably avoid alcohol too.
- Check the tips section, it contains many useful posts written by other LD veterans! They know what they’re talking about!
- And some general tips for the game design:
KISS (Keep it simple & stupid)!Your game shouldn’t be a overly complex 3D turn-based online strategy sim! Try to get a small idea. Describe it briefly (about the size of a tweet. Thanks to Neonlare for that idea!)
Cut features when needed! Sometimes there’s this great mechanic you have, and it takes AGES to implement. This is where a mental battle begins. If a feature takes too long to implement, you should consider cutting it (except if it’s your core mechanic). Sometimes that’ll help with speeding up development!
Get something playable quickly! You shouldn’t waste any time getting some nice, solid engine going. You don’t need an all-rounder. Just get your core mechanic into the game as fast as you can. If all else fails, you can still submit something like that.
Avoid feature creep. Yes, there’s this great feature, and that great mechanic, but you have a very limited timeframe, so forget about all the unneeded mechanics. Focus on the main idea!
Playtest, playtest, playtest! Hop on IRC (see above) and let people play your game (there’s always someone who has time for this)! They will find bugs you might not see! And they can point out any balancing flaws, graphical hiccups and other problems (The experience of DLL hell isn’t exactly great.)
Polish! If you have time left, replace the placeholder art with some pretty pixels. Compose some music (check the tools section!), add some bleeps and blops! Give your game that “finished” feel.
- But there’s one rule above all others: Don’t forget to have fun! After all, Ludum Dare is a competition just for the fun of making games! You shouldn’t force yourself to apply all of these rules, if you don’t feel comfortable doing so.
And after you read through this wall of text, here are some final words of motivation: Even if the time is limited, I know that you CAN do it! We all can do it!
Perhaps you are like me and have never made a game before Ludum Dare? Don’t worry! My very first game ever was made during Ludum Dare #19!
And even if you don’t manage to finish: There is always a next time.
Alright, that’s all I have to say for today!
Maybe you’ll come to IRC for a chat?
(P.S: Is there like a position for welcoming and helping the first-timers with their questions? If there is, I’d love to do that! *looks at PoV*)
Hi, Gravity Games here, and I can’t wait until the next Ludum Dare! I do however have a few questions about the rules if you don’t mind.
1) I saw in the rules that we ARE allowed to use base code if its mentioned before the dare, but how far would be considered base? Like, a basic routine to open a window and draw graphics? A basic engine with a level editor (though I’m assuming that this would be a little bit too far to be considered a base).
2) Continuing the above question, I have a level format that I tend to use for every project I start. I was wondering if it would be okay to copy and paste the same code that reads these files, or would I have to recode the same format from scratch. Or would I have to make a completely new format entirely?
3) Continuing from the level format question, I already have a level editor for this format. Is it against the rules to use this level editor presuming I use the same level format? If so, would it be acceptable to program a new editor, or should I just type in the levels with a text editor?
4) Is it against the rules to submit a game to the dare, continue to work on it for the rest of the hours of the jam, and then resubmit it for the jam?
5) Finally, I’ve never completed a game before (not 100% anyway), much less in 48 hours. Quite obviously this is a big challenge for me, so how would I start practicing? Would you recommend going to past ludum dares and completing them, or is there an ongoing challenge I can use for practice?
Looking for established high-profile music? Don’t want to search websites for that one awesome track?
Then go check out Matthew’s Big List of Public Domain Songs!
Features several dozen folk-songs and classical pieces, used in such games as
- Vampire II: Bloodlines: The Masquerade (at one point in the background)
- Unstoppaball DX (shameless plug) (sorry)
Go check it out. Also features some pointers to locate more awesome usable tracks.
22 days into October challenge, and here is an update on the current version of Vox. Version v0.19 has just been released on Desura and IndieDB, so I thought I would share a post on here to list some of the new features and updates to Vox.
Here are the newest features:
- More Enemies in the world.
- Flying enemies.
- Skeleton archers shoot you from a distance.
- Skelebobs chase you and try to kill your with their deadly swords.
- King Slime boss spawns when you kill too many of his little slime buddies.
- Interactable NPCs.
- NPC movement behaviours – waypoints, world navigation and player follow.
- Questing system.
- Treasure chests.
- Particle editor in the game.
- Particle effects can be added to character parts. i.e head, body, feet, etc.
- particle effects can be added to created weapons and items.
- Undo feature added to creation mode.
- Much better character creation screen in front-end menu.
- Ore deposits that can be mined for ore.
- Collectable items (hearts, coins, ore).
- Damage text popups.
- Improved HUD graphics.
- Experience bar and leveling up.
- Gradient background and better sky rendering.
- Better intro animation.
- New custom frontend music and game music.
- Smoother mouse controls.
- X360 gamepad support.
Here are some recent videos demonstrating new gameplay:
There is a free version to download and test and I would really appreciate it if people would be willing to try this and maybe provide some feedback. As always I am really curious to hear peoples opinions and suggestions. I really like player feedback and love to hear what people’s opinions are (Unless of course they are just the 500th person to state that Vox looks similar to Minecraft or CW :P).