So we found out a way to finish our game on time despite of all the problems we had (idea for the theme, programming, art) and this is it! I hope you spare some of your time to play our game! Fire beats Earth, Earth beats Water, Water beats Fire. Have fun! Btw, this is our second game for Ludum Dare.
Posts Tagged ‘unity’
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.
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
Cosmic Conga is a fast paced strategy game that may… or may not be, balanced
Most of the feedback so far has been overwhelmingly positive (thanks everyone!) with the one exception of a psychotically insane AI difficulty.
Fancy a challenge? Try and beat the original LD submission Play [Web]
Sick of that stupid AI? Try our brand spanking new ‘balanced’ version Play Balanced [Web]
I stress ‘balanced’ as I’ve spent so much time testing this build I’m not entirely sure what constitutes ‘difficult’ anymore
Thanks to everyone who helps make Ludum Dare possible,
And congrats to everyone who submitted, the entries keep getting better every time.
It’s done! Since the last update, I’ve added a goal (buy all the planets), rebalanced everything to be more interesting, and added a bunch of quality-of-life improvements. (Windows stay on screen, you can rename lorries, etc.) It feels like an actual game now, and I’m really happy with it.
I appear to be afraid of making games.
My LD26 submission was an immersive world with graphics and audio, interactions and special effects, challenge and progress. It was clunky, confusing, cheesy, and short, but it was a game.
When LD27 rolled around, I looked through my feedback and made a plan. Graphics and interface were the biggest complaints I received, so I focused on a clean interface and smooth graphics. In that, I succeeded… but at the loss of a complex goal, and immersive interaction. The comments indicated such, but I didn’t get the hint.
LD28 added back some of that interaction, and gave the player a means to manipulate the ways they interacted with the game. It added back a challenge and goal, but lost the graphical and auditory polish, and it required content to really shine. Most of my time was spent on the upgrade interface, which was lauded, but the game suffered for it.
I didn’t feel too bad about my LD30 submission. I mean, it was missing 90% of my desired features, the graphics got skipped again, and I didn’t have enough time to playtest it well, so it’s statistically unlikely you’ll complete even a single objective… but that’s Ludum Dare right? 600 lines of code later, the inventory system works, the random goal and automatic goal-checking works, the random resource generation and base-color modification works, and the entire backend ties together in a bug-free manner. There are simple particle effects, some moody ambient audio, and a few hurried attempts at humor… It’s still a moderately successful submission.
The comment that really kicked me in the gut was, “Nice GUI Demo”. I know they didn’t mean it maliciously, but really? The worst part is, I can’t argue with it. I watched my timelapse, and I spent almost the entirety of the Compo mucking with the GUI. You don’t interact with the planets (yes, those were supposed to be planets), you push buttons. Everything is a button. You don’t live in this world at all. It worked for Adventure Games, but I guess we grew out of those in the late 90’s.
Immersion is hard. And evidently important.
Amidst the complaints Elder Scrolls Online receives (yes, random neuron firing here), one is how they focused on a nearly GUI-free experience. I’m beginning to understand their decision.
My goal for Ludum Dare 30 was to make a game that didn’t disappoint me. Instead, I think I discovered one of the issues holding me back. Just as good, I’d say.
Today I learned how to make the chat with AppWarp and the animation transitions with animator.
This is a great day, I have finished the basic game mechanics, but still need how to synch network objects like rigid bodies shared between players. In PhotonCloud is easier, I was searching in google but only found the old way to do it, like we did with socket messages, and i dont like it, so i opened a ticket in appwarp support service to learn how to sync rigidbodies using network views as easy as photoncloud does.
Anyway, so tired, i need to eat XD
Last weekend I participated in my second Ludum Dare ever. Completely different from last time, I knew what engine to use and what to expect. Does that mean everything went smoothly? No, not really. Am I unhappy? No, not really.
Engine choice: as opposed to last time, I actually decided on my engine beforehand. After seeing what some people could do with Unity, I decided to put myself over the fact that Unity uses the worst naming conventions ever (well… not really, but you get my point if you are a frequent C# programmer and know the Unity conventions) and give it a try. I only had time to do a simple tutorial and play a little bit around myself before the compo to refresh my Unity experience, so I knew in advance I would spend a lot of time figuring out trivial things. In the end, it did not turn out as bad as I expected. I got to know Unity a lot better, have learned to appreciate how it works and will most likely use it again next time.
Concept: I came up with several concepts that would cover most themes in advance. ‘Connected worlds’ was not one of them. This meant the first step was to come up with one. To prevent a situation like last time where it took a long time before coming up with a concept, I made a decision fairly simple. The concept I chose was fairly ambitious, but I deemed it possible. However, in my hurry to get started, I did not work out the concept far enough. I came across a lot of not-yet-made decisions during the implementation. I lost some time in that, which I could have prevented by thinking through the concept better. Deciding how the game should feel and where it should go to should preferably be done before the first line of code is written.
A good thing about the concept is that it is very scalable. It needs some critical mass to be playable and fun, but it is fairly open-ended and the critical mass is relatively easy to reach. As opposed to my previous Ludum Dare, this game’s fun-factor does not rely solely on level design, which means a lot less time has to be spent on generating content for the game.
Graphics: the graphics of the game suck. However, this time I knew in advance they would. I need a lot more practice to be able to make acceptable programmer art, and thus to justify spending time on making the game pretty. That is why this time I decided in advance to not spend a lot on time of graphics. Last time I spent a few hours on making sucky graphics, this time I spent a few minutes on making sucky graphics. Sounds like a fair deal to me.
Audio: while the music isn’t great, audible-music.com is a great way of getting rid of the silence and using some default drum loops in Garageband I can very easily flesh the music out a bit. I might consider practicing a bit with Garageband to make very simple tunes, as I think Garageband is a very understandable program and allows for not-so-bad-music to be made in a short timespan.
Overall: there are probably a lot of things I forgot to talk about, but I am sure the weekend as a whole counts as a very good experience. Considering it is only my second Ludum Dare, and my first time using Unity for real, I am not too unhappy about the result. I have definitely shown myself capable of applying my experience of the previous Ludum Dare to improve myself. From what I can tell, I have not made the same mistakes again. My goal is to participate in every Ludum Dare from now on — circumstances allowing. I am definitely looking forward improving my skills even more, and hopefully one day I will be able to participate competitively.
I just love to see what other people create as well. I feel very encouraged by all the people making a game in the same timespan, and the short period makes it an ideal distraction from the daily #gamedev obligations. Only by looking at livestreams and reading the updates I can enjoy myself and learn a lot of things, but participating adds another layer on top of that. Thanks guys, for being awesome.
If you are interested in my entry, you can check it out over here. Any feedback is of course much appreciated. If you wish to follow my other projects, you can follow me on Twitter as well.
Our team for the LD 30 Jam is still going strong, 15 hours to go. The game is about – you guessed it – connecting worlds by building bridges. The cultures that live on the worlds evolve based on the resources you provide them access with. Simultaneously, the evil enemy culture is growing without your influence, and your goal is to nurture the friendly cultures to a level where they can defeat it.
Can’t wait to see what everyone else has done with the topic! But first, the UI and controls have to be finished and the game be balanced. Also we encountered some interesting ideas and techniques which might make it into a postmortem.
- I only had 24 hours so I went sleepless. Too excited to sleep.
- The physics of the bird was the hardest to tweak. It still needs a lot of work
- Procedurally generated world.
- Fart poo noises was done by my mouth, not my bottom.
- Music was done with garage band
Playable here http://www.ludumdare.com/compo/ludum-dare-30/?uid=34676
The first night,since theme annuncied, here in Spain is really late, 2:30 am approx, i spent like 8h creating a mongodb server with php api rest to realise next day that it would take another two days to be implemented.
So, I moved to appwarp server for Unity for the first time after analyze all the other options like photon cloud, smartfoxserver etc
The demo was working, i added all the assets, and did some coding all the day until now, barely sleeped, the project got corrupted in a physics online loop in the editor and i was in pain, lucky me i recovered the files this morning and now the only part left is to finish some online mechanics and scores ,etc
Hud is done, also character motor and cool rendering with mirroring fx.
My first ever Ludum Dare! I was dared by a coworker to enter and make a game on Friday!
Enjoy playing Jacob’s Ladder here!
Jacob’s Ladder is an attempt at meeting my goals here.
I have had many successes through the last two days!
[x] Intro Splashes / Animations
[x] learned to make materials / textures / normal maps
[x] GUI Buttons
[x] city maze : Jacobs Ladder level
[x] Audio, Music, Sounds
[x] Secondary Main Menu / SubMenu
[x] how-to-play / controls / input
[x] footstep sounds triggered when walking
Didn’t get around to adding :
[ ] skybox
[ ] Cross Maze Level (from brainstorming session at start of LD30)
I surprised even myself on what could be done it such a limited amount of time. I learned a lot and can now add the scripts I created to a personal script library to use in other game dev projects!
Ludum Dare For The Win!