Jump to content
  • Advertisement
  • entries
  • comments
  • views

Post-Mortem on "Death is Useful"

Sign in to follow this  


About the game

"Death is Useful by Orymus" is a game developed exclusively for "the Week of Awesome III" gamejam event (#gdnjam).

The player is prompted to play as a nameless protagonist (sphere) and survive an onslaught of enemies (cubes) which are trying to push the player off a shrinking platform. By pushing opponents out of the platform, the player is able to force the platform to regrow, and furthers its own survival as a result.
The game is theoretically endless, but the player is left to pursue a few micro-objectives within the game (SPOILER ALERT!)
- Scoring above 200 pts (or even 300) returns a favorable descriptor in the result screen
- Dying progressively reveals a hidden message (which links back to the competition's theme)
- Getting better and scoring higher

The Week's Over!

Much like last year, I'd like to preface this post-mortem by thanking Slicer4Ever which, once again this year, came through with the organization of this event. I don't have numbers, but I believe there's a higher attendance than last year, and at the very least, the prizepool has increased by quite a margin! But more importantly, I believe that the information has flowed even more clearly than last year (which was already great). There's no denying this took a fair amount of time to put together, so kudos where due!

I'd also like to thank all the participants. I have yet to play another contestant's game (I was away for a few days) but something tells me the bar's height has been increased this year and I can't wait to play other entries!

Today, I'm coming back home after having to cut this week a few days short (I had to complete my entry in under 5 days for personal reasons). With only a few days gone since my final submission, I'd like to gather my thoughts while they're still warm.


I originally had set myself goals for this year's competition, but these had to quickly change given I wouldn't be able to give as much time to this as I had originally hoped.
For starters, I was hoping to be taking a week off for this, but changing job earlier this week prevented me from doing that.
Furthermore, given the limited amount of holiday I would get this year, my wife insisted that we take this time as a family: I've been doing crazy weeks the past 2 months and my wife and kids barely got to see me, so I felt this was not an unreasonable demand.
Add to this that I've been struggling with health issues the past few years, but moreso the past few months. Sleep deprivation was the one thing I simply couldn't afford.
I ended up having approximately 12-15 hours of time I could put towards making a game for this competition, which was significantly less than the 25-30 hours I was shooting for originally.

My original goal was to make a top-down design game where the theme would be the core and everything would transpire this, not as a complex set of features that work well together, but rather, as a holistic design piece which felt alarmingly accurate for the theme.
This particular goal could not be met with the amount of time I had to dedicate to design, so I had to drop that altogether very early on (start of day 1 in fact).

Another goal expressed in my original post was to avoid making something that felt too much like a clone of something else. My previous entry (The Life of Phillip Morris for the Week of Awesome II) looked like an old DOS game and though I felt I did a good job with it, I also felt it was a bit unimaginative.
This year's entry was a concept I did not borrow from anyone: it is entirely possible that it exists some place else, but it naturally evolved from my making for this competition. The only thing I can vaguely connect to this might be Smash Bros, but I'm not an avid fan (played only the one on n64) and there's only really 1 mechanic that is common to both games, and theirs was in a 2.5D perspective.
I feel I've done a rather good job at staying as original as possible under the circumstances.

My last goal was a bit ambitious:[quote]

And if at all possible, despite any potential participation growth, I'd like to do better than I did last year. That means, top 3 is my target, and I realize that may be over-ambitious given the amount of hours I'll need to sink into it (knowing how real life events are going to be a pain around these dates: MILESTONES!)."


Back then, I didn't know just how much time I was going to put into this competition, so I was thinking big, but in retrospect, it would feel very naive to hope to achieve top 3 with such limited effort compared to what others have had to work with: sleep deprivation or holidays allowed people to sink more hours, and most teams are not one-man-armies.
Without consideration to how many participants actually delivered something for this competition, I'd still love to be part of the top 25%, but as was made abundantly clear, the breadth of my concept may not 'cut it' for some of the judges.

What Went Right

Last year was my first attempt at using Unity 3D. It was interesting to see how far I've come in a year using this tool despite having worked only sporadically in the editor. Some of the tasks that took a fair bit of time the last time around were easy to crunch through, and I felt that mu better understanding of the environment made this game possible under 15 hours: Gone are the days of broken 'BroadcastMessage' all over the place!

One of the key 'wins' here is the use of the InputAxis, as per last time. I've basically built my game for a Gamepad using these, and ported it to Keyboard controls in about 15-20 minutes including tweaking actual input values. Walk in the park!

Though I ended up delivering game code that makes no sense (at some point I've had to copy an entire script into another knowingly of how ridiculous this was) Unity was certainly not the reason for my sudden spaghetti code spree!

I'm glad to see that what paid off last year paid off again: by day 3 I had the bulk of the game loop working, getting me out of panic mode and nudging me in the 'polish' direction instead. I wanted to deliver something, and by day 3, I had a realistic plan to do so, and as such, it was easy for me to simply polish the game as I went (skinning the primitives, for example, was not originally part of the plan!).

More than 75% of the time spent in making this game was actually spent running the build and testing it. As a result, there are a lot of things that don't work well in the game, but very few of which I'm not aware of.
This gave me a clear outlook of the level of polish I was delivering at all times, and an idea of how much 'fun' the core gameplay was.
I've spent more than 20% of the time remaining just tweaking the fun factor (spawn rates, shrink rate of the platform, etc.) to make sure I was making the most out of each system, thus minimizing the amount of time spent developing new features and hoping for better score on execution. My rationale is that good gameplay arises from fewer features that are well executed, rather than more unfinished or unpolished features.
Though the game may come across as somewhat naked, it should feel a lot tighter on controls than last year's entry!

I had not seriously considered working on a complex camera behavior in a 3D environment before, and so I decided to make something simple and efficient. Overall, I feel the Camera 'does the job'. It's not spectacular, and sometimes, it may be misleading as far as perspective goes, but I think the angle and follow behavior applied to it supports the game well enough.
Considering the camera script took me under 20 minutes to pull off, that's a big win for one of the 3 Cs!




I think the theme was forgiving, but it was also a trap. Overall, I didn't feel particularly challenged by the theme because it was easy to be 'on-theme' (it was very vague).

I felt it was a trap because, while one could make the player's death useful, I felt it wasn't particularly fun to ask the player to kill itself for the game to progress. At least one other participant found a good way to bend this in a way that appears to be fun, but from my standpoint, it felt like the easy way to hit on theme, but fail on fun.

Rather, I chose to interpret the theme as 'the death of others is useful to you' and pitted the player in a survival standpoint. The player is simply tossed in an arena and must push the others aside to survive. Note that there's actually no physical harm done per se (no concept of life points, etc.)

I feel that my somewhat abstract implementation of the theme could work in a variety of less abstract interpretations, but willingly chose to leave it 'as is' given I'm a big fan of such games.

I also felt that I could use my game loop to explain how I felt (as a designer) that death was useful within games in general (see top of post spoiler for more info on that).

I think a lot of what I did this time around was a result of what I hadn't done last year. Simple additions such as a Quit button went a long way, but a structure tutorial seemed like out of scope until it didn't. Playtesting with my wife showed me the urgency of adding 'something'. I quickly created a dummy mob (with no movement AI) and tutorial sequencing and ended up with much better results!

What Went Wrong

Unity is a powerful engine, and it is well made, assuming the user has some base knowledge about what they're doing. Of course, when said user tries something they've never done before (say, 3D?) it doesn't take long before that user is met with heavy resistance not because the engine lacks support, but simply because the user lacks experience. This was the case here.
Of all the games I've developed or worked on, very few were actually made in 3D, and of those that were, I was never part of the programming team. This left me with minimal understanding of what goes into making a 3D game work from a developer standpoint.
Sure, I can create primitives and use 3D physics (that's pretty much EXACTLY what my game is) but I'm afraid I don't have much to offer as far as 3D production is concerned.

At some point, I considered making 2.5D gameplay with actual sprites displaying over invisible 3D objects (which is a tech I've already attempted a few weeks back with much success). That being said, I knew on day 1 I would not have enough time to make sprites that were kickass enough, and I was afraid on making a physics-centric game where the collision might have looked awkward as 2D sprites. I chose to go all 3D.

Since I didn't have any tools to create models (Blender not being installed over here) and that most of my 3D experience dates back to the 90s, I started prototyping with primitives and never looked back. In hindsight, this might look a bit too prototype-ish and having actual mob shapes that are recognizable to the player would've been worth the extra effort (if only I had the know-how!).

As per every year then, the artistic side of the project lacks severely. Not only did my 3D skills suck so bad I was stuck with primitives, but I also lacked the ability to make good-looking materials for these. Thanks to paint.net, the game is not entirely horrible, but it's still rather poor, and, compared to last year's, I think this is actually worse.

Unity's physics engine is weird. It appears that, depending on which tick of the CPU I land a collision, the outcome can vary significantly. I've isolated a few edge cases where a given collision would return a velocity that simply made no sense, and was unable to find a suitable way to contain these inaccuracies engine-side.

Up to now,I had only heard rumors of Unity's poor physics, and it is interesting that I was then faced with this untamed beast. I have yet to determine an action plan on how to fix this in my future projects, but at least it got me thinking of ways to handle this.
At some point, I implemented a forced Vector3.zero catch-case, but the outcome was too artificial. I've also delved into 'faster gravity decay' solutions, based on certain conditions (velocity above a certain threshold value) but nothing quite well enough, and ultimately I felt my time was best spent elsewhere.

The result is that it is possible to push an enemy, or the player, so far away that it can actually move over 1000 times further from the center than it can actually jump or dash (ugh!!). This can theoretically lead to a game lock in the tutorial if such a collision occurs then and the mob is pushed away from all triggers (I have experienced it myself once).

Definitely keeping this limitation in mind for the future as I'm trying to avoid to make my own physic for every project!

I'm starting to sound like an old record, but time was an issue this year, and a big one at that. 2 days short, and several hours fewer per day meant I couldn't realistically deliver a game worthy of the time we were allowed to take.
I'll need to carefully determine whether I'll be part of a Week of Awesome 4 event given the circumstances, or perhaps join events that are a single day long?

JFXR is still my go-to solution this year, and it has done a decent job of turning a muted game into something with sufficient feedback. To a degree, I'd say some of the SFX I've pulled off even sounded decent, but the truth is that I'm unmistakably finding myself searching for an audio-off button in my own game.
I think I've done better than last year as far as sound is concerned, but unlike last year, I did not add a musical track (time!) so it evens out.
Audio is something that needs more of my love in future projects, especially as I like to consider myself an accomplished musician and sound designer!

Closing Words
All in all, this was a very fun event and I'm satisfied with what I'm delivering: when considering the 12-15 hours I've actually spent doing this game, I find that the amount of gameplay, visual, audio and sheer fun (balancing/tweaking) I've put in this prototype/game is a lot (some of the programmers I work with that are handed similar tasks don't do nearly half as much!).

It gives me renewed hopes in my capabilities as a one-man-army, but it clearly demonstrates my need for a team-mate for the long haul.
I've spent the last few months toying with the idea of partnering up with a jack-of-all-trades artist and this post-mortem seems to reinforce that approach. I'd sure love to pair with someone local though, so who knows who I might end up finding here!

I'll leave you with this:

Sign in to follow this  


Recommended Comments

That was a rather interesting read, I found! Thank you for sharing these thoughts. ^_^


I am curious, if I may: what was your original idea? It sounds as though it might have been quite interesting, based on what little you've said!

Share this comment

Link to comment
great read orymus3!
I particularly like this quote:

good gameplay arises from fewer features that are well executed, rather than more unfinished or unpolished features.

I think alot of developers should keep this in mind when creating something.

Share this comment

Link to comment

Furthermore, given the limited amount of holiday I would get this year, my wife insisted that we take this time as a family: I've been doing crazy weeks the past 2 months and my wife and kids barely got to see me, so I felt this was not an unreasonable demand.[/size]

You made the right call sir. Being a good father and husband was the way to go. The entire house needs to be on board for the Week of Awesome, otherwise it won't be a good experience for anyone. smile.png

great read orymus3!
I particularly like this quote:

good gameplay arises from fewer features that are well executed, rather than more unfinished or unpolished features.

I think alot of developers should keep this in mind when creating something.

Agreed! I played all the entries this year and some teams went way too big for 1 week of time and it really shows. Even though you only put in 15 hours your game looks way more finished than several entries.

Without consideration to how many participants actually delivered something for this competition, I'd still love to be part of the top 25%, but as was made abundantly clear, the breadth of my concept may not 'cut it' for some of the judges.

The competition was really strong this year and there were a lot of great entries. In my scoring, you beat out 12 other entries with only 15 hours of work which really speaks towards your skills. I'll send you a link to my review journal so you can check out the competition and take a look at the spread sheet.

Share this comment

Link to comment

Yeah, Unity Physics.  It's great for incidental stuff, a real pain if your gameplay relies on it.


Anyway, the really short story for quick and dirty attempts to make the physics run better:

In Unity there is a setting for how often the physics is updated, the default is not good enough if you rely on physics.  You can also up the solver iteration count in settings->physics somewhere.  And you can also do that on a per RigidBody basis, so for example, the player can be set higher.



EDIT:  Did you consider trying to grab any of the free stuff from the Asset Store?  Even just using the free assets that Unity provides can help a bit.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!