On Deadlines...

Our development cycle has been very heavy these past few weeks, and I'm currently neck-deep in artwork so I'll be rather brief with this blog post (for your sake and mine).  I've been told on more than a hundred occasions that I'm rather... "wordy," and I'm trying to work on that.

When Nicholas and myself began developing our skillsets (and I mean "from scratch" in every sense of the phrase), it was he who pushed the paradigm upon both of us to emphasize the practice of our ability to "meet deadlines."  I was very much against this.  Deadlines, from the outset and almost by definition, limit your ability as a developer to add content.  Before you set a deadline you must first establish all of the parameters of the game that you're developing.  A deadline, for the most part (unless it's a "soft" deadline) is ironclad.  Limiting my "freedom" to develop content, as I believed this early-on, upset me quite a bit.

But there are two things that I came to understand upon completing our first project, TimeGem, and understand much better with each subsequent project:

A.)  Deadlines help you to finish your project.  It may not seem obvious, and perhaps a little counter-intuitive, but establishing a stop-point for your work actually causes you to push harder to achieve your end.  When you can see the "end" ahead of you and rushing toward you, you instinctively feel a need to complete as much of your work as you can before it reaches you.  It's really an awful lot like "evolutionary pressure," which causes creatures to adapt to their situations and surroundings due to the inability to remain stagnant and "free" in the total sense.  Because you feel the pressure of the deadline, you learn to cut corners (also known as "efficiency") in order to reach your destination product.  This can be either detrimental or beneficial for particulars, but it *gets the job done* which is always better than not getting the job done.

An example of this was the satisfying end-result of our one-month deadline for Calculated Risk.  Both Nicholas and myself felt an immense amount of pressure from Day 1 to conceptualize, model, texture, animate, code, and dress the entire game.  It was also the first time we started using Trello Cards to aid us in plotting our course, and that simple addition literally changed the course of our development and even our lives.  We were able to individually categorize our workloads for the entire month and work on them as though they were individual "quests" in an RPG, moving the marked cards (with, say, "Model the Monsters" as a particular job to complete) "from "backlog" to "In Progress" when we were working on them, and further into the "Finished" column when we were done.  It was brilliant, and even a little bit fun(!) to follow development this way.  And we were very happy with how Calculated Risk turned out as our 3rd project.

To contrast this example, our 4th project, Spell Bound, which we released for the Android system, had a much longer deadline than we needed it to be.  We gave ourselves 3 months when, in reality, it only needed 2.  We knew this going in but we allowed the deadline to slack because we thought it would help us relax a bit.  It did help us relax, but it was detrimental to our development.  What we should have completed in a few days, we let drift into two weeks, and each of us did this multiple times with some of the particulars of our workloads.  After examining our course throughout the project we both agreed that our slack was directly attributable to the lack of a firm deadline.

B.)  Deadlines mitigate scope creep.  This is self-explanatory because, by definition, a deadline effectively plugs all further development input once you set it.  You can alter things within your scope, but if you add mechanics or assets, then you're going to either increase your deadline or increase your pressure within that deadline.  It is possible to add scope, but it's a very, very delicate procedure.  Being "Independent" from publishing houses allows us to set our own deadlines, or none at all, but we have found that setting hard deadlines in the first place allows us to learn what to throw away and what to keep in our workloads.

This is, by no means, a definitive method to establish deadlines in your project.  This is only what an up-and-coming, currently-amateurish, independent development studio has learned in the past ten months of dedicated development.  Other, very successful developers like Ed McMillen of Team Meat prefer to work outside of hard deadlines in order to allow their admittedly learned expertise the freedom to create.  But this early in our own history, we at Verus Games have found that starting hard gives us the exercise we need to hone our skills, both technical and creative.  And most importantly, it is absolutely responsible for the fact that we can complete our projects in the first place, which is paramount to personal and professional success.

There is probably nothing better than holding a completed project in your metaphorical hands.  Something that you've had a hand in making, and something that you're proud of.  Deadlines helped us through the trying times of initial development.

Thanks for reading!