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.
New monster and zone almost done!
Check out the video:
I’ve been working with physics and lighting.
I had some problems to optimize the entire theme of light and shadow with the mobile hardware, because some older devices do not support anything but OpenGL1.1 and the ones supporting OpenGL2 only have two lights (hardware acceleration) dynamics, and are directional.
I also had a hard time trying to coordinate all the events of the generation systems and balance enemy load, these are synchronized via environment variables with the AI, once you load the level you meet certain standards for each part phase, it run macros that direct action through the gaming experience.
I made several models in 3DStudio and Maya, textures with Photoshop and it has been more difficult than I thought, but also a lot of fun
I’m making a summary of what I’ve done since the last update:
– Added a compass (triangle in front of the avatar) to know where to go next
– Creation of optimized materials compatible with light and shadow
– Creating a new enemy: mini skeleton, with its animations, etc..
– Creation of a series of doors with different animations, particle systems and so on, that are synchronized to provide a consistent flow to the game
– Including transients and environmental sound effects are played according to a given priority
– resource optimization: its a need to use the least number of objects in memory and AI’s possible, it’s an art to know how to do this and mantain the FPS high, almost between 40-60+
In six days I have to submit the game to the markets.
And it is working in Blackberry PlayBook, iPhone4+, iPad (1,2,3), Pc (win,linux,mac), etc