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
We’ve received quite a few comments and questions about our entry, Dungeon Raider. Since people don’t tend to come back to the comments page, we figured putting up a blog post could lead to people seeing answers to their questions and feedback.
TL;DR: We ran out of time to do a lot of things that we wanted to add.
Q. How did you guys manage this in 72 hours?
A. Our team has worked together a number of times, using the same tools, the same programming language, and similar code libraries (Slick2D, Artemis, etc.). Basically, it’s a lot of practice. If you’ve done something before, it’s a lot easier to do it again quickly.
Q. Can you share the source code?
A. It’s too messy! I know that’s to be expected during a 72-hour jam, but if I’m going to share source code I’d rather clean it up before I release it. I can, however, discuss any particular techniques used if there is anything in particular you’re interested in.
Q. Excellent game, but did I miss the link to the theme?
A. You only have one life is pretty much a staple of roguelike games. We were intending to do a second link (you only get one heirloom when you die), but time restraints caused us to drop this.
And some responses to common feedback:
Comment: There’s no use for gold.
Reply: We wanted to add a merchant room spawning randomly in later depths of the dungeon, but we ran out of time, as with a lot of features.
Comment: It runs slowly.
Reply: The game was optimised only enough to get it to run smoothly on my reasonably low-end laptop. It runs pretty poorly on some other computers, unfortunately, but there wasn’t much we could do about that during the jam (lack of time, and lack of computers to test on).
Comment: It’s too easy.
Reply: We agree. I think we got the balance right for the first level, as an introduction, but we spent too long on some things and didn’t get enough monsters implemented. We were hoping to add ranged monsters, traps, minibosses, etc. as well as the game progressed.
Comment: The lighting is cool.
Reply: Thanks. That was probably my favourite part to code, having not done that in a jam before. There’s no shaders or anything there, just determining light levels by sending rays out from the light sources (once, at dungeon generation time, for speed purposes), and line of sight checking from the player. The light gets darker gradually over distance, and quickly when it hits something.
Comment: The attacking is awkward.
Reply: Yeah, the hitbox, movement, and collision code could do with a complete rewrite. That’s something that I am never quite happy with in my LD entries, so I think I need to pay far more attention to this in future jams.
Comment: A really, really awesome entry. I even ignored the fried chicken nearby while I was playing the game.
Reply: Wow, that’s the best response we’ve ever had to a game.
Comment: I kind of don’t like the audio.
Reply: Neither do we. Our regular audio guy was really unwell during the jam, so we just quickly added a few effects. We should have spent an hour or so more working on this, as we feel that it really let down our entry overall.
Comment: I bet you had previous experiences with the genre due the polish level you gave it!
Reply: Not really on the development side, other than our second LD entry, Stranded, which had some similar stuff. This is the first time we’ve released something with procedurally generated levels rather than hand made ones, and the first game that had line of sight in it. We have played a lot of games of this type though.
Thanks to everybody who has rated or commented on our entry. We really value the feedback.
Rather late post-mortem time! This is The Evil Cult’s most ambitious jam entry yet, Dungeon Raider. We’re really happy with how it turned out, and would really appreciate some feedback on it. It’s by far the most we’ve been able to cram into the 72-hour timeframe of the jam.
What went right?
The lighting adds a lot to the look of the game. The walls and floor are all mostly the same (with a few variations), but the lighting and shadows help to vary the look.
The dungeon generation works really well. I really like the room-based approach that we opted for, as it gives some variety in otherwise very similar rooms.
The number of features we managed to get in – items + working inventory management, loads of unique scrolls, potions and spells.
The coins spilling out of treasure chests look really cool, both in the graphics used and the scattering of the coins.
What went wrong?
Our audio guy was unwell, so we had to make do with some quick sfxr sounds and royalty-free music.
One of our artists was also unwell, and only made it for one day of the jam. As such, the main character, while cool looking, is lacking a full attack animation.
We didn’t manage to quite get as many monsters into the game as we wanted, and the boss fight was lacking – we had hoped to build a lengthy boss fight with a number of mechanics involved.
The game requires a reasonably powerful computer to run. We simply didn’t have time to optimize the game to run well.
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.