Join us on Twitter and IRC (#ludumdare on Afternet.org) for the Theme Announcement!
Thanks everyone for coming out! For the next 3 weeks, we’ll be Playing and Rating the games you created. You NEED ratings to get a score at the end. Play and Rate games to help others find your game. We’ll be announcing Ludum Dare 36’s August date alongside the results.
New Server: Welcome to the New (less expensive) Server! Find any problems? Report them here.
Done for today, I have a level full of archaeologists just waiting to be slaughtered. When they die they drop ancient coins, which you need to operate the ANCIENT TECHNOLOGY.
I’ll save fixing this buggy behavior for tomorrow. My super villain archaeologist with a gun never aims it at you properly, but he still tries shooting it, best of all if you circle around him he ends up shooting himself.
EDIT: What does everyone use to make their animated gifs? Mine doesn’t seem to work…
As I explain the the entry description, I was not able to get sprites rendering correctly, which kept me from completing the game. I decided to submit it anyway, though, mostly because I though there might be a couple people interested in the Cow Vision effect I was able to implement.
Hopefully the rest of you had better luck than I did this weekend!
I’m going to try to do my fair share of judging, but my hopes are not high – I’m moving to Taiwan next week so I don’t have much time! AAAH! Why am I sitting here coding, I should be packing!
Yesterday evening was largely a bust, but I’ve been making a decent bit of progress today. Hooray! I’ve got random dungeon generation up and running now, and MY SPECIAL SECRET IDEA THING! Let’s see if anyone can tell what it is from a pair of screenshots.
First, just the random dungeon as one would expect to see in a Wolfenstein-esque raycasting FPS:
Next, same dungeon, same position and everything… but now with my crazy idea enabled:
Any guesses as to what’s going on? Any idea what my game is? Tune in to my next post for the answers!
After some thinking and a little playing around with a quick build, I’ve mostly solidified the game idea.
You play as the ghost of a dead crew member aboard a spaceship who has come back to haunt the living and destroy the ship, for reasons unknown (to you guys, anyway). It’s a fast FPS with things like bouncing bullets and multishot, might throw in some grenades or something too. The only problem so far is I’m not sure how to make it mean much. I mean, the premise is cool, but it doesn’t seem to affect the gameplay much. But I do have a few ideas…
I’m thinking perhaps your goal is to revive yourself and leave the ship while blowing it up. To this end there would be 3 things to do and the order would be somewhat up to you:
Set the ship to self-destruct
Revive yourself and become human
Escape the ship
Obviously if you escape the ship before the others, you get a pretty bad ending because you didn’t kill everyone and you’re still a ghost. I’m thinking that as a ghost you can see/interact with certain things like platforms, powerups, and areas that you normally can’t, but perhaps as a human there are things you can do that you can’t as a ghost, like activate objects and open doors. When you sabotage the ship, it will start a countdown and if you don’t escape within that time you die, and the game ends (but you don’t necessarily fail!). So, you have two main paths; Revive yourself and then set the ship to destruct, or set it to destruct and then revive yourself. The first is risky because you can’t use as many safe options and can’t get as much combat advantage when you’re alive, the second is risky because you have to both revive AND escape in the time limit, instead of just escaping.
OK, I’ve sorted out my issues. I like where this has gone, and it’s what I’m sticking with. Thank you for reading, and good luck in the competition!
ChromaGun was our entry to Ludum Dare #32. The concept’s inception came late at night after a few (ahem) beers. The theme was “an unconventional weapon”, and we decided to go with color. The player’s objective is to paint walls and enemies with the “ChromaGun”. Enemies are attracted to walls of the same color and float towards them. This core mechanic, paired with elements such as button-triggered doors, deadly electrified tiles and particle grids which only allow bullets to pass through, created some seriously entertaining gameplay, even in the early stages of development.
My Ludum Dare game, “Perfect Squad” is now up. I really wanted to do an FPS so I came up with the idea that you’d control each squad mate individually and then the game replays all the recorded actions of all 4 squad mates simultaneously. You can redo each of your squad mates actions individually till it’s perfect. The overview screen (entire game on this screen) shows a replay of all 4 members of your squad. Sort of a turn-based FPS.
You control all 4 squad mates
Due to time constraints, I wasn’t able to complete everything I wanted to do but the recording and playback of each squad members actions is there. Check it out!
I’m quite happy with this LD. I didn’t plan to participate, as I usually don’t have the energy for it in the dark winter months – but I wanted to play around with WebGL so I figured what the heck. Only library I allowed myself to use was glmatrix to help with the vector/matrix math (Thanks Toji, I wouldn’t have pulled it off without it). I also used a single call to jquery, but that was totally not necessary (I change the background color when one gets shot).
In my time zone, the theme is announced at 3 AM – so I got to work a couple of hours before I hit the hay the first night. I managed to get a quad to render as if it was on the ground before me. That was it.
The next day I started making some code that dealt with the level itself – I built a 3d model from an array of strings, which also gave it the old Wolfenstein 3D look. I made some code that allowed you to walk around in the model – adding some poor collision detection code (it’s really bad) – and a door that worked approximately like in Wolfenstein 3D. Then I hit the hay again, this time also at 6AM.
Then the last day, with a little more than 12 hours to go – I made an enemy, some things you can pick up along the way, keycards, doors that require keys, a win condition, a lose condition – all the gamy stuff. The enemies will shoot at you if they’ve looked straight at you for two seconds. The enemies will never walk, as I haven’t implemented any path finding algorithms. With another day, I could probably have done A* or something.
So, at a couple of hours left, the game was complete – I spent the last hour improving a few textures and then I handed it in. My usage of the theme was incredibly poor, and was never mentioned in the game itself; One bomb, one life, one gun.
The reason I managed to pull this off at all, was to a large extent because I’ve worked with OpenGL a lot this year – my spare time project is currently to create a full version of a game based on my LD26 entry. Rewriting it in C++/OpenGL, and making it as good an experience as I possibly can. WebGL is too a large extent similar to OpenGL ES2, and anything you’ve learned from either can be used on the other. Especially understanding matrices have been useful to me.
I’m quite happy with my Wolfenstein 3D-clone, and can now cross “create a fps from scratch” from my bucket list. No matter what people rate me, this is a personal milestone.
All in all, the game has a lot of flaws. No pathfinding, it’s not very challenging, poor collision code, quite short – yet again. Happy
So, I made a game in 72 hours. Well, the competition entry is not entirely what I had envisioned for the concept, but I accomplished quite a bit in the time I had so I’m pretty proud of it. Time Frame is a game about exploring a strange world that moves in slow motion. The game takes place over the span of only 10 seconds, which you experience over 10 minutes. With a theme like 10 seconds and I really wanted to make something that wasn’t fast-paced and frantic like I knew 99% of the other entries would be. The idea was to have a vast area that you would never actually be able to completely explore within the time limit. I succeeded with that, but I wasn’t able to fill that area with as many sights and sounds as I had hoped. I wanted to have all kinds of things happening in slow motion to emphasize the time dilation, but I ran out of time. In the end there are really only a couple things that give you a frame of reference for how slow time is moving. The first is a fountain at the entrance of an abandoned city that has water falling in slow motion. The second is an event that happens towards the end of the game that reveals why the game ends at all, so I won’t spoil it for you (though I have updated the game since the competition deadline and added more stuff… read below).
The art style was something that I chose to make asset creation faster. Everything has a very simple, yet high-def look that emphasizes triangles. I actually made all the textures using a really neat application called Hexels. It’s an awesome tool that lets you paint using shapes other than just pixels. I used the trixel shape mode and was able to really quickly develop a unique style. Hexels has a free version that I would recommend everyone check out.
Soon after the close of the competition I added in support for the Oculus Rift as well. I have had the Rift dev kit for about a month now and have been wanting to do something with it for a while. It was a great way to get familiar with the setup so that we can use it while developing Lacuna Passage as well.
I’ve had most of my time wrapped up in developing Lacuna Passage, but I have been working on Time Frame on the weekends and I managed to update the game with a bunch more stuff to explore and discover. You can play the updated version or the original version via web player, Windows download, or Windows Rift versions from our competition page.
This is a slightly edited version of my post on our own blog!
Back in April, Ludum Dare 26 was not so great, as I couldn’t participate. It was right after the AMAZE IndieConnect, and this convention drowned my energy so much that I got sick. All I made was some visual experiment, which I couldn’t develop much further because the headaches got too strong – partly because of my chosen art style. 😛
So, last week’s Ludum Dare 27 was much better in this regard! And after kernel exception, this is the second Ludum Dare we entered together (thus being a Jam entry, not a Compo entry). We had a lot of fun, but also some problems, of course.
Our entry is a first-person shooter, with a little twist: you have five weapons, and every 10 seconds your current weapon switches automatically to another one, randomly selected. And there are “floating devices” all over the world (= a medium-sized planet) which you have to stand near for 10 seconds, so a bunch of power-ups get spawned (ammo and health packs). Enemies spawn in waves every 10 seconds. And when you collect ammo, you basically get an additional 10 seconds of shooting time.
As you might know, this Ludum Dare’s theme was “10 Seconds“, and we called the game BLAM BLAM PLANET.
After some minutes of playing the game becomes quite intense, because more and more enemies spawn. If you just run and shoot around instead of waiting at a device now and then for a while, you will soon run out of power-ups, and thus health and ammunition. So it’s even a bit tactical, one might say.
The development of the game had its ups and downs, but it went well in most cases.
On Saturday, we thought of the game idea by talking about different possibilities and going for a walk. Ludum Dare starts 3 am here in Germany, and if I remember correctly, it already was afternoon when we agreed on making a first-person shooter, because we never did one really. To make it more interesting we decided that the setting should be on a round surface, which meant the game would need spherical gravity for all entities.
At the beginning we named the game “GLITCHIG”, because we wanted a broken look and have destructible environment, so lots of triangles are flying around. RottenHedgehog started building a neat planet surface with some asteroids around it in 3dsmax, while I started to let my character controller be influenced by gravity pointing to the level origin. Shooting little spheroids was also a priority.
So both Saturday and Sunday were all about getting this right: a planet, a player, a weapon, some enemies walking around. Mostly I tried to get it all working smoothly, by getting the physics of the character and the weapon right. But the hardest part were the enemies and their AI on the round planet. For this, I searched for some code for creating the vertices of a geosphere, mapped this via raycasts on the planet geometry and connected the resulting points – those were then the nodes for the enemies’ path-finding. Just letting the enemies walk directly towards the player probably would have been much easier, but less fun to create. 😉
Another nice part of development was inventing the different weapon effects – two weapons in the final game deform the geometry, so I can push the vertices of the planet around a bit when the bullets hit something. It looks quite ace. As “glitches” was our personal theme from the start we knew the geometry would look strange and broken the more you use this weapon and we embraced that. In fact, when I last played the game, I fell through the level and I could attack all the enemies from below while they couldn’t see me – but that also meant I didn’t get any new ammo, so it was okay.
RottenHedgehog was mostly busy with modeling the three types of enemies and animating them. They look kind of deformed, emphasizing their low-poly nature, and it really looked well. Especially when she added the walk/fly animations, which are really hilarious. When the enemies spawn in masses it becomes a really cool effect.
In order to tie the look together, she also created a color code in Photoshop. After that, the game looked “right”, as the colors of most assets didn’t need much tweaking afterwards. Having only very few placeholder art from early on really helped the motivation somehow.
Sunday evening RottenHedgehog also started to make some sounds for walking and shooting by using our laptop’s inbuilt microphone. High tech! All the sound effects you hear in the game are actually RottenHedgehog‘s voice. Adding sounds instantly made the game more alive; in the end, you can’t have enough of them – that’s why she made more on Monday, along with the art for the bullets and particle effects.
On the third day the theme of “10 Seconds” still wasn’t in the game, and I thought long and hard about how to implement it. I weighed the pros and cons inside my head of different game mechanics, like “every 10 seconds, you have to collect new ammo” or “activate 10 bases, 10 seconds each, and then you won (whatever that means)” – and only when I finally began to create the five different weapons and let the enemies spawn in waves, the probably best restrictions (automatic weapon switching, time-limited ammo, etc.) came naturally. So there’s that: sometimes tinkering too long can be bad, and you should just “do it”, I guess.
In the final hours I was able to quickly implement the main menu and a death screen, which always is satisfying as it ties the game together and makes it look complete. RottenHedgehog made the logo and the button graphics, and also captured a video of the game.
So, that’s how it went. Let’s take a look on some quick facts about …
… what went wrong!
Finding the idea was hard for us, as we couldn’t agree on most things. In the end, the game we created isn’t as innovative as I would have liked, but at least it’s superfun to play this time!
As we struggled with the idea, it’s clear the theme didn’t help much. Although “10 Seconds” is in the game more than once now, it feels a bit off.
On Monday I nearly lost the will to finish the game, because of the lack of a clear direction regarding the gameplay, caused by the theme.
RottenHedgehog had some severe problems with the CAT animation system in 3dsmax. It seems to be buggy as hell, and I heard her cursing a lot. 😉
There are no game-breaking bugs in the game, phew – only some small stuff, like resetting the option settings when you open the “Options” menu. The bigger problem might be that the game is “broken by design”, because of the Glitcher (the weapon that deforms the planet’s geometry) – we should have used this feature more often, so it doesn’t feel strange when you fall through the geometry.
A lot of feedback is missing, like some kind of visual hint when you got hit, or a sound and animation when the ammo is depleted. Also, the “story” isn’t communicated in the game: you don’t know what you’re doing here, why your weapon system is defective, and why you have to stand near the floating devices. (Some people didn’t understand that the enemies only start to spawn when you do that for the first time.)
… what went right!
It’s always great to work together with RottenHedgehog, because we know exactly what each of us can do, and how. While I do the scripting, she does the modeling, texturing and sounds. Perfect team work – all in the same room!
I set up an SVN repository, which sped up the work flow incredibly, and also saved my ass at least once when I accidentally deleted some files in the Unity project folder.
I prepared some basecode a day before Ludum Dare, by skimming through my former projects and picking useful helper code snippets. Having a basic character controller, path-finding, simplex noise and other functions ready before you even have to think about where to find them is wonderful!
RottenHedgehog recorded the sounds with her own voice and distorted them in Audacity, which was much faster (and cooler) than trying to find sound effects on freesound.org with the right license.
The abstract, low-poly, somewhat “broken” graphics style looks quite well and gets very positive feedback, even without textures – AND it also was done very quickly.
The five weapons are fun and pretty diverse. This way, the whole game is fun enough for a few minutes, and that’s the most satisfying part of this Ludum Dare for me.
Before we started I thought the spherical gravity might not work at all, neither as a gameplay mechanic nor as a visual style. I especially was concerned with this style the player would see too much sky and not enough ground surface. In the end, with the recoil of some weapons (so you fly away, looking down) and the high amount of flying enemies, this wasn’t any problem.
… what we learned!
Due to the lack of time at the end, the balancing is kind of subpar. Good thing the game just is an endless shooter, and thus it is good enough. It’s also cool that you can “learn” the game, as using the floating power-ip devices is important, but not obvious. Always try to add stuff like that.
“Crappy” graphics often look awesome when animated and with a nice shader. 😉 Coherence is very important though – that’s why creating a color code sheet early in the process is a must.
Try to not make any placeholder art, because it either means you will have to make an asset twice – or it will be in the final game.
Even if you lose motivation near the end, at least try to give the game an ending. Sometimes, it helps to finish the game nonetheless, because this, this and, oh, that too, has to be done before the game can have an ending and be called “done” …
Three days are still too long for me, because it automatically makes the project too ambitious.
Every time I see a Unity project with the standard Unity button graphics I get the urge to close it instantly. Really, it’s easier than most things in Unity to add some custom button graphics and a downloaded font to the GUI skin. Give your game some love!
As much as I’d want to extend the game a bit, like adding more levels, I don’t think it will get much bigger than now. The feedback of players and Ludum Dare ratings is really nice so far, but I don’t know if having more enemy types and whatnot would increase its popularity. An online highscore would be nice, though, so maybe I will add that.
We even followed the theme – your weapon system switches your current weapon every ten seconds, and enemies spawn every ten seconds. Yeah, it’s a bit crude, but at least you can play it longer than ten seconds. 😉
This is my second Ludum Dare and I feel much better about this one. I am using a lot of random assets that have been collected over the course of the last year, or so. This is also my first FPS game done with UDK, which I find somewhat amusing.
I had a few issues with the weapon placement as well as the hand rig but it only cost a couple hours to figure out.
Tomorrow I will get the AI working as well as the “10 second” theme involving them. I will also start to work on the level as well as the menu, before wrapping up the game elements on Monday.
If you want, I put together a time lapse video of today’s effort.
Yes, we make an FPS, although 7DFPS is over. The theme didn’t gave us good ideas (good in the sense of feasible), so we’re doing something new for us (we never did an FPS with shooting before, as far as I remember). We will add the theme afterwards – like “your weapon changes every 10 seconds” or so.
Some basic gameplay and graphics were done today, so we can go to sleep now.