Welcome Agent Green...
And here we go, Red Cell: Agent Green is finally released on Itch.io!
Don't believe me?
Now you should!
It was quite the journey from simple gamejam entry for the Week of Awesome III to here, but I'm glad I stuck with it.
The game is now coop, has leaderboards (thanks Gamesparks!) and is a lot harder to deal with.
Hoping to add new modes in the future too!
See the whole story here
I won't take more of your time, until I actually add more to it.
(If you DO play the game, do drop me a line, I'm always curious to hear what people thing!)
Been a while since I took the time to write a proper entry, even more so in this journal (The Week of Awesome III was a summer 2015 gamejam entry after all). But today is different....
After building up my own freelancing business for a decade now, I'm more than happy to report than I've spent the last few months doing it fulltime, which is a lifetime achievement for me, and something I've been contemplating / building for a long time now.
But this entry is not about how great life is on the 'other side', but rather, about a very specific project.
A New "Death is Useful"
In 2015, I made an entry in the 'Week of Awesome' GameJam hosted here at Gamedev.net titled "Death is Useful" (which was also the theme of the competition). It wasn't my best entry as far as results go (I actually managed to score 4th position on both Week of Awesome II and IV) but I felt it was the one with the most potential to scale into an interesting game.
Some time ago, I even revisited the title with the intent of researching the 'new' and 'improved' WebGL exporter now bundled with Unity3D. Suffice it to say that, back then, I was anything but impressed with the results (as can be read in my previous posts). I chose to let the project to rest and resumed work on a variety of other exciting ideas (some of which you'll be hearing about soon-ish).
The WebGL Exporter Strikes Back (if you're not tech-savvy, you may freely skip ahead!)
By mid 2017, I was put in touch with the reps over at Unity through a client and ended up doing some R&D with the actual WebGL exporter and it had come a long way since I had last used it. So, little by little (working fulltime as a freelancer leaves very little spare time for passion projects) I ventured a bit deeper with the exporter, to see how I could polish & optimize the results.
I think a word on the state of HTML5 is in order here, as one might be wondering why anyone would even bother using WebGL to begin with:
I don't think there's 'one single truth', but I've been involved with a sufficient amount of projects through a relatively large client sample to know that, right now, HTML5 is 'popular', but it does not deliver. The reality is that there are few efficient engines to work from, meaning most projects end up being made up from scratch, or from a new unknown tech, making development very slow and costly. The problem is that HTML5 was meant to be the 'Flash killer', and as far as I can see and hear, it's simply not 'as fast' and 'as cheap' as making Flash games yet. I've been working with a lot of businesses that have tried and failed to make HTML5 a truly viable alternative, and so far, I'm unimpressed by everything I've seen.
I would not consider WebGL a true contender here either, had it not been from the fact that it was Unity's fallback solution to having the Unity Web Player blocked on major browsers (primarily Chrome), nor would I even consider it an alternative had it still been in the state I 'found' it in a few years back, but clearly, things have changed.
As developing in Unity (an established engine) is very fast, I was hoping to gauge how much time I'd need to invest in optimization and troubleshooting to make it work. Turns out that's roughly 10%, which given the alternative (HTML5 would've probably taken 2-3 times the amount of time it took to make the game in Unity, once again based on similar documented projects) is fairly cheap.
Let's face it, there are a lot of people out there wanting to make their digital presence felt (I'm thinking about industry giants such as Disney, Warner, etc.) and HTML5 is making a serious dent in their marketing budget to achieve these results, so I was somehow hoping that the WebGL exporter would be an 'easy sale' but needed one or more proofs of concept. Death is Useful was going to be 'it'.
The Return of Kongregate
Another 'question' I've been asking myself steadily over the past few years is whether the so-called death of web games was real. With the relative decay of Flash, I felt a lot of people had assumed this meant the end of web portals, and for the most part, I think this is somewhat accurate, and the short-lived Unity Web Player didn't really endure. Players have come to expect a certain level of quality in their web games, which HTML5 couldn't really do on a budget, so in theory, that death was inevitable.
On the other hand, some few key accounts from local and remote indie developers with whom I'm acquainted tested that theory. For obvious reasons, I'm not going to name names here, but the thought of turning up a profit of more than $ 8000 USD per quarter is certainly not something you'd expect from a 'dead' market. I understand a lot of developers couldn't justify a tech pipeline geared at web development for 'so little', but for the smaller teams, that's a very enticing offer. Though most of these revenue figures game exclusively from incentivized ads (ads that are tied directly with in-game rewards), I was curious about the demographics of the web games world in general and wasn't going to be very specific.
Kongregate was a platform of choice for this 'test', as I've been a member since 2010 (and a lurker for much longer) and also participated to the release of a CCG that became #1 at some point (even though it was merely a port from a different platform). Suffice it to say I was well acquainted with the platform and knew the opportunities there. Kongregate was unique in that it provided a very healthy ecosystem for players with some metagame implications.
All I needed was a project to test this platform, and it soon became obvious that Death is Useful was a perfect opportunity. Testing both a market and a technology at once may be risky, but I wasn't bound to any deadline, so it made sense.
The Red Cell Awakens
Death is Useful became 'Red Cell', rebranded after the decisively retro visuals and audio. I was born a bit too late to really experience the Atari and early Commodore days and always had a fascination for that era. I wanted to rebuild the game as something that would've fit a late 70s / early 80s arcade without limiting myself to the technology that existed then. The game concept was perfect for this, but the original perspective was fundamentally flawed as it was a 3D game. Besides, it wasn't really making great use of that 3rd dimension, so the switch was all the more valid.
It took some heavylifting to reuse what had already been done (quite honestly, I should've gone full tabula rasa mode) but it helped me appreciate the kind of legacy code game-jams can generate. I wanted to give the game a 'Super-Hexagon' feel, as something that's infinitely replayable and simple to grasp, where most games take but a few minutes to play. Super Hexagon had opted for longevity through more patterns, faster game speed, etc. Given I'm an avid speedrun fan (and have some reasonable PBs on some of the retro titles) I wanted to make a game that was finite in nature, but one where you could beat your own score repeatedly.
Kongregate was a great platform for this as they have a built-in score API which took some getting used to but was relatively easy to implement. Once I landed the 'best the game as quickly as possible' score idea, I felt I should also give other players an incentive to play, and added a few more score options (most mobs killed in a game, most mobs killed all time, etc.)
Kongregate has something called Badges, which are achievements you can earn in games that give you a boost in the Kongregate user metagame. Unfortunately, developers can't make achievements, they can only expose scores and hope the editor picks the game up and implements 1-3 achievements based on the scores already implemented. So having more scores (some of them invisible!) was my tactic for trying to get the editor's seal of awesomeness, and the potential traffic that goes along with.
I've developed the game on and off in my spare time for the past 2 months (alongside many other personal projects) and completed dev about 2 weeks ago. Given Kongregate has monthly contests, I figured I'd wait until the new month, and what better day than the one right before July 4th to release? (arguably, that release is very random, and I'm not quite sure how July 4 will play into monthly traffic).
The Last Build
All of this just to say the game was released today. It's not the most amazing thing on earth, but it is a fun minigame that has some potential (as far as web games go). It's also a business test I'm making on two different fronts (Platform & Technology) which, in itself, has a lot of value. As a result, I didn't see fit to make In-App Purchases, and chose to distribute the game for free (as in FREE free). I might get some minor revenues through conventional ads, which won't pay back for the time invested, and that's quite alright. I'm just glad it's finally out and people get to see it.
The game is currently open to more development. I had a local 1v1 and coop 2 player game modes which I've disabled right before release. They work, but I feel they should have a few more features before being worthy of the game (chance to revive your friend when he dies in-game, etc.) I have ideas, but limited time, and quite honestly, I'm waiting to see whether the game gets any traction before investing more time into it.
If you care to give it a try, here it is:
- Game Link -
So, I was really looking forward to export to WebGL, but it appears they call it a Beta for a reason! Turns out Unity's WebGL exporter is not where it needs to be just yet, so I'll give this one a pass, for now.
That being said, here's something that's been lurking in the back of my mind for a bit. At the end of WoA II, I had realized that my idea would've probably worked best using 3D instead of 2D, so I set out to do WoA III using 3D, but I'm having second thoughts about this.
Throughout the production, I felt I had much less of a grasp over 3D than I would hope for, and more importantly, that my game wasn't really a 3D game. Sure, cubes fall to their doom, but couldn't this just be closing walls?
After receiving today's scores (and being disappointed with mine for a number of reasons), I've started reading through the judges' comments, and a few of them listed items that were caused by 3D issues that annoyed me too during production. Add to this that I feel 3D really didn't add much to the game and you end up with a somewhat angry me trying to figure it all out.
In an effort to verify my claims, I've toyed with the idea of 'porting' the game as a 2D game instead. 2 hours in, I ended up with this:
Apologies for the accidental soundtrack, although kudos to whoever figures out the artist!
So, I can live with the low art score, I'm really not much of an artist sadly, and I chose to go at it alone, so shame on me! To a degree, I guess I can live with the theme score, though I didn't feel like I had cheated the theme.
What I'm trying to figure out is really these small points here and there that were lost either in gameplay or user experience because of poor controls. Jumping, for example, didn't add much depth to the game, but it being enabled, and the funky 3D collisions used by Unity ended up pushing the player way higher than it should, so I axed that by turning it 2D.
There's still a lot of tweaking and re-implementation to do, but I'm confident this will make for a better game in the end, and who knows, maybe 2D rendering will dodge most of the WebGL exporter's issues?
The thought of preserving my participation to this year's Week of Awesome (III) led me to investigate the new Unity 5 exporter to WebGL. My goal here is to try to port the game to WebGL and upload on a platform such as Kongregate to see how easily it can be achieved (and if at all lucky, make 25$ off ads woot woot!).
I've tried the exporter, fixing a few quirks here and there and ended up with this result in under 1h of work:
There's a lot of issues with my current implementation: - Performances (though this is currently built as 'slow' for testing purposes, and having tested fastest/optimized, I'm confident there won't be much lag and that I may even increase Physics refresh rate) - The 2D textures are off in the UI - That is, it seems like they're resizing to a different ratio despite being forced as 16:9. I need to investigate this further as it looks really bad. My hunch tells me UI anchoring isn't exactly working well in the exporter right now. Might need to make a non adaptative UI for this port (sad). - The 2D textures are off in the materials. This is the most concerning issue at this point as they're natively meant to skin the primitives and I'm really not sure what's wrong. I'm guessing WebGL export is not resizing the materials to scale which could be a major issue.
"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!) [spoiler] - 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 [/spoiler]
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] "[color=rgb(40,40,40)][font=arial]
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!)."[/font][/color][/quote]
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
Unity 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!
MVP 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!).
Testing 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!
Camera 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!
[color=rgb(40,40,40)][font=arial]Theme[/font][/color] 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).
UX 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
3D 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!).
Art 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.
Physics 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!
Time 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?
Sounds 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!
Day 5 Goals [color=rgb(40,40,40)][font=arial]
[font=arial][s]- Find a [/s]simple [s]solution to avoid Purple overcrowding[/s][/font][/font][/color] [color=rgb(40,40,40)][font=arial][font=arial][s]- Package the build[/s] and test it under various conditions to insure judges are able to play it![/font][/font][/color]
I ended up finding a solution for the Purple overcrowding, but it was nowhere near simple. There's now a system in place to gauge difficulty in the game and I'm happy on how it all turned out (as it effectively annihilates the chances of getting purple overcrowding!).
I've also made quite a few changes, namely, the platform no longer shrinks while there are no mobs on it. I felt it was a bit weird that it would, and I feel that rewarding a player for getting rid of mobs very quickly was a good test of reflexes.
I've also packages the build, but couldn't muster the time to test it under various conditions, so I'm assuming that Win7 is all that it needs to run smoothly. Crossing my fingers here! Not sure when the judging will start/end, but I won't be around to troubleshoot until Wednesday so I'm hoping judges can play the game!!
I've also polished some of the elements in the result screen, some of the mobs' values and even added a splash screen for the game title.
I'm rather satisfied with what I'm delivering after 5 days (with roughly 2-3 hours per day making this an under 15h prototype!) Wish I had more time, but definitely enjoyed every bit of it!
Will most definitely post a Post-Mortem after Judges scores are in, but for now, I'll have to be patient!
And for anyone interested, here's an updated video of the final game!:
- Rework the Result Screen visual.[/font][/color] [color=rgb(40,40,40)][font=arial]- Add two mob variations[/font][/color][/s] [color=rgb(40,40,40)][font=arial]- Find a simple solution to avoid Purple overcrowding[/font][/color] [color=rgb(40,40,40)][font=arial]- Package the build and test it under various conditions to insure judges are able to play it![/font][/color]
[color=rgb(40,40,40)][font=arial]It was supposed to be my final day for packaging... but a lucky turn of events allows me to be partially focused on this on Friday evening (yay!).[/font][/color]
As originally planned, I set out to rework the Result Screen, and it turned out a bit better (though still very bland).
I've also added 2 new mobs! (actually 3!!!) reusing some old ideas into better concepts. There's now... - a sub-boss that spawns 3 weak mobs on contact - a rail that passes through the level and pushes everyone to their deaths (which is very hard to dodge, but can swipe the plane clear of foes!) - a mob that fires bullets (don't let it!)
My wife also playtested my game, which revealed some of the controls / goals were uncleared, so I created a quick tutorial (with text overlay and a 'neutral zone' where the player doesn't feel under pressure).
Most importantly though, I've spent close to an hour reskinning all of the mobs with more interesting skins. The original abstract skin didn't make them very memorable, so I included quick sketches and played around them in paint.net. Some of them turned out good, others, well...
Overall I feel much better about where I'm at right now as I feel I cover UX a lot better and cleaned the scene of most 'ugly' options.
The only additionnal thing I'll do tonight is upload a safety build.
It's almost over!
Mandatory gameplay video of the progress made this far!:
DAY 3 (Wednesday) - [s]Art[/s] - [s]Sound[/s] - [s]Tweaks to the mobs[/s] - Setting the spawn order to a fixed order (to circumvent situations where I could have to deal with more than 1 purple at any given time)
DAY 4 (Thursday) - [s]Implement Splash Screen[/s] - [s]Implement Keyboard controls[/s] - [s]Implement Result Screen[/s] - [s]Create buttons (Quit, Retry, etc.)[/s] - Package the build and test under various conditions
EXTRAS - [s]Add controls panel (reminder)[/s]
Day 3 Progress
Day 3 was better than I expected... Art I knew I had little time and this was my one night to really get something going. After a few unfortunate attempts, I settled for a very abstract feel which I feel contributes to the athmosphere of the game. It wants to be arcade-ish and somewhat unsettling too.
Sounds This will be a love it or hate it spot for the judges for sure, but I tried to go for low-tech (generated waves in JFXR) and yet give it some flair, especially in terms of feedbacking everything right (when cubes fall to the ground for example). Even managed to put a very eerie sound in the result screen which makes death all the more meaningful. I can see why this might turn off a lot of people, but in my opinion, this is one of the big wins of day 3!
Tweaks to the Mobs There's been a lot of that, even a new Mob type! I wasn't too sure how to approach this item, but I knew I wanted to squeeze the fun out of the gameplay elements I had laid out and I felt I did a decent job of making them more interesting to face.
Setting the spawn order to a fixed order Sadly, I did not really have the time to truly assess this item, and to be honest, I'm not too sure on the fixed order altogether. That being said, I need to revisit the issue to at least prevent having two purples in play at the same time, at least, in the early stages of the game (on one attempt, I had my first 4 spawns be purple, which was simply impossible).
Implement Splash Screen A bit of a brain-dead operation I had originally planned for Day4, but actually started on Day2 (late evening). Made a simple fade in/out with more than 2 seconds on-screen as per the requirement, which is a small unknown out of the way!
Implement Keyboard Controls Week of Awesome II prepared me well for input management, so I only had to use the Input Axis management in Unity to quickly mirror controls from Gamepad to Keyboard. Took a bit to fine-tune actual scale, but thank Unity for the "sensitivity" value!! All in all, a well spent 15 minutes!
Implement Result Screen This one took a bit of time to implement and get right. There's a lot of hidden stuff in there, but it was part of my plan all along to create a system where there are two "endgames". I won't spoil anyone here though!
Create Buttons Simply added buttons in both the Game and Result screen to complete the flow (retry and quit). Simple but effective: I've lost points in Week of Awesome II (and learned a valuable lesson about game-jamming) based on having no reliable means to quit the game aside from alt-f4, thus, from a UX standpoint, I felt this needed to be added asap!
UX - Controls reminder Following the UX train of thought about quiting the game, I simply added a controls reminder on-screen as a placeholder. It is unclear whether I'll be able to have the controls show up on-screen as per my previous Week of Awesome entry, so this will most likely be the final implementation. It's really "out there", but at least it's there.
With so much of Day 4 done, I figured I might as well push my luck and try out a few things. All of the below were ideas I tried to implement and ultimately trashed: - Moving platform (rotating, etc.) - Originally started on Day2, and ultimately trashed because it was competing with core game elements. - Cylinder platform - Tried to make it better-looking (circular arena), but it seems that it would require a custom collider which caused issues with OnCollisionEnter triggers. By lack of time to fine-tune, shelved this. - Spawning new platforms on platform death - Felt it could be interesting but added a lot to the scope and I didn't feel I could get this done reliably within my own personal availability. - Multi-spawn logic - Tried it, thought it would be fun if, sometimes, instead of a single mob, 2+ would drop from the sky at relatively the same time, but it made the game very noisy design-wise and I chose to comment the feature out for now.
For Day4, I'd like to be able to: - Reword the Result Screen visual. I liked the texture, but it just doesn't work with text. - Add two mob variations (one of a larger Striker to force players to Jump more, and a mob with a custom AI that acts as a "striker shooter" which could really add some depth regarding positioning and target priority). - Find a simple solution to avoid Purple overcrowding - Package the build and test it under various conditions to insure judges are able to play it!
So it wasn't the Week of Awesome I was looking for. I had hinted originally that I might need to drop out due to work-related issues, and as it turned out, I had grossly underestimated this issue. To put it in my boss' words: I'm currently doing 3 people's fulltime job (on a single of my projects). Professionally, I put more than 60h/week just to try to get on top of the most pressing issue. Add to this that I'm ALSO freelancing with a few of my clients... But more importantly, health issues have been going from bad to worse, putting my in a position of constant nausea, headache, vertigo, etc. Sleep deprivation certainly won't help...
But I was looking forward to this year's competition after last year's, and I intend on delivering something even if its not as good as it should be. I already know I won't be able to work on this past Thursday evening, which WILL be my final delivery (eh...) so I had to settle for something simple.
Enough of that, it is called the Week of Awesome, so it's about time I put some 'awesome' back into this week!
"Death is useful".
Coming in, I knew the theme was a trap, at least for me. I've been toying with the ideas of pushing enemies to their death and turn them into gameplay objects for close to a year (as some might remember, my entry from last year allowed the player to permanently modify the gameplay beyond the player's death and I had originally planned to have a section dedicated to pushing obstacles off the board to turn them into helpful objects). I figured a lot of people would go down that route, so I went with something simpler, knowing that time constraints would allow for something simplistic only.
The core of my idea is simple: the player stands on a platform which is slowly shrinking. Enemies fall from the sky. You need to push enemies to their death so that the platform grows a bit and allows you a bit more survival time. Ultimately, all fall to their doom, but the victor is he who survives the longest.
Simple mechanics, simple execution, just needs a ton of well-balanced elements to work well! Of course, I have very little time, so we'll see how it turns out, and how much feedback I can implement.
Day 1 was very productive. I ended up figuring out the general concept and re-implement a camera system I had done barely a few weeks ago for another project. Since we are not allowed to re-use anything, I had to re-code everything from scratch, but the logic is pretty much the same overall (although a bit refactored given I knew what I was shooting for this time around). I did the camera (there's no deadzone yet, but it looks allright), the player/controller input (still raw around the edges, but works so far) and the basic enemy. So far, controller support is enabled (I used Logitech for testing, but I think it will map out differently on a X-box gamepad). Jumping and dashing (including charged-dashing) work currently, but have yet to be balanced.
On Day 2, I used the original enemy and created variations (the fast one, the tough one, the very tough one, etc.) and a simple spawner system so that all enemies don't start immediately on the board. I also added camera shakers for enemies based on their relative strength and allowed the platform to shrink/grow based on time and kills. I briefly toyed with the idea of having the playfield rotate around various axis, but given the fixed-angle camera, I felt it introduced too much confusion and generally led the mobs to their death as opposed to providing a challenge. On the bright side, it DID emphasize the use of jumping, but I think I can come up with a mob type that does a better job (if jumping becomes a meaningful way of dodging these crazy teal/cyan enemies!).
There's no denying that the theme is a bit bland right now. The Death of others IS useful in that it furthers your own doom, but there's little more to it. My original goal was to do top-down design this time around, but my availability to this project is too limited to risk that at this point, and I'll have to work with what I've done this far.
There's still a bit of Day 2 left to work on this, but I believe my health will prevent me to add to this today.
Plan for the coming days:
Day 3 (Wednesday) - Art / Sound (if any) and further tweaks to the mobs. Also, if possible, setting the spawn order to something slightly more 'fixed' (tired of getting Purples right at the start given how tough they are, and getting 3 of them makes it very tough to play).
Day 4 (Thursday) - Packaging the build. Adding the splash screen, and UI implementation (quit button, score panel). Delivery.
Last year, I took part in the Week of Awesome II, explaining the reasons why I chose to join. As I've effectively just determined that I'll be joining up for the Week of Awesome III, I thought I should set forth my goals for this year's competition, and revisit my original objectives.
2014 - The Week of Awesome II
HTML5 vs Unity I originally joined the Week of Awesome II in order to provide me with a short-term, time-boxed objective. I wanted to measure my ability to switch gears from HTML5 (DartLang) to Unity. In a lot of ways, my entry for the WoAII was merely me trying to figure out how the engine worked, and where it could be leveraged to promote gameplay ideas that I wanted to prototype.
In many ways, Unity is more powerful AND easier to use, but there are a few caveats that I was able to identify, namely:
- Physics - Innate physics (torque, force, etc.) are easy to tweak right, and more often than not, I prefer building my own (though using rigidbody and colliders).
- MonoDevelop - I still consistent issues using this code editor. It's clumsy and inefficient, and is prone to introduce errors. I've already expressed my discontentment so I'll leave it at that.
- SceneEditor - It's not terrible, but it's not great either. It doesn't feel at home when trying to put together tiled level designs and I'm not too fond of the pixel to point ration native importation settings.
All in all, Unity is still miles better than whatever engine I might have used previously, so I effectively migrated all of my projects to Unity in 2015.
Value A hidden objective I only realized as I started working on my WoAII project was that I wanted to measure my worth as a developer. In everyday life, I'm a video game producer, and I also freelance as a designer (game/level/economy) along with a few other responsibilities here and there (UI, UX, Bizdev, etc.) I rarely get to code a prototype for anyone else than myself and a few friends. WoAII gave me an opportunity to enter a jam (something with a deadline and audience) which is something I had not done in over 12 years.
The outcome of the competition (tied at 4th place) played a strong role in my growing motivation to pursue my prototyping efforts. I already knew when WoAII's final results came in that I was looking forward to this year's edition.
Judging This was a tiresome experience: there were too many games to review, and we, the judges, didn't want for this process to take 1-2 months, so we went the extra mile and stepped on our own time to get it done. I found that the judging experience, particularly using Slicer4Ever's guidelines, was a formative experience: it meant we had to clearly express why we thought a game worked or not. I think I was harsh on some of the reviews, but just because a gamejam is about fun, doesn't mean people don't want to learn from the experience, and I always feel like I grow more from harsher criticism than I do from people that say "looks good", so I chose to give out as much as I could.
That being said, this year, I won't be around the week after the competition, so I know for a fact judging is out of the equation as a result. Plus, I felt like ending up tied 4th didn't carry as much weight knowing that I was also a judge (even if I didn't actually judge my own entry and refused any form of monetary prize).
- Language: C# - Engine: Unity - Graphics: Paint.net (what a simple and effective tool!) - Sound FX: JFXR (Thanks to 0sok!) - Music: MTR (Midi Tracker) & Goldwave (for the export) - File hosting: My own website
What I ended up delivering:
2015 - The Week of Awesome III
Flashforward one year, my objectives have evolved. This year, I've gained some experience with Unity, and it's no longer about showcasing a tech demo + art of what I can achieve.
I want to make a game.
Sure, WoA II's entry (The Life of Phillip Morris) WAS a game in its own right: it was DOS Micromachines meets horror survival, but to be fair, Micromachines was labeled all over it and it did a poor job at hiding it.
This time around, I'd like to make something that's a bit more top-down, where the theme is more central than the gameplay idea behind it. I don't want it to feel like a reskin, and if required, maybe it can be inelegant design, but it needs to work for the theme first and foremost.
Last year, I was particularly fond of a text adventure entry where you would sneak out of a toy chest and venture out in a very grim world. I felt it did a great job at drawing the player into the experience, despite having very odd mechanics taped together (Text adventure with a clock and resources). I don't want to end up having that kind of game, but I want a similar thought process.
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!).
Therefore, this year's forecasted techs are: - Language: C# - Engine: Unity - Graphics: Paint.net - Sound FX: JFXR (if relevant, I'd like to sample my own SFX through Goldwave) - Music: TBD - File hosting: My own website
I'm apprehensive of the theme but looking forward to having a blast!