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

Of MUCK and Men

This week I decided to keep things short and sweet, and talk about something near and dear to my heart: MMOs and sandboxes!

To start off, I've been out of the development game for a couple of weeks now, mostly due to the holiday, so I don't really have any Shibe Warz updates to give.  Anthony has been hard at work on the art lately, and has been pumping out some really great assets.  I'm really impressed with how far he's come since our first project one year ago.

Speaking of being impressed with how far things have come, I played my very first MUCK today (and by played, I mean mostly fooled around in).  For those unaware (like myself), a MUCK is pretty much a MUD, a Multi-User Dungeon, and is the precursor to MMOs.  The ones that I played in had no questing or leveling system, no equipment system, and in fact were completely text-based.  They existed simply to provide a space for players to meet and roleplay in.  You navigate throughout the world using commands such as "go north", and are then presented with a wall of text describing the location you just arrived at and any points of interest.  This might not sound like much of a game at all, and is really just more of a sandbox for the players to fool around in.

In retrospect, I am very surprised that I had never touched a MUD before in my life, considering I spent the greater part of 4 years of my childhood playing EverQuest.  Within only a couple of minutes of playing a MUCK, I could see the overwhelming similarities between the two.  Emotes, whispering to characters, going out of character (OOC), traveling the world just for fun (and not for a quest), the list goes on.  It's really more of a sandbox than a game, and personally I think that is a large part of what made the first EverQuest so wonderful.  It had its quests, and it had its big bosses, and obvious things you should be doing, but the things I remember most of that game - more than 10 years later - are the times that I took the rules and did something unconventional with them.

For instance, I played an Enchanter in the original EverQuest, and one of my character's abilities let me transform into the nearest object.  Often this was a tree, rock, torch, etc.  I would stand outside of one of the most populated "newbie" towns (Freeport), turn myself into a cactus, and then shout, for all to hear, "First person to find me gets 1 platinum piece!"  This was a huge amount to a character just starting out, and I received no actual reward from doing it.  Yet I loved it, and I did it multiple times, and it's one of the most memorable parts of the game for me.  I had been on raids, run dungeons, did almost all there was to do in EQ, but I can barely recall any of those adventures.

Without sandbox elements, none of that would have ever been possible in EverQuest.  And that's basically all MUDs are, are sandboxes that allow the players to invent their own enjoyment, rather than go on endless pre-made quests and slay mob after mob.  It takes a lot more investment on the player's part, but can have a much higher return as well.  It can create lasting memories that designed games have a more difficult time doing.

-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

Video Games: Why?

Chances are, if you are reading this, you like or even love video games, or at the very least, you can appreciate them. If you accidentally found this post by mistake, I still invite you to stay and read about why video games are so popular. For you gamers reading this, I expect you’ll already know what I’m presenting, but perhaps you never quite thought about it in this manner.

Why are games fun?

So why DO we love video games so much? Why can we spend countless hours in a virtual world tirelessly? A quick but naive answer would be, “because they are fun!” But what makes them fun? It isn’t just one thing, and there is no one size fits all for games. I know personally, I enjoy games that offer a great story with good three dimensional characters and a deep plot. Others, such as Anthony and Nick, prefer games more as a test of skill - something easy to learn but difficult to master separating the men from the boys, so to speak. For some, it is the element of competition between human adversaries, such as those who play League of Legends. I could go on, but the bottom line is: video games mean something different to each person.

Are there any common factors between all of these different interests? What aligns them all in a way that allows us to neatly package the whole experience as, “yes, I like video games?” The answer is rules. Yes, rules. Specifically that our brains love rules.

To understand why that is, we’ll need to take a step back and examine the biology of our brains. First of all, what is a brain, other than a mass of fat-sheathed neurons all excitedly firing at each other. The brain, and not the heart, is also the seat of our consciousness (sorry Aristotle, you got that one wrong). Brains have evolved to be decision makers, and their job is to think about things and direct the body to the best course of action. But in order to make good, informed decisions, we need to understand the world around us, and sort all of the information that come to us through our senses. Because of the brain’s desire to make these good decisions, it loves, and to an extent, demands rule sets, or, more abstractly, patterns.

If you think about it, you’ll realize that our brains are constantly filtering noise looking for patterns. An interesting side effect of this mechanism is demonstrated with coincidental occurrences; sometimes things that are purely chance related seem much more significant to us than they really are. This may happen to you when you learn a new word -- afterwards, you suddenly start hearing it “all the time,” when in reality the frequency of that word’s usage hasn’t increased, and all that happened was your brain added more significance to novel knowledge.

Great, but what does this have to do with video games? Well the answer isn’t just related to video games, but games in general. Human beings have been creating and playing all kinds of games for thousands of years. Everyone generally agrees that it is fun to win games, whether against another player or even playing by yourself. There is a certain satisfaction that comes along with creating an imaginary game space in which the game’s rules are that game space’s laws of reality, and then successfully executing actions to achieve your goals using the framework of the rules.

Successful execution of the rules is probably so satisfying because we are programmed to want to succeed at “the game of life” (not to be confused with Hasbro’s Game of LIFE), where the rules include actions such as eating food, finding a mate, etc. Playing and winning games in this way is a micro-model of “winning” real life. No wonder we love games so much!

Video Games Solve the Complexity Problem

But what about video games? What appeal do they have that your standard board or card game doesn’t? This time, the answer lies in the complexity. Most board games have few rules compared to today’s video games, not because the people who created them were less intelligent, but because adding complexity either adds costs on the players as additional rules to remember, or adds complexity to the board game itself, which could be manifested by adding additional pieces, additional point scoring, additional boards, etc. It simply becomes more of a hassle to manage the game space’s laws of reality than it is to actually utilize the framework. In addition, solving more complex problems ends up being more rewarding, especially when you reflect on the work you did to get to that sweet point of victory. Video games, in all of their virtual glory, do not suffer from this physical problem of complexity and therefore offer all of the rewards solving a complex challenge entails.

Because video games rely on a medium that is transformative (IE your computer monitor or television set), they are able to keep track of the game space rules as well as present additional complexity at relatively low cost to the user. For instance, a Nintendo controller consists of a whopping 5 separate buttons (counting the directional pad as one button). That’s not very many inputs, however, since different buttons performed different actions depending on what screen you are in (the game screen, the menu screen, the battle screen), you are now able to interact in a much more complex manner with the game space without having to utilize more buttons.

While it is true that video games offer more comprehensive rulesets, no video game ruleset encompasses everything. It’s fun to play different games with different styles because we are offered different rulesets to conquer. And now we come to the advantage that Indie games offer over commercially driven games: unique and novel rule sets.

Commercial Games Vs Indie Games

First, though, let’s examine what I’ll call “commercial games,” which I don’t want you to confuse with commercially successful games. They are usually produced by large studios with large budgets, and are ultimately driven by profit. Yes, the game developers are working there because they love developing games, and creating fun, interactive experiences for their customers. Yes the artists and composers and writers are all there because they love what they do and want to produce quality material for the masses to consume.

It’s their bosses, the leaders of the companies that employ them who are the ones demanding profit. That’s not to say they are a bunch of avaricious penny-mongerers, because in order to run a successful business, well, you need to make sure your business is making profits! In the end, however, this constrains the total creativity of everyone who works on the game as a whole. None of the higher ups will approve wholly untested concepts for games because those represent the riskiest ventures; spending $100 million developing a game that could potentially see no return is, at its core, a very stupid idea.

I’ll give you an example: Grand Theft Auto is a great game developed by a great company. In its first iteration, we had a top down view in which you control a little man who can steal cars. Fast forward to Grand Theft Auto V, and the game is radically different, but if you really had to boil it down, you control a guy who can steal cars. It is one of the game’s central concepts, and yes it is recycled because it is a sequel, which by definition would only offer iterative changes at most. But my example goes beyond that: if you compare Grand Theft Auto V to Grand Theft Auto IV, you won’t see much of a difference in terms of the ruleset. The world is different, the detail is higher, the story is longer, but it still follows the same formula, because that formula has been proven. Rockstar knows it can afford the $200 mil on that game because of how successful the previous versions have been. The ruleset remains the same.

Conversely, Indie games, which are NOT driven by profit, offer a realm of total creativity from the creators. We are free to explore concepts not previously explored, and to offer unique rule sets to our players. In a way, we can offer experiences to our players that commercial games cannot. Remember, the brain places significance on novel information, which in turn leads to a more intense experience. That intense experience coupled with the satisfaction of successfully utilizing the framework we present offers something wonderful to our players. Remember, just because the interaction is virtual, doesn’t make it any less real!

Having said all that, I’m not trying to bash commercial games, or say that Indie games are better, but I do want to say that the continuation of the creation of Indie games can only be a beneficial thing. It should never be something that is scoffed at, because if you think about it, Indie games essentially constitute research and development of gameplay. This is cutting edge stuff, folks, and that means you may encounter failures, but like scientists, all we need to do is modify our hypothesis and try again.

After all, games bring people joy in the world, and who could argue with trying to find new ways to bring joy to those people?

Merry Christmas

~Michael

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

What I've Learned

As the new year quickly approaches, so does the one year mark for when I started actually getting into gamedev.  I started in January with a basic RPG tutorial in XNA, and here I am now, 4.5 projects later, and I would like to reflect on some of the most important things I've learned over the past year (about gamedev, that is).  I'm a big fan of lists, so let's get this thing started right.

1. Your code will get ugly

This might not be true for some of the more experience devs out there, but as a recent grad (not even a comp sci one), one of my biggest hurdles getting into gamedev was worrying about how clean and perfect my code was.  Reusability is huge in object-oriented programming, and I was eager to keep everything separated into their own chunks of functionality.  This soon took its toll, however, as I would often get paralyzed trying to do things in the cleanest possible way.  Nowadays, I spend a couple minutes thinking about a good approach, and then I dive right in.  I could sit around coming up with the most efficient code possible, but at the end of the day I need a working game before I need an efficient one.  "You can't edit a blank page," so the saying goes, and the same goes for coding.

2. People see the product, not the work

When you release a game, it's important to remember that nobody sees the amount of work that goes into it, only the final result.  This was a big misstep that we took when releasing Spell Bound.  We had all worked hard on it for 2-3 months, and we focused too much on being rewarded for the hard work, rather than being rewarded for the finished product.  We released it as a paid app (much to the chagrin of Mike) but thanks to the single review we got, we quickly saw the error of our ways, and made it free.  It may have taken 3 months of hardly ever missing a day to work on it, but it was simply not up to par with similar games, which were mostly made by larger studios of more professional developers.  It's important to note, however, that we did receive payment in a way in that we learned a LOT from Spell Bound, and gaining knowledge when you're as novice as we are is often better than gaining money.

3. Don't overplan

Planning is a great thing, especially when you're working in a team of more than one.  However, overplanning can start to be a problem when it gets in the way of getting work done.  Case in point is Shibe Warz, our current project, in which I tried to move more to a production role than a developer one.  I set up all the tasks for everyone, made a gantt chart, set up perforce to (semi-)work with unity, and all the things I could think to do to make everyone else's job easier.  This went great for a while, until I realized that with me in a production role, we were only down to one developer in a team of 5-6, and we were quickly getting behind schedule.  Everything I did production-wise was probably helpful to the rest of the team, but not nearly as helpful to the project as a whole as if I had dedicated all my time to developing.  As the team gets bigger, a producer will definitely be a more beneficial addition than an extra developer, but with as few people as we have we aren't quite there yet.

4. Keep It Simple, Stupid

This is something you read about time and time again, and anyone who has started (and probably given up on) their first game project is already well aware of this, but it's absolutely vital.  Keep your first games simple, plain as that.  Development is hard, game dev is even harder.  Things pop up that will take extra time that you hadn't even thought of before, like the GUI, a tutorial of some kind, options, the list goes on.  It's easy to skip over these small details because we take them for granted, they aren't what make a game fun but they are what make a game polished.  To date, the most polished game I've made has been Lightmaze, a simple puzzle game and definitely the simplest of the games we've made.  We had a month to do it in, I finished all of the gameplay in the first week and spent the rest of the month adding GUI, menus, music, special effects, everything.  Calculated Risk is our second-most polished game, and that is another very simple concept, which again took us a single month.  Spell Bound, which took us 3 whole months, is nowhere near the polish of either of those games, due largely to the fact that it is so much more complex.

5. Don't reinvent the wheel

This may be personal preference, but I see it as simply being resourceful.  There are countless resources out there, many of which are free, that you can be using to build your game.  Gone are the days when you need to build your own engine from scratch, now you can pick up Unity Free and get something semi-professional going in just a few days, with a little help from the asset store.  There is a cost with utilizing all these resources, however, and that price is that you don't actually learn how to make them.  But I don't think that is always a bad thing.  If you are looking to land a job in industry as a programmer, write your own engine from scratch.  Trying to get into the industry as an artist? Learn the ins and outs of modeling and texturing.  But if your primary goal is to make a game that people want to buy/play, then use as many resources as you can to achieve this end.  There's still plenty of learning to be done using this approach, as the resources typically need to be tweaked to all be fit together, which requires at least a basic understanding of how they work.  A perfect example from me personally is on Shibe Warz: I am not a GUI programming and I never want to be, so I picked up DaikonForge GUI on the asset store and it has enabled me to produce a much more professional GUI much quicker than I would have otherwise.  I'm not learning the ins and outs of GUI programming, but that is not my goal.  My goal is to make a fun game that has a nice, clean GUI, and by utilizing outside resources that goal is achieved much quicker, allowing me to focus on other, more important aspects of the game.

That's it from me! This ended up being much longer than I wanted it to be, but it was nice to get all of my thoughts in writing.  Hopefully this will help someone out at some point, as well.  Time for me to get back to what really matters: developing!  Thanks for reading!

-Nick

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

Never Give Up. Trust Your Instincts!

So.

Here we are again.

Shibe Warz is coming along. There isn’t much to say on that front other than business as usual. Simply put, we have a schedule against which we churn out assets, and there is a set level of progress expected, a quantifiable amount of work needing doing, and we are doing it. It’s mind-boggling, but after such a short time, the pieces are falling into place and something resembling a game is emerging.

The team has done a great job so far, they’ve put in a ton of effort, blood, sweat, and tears. Well, ok, perhaps a little less on the blood I hope, and, having not heard of any mental breakdowns, I assume we are good on the tears. It isn’t easy to produce a product that is worth your time, so my hat goes off to the rest of the Verus team.

In fact, it might not be readily obvious how much work even goes into making a game, so in case you don’t know (and if you do feel free to skip the following statements), it’s a lot. For instance, you never know how many models and textures you need until you build your world and realize how empty it is. There are so many things which will come up that were not planned for. To try and capture a scene, setting the lighting, the ambiance is no easy task. As Andrew Hussie (author of Homestuck) said, “Creating entertainment is not really a lifestyle of madcap shenanigans. It is a very sober, often dull process that requires a huge amount of time and concentration. “ A short game you chew through in an hour could have taken a month to create from start to finish. That is a month of effort distilled and crystallized into a single experience. Now imagine creating a game that take days to finish.

So that’s why I am thankful for these guys. Their effort really is phenomenal.

But let me say this: everyone one of us will agree that it is worth it. I didn’t just lay all that out to start a pity party; you’ll find that greedy emotion is misplaced here. Ours is truly is a labor of love. We know that if you want something in life, you have to work towards it and never give up. We definitely won’t give up either, but it is important to keep an open, flexible mind when it comes to creation. The origin of creation usually comes from one idea, the “spark”, but in order to construct your creation, a bit of brainstorming usually has to be done.

Well, the thing about brainstorming is, usually just a few ideas come to fruition and the rest are discarded into the black and twisted depths of oblivion. This makes sense - after all, not every idea is possible, let alone good. This is what I call “brainstorming for the short game.” This is a very valuable skill and entirely necessary to reduce the scope of any project to the realm of feasible.

Yet, I urge you not to forget the short game’s counterpart, “brainstorming for the long game.” Brainstorming for the long game means that you keep ideas that are valuable even if you can’t enact them now. This includes ideas that had to be abandoned along the way. We’re just a young company, but already we have had to shelve some ideas even as they were being developed. It is important to maintain the ideas kicking around your head. Nourish them, entertain them, think about them. You never know when the day will come when you find that suddenly they are within reach and you have to act immediately.

The key to remember about the long game ideas is that they require a certain level of refinement. In many cases it is not even possible to refine the subject until you have more life experiences. Verus would not be what it is today if we all tried this 5 years ago, for instance. One of my favorite things to do is read early script versions for iconic movies. Back to the Future’s first draft script resembled nothing like the final product (for instance, the time machine was not a DeLorean, it was a refrigerator box). The first version of the script wasn’t even written until two years after Zemeckis has the idea. That is a long time to wait on your dream, but I think everyone agrees that it paid off.

And that’s what good, refined ideas do - they pay off. I’m not talking financially, either (though that certainly can be the case), I mean they pay off with the satisfaction of having made your dream a reality. A strong sense of pride and accomplishment, but especially satisfaction, accompanies attaining your dreams. Even if you don’t do it all at once, as long as you work towards it, you are doing something that matters. When you rest your head on your pillow at the end of the day and recognize the work you did, the steps you walked to get closer to your goal, then you will sleep soundly.

So the next time you have a million dollar idea, never doubt it or yourself. Acknowledge the steps you can take to reach your goal, chart your path to success, put your head down and go for it. After all, YOU had that idea for a reason, and only YOU are the one with the vision, and YOU are the only one capable of showing it to the world.

Well?

What are you waiting for?

~Michael