Posts Tagged ‘postmortem’
This Ludum Dare was interesting, as it was my most ambitious game. And it failed. I should have known.
What went wrong? As always I tried to include an AI, random generation of something (this time a world), a dijkstra-algorithm (and removed it again, it always needed too much time calculating the paths) and fun.
And… it worked! Except for the dijkstra, which was at least bug free, but still not fast enough to calculate paths for 100+ animals every few seconds. And far from fast enough while running on a Pi. I had animals, the player could build rudimenarily, the villagers spawned, there were not exponentially many of them, things were fun (for me).
So, what was the problem? For multiplayer in a website I used websockets, which are great for that stuff, it went better than expected. But then again, it was the first project I successfully used websockets for. I found a python library (ws4py) based on another python library (cherrypy) with which I never worked before, and used them. Bad decision. It was sunday evening, three hours before deadline, when I first tried moving from localhost (lo) to local/public IPs/Domains (wlan0, eth0). Didn’t work. The Python socket implementation has a small bug… crashing connections far too often. I changed some parts, sent smaller packets, added small time.sleeps, It made the connection more stable. Then at least one in ten survived and worked. For a game based on an active connection that’s bad. But at least you could reload and play on.
But then not only did the connections crash, but sometimes also the thread handling the sockets. From the library. The bug is in the python standard lib. Without a chance for me to fix the bug. So… It doesn’t work.
What did I learn? Don’t be ambitious. I should have known that. Multiplayer is a lot of work. Use libraries you have already worked with. Did I ever do that? I guess not, but this time that paid out badly. Don’t use two languages at the same time. Make fun games!
So far, see you in december. I’m sorry my game does not work. Neither did using different backends for the websockets work, nor using pypy for the server.
Okay well, I have this stuff which is buggy, almost has no gameplay and was not even made within 48 hours but only in ~10 but somehow I stll can be proud of.
What was bad?
I’d start with it, cause it’s the more. Practically everything went wrong.
- I didn’t even have Internet conection at home, so I couldn’t join the flow of the community with WIP shots and random tweets. It’s pretty important for me, as it’s a major “feature” of Ludum Dare for me.
- My first idea was good, but went bad: it was too far from what I imagined, an beyond a point, it overwhelmed several bugs as well. Finally, I couldn’t even do “basic operations” like return the value of the tile Player is standing on. At this point, I gave up.
- On the second day, I had other things do to (girlfriend visit – so yeah, kinda important!) so had very little time. Maybe I simplified too much on the contribution itself.
The what was good?
Suprisingly, the most important thing went well.
- I LEARNT. Both the abandoned and the fina game learnt me somethig bot facts and programming things.
So I learnt:
- that procedural generation is extremely hard sometimes, and even though you wouldn’t think, writin a proper random map generator might take much more time than creating maps by hand.
- that proedural generation is STILL helluva funny!
- that addig features in hurry is like using bubble gum instead of duct tapes. The result is the same.
- that even if ugly, hanging trains are god damn awesome.
- that you can create decently looking people even from 4 pixels.
- that fun can cover the mistakes in gameplay.
- how to create randomly wandering people.
- how to use sound functions in LÖVE properly. It’s the mos important since I was completely lost before.
- how to use color changing functions in LÖVE properly.
- how to create realistic trains (in behavioural aspects)
So yeah, finally I learnt in LD#30 that the most important thing in Ludum Dare is LEARNING.
When we (me and tommislav) first started thinking about organizing a game jam at Isotop we never imagined that we’d get the response we actually got. During two days in August over 15 people gathered at the Isotop office in Stockholm to develop games for the Ludum Dare game jam, eat pizza and have an excellent good time!
These are the entries submitted by the participants from our Real World Gathering
Trapped Between Worlds
Terrorist Hunter 2D
by Martin Vilcans
The Two Sides of the Rio Grande
frozzare from Isotop tried out Haxe and Haxeflixel for the first time, and even though he created a fully playable game, he did not submit it to the compo. However you can give it a try here.
What went right:
I felt like the scope was perfect for the limited amount of time I had this weekend. This was mostly luck, but I also knew when to quit tweaking and didn’t regret it.
The match-3 and block-dropping algorithms fell into place like magic. To be fair, I’d given it some forethought–I did a quick Unity refresher on Wednesday where I attempted to build the line-clearing mechanic of Tetris with help from this tutorial. However, that’s a much simpler algorithm and I didn’t have an exact plan. It was a leap of faith that paid off early, leaving all of Sunday for polish. (I’d probably remiss if I didn’t mention that the match-3 concept was inspired by the time I spent in SeishunCon‘s digital gaming room this year.)
I’m happy with the art. I didn’t stretch myself stylistically, and it’s not as crisp and detailed as what I’d hoped, but overall it feels pretty slick if you don’t look too closely. I love posting those screenshots because it feels like a “real” game (well, at least to me).
As in the past, adding a GVerb track covers over a multitude of recording sins. I’m going to say this a lot in this post, but this feels like cheating.
Driving 40 minutes back from the Knoxville Game Design meetup is always a good way to start thinking about design and algorithms.
What could have gone better:
I basically shoehorned a puzzle game into the theme. This was premeditated, mainly because I was itching to dip my toe into the genre. It restrained the scope by removing the need for level design, which helped. However, it also felt like cheating the system to start thinking about a game genre so early (especially since I feel like my LD29 entry was a much stronger “Connected Worlds” concept).
Overall gameplay was good, but not great. I’m happy with this in one sense–I didn’t make a ton of explicit design decisions, so I won the “go with whatever’s easiest” lottery. Still, I feel like the “flip or drop” choice is missing something. I enjoy the game, but I restart as soon as I clear out all of the obvious flip combos. Once I have to drop blocks, it’s like I’ve failed. I feel like a “flip or shift” mechanic would have been better.
What went wrong:
Because I wasn’t livestreaming, I tried to do a status update video on Friday night. OpenBroadcaster doesn’t work smoothly on my laptop. I wasted about an hour or so tinkering with OBS on a night I ended up staying up until 4am.
I don’t understand music. Originally, I picked the current chord progression as a base, then played some random notes over it on a second track. Seemed clever on Saturday, but on Sunday I realized it was too chaotic. After talking to Mike at the post-LD meetup, I think I need to study up on some music theory basics rather than hoping a clever experiment will pay off. (I feel like I’m reusing the same chord progressions and I always use a similar rhythm/picking pattern.)
Overall, I don’t feel like I stretched myself like I should have. I stick to the same style musically and artistically because I don’t have a lot of range. I stick to Unity because it’s all I know. To be honest, I’ve had a few good ratings in past LDs, so I avoid the unfamiliar because I want to keep that up. Next LD where I have the time, I need to set a few goals–for example, use Inkscape instead of GIMP, or use a digital tool like PxTone or Bfxr.
My game is called “When Worlds Collide”, and you can play it here. I had a lot of fun during the competition, and I learned a lot too!
What went right:
I had an idea before I started. Usually I try to think of ideas for each of the themes in the final round so that I am prepared. This time, I simply had two ideas that I liked, and fortunately could think of ways to fit them into the themes. So this is something that could have went wrong, but didn’t.
I succeeded in making my game’s code modular and clean early on. Sure, by the end of the weekend it was a mess, but because it began well-structured and easy to modify, I was able to make changes to the game and fix parts that weren’t fun or didn’t work well enough without using up a lot of time.
The game is juicy. Very juicy. The biggest issue my games have (whether they were made for a jam or not) is a lack of visual polish and feedback. I specifically wanted to improve in that area with this game, and I think I succeeded. Images just don’t do it justice.
The game is fun. That’s what is most important, in my opinion.
What went wrong:
I should have spent more time working. Honestly, I didn’t take a lot of breaks, but I submitted early and didn’t work until the deadline. I was tired. There are a few things I can think of that should have been better, but aren’t.
There are bugs. Well, all code has bugs, so of course this game has bugs. What I mean is that there are known bugs. The are known bugs that have taken so much of my time, and still aren’t completely fixed. In the past I’ve almost always succeeded in fixing every known bug before submission, so this is a huge disappointment to me.
In the end, I’m extremely happy with how the game turned out. Many things went right, only a few things went wrong, and the game is fun. I’m considering adding multiplayer cooperative and versus modes, but for now, you could always play cooperatively on the same keyboard.
My fifth Ludum Dare, after a small 2 Ludum Dare break! I think this time went a little better than other times in terms of how fun the game is, though it suffered a little bit in that I wasn’t able to add as much polish as I would have liked. I used no middleware or prebuilt engines as I thought it would be worth the learning experience, and it sort of was! Here’s a breakdown of how things went:
Things that worked out
- I’ve been messing around with WebGL a lot recently, and thought it might be a good idea to try out a deferred lighting system for the map rendering. At first I thought it might take too long, but the final result turned out looking fantastic (and running smoothly too)! I’m definitely going to experiment a lot more with this in future.
- The grapple mechanic – I spent basically the whole first day tweaking it to work perfectly. You might not notice while playing – but the gravity force is actually disabled when using the grappling hook! This makes it much easier to swing around a point in a circular motion.
- The level editor I used, Tiled was completely on point! The editor was much more robust than Ogmo Editor, and the json export was a godsend.
- PxTone always amazes me – I have no idea how I was able to create music that fast.
- The graphics really worked out this time. I started each tile by designing specific palettes for them and then deviating a little. The result is quite striking!
Things that didn’t work out
- I designed all of the levels in the game in literally a few hours, so I couldn’t really streamline them.
- Only the level shown in the top gif really uses the platform switching mechanic to it’s fullest potential, I didn’t have enough time to integrate it into the others (especially level 2! those platforms before the swing around could have been switchable – but I had worries that the difficulty would spike because of it)
- I wrote the music in literally the last 30 minutes, so let’s just say that it incredibly accurately encapsulates how rushed I was at that point.
- Because I used no middleware or pre-made collision engine or loader – I spent a lot of the time setting up the game engine from scratch. If I didn’t do that, a lot more time could have been dedicated to level design and adding decorative tiles to the levels.
- No menus! No victory music! Altogether not quite as “complete” feeling as my previous games.
Making an accidental sequel
I’m going to ramble for a bit – so I’ll put a read more tag here. Click that if you want to, uh, read more.
As the title says, this was my first LD, and I’m proud to say that I actually “finished” a game.
I was streaming for almost 30 hours, here’s a 5 minute timelapse video of the weekend:
The game I created, HexConquest, is a turn based strategy game, made with Unity.
Here it is
When I woke up on saturday, the competition was already 7 hours in, and I tried to come up with an idea as fast as possible. The first idea was a strange tower defense game, but I tossed it pretty fast. I could reuse the tile generation code I created for the tower defense game for my second project. The second idea was to create a playing field controlled by different fractions, and the player should use his units to conquest the enemies’ zone to connect his main world to others. As you see in the list below, I didn’t get to actually implement the “zone”-thingy, that’s why the theme may not appear obvious…
I didn’t make a plan (one of the things I want to do different next time), so it was pretty chaotic. I spent a lot of time with the pathfinding, so I had to do the A.I. (a topic on which I don’t have any experience with at all) and game objective in a rush and couldn’t even start creating sound/music anymore.
- Action Menu
- Particle Effects
- Planets & Conquest
- Round Manager
The game has some serious usability problems, few bugs and calls for an overhaul. Until the next LD, I will spend time to improve everything and implement all the features I wanted in the beginning.
As I’m only a hobbyist developer, I learned more over a single weekend than I learned in all the months I was using Unity before, most likely because I never finished a game and never had to deal with every subject of development.
This was the first, but definitely not the last LD for me!
PS: Thanks for all the feedback on my game, it helps a lot.
This was my second LD, so I took it with a more relaxed mindset than the previous one. I aimed for the 48h challenge but if I didn’t have something playable I could always enter the jam. Eventually I’d submit Elyseus for the 48h compo
This was my first Ludum Dare using Unity.
For the graphics I used Photoshop as always.
For the music I used Music Creator 6 and my trusty midi keyboard.
Sfxr and Audacity for the sound effects, with some recordings of my own.
What went right:
Music and sound are hard to get right in so little time. In my last Ludum dare I didn’t even had time to make music. So for this one I gave it more priority.
The first morning I dedicated it to make some music to set the general mood for the game. I originally intended to make another variation for the underworld music, but left it as an optional goal which sadly I didn’t met. But overall I think the music fitted just well enough.
I also wanted to make some satisfying combat sounds. The sounds for the main enemies’ bones exploding deaths were made from a combination of Sfxr explosion sounds and a recording of some dirty cheap dice rolling
The “clink” sound for the shield mechanic, which at first wasn’t even planned to exist but I had to implement it because the combat was so frustrating, was made by hitting my coffee maker with a pen!
Also, the world change effect worked surprisingly good, although it’s a bit incomplete. I wanted to fade the enemies from both worlds to be able to see what was coming, but only got it halfway and the appearing enemies just pop around when you are already in that world, so sometimes it’s a bit unfair.
What went wrong:
The main idea behind Elyseus was a lot bigger in my head, and big is always bad for a jam. For instance I originally planned to have a more simple combat to be able to make it quickly so I could make more features. Features which initially included online play invading other people’s games Dark Souls style… But that was way too much. So I focused on making sure what I did was at least fun to play.
The base objective of the game eventually ended as a cyclical infinite battle with the only possible ending being death. I wanted to make a more positive ending, but didn’t have enough time or any good and clear idea for it.
The other critical point was that to make the cyclical aspect, you could fight against another hero and without online implemented, I had to make an A.I. and A.I. is difficult to make. I spent the majority of the last day trying to make that work, even as shitty an A.I. it ended up being…
It’s always a learning experience. At the end of it I had a playable game. In my opinion not enough fine tuned as I wanted but playable nontheless. I hope you have fun playing it! I want to know what you think!
Here’s the link to it: http://www.ludumdare.com/compo/ludum-dare-30/?action=preview&uid=36237
I worked a lot harder on this Ludom Dare then the last one. Did it pay off? Well, I think it did… I mean, my game is kind of amusing, and longer than my last entry. But there are still some things I would like to have worked on more, or added.
I kept on schedule through this LD. Everything I did took as much time as I thought it would. Friday, I started the project. I came up the concept for my game, and once I got back from dinner with my family, I made a few sprites, and a background. I also started music. I finished the fight scene on the Saturday, and even made some extra sounds and graphics for Sunday. On Sunday, I finished the intro and handed in the game!
I came in luck with the music. I can’t make good music, no matter how hard I try. I tried fake music generator, but it wasn’t generating the type of music I needed. And I could make what I wanted on Otomata, (which is a really cool music device btw), so I went to Abundant Music. It generated a super slow song, that had potential. I sped the song up (a lot), on Audacity, and boom! Nice background music, (well I think it’s nice)!
I figured out how to check if the player is walking on ground in Unity2D, for the first time. I also made it so he has to jump over a gap, which was pretty good.
I learned the difference between OnTriggerEnter2D, and OnCollisionEnter2d, which is great because I always seem to have trouble with collision detection in Unity2D, and that probably was part of the reason!
Graphics were pretty good. I’m not very good at making them, but thanks to the powers of Gimp, they didn’t look to shabby!
Difficulty. The game was way to easy. For some reason Unity had this glitch where, some of the mirror beams would travel faster than I coded them to when I ran the game, (thank God it doesn’t happen in the build)! This made it harder for me to win when I was testing, so I thought the game was harder.
The intro was too long, and the game was to short. I should have made the intro more faster, and more interactive. And the game longer, and harder. I find it sad that my game didn’t have a lot of gameplay, because that was what I was trying to focus on this competition!
I should have made it so you are able to skip the cutscenes. They really get annoying after a while.
Controls were a bit funky. You have to press the down arrow to go duck, and the down arrow to get up again. I used to have it so you press the up arrow to get up, and up arrow to jump once standing. But I found that made it harder to jump over the mirror beams , (especially with Unity making them super fast). So I made it so you can press the up arrow to jump when ducking, and the down arrow to stand when ducking. It’s kind of confusing to press the down arrow to get up though. It’s actually ironic in a way…
Animation wasn’t the greatest, but I do suck at graphics, so how good could it have been?
I had to make a lot of sprites. One for each deformation of Alex, in jump pose, duck pose, and stand pose. What I should have done was make four different versions of his head, each with a different deformation, and moved them whether he was jumping, ducking or standing. But oh well, what can you do?
In the scene where Alex’s mirror breaks, I should have made the text “My reflection.”, fade out faster. And I should have made the scene after fade in, because it all of a sudden just appears!
My Overall Feelings
Overall I think this was a pretty good LD. I learned some things, and found some cool new tools that I might use in the future. Though my game is short, and there wasn’t that much game play, it’s crazy, and funny, and I had fun making it!
And finally if you want to play my game, you can find it here.
Hello, everyone! I’m Shaquille Stoutamire (Defacid/Acid) and I had a lot of fun with Ludum Dare this year! I’m really excited that, even though I still had a lot going on, I managed to finish my entry! It’s not as fleshed out as I wanted it to be, but I submitted it in time… with a whole minute to spare!
WHAT I ACCOMPLISHED:
- Randomly generated worlds with terrain and plantlife variations
- Pretty decent gravity and rocket physics (there are definitely bugs, but it’s relatively solid)
- Basis to a leveling system
WHAT I FAILED AT:
- Fleshing out the level system to actually DO something
- Adding outposts and environmental interactions like gathering resources and using them to survive
- Spending too much time on the planet generation: I had already build a similar system before, funnily enough for a previous Ludum Dare, but I ran into an error didn’t want to look at it or use that code base – when I do a game jam, I like to work from scratch in the engine/IDE that I’m using. Next time, even if I’m not going to copy and paste, I’ll at least look.
- Actually fleshing out the morality element. Right now, the player themselves has to ask the question of “Why am I killing these little guys?” when experience doesn’t change anything about the gameplay. But I wanted to actually add something of value to the mix like planets losing color saturation when you kill enemies, but you get something in return so you have to weigh whether or not it’s worth it to kill these defenseless little guys.
- Clearing my schedule for the event. It was unavoidable (school, watching my son, my car broke down haha) but it still definitely hurt my game. I lost AT LEAST 24 hours due to obligations and 8 to sleeping. So I ended up with about 12 or so game dev hours at the maximum.
WHAT I’M DOING NOW:
I’m going to port my game to HTML5 within the next day so that more people will play it! But within the next 20 days, I’m going to play as many other compo entries as possible! I will make sure to play and rate every game of every person who rates and comments on my game.
Our jam entry “Corponnected Ltd.” is now in the wild, and first feedback has been very positive! To hear people saying they actually finished the game / played it for half an hour is incredibly heartwarming. Here’s a quick postmortem while memories are still fresh:
Before the Jam
This week-end was my fourth LD, and the second one with teammate Manu. This time we managed to make a 3rd person, Guillaume, join the team, so with our extended workforce we felt like the sky is the limit! With our little experience with previous jams we knew we had to avoid making a too complex game, so we planned to make something that could easily start small, and then be iterated over.
We chose in advance to make the game with Phaser.io (HTML5 engine), so we could practice with it a bit before the jam (before that, our engine of choice was CraftyJS, but while we love its API, some annoying issues made us want to try something else).
This past weekend I participated in the 30th Ludum Dare 48-hour competition and created Fusebox, an energy management simulation game. What follows is a summary of my experiences creating it, and what I learned from doing so. I had a lot stacked against me, and while I missed some milestones that would have taken the game from mediocre to great, I think that I did really well considering the situation. Before we can assess that though, we have to start from the beginning.
Sure-footed as a Mountain Goat
One week before the Ludum Dare competition started, I was at the local rock gym with a friend of mine. They had more than just rock walls there, and in my first (and most likely last) attempt at this whole slack-lining thing, I fell and landed sideways on my foot. It instantly swelled up to the size of a potato, and I haven’t been able to walk properly since. I have made a pretty decent recovery so far, but one thing I can’t do is sit up. If my foot isn’t elevated above my head, it swells back up like a balloon and becomes incredibly painful. Since working on a computer with any amount of comfort necessitates putting your feet beneath the desk, I wasn’t sure how it would turn out.
The downside to this was that I couldn’t get into a position that was ideal for either my foot or for writing code. I was at least slightly uncomfortable the entire time, and several times throughout the weekend I had to stop and move to the couch to give my foot a proper rest. This had two side effects. The first was that I lost a lot of development time to laying on the couch with my foot on the back. The second was that in order to try and take advantage of this time I brought my notepad and did as much design and planning as I could while I was away from the computer. This is probably the main reason the game is so complicated and over-engineered.
What is it Even Uniting?
One of the main reasons I do these competitions is to force myself to try something new. I’ve used new engines, tools, or frameworks every time, and I’ve never made a game in a genre that I’ve done before. It’s a great way to learn a lot in a very short amount of time, and when you’ve been programming for a length of time measured in decades, it’s not a stretch to try and figure something out in that time frame. Since my current game project is in Unity, and I’ve been struggling with it since day, I decided that I would force myself to figure out and use Unity for this competition. In retrospect, I’m glad that I did, but it definitely slowed me down quite a bit.
I also chose to do a very UI-intensive project this time around, for a couple of a reasons. I felt that my foot might get in the way, and I wanted something I could work on from the couch if the need arose. I also know that I hate writing interface code, mostly due to the fact that I’m not very good at designing interfaces, and I find the whole thing very tedious. I may have been setting myself up for failure here, but the goal was never to win the competition. In all of the work I’ve done on Project Dunwich, I have not even touched the interface yet. At one point I actually had to look up how to make a button. I was starting from scratch here.
Despite using tools and techniques I was unfamiliar with, and dealing with Quato growing on my foot, I felt pretty good going into the competition. I had read through the list of themes, and I focused my thoughts on the highest rated candidates from the first four days of voting. This is by no means a fool-proof method of predicting the winner, and I wasn’t writing any code or committing anything to paper, just idly thinking about the design possibilities. I ran through some ideas while I went about my day, and initially I wanted to make something with more action, since my last two attempts sort of fell flat in that regard. Most of the ideas I thought of with any amount of action seemed either too obvious, or not connected enough to the theme, and UI was another focus area, so I settled for a management sim game.
Once the theme was actually announced, I was a bit relieved that the top theme won out, since it meant I already at least knew what genre of game I would make for it. The idea was simple, connect worlds together through some interface, but give those worlds multiple, intricate layers of connection. I like to make my games hit the theme in multiple ways, and that satisfied that requirement. Connecting worlds to an energy source was the obvious take on the theme, but having them be linked to each other as well added a nice extra layer of depth to the interpretation. I’m not sure any ever notices these little touches, but it makes me feel better about my interpretations.
I immediately started with graphics, since I didn’t think there would be very many, and I wanted to get it out of the way. I drew up a mock interface, some icons for the planet stats, and some graphics for the planets themselves, and actually had something passable by the end of the first night. I have used Inkscape quite a bit over the past few months, but I had never done clouds or noise in it, so that was a fun little challenge to overcome. In the end, I spent less than four hours total on graphics, and I’m glad I didn’t have to fight with them at all once I got into the interface code.
With graphics in hand, I set to create the game objects and renderers that would use them to actually put the images on screen. Unity actually made this really easy, though I have no idea if the setup I used is proper for an entity-component system. Since most of the game objects were just data containers, that didn’t take very long, and well before the half-way mark, all I had left was to write the code to process the interactions on the game objects, and then do a whole lot of UI work. After a brief stint on the couch to rest my foot, I started in on the UI.
As I mentioned earlier, I had no idea how to approach the interface. I created things using GUIText and GUITextures, I switched to converting screen coordinates to world coordinates and driving the UI with game objects, and eventually discovered the OnGUI method and settled on using that. Throughout the course of the day on Saturday I created as many interfaces as I could, to enable interaction with the game objects. I could just as easily have started by coding that all into the setup and working on the simulation, but that seemed like it would be harder to iterate on. Once I learned how to make the interfaces, it was a pretty smooth ride of create, test for usability, modify, repeat. I didn’t do things in a very efficient way, there’s a lot of copy/pasted code for UI stuff, but I just kind of zoned out and started writing.
By the end of Saturday, I had about half of the interface done, and none of the game logic. That seemed like a bad situation to be in, so I set out to right that first thing on Sunday. Since I had spent a fair amount of couch time writing out notes on how I wanted it to work, that actually went pretty fast. The logic is pretty complicated, there are a lot of moving parts that determine how the hardware will react, and how the planets will respond to their situations. The biggest problem with all of that is that I couldn’t get the interfaces done in time to actually explain all of that to the player.
The final interfaces were the ones that told you what was going to happen when you advanced the day, and the one that you manage your circuit board. You know, where you actually play the game. I knew what needed to be done, but by Sunday my foot was in open revolt against me. I spent a lot of that final day on the couch resting, and with nothing to plan, I just sat there mentally writing interface code to draw out how I wanted it to look. The funny thing about mentally writing out code, is that it’s a completely useless activity. When I felt good enough to try and implement it, everything fell apart on me. I had planned on whipping up those last two screens and then playtesting the game for bugs and balance. What ended up happening was a mad dash to get the interfaces working that ended about 15 minutes before the deadline.
At Least I Finished… Sort Of
I decided that I was done, and 15 minutes wasn’t enough time to get any of the last things I needed from where they were to where they needed to be to even be passable. I set to build my project and upload, and then Unity decided to remind me why I hate it so much. Apparently the method I was using to color the planets with HSV colors was only available when you ran the game through the editor. It wouldn’t even compile. Fortunately, HSV to RGB implementations are a easy to code, so I started throwing one together. In the past I’ve worked on them with hue being an angle from 0 to 360. Unity’s method had it as a float from 0 to 1. No sweat I thought, I’ll just multiply it by 255. If that doesn’t make sense to you, it’s because it shouldn’t. All of the planets turned green because I mixed up angles with rgb values, but I didn’t have time to figure out why. Up it went, and just like that it was all over.
I’m glad that I made the choices I did. I learned more about unity and its UI features in this past weekend than I have in the past four months. Sure, I could have scrapped the planet interface and focused more on good UI, and I probably would have been better off spending time on tutorials rather than tweaking button positions. Given the constraints I was working under, I’m really happy with how things turned out. I do have some ideas for how to improve next time though.
- Simple design with good balance – I had so much time away from the computer that my end product was as overly complicated mess, and there’s really no way for the average player to figure out what’s going on. Having a more simple design with a better balance would have been a better approach. Instead of having four types of compatibility and a two-hundred line calculation for fuse load, cut it down to two stats and spend more time on making sure the numbers work out over the course of the game.
- Interaction before eye candy – My planets look way better than they need to for a game that is mainly driven by button clicks. If I had put that off until the end, I would have been able to see that before wasting time on them, and I might have had time to implement things like a proper tutorial or a win condition.
- Playtest as early as possible – I put the core logic off for so long, that by the time I had it finished, I was already in crunch mode. This left me no time to make sure the numbers worked out, or that the game was even fun. With a game like this there’s really no excuse, I could have had unit tests written to test out the formulas and algorithms through all 100 days by Saturday morning if I had prioritized it. Good balance is going to be my main goal for next time.
That about covers it. I had a good time, and in the end I have another game to throw on the website and say “look what I can do in a weekend.” No matter how bad I do, or how stressful it is, that sense of accomplishment will always be worth it.
4 Ludum Dares down, many more to go! I managed to “finish” my “game” within the 48 hour window this time, and I didn’t stress out anywhere near as much as I have for previous events. I’ll take that as a sign of consistency. As always, I’ve learned so much over the course of this past weekend and I’ve had a great time to boot! Anyhow, shameless plug for my own game here to accompany the obligatory postmortem.
Tools and Software
- Adobe Photoshop CS6 was used for all graphics, sprites and tilesets.
- Tiled was used for map editing and design.
- PxTone was used to write any audio.
- Firefox Nightly and Google Chrome for testing.
What Went Right?
- Experience in programming. Over the course of the past year, I’ve been programming far more regularly – so I’ve noticed myself writing far, far less mistakes and being able to more efficiently debug those I do make. Naturally, this means less time stuck in a rut, moping over the sorry state of my code!
- Having past code and engine work to refer to. Having past examples makes for a great starting point to start working while you come up with any ideas, and allows you to iterate on the design of any underlying systems. Besides, I always love coming up with better solutions to problems than I could have thought of before!
What Went Wrong?
- I kinda lost my drive to work on the game for a while. Unhappy with the state of my game at the time, art and gameplay alike, I lost most of my drive to code for a large portion of Sunday. Had I not done that, I could have implemented a few more features before the deadline (including, you know, scoring). Urgh.
- Cut features lead to seemingly meaningless design decisions elsewhere. Considering the game features only golf as far as gameplay mechanics are concerned, having to walk around everywhere seems rather stupid. Unfortunately, I didn’t have time to implement any enemies or aliens, or even proper entities so little artifact design choices are littered everywhere.
- Harsh choice of palette. As much as I enjoy working with limited colour palettes, this time I had an awful lot of trouble coming up with graphics that weren’t trash. Ideally, I should have created far more colourful structures around the map to help create contrast and allow the generally flat blues of the asteroids and walkways to stand out more.
- Sprite design? Still not my cup of tea.
Stuff I Enjoyed
- Working with new tools and file formats. Although it took a little while, working with new programs like Tiled was a very interesting experience, and I’m certainly glad to have spent some time working it out! It was fun integrating someone else’s map format into my own engine, I’ll admit.
- Painting nebulae for backgrounds. Photoshop’s ability to map an image to a given colour table was amazing, and allowed me to go wild with a nice set of brushes on my tablet while still keeping in my 8 colour limit thanks to automatic pattern dithering etc.
- Writing music, for once. It was kinda meh, but I totally do not regret writing some music for a change. I have enough oddly silent Ludum Dare projects as is.
Thoughts for Next Time
- Be more positive. I really need to not get too hung up over the current state of my game, knowing full well that additional time and effort will almost always make it better in the end!
- Pick a colour scheme, but don’t be afraid to deviate. Sometimes, 8 colours can be just a little bit too stifiling.
- Reel in my ambition. I hate having to cut features as the deadline draws near, but at the same time I still like seeing my original idea transform and evolve as compromises have to be made over the event.
- Come up with a more ‘fluid’ game idea. I love fast movement and freedom in games, so I want to make something far more unbounded next time.
- Consider time management. Then again, I never really benefit all that much from excessive planning and so on. So this probably wouldn’t be all that good for me.
Again, if you’ve spared the time to read through all this then thank you very much! This is more for myself to crystalise any knowledge I’ve gained for surviving game jams, but it’d be even better if this ends up helping any of you folks out there. Now, get back to rating all those games!
Hi guys, this is a post-mortem of : Must to be Invasion
For those who have not played I recommend you play, to better understand what I mean. I will cite references in the game to practical examples.
What I used:
- Unity 4.6 (2D project)
Day 22/08 – Start: 23h – Total work: 5 hours
- 3 hours of brainstorm
- 1 hour enhancement concept
- 1 hour prototype
- Sleep (4am day 23)
Day 23/08 – Start: 13h – Total labor: 16 hours
- 2 hours drive to implement player
- 3 hours collecting the web assets
- 2 pm Lunch / Dinner / Rest / Play / Chat
- Implement person 30 minutes
- 1 hours Implementing player commands (shoot, abduct)
- 30 minutes Implement cars
- 1 hours Implementing fake-physics
- 1 hours tidying bugs
- 1 hours rewriting code to be more readable
- 2 hours placing and arranging scenery animations, camera
- 2 hours writing fake-AI for helicopters
- 30 minutes implementing the helicopters
- “Breakfast” 30 minutes
- 1 hours testing and correcting bugs
- Sleep (15h day 24)
Day 24/08 – Start: 15h – Total labor: 7 hours
- 4 hours Rest / Eat / Play
- 1 hours tidying bugs
- 30 minutes implementing life cycle (person dies -> turns ghost -> abducts -> turns zombie)
- 1 hours Fixing problems in resolving
- 1 hours recreating scenario
- 1 hours and adding difficulty leaving the way I think it has to be the level
- 30 minutes implementing sound
- 2 hours doing input screen and other screens
This was my first ludumdare, but not first GameJam. So there are some things I had in mind when I decided to enter:
- Make a game that I already have in mind how to start (like platform, running, football, etc), ie, not risk on land that I have no idea where to start
- Use an engine and language (programming) I understand and used before
- The clear concept is the key
- Eat well
- Sleep well
- Know what your potential. Ex: not necessarily choose the first idea that comes to mind after seeing the theme
- Know the difference between technique and what can be done in 48h / 72h. I often fall into the trap of thinking you could do a game in so long only because I had already had done and know-how, but unfortunately time is needed, not only to produce but to fix things that do not work, improving among other aspects. Ex: Make a spaceship game
- Do a post-mortem of the game and numbering (if possible) what were the failures and what happened as planned. This also applies to personal growth
What I learned and / or should have done
- I need to learn more about other areas (art, sound). Ex: Scenario
- I need to stop spending so much time on things that will not change the player experience, or enrich the game. Ex: animation of the input screen
- Structured better the game, from beginning to end before starting. Ex: no end, and in the middle of the project I thought of putting an end, put two players
- Having planned my time better. Ex: I overslept and spent time playing and doing other things
What will never be satisfied and always will think that I have to improve (for game jams)
- Learn more about the tool
- Structure the game before you start
- Polishing, polishing and polishing. I know it’s not possible, but I feel well and is not too bad.
- Mechanics and Design Level
Do not know if this will help someone, I found it necessary to share with you what I went through.
There is a saying: what good is an education if you do not pass along?
For the last, I encourage you to write and share your post-mortem, I would love to read.
I hope I have been as thorough. I swear I blacked out many other details to spare you from them.
Comments, criticisms are welcome.
Thanks for reading this far.
Images – More images here