Jump to content
  • entries
  • comments
  • views


Sign in to follow this  


The Week of Awesome?

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.

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.

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).

Last year's originally planned toolset:


- Language: C#


- Engine : Unity


- Graphics: Paint.net / Possibly Tiled


- Sound FX: Goldwave / Possibly freesounds.org


- Music: Goldwave, Audacity


- File hosting: On my website


Actual techs used:

- 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!
Sign in to follow this  


Recommended Comments

I've seen so much complaining about MonoDevelop that I never even tried it when I started learning Unity. I just made it use Visual Studio instead. I also found an auto-save script that saves the scene and project every time you run. Never* lose hours of work again! smile.png


Put this script in Assets/Editor/

using UnityEditor;
using UnityEngine;

public class AutosaveOnRun
	static AutosaveOnRun()
		EditorApplication.playmodeStateChanged = () =>
			if (EditorApplication.isPlayingOrWillChangePlaymode && !EditorApplication.isPlaying)
				Debug.Log("Auto-Saving scene before entering Play mode: " + EditorApplication.currentScene);


Good luck in the Week of Awesome III sir!

- Eck

Share this comment

Link to comment


Would've been useful yesterday when I tried to do something... stupid... just to see if it would work!

(Crashed Unity big time).

Share this comment

Link to comment

Yeah... I had a couple of endless loops the first time I started playing with my pathfinding in unity, that script would've been handy.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!