Thanks to everyone who has been playing our game, Square Heart Flower! We appreciate the comments, and we look forward to finding out how it’s been rated!
Here’s a timelapse of us making it. There were three in our team (Jonathan, Dunk and Ricky), and Jonathan used two monitors. You can see our different attempts at trying to achieve the distinctive minimalist graphics, and some clips of gameplay at different stages throughout the development!
A post-mortem of ❏♥❀ (Square Heart Flower)
Please do play our game and give it a rating!
Here’s a timelapse of us making it:
Unity is brilliant, and easy to use! We’ve used it for a couple of games, and although we could still improve the way we organise our code/prefabs/scenes, it lets us put a game together very quickly! It’s also robust enough that we don’t have to worry about crashes or rendering problems.
Minimalism made the art easier to create! It would be easy to think that a minimalistic theme would allow us to create bad art and pass it off as minimalist. However, we spent some time thinking about minimalism, and came up with an art style that looks great without requiring detailed texture work! Using Blender’s Inset Faces tool with a group of faces selected, an outline could be created in the geometry of the model itself, and then a black material applied to the “outline” polygons to suggest the edges of the object in the white game environment.
Objects are reduced to the minimal graphics needed to represent them, but you can still tell what they are.
Minimalism made the dialogue easier to write! There is no text in the game – we explored the concept of reducing language down to symbols. It’s part of the puzzle, but we find it interesting that players can figure out what’s going on even though the characters they meet and the dialogue interface only convey a minimal amount of information.
We pushed ourselves to make something new! We are all programmers by profession, so it is unusual for us to have a go at making an artistic game. Violence provides a variety of game mechanics that are easy to build a game around, so it was a challenge to create a non-violent game for a change!
Having only one Unity scene meant we couldn’t all work in parallel. Unity scene files are binary, which means they won’t merge properly if there are conflicts in the source control. At the beginning of the weekend we were working on separate scenes to test individual systems, but at the end there was a lot of work to pull everything together, and it could only be done by one person.
We didn’t get the story working completely until the end of the third day. It took us a long time to create all the content, including the AI behaviour. This meant that the story we implemented, although a complete story, wasn’t as elaborate and non-linear as we were hoping.
We didn’t make use of all the features we’d programmed into the dialogue system. By having a minimalist dialogue system, we envisioned that the player would be able to say anything they wanted by constructing the sentences from symbols. That is present in the game, but because of limitations in the graphical dialogue interface, we removed the ability for characters to respond to every piece of information you give them. Also the code allows for much more complicated logical rules – to change what the characters think and do – than are present in the final story, but again the GUI is limited in what can be reasonably displayed.
Our external source control system was slow. The Mercurial repository was hosted on bitbucket.org. I had hoped that this would be a good way of enabling us to continue working on the game together after we had all gone home, but it meant that pushing to the repository took up to several minutes. “We’ve wasted, like, hours of the competition, pushing to this repository” said Dunk, who has no concept of the passage of time, and who liked to commit huge MP3 and WAV files.
In the UK, the competition started and finished at 3:00 AM. Technically that would give us more time, because we usually sleep through the theme announcement and start when we wake up on Saturday morning, then stay awake on Monday to work through to the competition deadline – an extra hour this time compared to the usual finish of 2:00 AM. However working that late is a recipe for introducing bugs into the game at the last minute, so we decided to create a stable build, submit it and go to bed even though we could have stayed up longer to add more features.
We’re very pleased with the game we’ve made in Unity! It fits the minimalism theme well, and is playable and fun. We can always think of more that could be included, but it’s a time-constrained competition. Please play and rate our game!
This is our second time entering Ludum Dare! Our previous game was Macro Marines, and you can read about how we got on. We’ve learned from some of our mistakes, and we think that this time our game is better! Please play and rate it!
See how we made it:
Unity is brilliant, and easy to use! We had great fun learning to use it in LD23, so we used it again this time and had a better idea of how to use it properly. It does everything for you and lets you get on with making the game, we love it!
We got plenty of sleep and decent food!The Jam started at 2AM UK time, so we decided to get an early night and wake up bright and early to discover the theme in the morning and think of ideas over breakfast.Each night we slept enough to be refreshed the next day.This is in contrast to how we’d do things at university, where some of us would try and go the whole weekend without sleep! (it didn’t end well)
Nice graphics!There are still some rough areas in the GUI, but overall the game looks good and the bacteria shaders look like proper scanning electron micrograph images.
Catchy music!Just listen to the groove on that DNA upgrade screen, yeah!
Good time management!Although we didn’t get a “basic but finished” version of the game uploaded and submitted 4 hours before the deadline like last time, Ricky did drive us to finish before the deadline and concentrate on the important features.
Decent gameplay in a short amount of time!We programmed the basic flight and shooting controls in an hour or two, allowing us to spend time tweaking and making sure they felt good. The bacteria AI took longer, but was working well by the end of Day 2. This left us with a day to implement the DNA upgrade screen – the key to the “Evolution” theme (although the bacteria do mutate and exhibit natural selection) and something which makes the game more complex and interesting than a simple shooter. But does that make it more fun?
Title screen – pwnz deus ex
Spent too much time on procedural environment generation. We thought that generating the “tunnels” in code and having junctions or “rooms” between them would allow us to either create a large level for the player to explore, or allow the computer to generate the level for us. In the end, neither happened, we just created a small level with three joined tunnels. For the work we put into it, we could have created an equivalent level in Blender in half the time, but when we extend the game beyond the competition it will come in very handy…
No jokes or silly voice acting, the bacterial theme didn’t really lend itself to that although I suspect we just weren’t trying hard enough to fit them in. Also we were running out of time and this was low on the priority list.
Upgrades aren’t balanced, it’s too easy to become too powerful too quickly. We need to learn how to pace a game properly.
We had great fun making a game with Unity, and I think we’ve learned from our previous Ludum Dare and made a better game this time!
Please play our game, leave some feedback and help us see what we can do better next time!
This is our first time entering Ludum Dare! We’re a group of programmers who used to make games together at university, while studying computer science. We re-united for a fun weekend of game making!
We thoroughly enjoyed making Macro Marines, and thought we’d share with you some of the things that went well and not-so-well over the weekend!
Unity is brilliant, and easy to use! It dealt with all the low level fiddly bits that go wrong all the time, and made it easy to get a prototype up and running within minutes (although… more on that later). Lots of 3D and game engine features are there and ready to use, cameras, lighting, shaders, physics, input, everything we needed. Any questions we had were easily answered with a look in the documentation or a search on the internet.
We discussed our tools in good time before the competition, so we could decide what to use and practise with it beforehand. We tried out a couple of game engines before settling on Unity (the first time two of us had used it). The night before the start of the Jam we set up a SVN server and made sure we could commit and update a sample Unity project. This meant we could spend all of our time during the Jam focused on making the game!
We got plenty of sleep and decent food! The Jam started at 2AM UK time, so we decided to get an early night and wake up bright and early to discover the theme in the morning and think of ideas over breakfast. Each night we slept enough to be refreshed the next day. This is in contrast to how we’d do things at university, where some of us would try and go the whole weekend without sleep! (it didn’t end well)
Our time management was fairly good, prioritising what needed to be done for our game to be playable. We reached our target of making a first submission 4 hours before the deadline, then expanded the content and graphics after that. Of course, this is only true to a certain extent, we were having fun with shiny graphics and non-essential physics way before we got anything functional or any gameplay (see the bad points), but towards the end Ricky was good at keeping us focused on producing something playable and submitting it before the deadline.
The graphics were half decent, above and beyond our usual “programmer art” fare! Practise with Blender was essential for this, and the excellent http://cgcookie.com/blender/ since I’d not used Blender for a long time.
Both single-player and multiplayer support are in the game! It’s unfair to expect everyone rating the game to find someone with whom to play local multiplayer, but equally that option is available (and probably better)! With this in mind we searched for “multiplayer” after the competition and rated a bunch of local multiplayer games while we were still in the same house.
AI is TOO good, it’s beating a lot of people who try to play! (according to the comments) Although this is a bad point too, it’s something we like. The AI is probably less sophisticated than you’d imagine, but it was still quite a bit of work to get it to play the game strategically. It’s amazing what you can do with smoke and mirrors
Title screen – pwnz civ 4
Unity is TOO easy – the overconfidence it gave us with our simple prototypes led to a complicated game design that we couldn’t easily balance in the time. The use of the theme in our game was to play on a looping play area – the surface of a small planet. Having a tiny world opens up strategic opportunity by allowing attack from multiple directions. But, even though Unity made it simple, it took more work than expected to fit everything onto a sphere. This leads on to the next point…
We didn’t get a working game until Monday afternoon, at which point it was too late to balance it or change the gameplay in any meaningful way. Up to that point we had been playing with prototypes and working through the game on paper, including several redesigns (originally you could send units over the poles of the sphere, and rotate in any direction, but that got really confusing). I think we needed to be playing the game, even with really simple gameplay and placeholders everywhere, as soon as possible so we could iterate on what we played. There wasn’t much time to refine it or explore the concepts we were looking at.
Our game relies heavily on either a second player or a sophisticated AI. We got AI working eventually, but it’s not balanced, and I’m not sure how fun it is to play against. Perhaps we should keep this in mind when doing our next Jam, as it’s something we have a tendency to do when designing games – make them system-based and symmetrical.
Misuse of Unity – to begin with we didn’t understand the significance of GameObjects and Components, and tried to do everything using singleton classes and static methods. Eventually we realised what we were doing wrong, and ended up with a prefab containing the planet, camera and game logic code which we could just drop into a new scene, then change the textures and building layout (using Dunk’s awesome level editor plugins) to make a new level. Then playtest and balance it… oh wait no time left.
No tutorial/horrible instructions screen, we left that too late.
There wasn’t enough time for music or silly amateur voice acting; I think those would have added a lot of character to the game!
Unity helped us make a good, complete and fairly polished game in the time we had, but we spent too much time on a complex design and not enough on playtesting. However it was a lot of fun, and we can always improve
Play our game, and help us see what we can do better next time!
See how we made it!
Here’s a timelapse of all three of us making Macro Marines for the Jam!
We’re in! We’ll be entering Ludum Dare for the first time, although we used to organise our own 48 hour competitions back when we were at university. It’ll be good to have 24 hours longer in the Jam than we’re used to!
We’ll use Unity to make the game, Blender for the 3D modelling, GIMP and Inkscape for the texturing, FruityLoops for music, as3sfxr and Audacity for sound effects, and Chronolapse, AVISynth and Fraps for timelapse videos! Also SVN to keep everything in sync.
Looking forward to this!