Posts Tagged ‘postmortem’
It was the first LD I patricipated in, and I’m quite satisfied with the game I made. I found the theme a bit too constraining, though I managed to get an idea of my game fairly quickly. So, without breaking everything in good and bad aspects:
- Graphics. My programmer art really sucks so I went for a minimalist graphical style. My inspiration was Super Hexagon which manages to look really good without having sophisticated graphics. I think my game looks quite well, and that’s mainly due to particles flying everywhere.
- Music. In short, there’s none. I found out I couldn’t make a good-sounding soundtrack and I didn’t want to resort to autotracker.
- Gameplay. It’s unoriginal and repetitive, as it’s just your everyday top-down arena shooter. Magnet phase makes things a lot more interesting, though I got comments saying that it’s confusing.
- Scope. I didn’t pick a complex idea, so I was sure that I could complete it in 48 hours. I was right about it, almost all mechanics were done during the first day.
Taking part in an LD was a great experience, and most of all a fun one. Looking forward to next compo!
I had a run at a few LDs before, but every time something came up that didn’t leave me the space to flesh out my concepts (which also happened to be quite ambitious most of the time). Between the last LD and this one I gave in and picked up Unity. For a while the proprietary/closed nature of it and the scene/gui-centric design scared me (as did the reporting of information about my machine during installation). Unity itself clicked with me quite quickly after I started doing things with it, and it is just what I needed for prototyping. I start (way too) many small experiments, so I want something that allows me to easily setup lightweight projects. In regards to that I only wish Unity would let me setup an empty project with metafiles and text-based assets from command line.
Also “error CS1061: Type `int’ does not contain a definition for `f’ and no extension method `f’ of type `int’ could be found (are you missing a using directive or an assembly reference?)” some day will make me break something.
I designed ReTurtle) as some kind of puzzle-shooter. You would have 10 seconds to beat a boss, so you need to find out how to do enough damage to him in the time. To make things interesting you would record 10 8 6 5 characters, one after another, where the coordination would give the game some depth.
At first I was worried that coordination would be trivial. To fix this, friendly fire would make the player have to actually adapt the path for each incarnation to keep them out of each other’s aim. That doesn’t necessarily make for non-trivial coordination. Every character could still have his own small space he would stay in and just move a little now or then to avoid attacks. So it became the enemy’s job to make them move. I designed a set of attacks to get this done:
- Motion: He would move everywhere once, and cover some space with bullets, so the whole group would be pushed around the stage, having to avoid bumping into each other.
- The Grid: Having attacks that separate the playfield into cells would force the player to pick different safe spots for his individual characters if he wants to keep shooting at the boss.
- Grenade: The grenade aims for the current position of every player. This way you have to consider where your previous incarnations will move to, while picking your path, which adds another aspect to the puzzle. The second use of it is that it avoids any completely safe spots.
Now having an idea of the base concept, I wanted to add a bit of depth, so I added two mechanics.
- Gun Charge: Friendly fire is already there to keep the player’s finger off the trigger, but I didn’t want to make him feel bad about it, so I added a small challenge. While not firing, the gun charges for one second. Firing once the gun has fully charged does quite a bit more damage but getting the most damage out of it requires focus. This creates space to improve.
- Shield: You would have a shield that reflects attacks (by either player or enemy), making them more powerful in the process. To make things more interesting the shield is not able to reflect projectiles right back (which would leave some space for abuse). A frontal deflect would just destroy the projectile, while bouncing it around at 90° would maximize damage.
The numbers were designed so you can do 25% damage with one character through rapid fire. This means you need four of your five incarnations to beat the boss that way. Using all perfectly timed charged shots lets you raise that to 34%, which is just enough to win with three characters, but requires to not waste time between the shots (and of course every shot to hit). An optimal reflect doubles the projectile’s power, so reflecting a charged shot adds the equivalent of another on top of it (without needing charge). This way the first character can replace the third, if all shots are perfectly reflected by the second. So every mechanic was designed to cut one character by perfect use (note: due to projectile flight-time it probably doesn’t, but gets close).
Back to earth
For the first day I planned to make all core mechanics work and do all the visuals. That’s quite risky, since I couldn’t tell whether the parts would work together at all. So after day one I had incarnations being able to get recorded, shoot and reflect shots. The boss just sat there and fired a shot straight down now and then. Modeling the boss took me longer than it should have and he didn’t look much like my sketch (I suck at blender). To make up the time the player built from a few 2D-Layers without any animation. The stage suffered the same fate. Planned were multiple layers of tech-y plates and a stripe in the center with numbers running through it to show you the remaining time. But to close out day one, I made what is in the game now instead.
Schedule for day two was boss-actions, menu and intuitivation (that’s a word now), sound was pushed to what would be left. After attaching a hitbox to the boss and making him move through the stage, I could finally test some of the feel. To my surprise coordinating characters already was more interesting than I expected at that point. One of the challenges I didn’t think of is that under pressure one tends to react to an attack the same way every time. This makes the act of creating different paths for all characters challenging by itself, since any time you have to rely on reactions you end up in the line of fire for another incarnation.
Fireballs were already there from day one, so I only had to implement lasers and grenades, which went smooth. Unfortunately not everything went this well. With most gameplay in place, shield just didn’t work out. I boosted its value by making the scaling multiply. That doesn’t help if you can’t set it up though. It’s still too powerful due to a bug, but quite useless for proper gameplay.
What threw my schedule off was the upgrade for player-visuals that got pushed over from day one. I wanted only the ‘head’ to move and the game also needed something to point at the currently controlled character. Some information on the charge-state and something to show the number of an incarnation was critical too. With all of this done I was already closing in on the deadline.
I still had to add a menu, and link everything together. So I threw together the atrocity that is the main menu, added some hit-detection for clicking, and moved handling of the game-progress to the new scene. That left me just enough time to set up a dropbox-account until the submission-hour started. What fell off was sound and any kind of ingame-instructions, including any hints on what you have to do on the main menu.
I’m mostly ok with how the game turned out, I got to play with a few mechanics and they didn’t rip each other apart. It is desperately in need of instructions, some tuning for the core and an overhaul in regards to presentation. I gave myself a week to tweak everything, before I let the game go and focus on other prototypes. The time is up and I’ve added the post-compo-version you might want to try after playing the compo-version. You could also try to beat these informal challenge-times in the post-compo-version: under 6 seconds as a ‘silver’-mark and under 5.5 seconds as ‘gold’-mark. I’ll follow up with an overview of the changes soon, this post is long enough already.
I had heard about Ludum Dare a couple of times, seemed like porpentine – who got me into making Twine games in the first place – had made quite a lot of her games for these kind of game jams, but I thought I’d not be able to make one for a jam myself, as me writing under time pressure doesn’t work very well.
Seems I was a little bit mistaken.
Ludum Dare 27 had been going on for about half a day when I by some chance stumbled upon it. The theme suited me perfectly; I wanted to do something minimalistic and the idea of having something that would only last for ten seconds made me thinking that this will actually work out.
I wrote the script almost entirely in Swedish (my first language) to begin with, using OneNote and Word, I then began translating it with at least two different translating tools and one online dictionary, and I actually texted a friend of mine a couple of times too just to get his opinion on the translation.
When I code in Twine I always consult porpentine’s twine resources, and it’s thanks to her and Leon Arnott’s macros that the games turn out the way I want them to. Be sure to check out their games this LD too; they’re amazing.
I’m not sure how long it took me to create the game; I’m usually only creative in short bursts, the rest of the time I’m consciously thinking or doing something else.
Apart from writing it, what took me the most time by far was making it look the way I desired; I’m always having a problem with the colours and how the text lines up.
These things considered, turned out I had a couple of hours left until the deadline, but I didn’t want to change or expand on anything. I know everybody thinks my game is short, personally I don’t have such a long attention span – especially when it comes to reading on a computer – and I’m more interested in getting the player to think and contemplate on the experience, rather than for it to actually be lengthy one, so it has both to do with this, and the fact that I’m a slow writer.
I had an explicit idea of what I wanted to do with my game: I sought for it to remain open to interpretation so that the player could put in their expectations and wishes and let the experience kind of be what they wanted it to be, or perhaps the way that seemed most natural to them. The interactivity had to be meaningful, and had to be approachable and able to interpret in a lot of ways, and as I didn’t have the time to try and expand the game as that would have jeopardized my vision, I focused on making what I had as good as it could be.
By doing that I hope that instead of bringing a longer experience the tale would live on and expand in the imagination of the player, as it really is their experience and story, and I have no idea of what they choose and how they choose to interpret this, though I would love to know.
This has been a very inspiring and fun thing to be a part of, and I’m thankful for all the comments I’ve been getting and have really enjoyed playing your games. If you’re interested I have a tumblr where I publish my games (or interactive fiction if you prefer) just two of them so far but I’ve got some under development and some just waiting to get translated.
Thanks for reading! I appreciate all your feedback and comments!
Ten Second Sprint was made in 48 hours for Ludum Dare 27, in August 2013. As my second Ludum Dare entry, I knew how the competition was going to go down, but I still didn’t have much experience or expertise. Here’s what went right, and what went wrong.
What went Right
Of all the Ludum Dare theme options, ‘Ten Seconds’ had the most votes by a long shot. With this knowledge, it seemed that ‘Ten Seconds’ would be the theme for Ludum Dare 27. So I started thinking of a game that fit the theme. I knew I wanted to do a platformer for Ludum Dare 27, so I though of a simple idea, not too complex, a platformer with a ten second time limit.
I used sfxr to create the sound effects of Ten Second Sprint. Even though sfxr is really easy to use, I managed to get great sounds for Ten Second Sprint. I feel this made the platforming a little better, as having a pleasant noise when you jump is very rewarding.
The clock alone didn’t add enough tension to the game, so I wrote a musical piece with that purpose in mind. The music gets continually higher pitched until the end, where it cuts out as you run out of time and lose. This adds the tension that was lacking before. This also lets players know when their time is running out, they’ll remember that when when the notes change pitch, they’re running out of time.
I’m no great programmer, so that restricts my game development quite a bit. It took time and lots of trial and error and I’m very pleased with the final collisions. I feel it all worked out well, it was very precise in my testing. Precise collisions were necessary for making Ten Second Sprint fair and fun to play.
I often get frustrated or bored during the less exciting development tasks, but the 48 hour limit of the Ludum Dare is a great motivator. It never gives you a break, so you don’t have a chance to postpone. Constant pressure is a great short-term motivator, but having it all the time could be damaging to your sanity.
What went Wrong
Not too long into making Ten Second Sprint, I realised I would need more rooms than GameMaker: Studio Free Version’s 5. So I switched to GameMaker 8.1 Lite, where I had unlimited rooms, but a small watermark. I am able to use any other software or programming languages, so I’m stuck with GameMaker for now. I don’t have the paid version, so that restricts me from making the best game I could, as the restrictions limit my ability to implement my ideas. Buying GameMaker Studio has been on my todo list for a long time now, and I hope to have it by the next Ludum Dare.
I had many ideas I wanted try during the creation of Ten Second Sprint. Different types of color schemes and different blocks were some of them. Unfortunately due to my lack of skill, I couldn’t implement them in Ten Second Sprint. I still have interesting mechanics in my head that could make their way into future projects of mine.
The physics of Ten Second Sprint are very basic. The player does not move fast or have any fancy sliding mechanics. This is acceptable, but I made the player fall unnaturally slow. I feel this breaks the pace of the game and feels wrong. Increasing players moving speed would have been a good idea too. Next time I’ll focus more on the feel of the player’s character.
Ten Second Sprint was coded very poorly. My GameMaker Language code is all messed up. It doesn’t follow a strict format and it`s impossible to understand. Next time, I’m definitely trying to work on this and make it easier to read and edit.
The theme of Ludum Dare 27 was ‘Ten Seconds’, so I made a game with a ten second time limit. This wasn’t very creative on my part, I was hoping to think of something super creative. Maybe I should change my expectations next time.
Ludum Dare 27 went well for me. I’ll definitely participate next time, if I am able. I have learned a lot from this experience. I didn’t have to make a masterpiece to feel accomplished.
Ten Second Sprint can be played here: http://www.ludumdare.com/compo/ludum-dare-27/?action=preview&uid=21642
I made a little game called Oxy (please give some feedback) and here it’s its postmortem.
I like games and I play a lot of them. I got into programming because I wanted to make one, but never finished any worth showing project.
I wasn’t going to enter LD. I was only waiting for the theme announcement and I was just going to play around. I had no idea of what tools to use or how to make it. The theme was out around friday at 23h where I live and I stayed up until 2h in the morning trying to think of something to start. All I got was an “old” idea that could be adapted to the theme, but it didn’t feel right. So I went off to bed and started thinking about giving up.
The basic idea of 2 divers in an underwater cave only hit Saturday morning. From this moment on I had a blast of ideas. Some of them were good and others, totally crap. Like the idea of moving the 2 characters at same time. I’m so glad I didn’t push it. It would ruin what become the best decision I took. Finally I got to the idea of having the 2 characters, but one of them would be unconscious and would be in need to be dragged around. Both would be in a underwater lab that would need 2 people in different positions at the same time to push the buttons to open doors. The only thing that I was certain about it, was [SPOILER-select to read] that Dave wouldn’t make to the end alive. My main goal was to make the player feel attached to Dave and then, well, kill him. [/SPOILER]
- Instructions: I think I could have made a better job at explaining the game to the player. I made the “title”, “game over” and “win screen” in a heartbeat before the due time. I almost forgot to include the controls.
- Planing: I hadn’t planned anything at all. Not even whether I was going to participate or not. That made difficult to polish some ideas. Next time, I hope to be more prepared.
- Short: This is kinda good for the competition, but I wish I did more story-wise. I wanted to create a connection between Dave and the player, which some people got it, but I think I could have done a better job here. It feels a little forced how it all happens.
- Difficulty: Well, of course I’m the master of my own game, but there’s other people in the world, with different skills and patience. Once you died, you had to go through all again. As some user stated, it felt like a chore (even if at the end it was a rewarding one). Some people suggested some sort of checkpoint but I think that would break the immersion. It just needed to be a little more easier.
- Finished: Hell yeah. I f****** did it! I finished something that I’m not afraid to show. \o/
- Music and sound: Many users loved the music and so do I. I was very lucky to find the Circuli app. I spent a bunch of hours playing with many music generators (because I have no talent), but none of them felt right. I like how I made the sound effects (the 2 of them haha) fits with the music and ambient.
- Mood: The music really sets it, but I think that the little narrative and dilemma makes it full circle, even with the short duration.
- Controls: Even while I failed at explaining them, they were pretty easy to master and they felt right.
- When Dave dies, the game continues: I think this was best design decision that I made. Because when it happens you think “it’s over!”, and then it’s not over, but you have to drag the dead body of your friend. Not everybody got a deeper thought about it in this “silly game with puzzles”, but that’s what I was aiming for, so I’m glad that some people noticed and thought about it.
If I had more time
- Graphics: I really can’t draw as I stated in my entry post, but I know I could make, at least, the scenery look better and not THAT amateur and generic.
- WASD: I completely forgot to include these keys. I planned to do it, but I just forgot.
- Story: I think a better background story for both characters would make it easier to achieve my storytelling goals.
- More and better puzzles: Well, that’s pretty much it. More and better puzzles.
- Two endings: I wanted to make two endings: [SPOILER MAYBE-select to read] One if you crossed the final door with Dave and another if you didn’t.[/SPOILER MAYBE]
I really liked my idea, but the execution was mediocre to good, I guess. So I intend to take this to another level. Make it a full game. I hope to do so.
I had a wonderfull time. It was an intensive, scary, stressed and fun weekend. I finally finished something to be proud of. And people got it and liked it and this feels so good. This little experiment incentivated me to push more and harder now. I have met some incredible minds behind the games I rated so far and I’m excited to keep in touch.
Thanks for reading and please, pretty please give some feedback.
“Another Ludum Dare has come and gone, and the jammers have emerged once again with a new game. This is the postmortem of my entry, called “Jetpack Jacob in The Quest For Time” (May or may not be named after me).
The basic idea is that you have a jetpack and a shotgun, and have to collect clocks while destroying robots. Yes, it’s another 2D platformer. With a jetpack.”
This was my first time participating on a Game Jam, and it was a fantastic experience to me. It kinda happened by luck/chance. It was 1 hour before the theme announcement, and I was reading my twitter feeds when I saw a tweet from @ChevyRay looking for artists to collaborate on Ludum Dare 27. I had heard about it before, of course, but never really thought of joining due to my lack of coding skills. Soon enough we were chatting about it and waiting excitedly for the announcement of the theme.
As I had no previous experience with Jams, we were already talking on how we should do the art for our game. We both decided that low-poly would be the way to go, both to get things done fast and keep a simple, reproducible style going.
Once we got the theme, “10 Seconds” we went into brainstorming mode, throwing a bunch of ideas back and forth. We had talked before about which games each of us like, and we found common ground on “dungeon looting” games, so we started there. Soon we had the idea of an explorer that got poisoned while exploring, and only had 10 seconds to survive, having to find “antidotes” that would prolong his life. With that idea, I had a Indiana-Jones type character in my mind, and went to Maya to start blocking him out, just 30 minutes into the clock.
I decided to get the animations done before sleeping, so I would be able to only worry about props and enemies on day 2. Did some really quick and dirty placeholder animations and crashed in bed (I was pretty sleepy already).
I managed to send Chevy the walk, idle, and hurt animations by 1:52am, and went to bed.
Please just don’t ask why I feel like all my titles should be in uppercase, there is absolutely no valid reason. Anyway.
Last week was my first Ludum Dare, and, actually, my first game at all. I had been learning Lua for at least two weeks before doing this, so one might say I was an absolute expert. Expert of newbies, that is.
But, hey, I’m actually really glad ! Here’s how things went :
- Roughly five minutes after the theme was revealed, I had my idea and it didn’t change. One of my massive flaws is that I tend to want to do too much, and it’s not really something one can do during a jam.
- Ten hours after that, the game was functional. Ugly, boring, just as fun as a Derrick episode. ( [...] I just Googled Derrick… 90 minutes later I’m reading stuff about Mount Everest and Ice Age 4. Dang, back on topic. ) But it was still a game.
- Actually the 38-or-so next hours were mainly me procrastinating, adding one or two features when I felt like it. One of the most memorable was the recording of the sounds… 5 AM on sunday with half of Bapteme du Jeu sleeping next door, and me, yelling in Hugo’s mic… Realized halfway through that I was being REALLY loud, hence the weird ” one “.
- And finally, during the last hour, I added level 5. Just because of one or two people who beat the game like it wasn’t more complicated that toasting bread. Please, understand. My PRIDE was at stake here. And that’s why you’re all suffering on level 5 – for the few brave ones who endured my hellish voice until then, that is.
Notice that I’m not mentioning sleep. That’s because I didn’t get any rest. For 65 hours. Except for a ten minutes nap, waiting for my computer to reboot. I think it’s a pretty good way to jam, if you manage to do it and not procrastinate too much… Well no okay it was dumb. But still, I’ve been pretty productive, and it’s great !
What went right :
- The concept, found in a few minutes, and pretty interesting ( that’s what I thought in the beginning. Actually it was the opposite of original, but I’d rather set my goals to ” feasible ” rather than ” Hell yeah, if you’ve got a ten people team on coke for two weeks, you might make it ” )
- The graphics. Honestly. They’re plain simple, it’s pixel art, but compared to what I used to do not so long ago, it’s like comparing Picasso and Da Vinci.
- The sounds. I first thought ” Hey, let’s be stupid. I can’t make any sound by myself, right ? Rather than using the excellent sfxr, why not do something awful, yet fun ? ” Several people at Bapteme du Jeu said they wanted to see how it turned out, so here it is.
- The difficulty. Just what I wanted it to be. You end a level ( except level 1, but it’s a Field trip after all ) with 3 to 0 seconds worth of fuel left, and level 5 can be quite hard, even though you can get through with your hands tied behind your back provided you know where you’re going.
- The fun. Oh god the fun. I had fun making this game, I had fun playing this game, and above all I had fun watching people playing this game ( and getting crazy ). Nothing’s more satisfying, as far as I’m concerned, than a man in a hurry, late on his project, still sitting in front of your computer, yelling OKAY I’M TOTALLY GOING TO MAKE IT TO THE END THIS TIME, to end up laughing as hell because of the game over screen and the overdone explosion. But, hey, there’s no kill like overkill, right ? It’s supernuclear I told you.
What went wrong :
- Jeez, I couldn’t code properly to save my life. Had to make several corrections, because the game tended to blow computers up after a few minutes. Turns out that big ass sign on the top of love.graphics pages isn’t just for show. At least I know now. Thanks to everyone who helped me on this by the way
- My focus. I’ve never been able to focus more than a few minutes in front of my code, but in a room full of people working on ideas, it’s like being 9 again with the latest Pokemon game in the middle of history class. Try and stay focused now. Probably made worse by the lack of sleep.
- The ending. I planned to have Earth FUCKING BLOW UP at the end of the game, like an ultimate laugh at the player’s expense, saying ” Oh, you’ve made it out ? Cool story. Boom. *cue Earth Shattering Kaboom* ” I even had the graphics, or at least a draft, but ended up being 100% unproductive when it came down to ” Do or do not “. So I made level 5 instead. Which is, I think, for the best.
- And I think that’s all… Well I’ll probably think of a thousand more details, but I’m going to start pretending I have self-esteem now.
And that’s for me. I hope nobody got mad at the Game Over messages, they’re meant to be stupid and humorous, like the rest of the game, I actually love you all
Count on me to come again for the next LD or so, I really enjoyed this experience. And for the lucky ones who haven’t blown up their share or SUPERNUCLEAR PHYSICALLY UNREALISTIC HELICOPTERS yet in Hellish Copter, follow the evil rabbit !
PS : Some grammar mistakes might have occurred during the writing of this text. Please do not take them into account, since, you know, I’m french and stuff, and french people suck a languages. ( They do. ) Feel free to correct me if you like ; that’s how one gets better, whether at languages… or game making !
A Culmination of Learning Experiences
This is my second time participating in the official Ludum Dare competition. Overall, I feel like my skills with Unity have significantly increased since the last competition, when I submitted Amish Brothers. Since the last competition, I have submitted a game to each mini-LD, and each game developed taught me something new about Unity.
Bomb Squad Timelapse video
This time around, the theme was “10 seconds”. My idea was a game where you play as a bomb squad technician, where you have 10 seconds to disable each bomb. If the bomb explodes, the objects around it will be propelled away and add to the property damage value. The objective is to keep the property damage as low as possible, while avoiding bomb blasts which damage your suit. If your suit reaches zero percent, then the game is over. Additionally, you must “cut the wire” that matches the color of the bomb, otherwise the bomb will explode and you will take damage. For more details on my design decisions, see my Bomb Squad Day One entry.
For this game, I knew I wanted to use Unity’s physics engine for handling the explosions. I first started learning about Unity’s physics engine when I developed Earthball for the mini-LD42. When the bomb explodes, it applies an explosive force to all of the objects in the game, including the player. I found that this starting causing problems when there were over about 600 objects in the scene. When the objects were exploded and scattered everywhere, the slowdown didn’t occur. It was only when the objects were stacked, which I believe is because when the objects are stacked, they are continually colliding with each other, which requires a significant amount of processing power. The player is also affected by bomb blasts, but I feel that if I learned how to use the “ragdoll” physics in Unity, the effect would have been much more impressive. Currently, the player just has a cube bounding box, so the player looks very stiff when thrown by an explosion.
The ground is just a terrain object (like I used in the test Giga Guy game that I developed), but I always have issues with my models falling over when going up the terrain, therefore I just left the game area flat. However, I was able to use the blended terrain textures to make the ground look much more pleasing.
I used Blender again for rendering my models. There were really only two models that are in this game, which are the player and the bombs. From my LD27-warmup game North Avenue Adventure, I learned how to properly project my mesh to a 2D layout, and how to modify the unwrapped vertex “islands” properly to generate an image layout to be textured in Gimp. I am happy with the model that I created, but I would like to go back and add more details later. However, I found that it can be difficult to modify a model in Blender once all the modifiers (mirror, subdivision surface) have been applied and the armature added. I also think I could have done a much better job on the bomb model, since it is just a stack of cylinders. A spark particle system on the bomb would also be a nice touch.
My mini-LD43 game, Marching Band Simulator 2013 taught me more about composing music in games. However, for Bomb Squad I decided to go with Garage Band on my Mac laptop for composing the music. In my previous entries, I have used PxTone Collage which is a great tool, but the blips and bloops it uses cannot compare to the music that can be created with Garage Band. For the complete soundtrack, please visit my Sound Cloud page. The only problem with Garage Band is that I had to export my songs to iTunes to get the audio file, and then copy it over to my development system. It is a bit of a hassle, but I think it is worth the extra effort.
Another game I created in Unity for #1GAM was called Genetic Disorder, which is where I learned how to make the text meshes for the title screen using Blender. It’s a fairly simplistic process, but the number of vertices must be reduced otherwise the model file size will end up being huge.
For the 7dRTS challenge, I created a game called Ninja Squad Commander, where I learned many more Unity tricks. First of all, it taught me how to center a text object over a model, and how to make the 3D text sharp (by default the 3D text will be blurry). This was used in Bomb Squad to display the number of seconds until explosion over each bomb. In that game, I also learned how to make detailed particle systems, like the fire effects, using Gimp to create the fire texture using a gradient and IWarp filters. The game also taught me how to attach lights to particle systems at runtime, to give the fire a glowing effect which can be seen on objects around it. Both of these effects were used in Bomb Squad at the location of an exploded bomb. When I was developing the RTS, I also learned how to determine the distance between two objects in 3D space, since using multiple physics colliders for different events can cause problems. The 3D distance calculation was essential to determine how much damage the player would take from a blast, and how much property damage is received by an object. The distance calculation is also used to determine if a bomb is selected to be disabled. My 7dRTS game also taught me how to make a shadowed font from a text object, which made the static text in the game look much better.
The one new feature that I added that I hadn’t implemented in a previous game is the mini-map. I felt that it was needed, since the player can’t always see the entire game area, so there would be bombs hidden to the player. That problem could be helped by adding code to fix the camera behind the player, so that is something I will look into for a future release. I think the mini-map would still be beneficial, but some players noted that it makes the game a little too easy, so I may eventually take away the bomb color on the mini-map.
Honestly, I can say Bomb Squad wouldn’t have turned out as good as it did if I hadn’t created all of those other smaller games after LD26. One important factor in being successful in Ludum Dare is knowing your tools and all the tricks before the competition starts. Trying to learn new technologies during the competition is a recipe for failure.
Hey yo, postmortem time with lotsa gifs yo. The entry itself is here
So here we go.
• I’m satisfied with my game. I guess that’s a good point to start with. Seems people also find it generally funny.
• Fast, accessible game. That’s what I’m used to do anyway : short funny games that don’t require huge investment.
• No slowdown or lack of motivation during the jam, nor did I switch to another concept for any reason.
• I had lotsa fun doing what I enjoy the most : quick animations.
• EXPLOSIONS AND LAZORS §!!!§§!§§
As I already explained in my previous posts, the development of the game went in a somewhat cahotic fashion :
• Way, way to ambitious idea in terms of quantity of graphic assets/animations for a compo…
• ESPECIALLY when spending half of the first day messing around and watching a movie 3:
• Consequently, terrible time management which had me going jam because I was out of time.
• Screwing software issues all the second day (apparently due to a conflict between two pen tablet drivers) : I had to reinstall the driver many times and reboot my PC, and to forget about Photoshop which went nuts. (Oh and that’s why there won’t be any timelapse : after the second reboot, I decided to only run what was strictly necessary – so no recording).
• Questionable use of the theme. I mean, the sections of the game could last 15 seconds rather than 10, it wouldn’t actually change anything. Beh.
• No screenshake
• Double check, triple check, QUADRUPLE CHECK that I can run every software and hardware I might need altogether without issues before it’s too late.
• I’m saying it every time, but I really have to learn some sound design and music creation. It wasn’t a problem this time because of the going jam thing, but for next time, y’know…
• Don’t watch any movie if already late. DUH.
That’s it ! Hope you enjoyed the game of mine, have a gif anyway :
If you haven’t already, please play and rate our game, Hyper Furball!
This is my 5th Ludum Dare entry, and my second time working together with my artist xellaya. Things came together really nicely, and I’m really proud at what we managed to do in the 72 hours. Here’s what the game looks like:
Let’s go over what went well and not as well this time around…
What went well:
Settling on a good concept
We threw quite a few ideas around before settling on our sidescrolling RPG with the “hyper mode” mechanic. Initially we were thinking about doing a Warioware style 10-second minigame collection (nothing new, but probably still fun), and were also seriously considering doing something along the lines of Off the Leash. The idea thee was that you keep running to the right and have various obstacles and powerups that slow you down and speed you up, and you have 10 seconds to reach each checkpoint. I was all set to start working on that when xellaya pointed out that there really wasn’t anything new about what we were making. I thought about it some more and I agreed that it probably…wasn’t that exciting. Friday night came and went and we still weren’t sure what we wanted to make, but eventually my train of thought went to “we should make the 10 seconds as intense and crazy as possible”, and from there I got the idea of a side-scroller where hyper mode basically involves you steamrolling a whole bunch of enemies and leveling up a bunch. It ended up working really well, and I think it uses the theme in a way that’s clear, functional, yet non-cliche. Awesome.
Liberal copy-pasting of code
There’s kind of a delicate balance when it comes to high-speed coding. You don’t want to be clean and neat with everything, because it just takes too much time, and you’re only working with your code for one weekend anyways (not to mention, I’m the only coder here)…but you don’t want to be -so- messy that you end up introducing bugs and making things hard for yourself. I ended up copying a lot of code from my LD26 entry Minimalist Mayhem, which I also did in Flashpunk, and that sped things up a lot, as I already had code for flashing the screen (with fadeout), and I didn’t have to think about the proper way to create/recycle objects in Flashpunk or anything like that. There was also just a lot of one-off code that ended up getting duplicated, like the code for the parallax backgrounds–after doing that once, I just copy-pasted it each time xellaya finished a new set of backgrounds and I didn’t even have to think about it. Yes, messy, but as long as you’re careful, it all works, and it’s fast.
So many, so many Ludum Dare games are lacking in polish, but it makes such a big difference. It’s what makes your game seem AWESOME. That’s why it’s so important to pick something that you can execute easily, because once you finish the main execution, you can spend all the rest of your time making you game look pretty and fancy and smooth. Screen transitions, sound effects, cleaning up your UI…all these nice little things really add up. I’m really proud of the intro and title screen, for example–first impressions really count! I was really excited when I put in xellaya’s graphics for the title and synced it all with the music…so proud! Did I have to implement a jukebox screen with scrolling backgrounds (that cycle through the 4 different levels!) and colored stars flying around? No…but it’s really neat and awesome, right?
We really worked together well this time…I’m an LD vet by now, so I know how things go and I basically didn’t run into any big hiccups at all, aside from a FlashDevelop “out of heap space” compilation error which disappeared every time I restarted Flashdevelop (phew!). I even hacked the Flashpunk Text class to get the outline effect on all my text! I’m comfortable with Flashpunk and I’ve gotten really really good at making game soundtracks in constrained time periods now–in total, I wrote all the music in around 7 hours’ worth of time! (all that training from One Hour Compo paying off!) xellaya was also much more set up for things this time and we didn’t run into any of the miscellaneous troubles that we had last time for Marriage Quest (pngs being exported without transparency, etc.). We used Dropbox to get artwork from her machine onto mine; don’t know why we didn’t do that last time. It’s important to play to your (or your team’s) strengths when you’re thinking up a game…xellaya likes drawing cute things, and I really excel with 9-bit chiptune music, so it was great that we ended up with something that allowed us to use our talents to their maximum potential.
We both had the whole weekend to work on our game, which was awesome. No other stuff to worry about, no imminent tests or projects, no getting sick, etc. Awesome.
What went not quite as well:
I did better than last time (Minimalist Mayhem just had a single huge screen with all the instructions on it)–I was especially proud of the “mash space” animation that shows up on screen the first time you enter hyper mode. But the level up screen isn’t really that intuitive…in fact, the checkboxes ended up making everyone assume that you can use your mouse to click on them. Which…still confuses me, to be honest, but maybe that’s just because I’m an oldschool console gamer and I think everyone else is weirdos in the way that they think. I don’t really know how this could have been better, but I didn’t spend that much effort really thinking about it. I guess I’m just not that great at UI design. xellaya didn’t really have the time to think about this either, though, so in the end we just did what we could, and I think it’s at least functional. It’s not great, but probably not -bad- either.
The gameplay for our game is…”decent”. I wasn’t entirely happy with the simple attack/block mechanic that I had going on for normal combat, but I knew that it would end up being okay in the end because that’s not really the focus of the game anyways–the focus of the game is having fun with ridiculous crazy hyper mode! Still, I wish I could have made normal combat at least a bit more interesting somehow, though I’m still not sure exactly how I would do that. I think in the end I didn’t have time to push for enemy attack variations or anything like that, and xellaya didn’t want to do a lot of animation…if we had spent more time on this, the polish level would have suffered. So this is not really a mistake, per se, but still wish it could have been better. This is probably the main point that might hurt our ratings.
Not Enough Playtesting
Yeah, yeah, super common problem. This always happens, really. It’s important to get feedback and have people play your game, but…when your heads-down trying to cram in the last few features (Breaktime mode!), it just ends up by the wayside sometimes. I think I really lucked out that the game isn’t horribly unbalanced (at least, in a way that makes it not fun), because I really didn’t have that much time to spend on that and tweaking the enemy strengths and the upgrade requirements. I did spend a -decent- amount of time on it, which is why leveling up takes about the right amount of time and everything, so I didn’t do too bad here. But I feel like this was a danger area that I managed to sneak by on.
All in all, we did a great job, and I’m really proud of how things turned out. Our game is quite fun, and I’ve been trying to see how fast I can complete it using no continues
Please leave your feedback and comments! Oh, and go check out the soundtrack download too!
I spent my weekend at the picnic. Monday’s morning. I started painting comics “”Adventure Time”" listening to the audiobook about zombies.Suddenly, Artem (our producer) called me and said, I had an excellent opportunity to make the comics begining and ending of one cool game.I was agree, ‘cos I knew Artem for a long time. But!I couldn’t notice a trick) Artem gave me only 8 hours to do the job.
I was taken aback! I dropped everything! I didn’t eat and drink,couldn’t meet my girlfriend from her work.I was painting, and painting, and painting.. It was great to invent main character that looked like a heat on the stipe. It was unreal to make quality path, that’s why I colored pen scetch. Horror was in next situation. I spent 5 hours drawing the begining and I had only 3 hours to finish another comics. I must draw our team on a final picture and it was harder than main character. Team mates sent theirs photos for me and I started off drawing. The allotted time was ending but I had!
Funny moment! Our game designer Yaroslav turned from blonde to brunette!The fact is that he spent black-and-white photo!I was in a hurry and made him black-haired by mistake) I note that I know how Yaroslav looks like))I found out my mistake two days later, when I logged in skype)The result was a funny joke for our team chat.
I’m trying to write a postmortem, but so far I’m not very good at it.
The first day I started the stream on Twitch. If you’re interested, you can watch the record. But it will be available some time (problems with uploading).
In the game was more important animation and sound. So I’m not worried at the expense of code. It there is very little and it is very simple. And anyway I am very bad programmer. So I decided to focus on the atmosphere of the game.
I had an idea in my head to make the main character of the game by myself. Just fun to see myself as the main character in the video game. The character really took over some of my habits from life. He pulls it out from his pocket like me. It’s fun. It’s like I went for a walk and fell into my dreams.
Only a little more than an hour before the end of LD. The game as a whole was ready, but there was a very important part – the music. This is the basis of my game. And if I had not had time to make music, then I would not have made the game. Just would not make sense to load the game on LD without music.
And luckily I was able to do everything! Yes, I wanted to make more sounds and music, but the time is not left.
All in the game musical compositions 8, 4 individual sounds, 11 phrases (when something cosmic talking with us.)
The game turned out not as what was supposed to be, but it was a great experience for me. And it was fun. I love LD.
I will try to write a few more facts about the development (of course if you are interested).
And yes, my English is very bad, sorry for that.
To give you some background information first, I am a researcher working at “Technische Universität Darmstadt” in the field of Serious Games with a strong interest in games in general. After talking about it a few times with my colleagues, I decided that it was time to take part in a Game Jam myself two months ago. Because I found the idea of having other participants around in order to exchange ideas intriguing, I asked my supervisors if we could organize a local event at our building and invite some of our students as well. Thankfully they supported this idea, so this postmortem will take a look at two different aspects – organizing a local event in an university context and making our first jam game simultaneously. Spoilers: In the end everyone agreed that this won’t be our last jam. (more…)
When the time came, and the theme was set, I was initially dismayed. It was … not one of my favourites. Oh well.
Fortunately, I knew I needed some things working in XNA, regardless of what I did, so I could just start coding, while watching Ludum Dare screencasts at Twitch. so, I wrote an engine which rendered textured quads, and set up the camera so that I could set them on screen with pixel precision.
Some 9 hours in, I finally started getting an idea I liked.
The initial concept was, that you’d play a hero, who’d have to stop a disaster, every 10 seconds, and rush to the next one. I imagined a caped character, saving planes and trains, stopping robberies and alien invasions.
Well, that wasn’t going to get done in 39 hours. So, time to simplify.
The times I’d played Arkham Horror, or the last time I spent over-analyzing the setting in Sailor Moon, probably cued something.
What is there was just one disaster type, that of interdimensional invasion? You’d fight the creatures rushing in from portals, and… stuff. I was kind of fuzzy on the details, but closing the portals or taking the fight to the enemy should be an option. Initially I had civilians whom the monsters would attack, and locations the player could visit, but time pressures -> snip.
Onwards, with the post-mortemizing!
What Went Right:
Quite a bit. I was about 90% satisfied with my experience and results, although this was my first LD, and my second build-a-game-over-the-weekend participation.
Starting with the Engine.
Certainly not always a good idea, but in this case, I had a pretty clear idea what I wanted to do – I didn’t want to do any modelling, but I wanted to have access to rotations and whatnot. This was also my XNA learning project, and I made good use of the first nine hours, despite having no idea of what I’d make.
That being said, I had to rewrite the core of the thing, as my initial version was badwrong. Of course, I figured the correct way to do it immediately after a good night’s sleep, when the competition had finished.
Not having an overambitious design cut down on time needed, and I stil barely squeezed the minimum in, within the time limit.
Focusing on Finishing and Staying on Target
To get a game, not a game demo, I needed win and lose conditions. I sort of got there – if I’d just slapped a “you win” screen in front of the player, when they reached the final battle portal stage, it would have been complete. Now, while there’s a distinct lose condition, there wasn’t clear win condition. It has a screen showing controls, and even some sound effects.
It’s not just a tech demo, but an actual, if tiny and not very entertaining, game.
I like drawing, and I’m not horrible at it. I intended to leverage that, but I slapped in some quick placeholder art — which ended up being pretty much final. It’s aesthetics grew on me, like an alien fungus. I didn’t end up spending much time on it, just adding tiny little animations, which made things quite lively enough
The Tiled editor, while very simple, is great at quickly putting levels together, and I know some simple tricks with it, so that was fun.
What Went Wrong
Not that much, really.
Not in and as itself, but learning and building took a huge chunk of time, which I could have avoided, if I’d just stuck to blitting. As it turned out, I didn’t really need all those 3d features at the time.
Of course, now that I’ve rewritten the engine and so forth, I’m starting to see some benefits from the 3d engine in the background, but for the purposes of the competition, it was redundant.
Getting Zero Peachy Keen Features Implemented
I had a plan to give players power-ups depending on how they performed during each 10-second segment. Various attacks, heals, and other neato things. As I got none of them in, the player was left with two basic attacks, both which are kind of meh.
Using CamStudio for Timelapse
Not a big thing, but I lost first three hours of video due to hitting esc at the same time as CamStudio offered a save dialog, and that was that. ’twas a pain, mostly.
Afterwards, I familiarized myself with Chronolapse, which is much better regarding timelapse recording. I also lost a few minutes fighting with CamStudio, which may or may not count.
(I linked the timelapse videos in previous posts, if you’re interested)
Not Paying Enough Attention To Rules
I didn’t know there was a hour’s grace time to upload the product, after the actual competition time was done. I could have put in a bit more work on the game had I known that. Ah well.
Level Design, or Lack Thereof
My test level end up being pretty much the final one. I could have made the gameplay much more pleasant by simply redoing the level’s layout. Few things are as permanent as those meant to be temporary.
Still, I’m not very good at level design, in general. Need to improve there.
On the other hand, this was another thing, where an investment of, oh, 3-4 hours would have given me much more stylish graphics. Not that I had the time, due to spending most of the first day building the engine.
First of all : here’s my entry, since this is what I’m going to talk about.
Now : How the fuck did this happen ?
Warning, it turned up to be a long story (but there are pictures and all, so it might be fine)
Chapter 1 : The « Awesome » idea
Usually, on Ludum Dare (it’s my 7th), I go to bed early on Friday, then wake up early on Saturday to discover the theme and think about it in a cafe (I’m in France, so the theme is announced at 3 a.m). This time was a bit different though : instead of going to bed, I went to the bar and had some pints. Then some wine. Then some more pints. Maybe a wee too many pints.
I was feeling the theme would be « 10 seconds », so I started thinking about it…and then I had this awesome idea :
What about…10 seconds…in the life of a ROCK ?!
AWESOME, isn’t it ?You know…because rocks live a long long time…so what they would consider to be 10 seconds would be a much much much longer time for us….like a whole lifetime…so I would make a very very long game, while most of LD entries would be very short…funny…
…at least when you’re drunk.
I eventually went to sleep at 2h45 (to avoid spoilers), woke up, and saw I was right : 10 seconds was the theme indeed. Haha ! It was 9 am and I already had my game idea (and what a great idea!) This Ludum Dare was going to be piece of cake ! (sarcastic laugh from future me)
Chapter 2 : Hit by a rock, in the face
Well, our first Ludum Dare Jam is behind us now, and even though it didn’t quite work out we still managed to gobble together something (almost) playable, or hopefully atleast enjoyable.
I was really disappointed that I couldn’t make the physics work and so I upgraded the game to use Box2D (my second venture into Box2D programming, first was yesterday!) and guess what; it makes things almost too easy! Here is the link to a (windows) build that is much closer to the vision we had in mind when we set out to make this game. Hopefully we can take the things we learned and apply them in Ludum Dares to come!
What went right:
- The story. We came up with something that fit with the theme and was at the same time quite enjoyable.
- We knew our tools. No extra time was spent learning our tools. It might’ve been useful to grap Box2D earlier though when things started looking pretty grim regarding the gameplay…
- We managed to make something, even though it wasn’t anything special!
- The art got a lot of praise in the comments so I guess that went alright.
What went left… I mean wrong:
- Scheduling. I left the collision code for the last day along with polishing and minor additions, bad choice since I hadn’t really done any complex / physically (somewhat) accurate collisions before. Maybe I also overestimated my capabilities.
- Planning. Especially the gameplay should’ve been planned more thoroughly, and we should’ve tested the basic gameplay ideas more to see if it would be any fun.
- Testing. While writing this post a friend of mine spotted a bug in the intro / outro. Just because I have seen the intro working many times already doesn’t mean it won’t break when the code is altered.
Well our first LD is over, we’ve made our first ever game together as a team, and we’ve got the obligatory platformer out of our systems
Technical stuff: Made with Haxe 3.0, Flixel, Flashdevelop, GraphicsGale, sfxr, Autotracker, Excel.
What Went Right
- We finished a game in 72 hours without killing each other!
- The toolchain worked really well, Haxe, Flixel & FlashDevelop felt very familiar despite not using any of them before the warmup.
- Use of Microsoft Excel (hardcore mode!) as a level editor. There are obviously some very good tile map editors out there, but learning them would have taken way more time than setting up a spreadsheet with some conditional cell colouring.
- Bringing in a third person for brainstorming and powerup graphics on the first day. Thanks Graham!
- We anticipated that the main source of bugs would be unexpected interactions between multiple powerups, and set time aside to get this working properly.
- Almost all of the powerups we came up with initially made it into the final game.
- Staging the powerups and level progression to ease the player into mechanics without explicitly telling them. Combining different powerups gave us a clear sight of what obstacles a level needed to have, and a convenient “to-do” list for the 20 levels we built.
- Targeting web – easier for people to play off the bat, rather than having to install or download or compile, it just works on most platforms. Having never built a Flash game before, this was surprisingly painless.
- The platformer controls and the level design we thought went well, it felt polished and enjoyable to play, even when getting squished every 5 seconds
What Went Wrong
- Difficulty with scaling the character & collisions, as well as the timestep changes interacting poorly with the collision logic in Flixel. Getting it running at 60 resolved most of this, but there are still spots where a random bit of wall will just make you explode.
- Lack of experience with the IDE & HaxeFlixel meant the initial setup wasted about an hour.
- Music was a bit of an afterthought, we tried a few different packages to create the music eventually settling with Autotracker.py.
- Collisions. The collision logic wasn’t quite doing what we expected it to, and we wasted time re-implementing certain collision features that were already present in Flixel.
- We had smooth interpolation for the scaling of the character, but had to take it out as the player kept getting stuck in walls during the scale change. In the end we had to bodge in level-specific fixes.
- Not understanding transparency in GraphicsGale – a lot of time was spent sucking the backgrounds out of sprites using Photoshop.
- While we’re pleased with making a platformer that feels nice to play, the genre is obviously well-worn as a Ludum Dare standard. We defaulted to this because we knew we could get the game finished in the 72 hours, but it’s kind of old hat to people who’ve been doing LD for a while.
What We’ll Do Better Next Time
- Familiarise ourselves more with the tools, as well as deciding in advance what software packages we are going to use rather than flailing around!
- Artwork – practice creating artwork for next time, it had been a while since Bob had done any serious artwork and the simple 5 minute sprites that we knocked out were OK, but could have been better. Paul plans to learn some pixel art techniques too!
- We need to have alternatives for different game types, HaxeFlixel was good for rapidly building a 2D game, but it would have been nice to have the option of 3D.
- Work out how to use Flixel properly, rather than having to hack bits of code together to bend it to our will.
- Get together some flexible game ideas that we can adapt to the theme, instead of just defaulting to a platformer.
Please play our game, and let us know what you think!
Watch our timelapse video!
Play these awesome games that we’ve tried over the last few days!
Текст: Yet it was a team game. It was no time for quarrels and somebody should always agree. For example when Nikita’s trees and mountains had been ready and we had already began to make location from them Alex came and brought a new tree in the same pixelart but in quite other style. We liked it and threw all out and began to do it from the very beginning. So we can say courageously that Alex imported the style. But it’s one thing to promote your own ideas but it’s another one to agree and take someone else’s style. Nikita and Vova could do it perfectly. For instance, at first the hero appeared at location as a top view. Then we saw his face in comics and only after that we froze him on the start page. Three different men did all this. And it was so in many things. To draw in pixelart is not a new idea for quick project. But it is all artists’ merit that we could do something our own, original and complete.