In With The New

The Switch

As many of our fellow indie devs may have heard by now, Epic made a pretty epic announcement (get it?) at GDC this year.  They’ve decided to release their newest game engine, Unreal Engine 4, to the masses for the low cost of $20/month, plus 5% of any gross revenue companies make from games made in the engine.  This is a really great deal for many indie developers, who often cannot afford to pay much up-front, but would gladly give a piece of the pie to Epic if it enables them to make their dream a reality.  And now Epic gets to enable thousands to start making top-notch games, all the while reaping some of the rewards of successful devs.  It really is a win/win situation.

View fullsize

UE4, in all its glory

Naturally, as soon as we heard this news, we were intrigued.  We immediately began looking into what UE4 has to offer (with our newest developer, Dan, taking the reins on that), and after a short period of several of us purchasing the engine and taking it for a test drive, we decided to make the switch.  Ever since, we have been overjoyed, and have already been producing much more polished work than in the past.

But, Why?

I know what you’re probably thinking right now.  “But Nick, you guys had already made so much progress with Xeno!  You were two weeks into development, and only a few weeks away from the first prototype!  Why on earth would you throw that all away to switch engines?!”  Let me tell you, dear reader.

Firstly, we were only two weeks into development.  In the larger scheme of things, this is not much time at all.  We plan on spending at least the next six months working on Xeno, in which case 2 weeks is only about 8% of total development time.  And when you take into consideration that we will continue working on other projects in the future, it just starts to seem silly not to switch to superior technology when it only costs 2 weeks’ worth of work.

View fullsize

Out with the old...

Secondly, the price structure of UE4 is vastly superior to what we were using (Unity3D), at least for us.  We were only using Unity Free, because Pro costs $1500 per developer, which for us would have been $4500.  As a new company with no major titles and no income, this comes directly out of our personal pockets.  While UE4 does as well, $60 per month is much more manageable than a straight $4500.

Thirdly, a lot of the functionality that we implemented into Xeno in its first 2 weeks is automatically available in UE4.  Networking is built in, an AI framework is in place, the sample code provides us with a basic first person shooter, and the list goes on.  So even though we lost work, and lost some additional time in the learning phase, we feel like we still came out ahead.

View fullsize

...in with the new.

Progress Update

So how much progress has actually been made since we switched to UE4?  Anthony has been hard at work reconfiguring all existing assets to be exported into, and look good in, the new engine.  The female XMSuit is all but complete, which is a completely new addition since the last official update (although if you’re following us on twitter, you’ve likely seen it dozens of times by now).  The starting room of the players has been redone in UE4, and looks outstanding.  It now has some creepy red ambient light, with the occasional point light to add some character.

View fullsize

Just look at those tusks!

On the coding side, the pistol functionality is mostly finished, with only some minor tweaks left.  It has three modes: regular fire, 3-round burst, and piercing shot.  There are some minor scripts placed in the test level as well, such as a door that opens as the player approaches, and some basic AI that is able to move back and forth, take damage, and eventually die.  These are all mostly from the learning period of the engine, and from here on out things should be getting much more exciting!

View fullsize

That'll teach it to taunt me!

Blueprints Page

And last, but certainly not least, we are happy to announce our new UE4 Blueprints page!  Here we will be periodically posting snippets of Blueprints that we are actually using in Xeno, in order to give back to the awesome community that has helped us so much already.  Please check out the page here, and provide us with any feedback!

View fullsize

The Blueprints window in UE4, with a bonus sample blueprint!

Thanks for reading!

-Nick

...And We're Back

It’s been quite a while (almost two months!) since our last official Verus Blog update, but rest assured that it isn’t because we’ve been dilly-dallying around.  We’ve been hard at work these past two months, finishing up Stratewarz and beginning development on our biggest project to date: Xeno.  But more on that later!  First, I want to talk a bit about something that’s (not so) near and dear to our hearts: Stratewarz.

Stratewarz: A Post Mortem

View fullsize

A brief overview of Stratewarz, code-named Shibe Warz during development, for those who are unfamiliar:  Stratewarz is a 2-player, turn-based strategy game in which each player equips their characters from the ground up, choosing their armor, weapons, and spells.  Players then enter the arena, where they take turns moving units on the game board, all the while unleashing devastating attacks on each other, until one of them has no more remaining units.  The idea is fairly straightforward.  We took a lot of inspiration from games such as XCOM and Dungeons & Dragons.

One thing that Anthony and myself have always wanted to do was make a post mortem from our games, as much for our own benefit as for everyone else’s.  This time, we finally sat down and wrote one out.  And so, without further ado (Bear with me, I’m terrible at building suspense), here is the list of things that we believe went right with Stratewarz, followed by those that went wrong.

What Went Right

1. Formal Design Meeting

Four of us (Anthony, Mike, James and myself) all got together and held a 3-hour meeting before we even touched any code.  This meeting was to determine game mechanics and each developer’s role.  This might seem like a no-brainer to those in the industry, but for us it was a new page, and a leap forward in our ability to develop.  We believe this initial meeting garnered everyone’s interest in the project, and helped us familiarize ourselves with the concept of the game, all the while ironing out some of the preliminary kinks in the game mechanics and overall vision that naturally arise.

2. Rapid Bug Fixes

Bug fixes were extremely rapid, because by the time we started playtesting, I had a very intimate knowledge of all parts of the code and could traverse it easily.  We had about 4 major playtest sessions in which Anthony and myself battled it out with one another, and identified a plethora of issues needing correction, which were resolved within a matter of days.

3. Refused to Give Up

Even though things got rocky only about a month into the project, we kept on trucking until the bitter end.  With previous games, we learned that finishing a game is as valuable (and difficult) a skill as starting one, and we didn’t want Stratewarz to become some unfinished project, doomed to languish on as an ever-present and awkward reminder of our failure in our minds.  A heavy ennui plagued the project after about the first month, with many developers eventually departing (mentally, at least) before Stratewarz was finished, but even still, we are immensely proud of seeing it through to completion.

What Went Wrong

1. Bad Planning

The game, as initially planned, was way out of scope, but nobody realized it at that time.  It was essentially meant to be a one-month project, and in the end took 5 months to complete due to a flagrant underestimation of task difficulties.  To complicate this further, one of the main developers left the project only a month into production. At this juncture, we would have been best server to reevaluate the game’s requirements and re-plan accordingly, but inexperience reared its ugly head and we didn’t.  Instead, we just kept on with the original plan, which again, was unfeasible even for the full starting group.  

2.  No Artistic Cohesion

There was very little cohesion in the artistic vision of the project.  We knew how the game would play, and what varieties of abilities and equipment the players would have access to, but we never discussed how the game would look.  Everything was done piecemeal throughout production of the game, with very little communication, rather than designed with a consistent feel ahead of time.

3. Bad Prioritization

The GUI was finished before the networking portion, or even the core gameplay, and this was a huge mistake.  As a result of this grievous mismanagement, we were unable to playtest the game until it was very close to completion.  Obviously the core gameplay is paramount, so by prioritizing the GUI first, we ended up shooting ourselves in the foot, so to speak.  In retrospect, the gameplay should have come first, allowing us to determine if we even should bother creating a GUI for it in the first place.  They say hindsight is 20/20 for a reason, it turns out.This is the opposite of how things should be done.  We should have had the core gameplay done before anything else, so we could see if the game was even worth adding a GUI onto.

In the end, we are still proud of Stratewarz, despite its somewhat problematic development.  It is definitely our most beautiful game to date, and that doesn’t even scratch the surface of the game’s complexity as compared to any of our previous projects. These are some of the extremely valuable lessons that we learned from Stratewarz, which we will be carrying with us as we move forward onto bigger and better things.  Speaking of bigger and better things…

The Future of Verus: Xeno

View fullsize

Xeno.  Two-player, co-operative, suspenseful action.  Work together with your teammate in order to achieve victory, rather than just playing the same game at the same time, doing your own thing.  Watching each other’s backs will be a necessity as you both delve deep into alien worlds in search of precious minerals to send back to the homeworld.

We here at Verus have always loved co-operative games.  And by co-operative, we don’t mean simply 2-player.  We’re talking about actual co-operation, where the players interact with each other and the game environment in novel and meaningful ways.  We’ve all heard the phrase “the whole is greater than the sum of its parts.”  We want to take that philosophy and apply it to video games.  That’s been our vision since day one, and now we finally feel like we’re ready to start implementing it.

So what will co-operation look like in Xeno?  Will it come down to you and your buddy standing side-by-side shooting at the same monsters?  Well, of course it will, if you want, but we hope to add a bit more gameplay complexity than just that.  So far, we have plans for the combat to be a fast-paced back-and-forth between the players. For instance, one player may use a shotgun blast to stun an enemy, at which point the other player can capitalize on the opportunity by swooping in and stabbing the enemy where it hurts.  We’re also planning on implementing robotic companions, so it’s a safe bet you’ll be able to set down a sentry gun, which your friend can then remotely control, decimating your enemies.  Is your teammate low on health? Not a problem with polarities, a feature that will grant a great boon to your companion in exchange for some small detriment to you. In this example, you’d be able to sacrifice some of your own health to fully restore your friend’s.  The idea is to create an experience where you’re working closely with your ally the entire time, doing everything you can to protect each other.

All of us at Verus are extremely excited for this project, and we’re only a week and a half into development and have already covered an exceptional amount of ground.  Mike has been hard at work crafting a sci-fi universe, one that makes sense scientifically (with some liberties, of course) and conveys a truly terrifying atmosphere.  Anthony busies himself with breathing life into all of the nightmares that Mike is dreaming up, as well as coordinating the entire creative process behind Xeno.  Chris has already composed the first draft of a really catchy song, and our newest developer Dan has made tremendous progress coding, having set up the basics of networking in under a week.

We believe we have an extremely talented and, more importantly, hard-working team.  We think we have a really fun idea on our hands here, and our hopes are that you, the player, will help us refine it (more on that in a later blog post!).  We so far have over a year of straight development under our belts, which in itself may not be much, but when coupled with our passion for creating interesting gameplay and our love of co-op, we believe that we have all the necessary skills to make Xeno into a truly engaging and ultimately fun game.

So stay tuned, for regular updates on Xeno and in the coming weeks, playable prototype.  You better believe we’ll be working around the clock to bring you the co-op experience of a lifetime.

-Nick

The Year of Verus

Happy New Year!

Well, it's been an entire year since Nicholas and I began work on what is now Verus Games.  Last year at this time it was little more than an exercise in making a video game.  We agreed on our first project, TimeGem, which ended up being nearly unplayable, but the important thing was that we finished it.  We didn't know that at the time, but it really was probably our most important lesson: Just Finish It.

After TimeGem we accomplished "a game a month" for two more projects, LightMaze and Calculated Risk, respectively, before moving our goalposts a bit further back and completing Spell Bound in three months.  Spell Bound, it could be said, was our first actual "failure," perhaps not personally (as we've had personal failures before) but professionally.  We invested a lot of time and as-then-accumulated technical and artistic experience into it, and it didn't do well at all once it was released.  Going back and playing it months later now, it is a very bad game, by the standards we've set for ourselves since.

At the turn of 2014, we're now at the tail-end of our "final" project, Shibe Warz, that Nicholas and I agreed would only go until the end of the 2013 calendar year.  When we began twelve months ago, you see, we agreed that 2013 would be the year that we dedicated specifically to "figuring out how it all works."  There would be no attempt at profit because, frankly, how can you profit from something you don't understand at all?  Don't get us wrong, we're not greedy and we have no aspirations of becoming a Triple-A industry titan, nor a multi-million-dollar Notch.  But we do have a collective dream of working on video games, GOOD video games, full-time.  We want to do this as more than a hobby.  We want to help add to the industry, to the unique experiences of all human beings like and unlike ourselves.  And the only way to do that in the manner that we wish is to ultimately be able to make enough of a profit in order to survive outside of development.

And so here we are.  We're very close to wrapping up primary development on Shibe Warz and to put it out into the public for beta testing, followed by bug fixes and polishing.  The Indie scene that is already growing around us has been hugely positive and helpful in our endeavor, and we're trying to be just as helpful as well, and we already have a mailing list for people who have extended their hand to help beta test with us.  And for that we are very grateful.

But as we inch our way into 2014 we are coming to a few forks in our path which only a year ago we never knew we'd be faced with.  How do we continue?  How does this business actually work?  There are so many people who want to work with us, especially considering we've "gotten projects done" and we have formed the infinitely-important habit of finishing things.  Who do we bring in?  Do we need this many developers this early in the business?  Do we even know how to make a good game?  What is our niche?  What are our strengths and our weaknesses?  How do we find them and understand them objectively?  What is our brand?  What do we bring to the "table" of the video gaming community?

These questions are new to us.  Really they're just a macro version of the questions we ask ourselves in everyday life, in the backs of our minds as we go through the world individually.  But once you form a dyad, or a triad, or a tetrad, these questions become immediate and overwhelmingly essential to answer if the group hopes to progress creatively.  We're really trying to answer them as best that we can, but 2014 will ultimately be our "proving ground," as we begin to explore our strengths, weaknesses, biases, and our ability to adapt to this strange new world in which we find ourselves.

These musings are all I really have to say for now.  The past few weeks, alongside both my day job and development at Verus, have been fraught with introspection.  Before I finish this first post of the year, I'd like to give you 4 things that I've learned through developing in the year 2013:

1.  Get It Done!! - Nicholas and I recently did an interview (yet to be published) wherein a question posed to him was "what's something important that you have learned through development?"  And "GET IT DONE" was his answer.  He is absolutely, 100% correct in this, and I cannot think of a better piece of advice.  The habit that you need to form; the ambition that you need to have even for the smallest project; the discipline that you need in order to keep your blinders on against all of the distracting things that try to get in your way... these must be developed.  The lesson that you learn through finishing your first project is more important and more powerful than any of the creative or technical lessons of the project itself.  I still remember how I felt upon completing TimeGem, and I have long-since forgotten anything I did for that crappy game.  I barely remember what it even looks like, but I remember the elation and euphoria of Nick messaging me "We're done."  That feeling sticks with you for a very long time, and it becomes a piece of the puzzle, it becomes a "drive" in every other project you do.  Not only do you want it to be fun, to be playable, to have this-or-that mechanic... but you now also want to get it done.

2.  Network! - Your goal in development should not be to make games for yourself.  That can be your goal, but don't expect any kind of social success if you only develop things that you can play and nobody else understands.  If you make games for yourself, then you're a hobbyist, not a developer.  If you hope to even have a glimmer of outward success, of having other people use what you've developed, then you need to start Networking with people online.  Twitter and Facebook are the two favorites of mine that I use, and beginning this year we will be expanding into IndieDB and a few others that I've only learned about through networking.  We have been introduced to really incredible people through only the few avenues we've been using so far, and cannot wait to be introduced to even more.  Every person we meet is a potential player, and likewise for everyone meeting us.  We learn something valuable from literally every interaction, and that is probably the most important part of networking.  You cannot skip this part.  Do it early.

3.  Failure is KEY! - On the television show Kitchen Nightmares, chef Gordon Ramsay often repeats his mantra "You learn from criticisms, not from people blowing smoke up your ass."  This is absolutely true in any creative or technical endeavor.  We have learned more from what we've done wrong with each of our projects than from what we've done right, and each successive game we've developed carries with it the marks of our previous failures.  You cannot be afraid of failure.  You must welcome it.  For the first few projects it is essential that you prefer constructive criticism (basically mini-failures, as far as I'm concerned) over praise.  This is the only way you'll begin to develop a self-critical thought process that will innately force you to look at creative and technical decisions from multiple angles, because you will no longer trust your first decision and you will begin to objectively self-check your own biases.  This is crucial.

4.  Love What You Do! - It is very, very important that you absolutely love developing, and that you love what you're developing.  We have had a few people slip away from helping us develop because they weren't as dedicated to the project as we hoped they were.  This is no fault or flaw of their own, but it's an unfortunate fact of working on a project with no financial reward or stability.  If you're doing something for free, then you must be in love with it, otherwise when more pressing matters come up involving financial decisions with your rent, or your day job, then those will take precedent over your project.

5.  Do NOT Give Up! - Especially when you're beginning your journey into development, it's very easy to lose hope in the first few weeks before you finish a project.  The lack of experience you most likely have is a huge part of the overwhelming burden on your shoulders.  But it absolutely does get better.  Take a look through our "Games" section and see how far we've come.  TimeGem was absolutely hopeless.  If we were to place our bets for the two know-nothings who developed that slop, we would surely be losing our money.  But we had hope.  We learned so much from it, and from each failure since, and we've developed a working confidence through it.  And if you stick with it, if you welcome failure and learn to finish your projects, if you fall in love with the entire process and with your individual projects, then you just need to remember to not give up.  I cannot promise social success, but I can guarantee an inward personal success that is not achieved in our common hours.

Thank you for reading, and I hope some of this helps you on your journey into Game Dev, or to better understand the journey if you're not actively taking part in it... yet.  Happy Holidays, and make 2014 one that charts a new path in your life.

~Anthony

I Dreamed a Dream of Devs Gone by...

Well we missed a week of updating last week, but I suppose there's a first time for everything.  And hey, if Ed McMillen can miss a week, I can miss one, alright?

Our hard deadline for content freeze in Shibe Warz development was the last day of November, which was about two weeks ago.  But we drastically underestimated how long development on certain aspects and mechanics would take, and due to a few other previously unforeseen circumstances that arose for one of our programmers, Nick and myself had to double-up on our crunch and extend our development of Shibe Warz into Mid-January.  We're also reverting to a "soft deadline" approach (or as I like to call it, the "Duke Nukem Forever" approach) for Shibe Warz, as we're no longer going to lie to ourselves.  All of this is giving Nicholas enough time to handle the rest of the coding workload and get a few office builds out to us in order to begin QA testing.  We've already overwhelmingly rearranged the game's GUI to be more user-friendly and intuitive but there's still so much more work to do.

This is definitely the largest and most comprehensive learning experience for me/us to-date.  Except maybe TimeGem which was our very first project, and taught us what it even means to "make a video game," which was an arduous and mammoth process from standing still to taking that first step.  That first step was like a leap off a chasm, but with Shibe Warz we're definitely catching ourselves and learning how to glide.  It's giving me, personally, a lot of appreciation for graphics artists in general, more than I had before even when I was knee-deep in other earlier work and knew less than I know now.

But I must digress.  There is more work to be done.  Rest assured there will not be another lost week of dev blog updating (remember: Every Wednesday!).  Stay tuned for more updates on Shibe Warz and Verus as the days progress, and be sure to follow us on Twitter!

Thanks for reading, and keep playing!
~Anthony

Shibezgiving

It's been two weeks and I'm still eyeballs-deep in artwork for Shibe Warz as well as pre-pre-development for our next project that we're primed to start in January 2014.  So with this in mind, bear with me that this blog post will be brief and will include (FINALLY) some more much-needed screenshots of what I've been working on in the Art department.

Firstly, I'd just like to say that I've never had more respect for animators and, even further behind-the-scenes, animation riggers, than at this point in my life.  Animation is a huge deal, and a very huge burden if you're not familiar with the ins-and-outs of its technical mechanics.

This is a shot of my Blender window with the main (and regrettably, only) character in Shibe Warz with a weight-painted rig.  I'm currently highlighting and moving his left arm into a position for a single keyframe of an Idle animation.

I've fallen in love with every single aspect of video game art, and find myself wishing that I'd been dabbling in it for the past ten years (which I will probably forever refer to as my "lost decade").  I have several mountains of knowledge to gain with respect to Art in gaming (and Art in general), but what I've learned through hands-on experience has been exquisite and absolutely invaluable.  I highly suggest getting your feet wet and your hands dirty, and downloading the freeware Blender for starters.  There are tons and TONS of tutorials on YouTube and BlenderGuru.com for you to peruse at your leisure and learn the ins-and-outs of the Digital Art world.

View fullsize

I really do enjoy all aspects of game Art, but before Shibe Warz I never really took any time necessary to fully appreciate how much work goes into character modeling.  This character you see here was blocked in very roughly (and with an ultra-low poly-count) in Blender before being exported to the freeware program Sculptris.  In Sculptris, I was able to subdivide the polygons on this model several times, giving it tons more polygons and myself the ability to add a lot of detail to the body and musculature.  From there I exported it back into Blender and built the armor pieces from scratch around the body, exporting the UV's to the freeware (spot a pattern...?) GIMP and making the textures from scratch.

View fullsize

 What you see here is the finished Plate Armor set rigged to the original body and ready to be inserted into the game (complete with the Idle animation from the first image above).

Over the course of the past two months, I've probably stared at this main character and all of his equipment sets a grand total of 75% of my contributed dev-time.  I'm absolutely sick of looking at him, but I regret that a game developer's work is never done.

View fullsize

 I was fortunate enough to have found an artistic understudy who has taken the time to work at my house every Monday for the past two months.  He worked exclusively on the weaponry in the game in order to get his feet wet firstly with Blender and 3D modeling, and secondarily with game development in general.  The axe you see in this screenshot is his handywork.  You will also notice some artifacts present through the armor.  Those will be dealt with summarily, but I must continue to move onto other more pressing things at the moment.

View fullsize

This is an example of what you can do with weaponry in Shibe Warz.  Each hand is able to hold onto a different weapon, and on your turn each of your characters can use one of their weapons' abilities on the battlefield.

View fullsize

The same goes for this picture.  A dagger in one hand (which confers X2 damage if attacking an enemy from the rear) and a crossbow in the other (which fires 3 times in one turn at up to 3 different enemies on the battlefield).  The armor he's wearing is leather armor, with moderate physical damage mitigation and light movement penalty.

View fullsize

 You can also mix-n-match helmets and boots between equipment sets.  The weapon you see in the character's left hand is the Wizard Staff, which confers huge bonuses to spells cast.

View fullsize

And finally, this is the preliminary animation still for the Longsword swing.

I hope this has been somewhat informative for you, and that it's something you can take away and get excited about for the upcoming turn-based tactical strategy game Shibe Warz, coming soon from us at Verus Games.  We're very passionate about video games, video game creation, and our players.  Stay tuned for more info from us and be sure to check out our other DevBlog articles below, and our Games section up-top to see how far we've come!

Thank you for reading, and we hope you have a good holiday if you're celebrating in any way.

~Anthony, Creative Lead

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!

~Anthony

Morning Routine

It's after 4 am and it's difficult to go back to sleep. Our development cycles have become more intense as we begin to round the curve of "adeptness" for each of our skills. But becoming decent at development (aka. Sucking slightly less each cycle) brings with it a new set of challenges to overcome and responsibilities to be aware of. The better you become at something the more you naturally have to take care of. We gladly welcome the new set of pros and cons with open arms, as this is the path we set out to search, but the pros and cons are there and they are objectively existent in the universe before us. Another project, another set of hurdles. The more we overcome, the more we can overcome.

Our new development project, code named "Shibe Warz" is a turn-based strategy/tactics game that will be available for PC s by the middle of December. It will incorporate full 2-player competitive networking support so you can pit the characters you've perfected against your friend's favorite selections. The idea of Shibe Warz is to allow complete and utter customization of each of your characters on your side, including weapon loadouts, spell selections, armor and helmet selections, and even tertiary "one time use" items, all of which are dependent upon an overarching "point buy" system. You do not select a "class" for each of your characters. Rather you build your team from the ground up. Do you want a fully-armored spell-slinger whom also has a dagger capable of inflicting massive amounts of damage from the opponent's backside? Spend the points and equip him thusly. Do you want an extremely mobile, armorless healer on your team, incapable of offense but with the balance of having ridiculously powerful healing spells for the rest of your team? Done, with the right loadout combination.

We're very proud of what ideas we've put into the design of Shibe Warz so far and as of the time of this writing all four of us here at Verus are already knee-deep in developing the vision. I've completed the foundational "board" which will be placed surreally but effortlessly into each environment of the game to add a richness and depth to the combat experience. It's similar in style to a chess board, but is comprised of many different interchangeable textures like stone, grass and dirt, etc., and can be resized by the players. The default board size is 10x10, which is a decent amount of room to maneuver within, but much larger, and much smaller, sizes can be selected.

I've also completed the asset list for the Forest environment, including all trees, rocks, saplings, logs, grasses, ferns, etc. We will build the world at the very end of development, but I'm particularly proud of the asset workflow so far, as it allows me to significantly decrease the amount of polygons in the game compared to previous projects, while still maintaining a high level of fidelity in the textures. Not only is this level of captured detail important, but the assets I make for Shibe Warz will carry over directly to our next project (which we have already begun designing), thus saving me time in modeling. I cannot wait to keep working tomorrow.

It's a very, very exciting time in my life now. Never have I worked harder on something with such results. Verus has a great team full of promise, respect, and work ethic, not to mention incredible collaborative skill. This cannot be iterated enough.

Thanks for reading and thank you for playing.

~ Anthony