About The Evil Cult
Ludum Dare 28
Ludum Dare 27
Ludum Dare 26
Ludum Dare 24
Ludum Dare 23
Ludum Dare 22
The Evil Cult's Trophies
The Evil Cult's Archive
Some Ludum Dare tips for the people who are joining us for the first time.
- Unless you’ve made a few games under jam conditions, try to build a game that you can start balancing and tweaking (and making FUN!) right away. Some games can’t be balanced until they’re nearly done, especially if they need a lot of AI, a number of game systems in place, a number of game mechanics connecting to each other at the same time, etc. With some other games you can start adjusting things early on in the process.
- If your game is the type of game that has levels, don’t create them in the order they are played. Do the important levels first, then filler ones later, so that if you run out of time you still have a complete game, just a shorter one.
- Figure out what the core mechanics of your game are and do them really well early on. Basic actions should feel good (such as jumping in a platformer, shooting in a shoot-em-up).
- Keep the theme in mind. It’s important not to just tack it on at the end.
- Have a title screen, a menu screen, credits, etc. They don’t take long but they make a game feel finished.
- Make sure you’re familiar with most of what you’re doing. You should know your way around the language, libraries, and tools that you’ve chosen to use. Having said that, it’s good to stretch your limits a little by trying new things, but don’t get carried away by setting your goals too high. It’s more important to finish.
- It’s worth putting in little “juicy” things into a game if you have time. Particle effects and easing might not add anything to the game play, but people appreciate the little polished touches more than you might think.
- Don’t be afraid to scrap unimportant features. Also don’t be afraid to change your mind if something isn’t working. We changed our game entirely and started from scratch a full day into LD26 and ended up with a better game to show for it.
The Evil Cult will be back again this Ludum Dare for the sixth time.
- Language: Java
- Libraries: Slick2D and Artemis
- IDE: Eclipse
- Art: Paint.net, GraphicsGale, MS Paint, Photoshop
- Audio: sfxr or bfxr, SunVox, Audacity
- Other Stuff: Tiled, Trello
- Maybe some other things depending on theme and what we decide upon creating.
We had a load of fun this time around. It’s probably my favourite of the five games I’ve entered into the jam so far. We hope you like it too.
Factory Wars is a “tug of war” type RTS game where you control factory production and set lanes for your robots to follow. Spawns and income are on a ten second timer and you can capture flags to increase your income.
This is our game, Slime Factory!
This is the reverse of a tower defense. In Slime Factory, you start in a deadly stage full of turrets, lasers, mines, and other nasty traps. Your objective is to help the slimes escape by manipulating the level with a limited array of tools. We managed to get thirteen levels created before the deadline. The first few are relatively easy, being introductions to how the game mechanics work. The last two levels are more challenging to complete.
Our goal with the minimalism theme was to see how much enjoyable game-play we could add while giving the player only a few choices of tools. The hammer can break destructible blocks, the wrench can modify some blocks, the bomb can destroy most things in a 3×3 area, and the red block allows you to modify pathing.
We love feedback, so please let us know what you think of the game in the comments!
Not much has changed from last time - same four people, same tools and language.
Some things are changing though. I intend to use LWJGL for access to OpenAL for audio – I probably won’t use any other LWJGL functionality though, since I’m quite happy doing 2D games without OpenGL being involved. The reason for this change is that I want some more control over the audio than TinySound gave me. I’d like to be able to, for example, change the frequency of sounds.
I’m hoping to ensure that I can run the game as an applet this time. Last time around, it ran, but paused after each level while downloading the new level, which was quite horrible. As such, I released it purely using webstart, since I didn’t have time to rewrite enough code to fix the problem. It’s relatively easy to factor in this time, since I’m aware of the problem.
If whatever game we decide on lends itself to using a game controller, I’ll be using JInput to provide access to that.
Firstly, this is our game. If you haven’t played it yet, give it a go! These are some thoughts from our team members about how the jam went.
Andrew Beasley (Design + Tileset Art):
Ludum Dare was a fantastic experience for me! I had participated once before but my part then was minimal. This time around I created the majority of the art assets and level design for our game, as well as helping in the conceptualization of the game and design of game mechanics. I’m very proud of what we have acomplished and I am now a lot more confident in my development skills. Before the Jam I didn’t think I had any of the skills required to make a game whatsoever, but now I am looking forwards to doing a lot more game development work in the future.
I think we did an excellent job on the game but we didn’t get everything done that we wanted to. My biggest regret about the game is the implementation of the teleporters. There’s a lot that could be done to make them feel right such as adding sounds and animations, and fixing the mechanics as there was a significant design flaw with them. There was also a fair bit we had to cut from the game such as a Volcano level, more puzzles, and opening and closing cutscenes. I am looking forward to working on this game a bit more and getting something out there that I can be happy to call truly complete.
My favourite part in the making of the game was definitely the level design. I do not really consider myself an artist so it was really good to be able to take the art assets that I struggled on for hours and put them together in such a way that turned out working quite well. Game design has always been a passion of mine and it was a great relief to be able to put down working on the art for a while and get to work on what I consider the fun part.
My favourite part of the game is probably simply how it all came together. The different mechanics of the game ended up fitting together quite well and I’m especially happy with how the pushable boulders worked. Not only do they feel right to move around but it was a great idea from our programmer to make them able to squash the slimes.
Thank you to everyone who took the time to play our game and especially those that gave feedback. I had an amazing time this Jam and will absolutely be participating next time!
Brendon Byrnes (Audio):
What went right:
Choosing a musical ‘style’ – As soon as we had a game idea locked in, the overall musical style began to take form in my head. With our game being, in my mind, a flashback to Zelda, Commander Keen and other early games, I knew immediately I wanted to use music that felt authentic and sounded like it belonged in an older game.
Building ‘repetitive’ music – This was one of the things that went both right, and not to plan. With the game style, I wanted music that could loop easily and wasn’t too complicated, yet with time constraints it wasn’t long enough to keep from being ‘too’ repetitive. In the finished project I would like to see it go double the length, perhaps even triple before it loops back around, but I’m reasonably happy with the end result. It suits the game, and while repetitive and looping, still fills the gap for audio and helps convey the style of the game.
What didn’t go to plan:
Limiting Chord usage – I’m a musican, not a composer. My composition work before this jam had comprised mainly of arranging background to other pieces, or re-arranging a piece to fit the makeup of the group I was working with. This does tend to leave my composition work itself quite undeveloped, and give me a tendency to use ‘safe’ base block chords. Listening to the music now, I wish I’d used a larger pool of chord types.
‘Writer’s Block’ – I find writing, both music and language, on a schedule difficult. I rely on inspiration to write, which meant the jam environment didn’t suit my processes at all. The melody, speed and sublety of a piece actually started to take form with the tilesets, as I saw pixels and started to build themes I felt suited them. I also managed to get distracted several times for extended periods of time after I’d stopped working to ‘clear my mind and gain another perspective’.
What I learned:
I need to practice composing more, especially composing through ‘writer’s block’. Next time I’d like to create things that are longer and more varied, using multiple chord types (I’d really like to start using sus4 chords in something, just because I like the sound of it). Also need to practice with my tools to find how to build varying tempos more easily. This is so I can change rhythms, and generally get out of building simplistic music.
Patrick Beasley (Programmer, Map Screen Art):
What went right:
The team worked together really well. The pieces of the game fell into place nicely and without too much stressing. We ended up with a really polished product given the timeframe we worked in, and our relative inexperience with game development (two of our members had never jammed before, but performed really well).
There were no major bugs in the submission (though there were a few minor ones that have since been fixed ready for a post-jam version). I coded the game in such a way that I could test it the entire way through, constantly checking everything that I was adding. This took quite some time (because I could have been adding new features instead of testing) but I think was worth it, because I was able to adjust everything to make it more fun.
The game was fun. It’s a great feeling to have played through the game maybe a few dozen times (testing) and still enjoy playing it.
The game was complete (though short). I’m really pleased that we managed to get a proper title screen, map screen, credits, full sound, music, and all art done to a good standard.
What went wrong:
The game required way too many art assets. This is just in the nature of a tile-based adventure game (especially with multiple zones like we did). I think that in future jams we should probably consider this a lot more in the initial concept. We should probably pick a game that doesn’t require any where near as much art to be created (because none of us are dedicated artists).
There were a couple of things which I knew weren’t quite perfect before the submission, and that drove me mad. Things like the fog of war not being a perfect circle (the circle algorithm that I implemented was always off by one horizontally), the hitboxes not being fine-tuned, aliens being able to walk through pots, etc. They turned out to be trivial fixes, but I ran out of time (and I was in the mindset of “this isn’t important to getting the game ready to submit” at the time).
The game was too short. This ties into “too many art assets required”. There were so many things that we had planned that would have been absolutely fantastic to add, but we didn’t get to. We had plans for a volcano zone, some more gameplay that utilised the fog of war that we had, interesting weapons (a fus ro dah gun?), more enemies (mobs in the volcano that left a trail of fire behind them), traps, etc.
What I learned:
I learned that we were capable of working as a team and finishing (somewhat) a game for release. We had never worked together on a project like this before.
A lot of the code was new to me, this is the first real game that I’ve done in Java (last LD I used Actionscript + Flashpunk, I like to mix things up). There were some things that I hadn’t done before the jam, such as XML loading (for the map file format), audio in Java, etc.
Thanks to all that played our submission. It was also great playing through a lot of the submissions for the jam. It’s a real shame that we couldn’t rate more, there were some really awesome games this time around!
This is a play-through video of our Ludum Dare 23 Jam entry, Stranded.
If you’re interested in playing the game, please note that this video goes from start to finish, so contains spoilers.
There’s a group of us joining the jam this time around. Not sure on numbers yet, since availability still hasn’t been completely confirmed, but there looks to be a good mix of people involved.
The code is being done in Java using the Eclipse IDE. Some external libraries will probably be used, such as TinySound for audio playback.
The tools being considered for music creation are Sibelius, SunVox, Band in a Box, and MuseScore, depending on the style of music required for the game we end up deciding upon.
The design is likely to heavily use pens and paper/graph paper, white boards, Excel, notepad documents, and shouting at each other.
The artists are using Photoshop, Paint.NET, and possibly some 3D editing software depending on game choice.
FRAPS and Chronolapse are being used for recording our development and some gameplay footage, which we’re intending on editing together at the various stages of development (or maybe after we’re done, if it looks like time is becoming more of an issue) to create some devlog type videos as well as a gameplay video.
The team is a mix of a couple of people who have game jammed before and a couple for whom it is their first time.
What went right?
- The Flashpunk framework was incredibly easy to use, and had most of the features needed. The few things that it couldn’t do I was able to live without.
- I was able to pump out the few sound effects in sfxr extremely quickly.
- The graphics came together a lot quicker than I thought. I’m not an artist by anyone’s standards, but 8×8 pixel tiles are so amazingly simple to create that I was able to keep churning them out.
- My Trigger class. Although the code was messy, and it really needed to be cleaned up, it was extremely powerful. I was able to create interesting events in XML alone.
- It was a lot of fun. This is the first time that I’ve tried something like this, and the experience was awesome. I usually find it really hard to get motivated, but being surrounded by people doing the same thing is awesome.
What went wrong?
- Simply not enough time to put in the content. After getting the graphics and code finished, I didn’t have enough time to put together a fun game. There were actually a lot of features in the game that I had ready but that I didn’t even get a chance to put into the game. For example, there were obtainable items that could be picked up off the ground.
- There were some bugs that I knew about but did not have time to fix. The major one that everybody who plays the game fully will encounter is that doors appear on the wrong layer when you come at them from the top. To fix this, closed doors need to be two separate images in two separate layers, one underneath the player and one above.
- The code was really messy. It all worked, and there aren’t too many bugs, but I would not like to maintain this code after the event – if I do continue to work on this game, I’ll be cleaning up and redesigning the code to make extending the game easier.
- I ran out of caffeine.