Xeno: Proof of Concept

/

WOW, it's been a long time since we've last updated this blog.  It's really easy to get carried away with the messy chaos of development and real-life, especially when juggling separate jobs, families, and day-to-day responsibilities.  But nevertheless, and never fear, we've been working hard on Xeno all that time.

Probably the biggest change we've decided upon for Xeno has also been the most recent.  As a new Indie studio with no previous industry experience, it's a "5 steps forward, 3 steps back" endeavor.  In the beginning we ran with our imaginations and tried to envision a grandiose game that, while not MMO-size, or even RPG-sized, incorporated a detailed and meticulous vision of space exploration, xenoarcheology, scientific first principles (including basic Chemistry, physics and biology), and 2-player co-operation.  We planned for multiple planets, i.e. levels, and a detailed and not-shallow skill-based level-up system.  But maybe I'm getting ahead of myself.  Should we have a little brush-up on what Xeno "is"?

What Xeno is all about is the exploration of the astrophysical imagination experienced with a friend.  We wanted to specifically capture the little nugget of experience that encapsulates co-operation in historical video game scenarios.  Halo, Diablo, Hexen, Borderlands, Baldur's Gate (console versions), Army of Two, Gears of War, Minecraft, Everquest.  How one person feels when she successfully overcomes seemingly insurmountable odds alongside a friend, a sibling, a mate, or even a stranger.  It's something I've, personally, always found the most satisfaction in, and something we wanted to work toward with Xeno.  In Xeno, in the fashion of these aforementioned experiences, 2-player co-operation is key to survival on these distant planets, as you're tasked with the responsibility of collecting valuable chemical resources from these worlds and taking them back to the Human Network, which then utilizes them among countless human civilizations across the Milky Way.  It is a first-person experience for each player, and once you touch down on a planet, the gameplay is intense, strategic, and frightening.

The starting area for the Proof of Concept level, dubbed "The Protolevel".  Those relatively close tentacles are animated and move of their own accord.  The mammoth black structure in the background is the "Hive," which is accessed later in the level.

Xeno is "intense" due to the overwhelming amount of hostile biota on the planet you've just touched down upon.  You see, the importance of each level lies in its once-biologically-rich biome which, at one point tens-of-thousands of years ago, housed a "dominant intelligent species."  This species (drastically different for each planet) suffered through an extinction event completely unique to itself and the conditions of its planetary system.  In the deep time since the extinction, the planet's biota has re-stabilized with the environment and experienced evolutionary leaps all its own, resulting in the creatures the players discover upon planetary touchdown.  Our scenario designer has a very keen knack for, and understanding of, chemistry and biology, and has been developing both anatomical and behavioral descriptions of each of the creatures.  And we have a really great programmer on our team who's been very eager to work on the A.I. for our creatures, adding flying, burrowing, and even "pack mentality" mechanics to not only confuse and attempt to overwhelm the players at key points, but also to scare the ever-loving shit out of them.

Two "Dead Rovers" trying to sneak up on me, but I turned the tables on them by triggering the "Override" ability of my shotgun (each Override is different for each firearm) and blasting them away, dazing them for a few seconds in the process.

Xeno is "strategic" due to the ability for the player, individually and collectively, to experience emergent gameplay through the customized use of multiple skill-trees.  Each player begins her character with access to either a Pistol or a deployable Auto-Turret which defends her against hostile biota (this option is still subject to change).  As I explained earlier, the players' collective goal is to retrieve a certain total amount of resources (in the Protolevel's case, it's Xenon gas) in order to "succeed" at the xeno-mission.  With that said, the players can extract resources from a "resource node" by switching to their "XMSuit" (Xeno-Miner Suit) and extracting the resource manually from the node.  This, of course, leaves her vulnerable, and thus reliant on either a nearby defensive Auto-Turret, or on the co-operation of her ally who may or may not be close at hand.  The Auto-Turret, Resource collection speed/capacity, as well as numerous other statistics of the player's personal XMSuit, can be upgraded individually and branched into multiple avenues (would Two mid-range Auto-Turrets be better or worse than One high-end Auto-Turret? You decide!), and there will be other "Bots" at your disposal as well, including a resource-collection bot which can stay behind and slowly accumulate resources for you.

The XMSuit's "Resource" animation being used on a Xenon gas node.  You can see the Resources counter on the bottom-left of the screen.  This animation still allows for the player to move around freely, but it is separate from a "firearm" selection, thus leaving the player vulnerable.

Xeno is "frightening" due to the foreboding and alien atmosphere, and the silent immersion that we are bringing to the table.  Sound is extremely important to us, and we have two separate sound technicians working with us, each of whom have nearly two decades of experience with aural technique.  One is working specifically on our musical score, the other is working solely on sound effects.  Something important to keep in mind is that music will not be present throughout all gameplay, but will only be triggered during specifically intense (i.e. "lots of creatures") encounters, and will consist of "layering", which allows us to subtly control the experience by adding more musical layers with more creatures on the screen.  For the sound effects, we've taken a lot of inspiration from games like Mass Effect and Dead Space, especially Dead Space, which utilizes a lot of "industrial" noises and sounds and tweaks them for both metallic and alien effects.  We wanted to make the game frightening, or rather tense, in order to help facilitate the group dynamic of co-operation.  In a dark room, another human being can be more calming then all the flashlights in the world, and we want to work this to our advantage.  The players absolutely can play however they would like, including by splitting up, but we want them to remember that there is strength and strategy in numbers.

Two Resource nodes next to one another, for two players back-to-back, or one player and one "Gathering Bot" to work at simultaneously.  But be prepared for roving creatures... or packs of creatures.

As I started to say earlier, we have recently had a huge change in our development, and I think this is important for any other potential Indie studios who are currently at or will eventually cross this threshold.  When we began development on Xeno several months ago in February, we thought it best to explore the entire game idea all at once, to stamp-and-ship all of our game's mechanics into a Game Design Document and immediately extrapolate the game to three massive planets/levels.  This, as it turns out, was the wrong approach for us.  A significant amount of time and energy needs to go into R&D for this idea, and a lot of inspiration for some of our developers was lost in the quagmire of "scope", that ever-present imp.  About two months ago our scenario designer sketched out a rather brilliant level design for what he called the "Protolevel", and it was based on his countless years of experience playing and studying 90's RPG's like Chrono Trigger and Zelda.  Turns out, an awful lot of psychological detail goes into level design at its best, and for Xeno it should be no different.  With this said, a few days ago we decided to completely strip our GDD of all unnecessary scope details and tighten the project to the Protolevel itself, focusing all of our efforts on crafting and polishing the Protolevel into its own game.  Doing this allows us to test all of our ideas on a perfectly-tuned "game board" with rooms, alleys, avenues, structures, and expanses tailored specifically for each and every experience that we want to conduct in the game entire.  We are able to add or subtract mechanics on a whim within the Protolevel without having to debate over every mechanic under the context of the entire game.  We simply have an idea, pitch it to one another to see if it fits the intended "experience" of Xeno, and plop it down into the Protolevel to see if it has the intended effect.  This has been our most important development change to-date, the whittling of our GDD to something tangible and malleable and, best of all, creative. 

Some ambient assets. "Alien Pods", both of the "full" and... "open" variety.

The Protolevel Horizon, where the sun is... well... not "bright," exactly.  But you get the picture.

So that's it for this update on our progress.  We're quite literally in the middle of a "Xeno revolution" in the virtual studio and it's really very exciting and inspirational.  Just keep in mind that there is, indeed, a vision for Xeno and we're working on making it a very strong reality.

Thank you very much for reading and keep in touch with us on Twitter @VerusGames or shoot us an e-mail at ContactVerus@gmail.com for periodic e-mail updates!  And feel free to comment below!

~Anthony
Chief Creative Officer
Verus Games

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.

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.

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.

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

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!

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!

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

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

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

Unity3D: Armor & Weapon Attachment to Character Model

/

For this week's blog post, I'm going to get a bit more technical than we usually do in these blog posts.  This is very Unity3D specific, so if that's not your bag then you've been warned.

Problem

The characters in Shibe Warz can have any combination of armor, boots, helmets, and one weapon/spell in each hand, so how do we attach those models to the character and have them animate when the character does?

Solution

I'll start with the helmet and weapon models, because the method for those is very generic and can be useful in other games.  I've uploaded the entire .cs file here if you want to look at it before/while you read.

1. Create prefabs of the models to be used.

This is pretty straightforward, drag in all the assets you need and make the weapon and armor prefabs.

2. Create a script to assemble the finished model

I named my script "UnitBuilder.cs", and it has public GameObject objects for each model that we just made a prefab for.  In Shibe Warz we have cloth, leather, and plate armor, as well as a bunch of weapons, so the top of my script looks like so:

...etc. The prefabs made earlier can now be dragged into this script, so they are easily changeable later on.  Note the "baseModel" object, which is the prefab of the completely naked unit, which we will be building on top of.

3. Instantiate the unit's naked model

This is pretty straightforward. Notice that I'm using Network.Instantiate here because Shibe Warz is multiplayer over a network. If it's a single player game, you'd just use Instantiate.

4. Attach the helmet

This is where things get a little tricky.  The premise behind having models "attach" to the character is to make them children of the original model, because a child's position and rotation, once initially set, are locked in with respect to the parent. So let's say you make two cubes, A and B.  You make A the parent and B the child.  You shrink B and put it inside of A.  Now when you move A, B will move with it, retaining its position inside of A at all times.

So, what we're going to do is make the helmet a child of the unitGameObject created above.  But we have to be careful here, because the unit's model will be animating, and as such the head will be moving around a lot.  So what we really want to do is make the helmet a child of the unit's head, that way no matter how much it moves around, the helmet will move with it.  How do we do that? Well, first we have to find the head in the model hierarchy. This is how it looks in the unity hierarchy view:

So now that we know where the head is, we can find it in code and place the helmet there.  Beware, the following is hard-coded, which is never good.  But it was getting late, so I was just trying to get things working.  Please refer to my previous blog post, where I talk about how messy your code will likely get while developing a game.

One thing you may recognize is the use of the helmPosition object.  I discovered that I couldn't simply put the helmet at position (0,0,0) because then it wouldn't be fit on the head properly, so I had to mess with it a little bit to make it look good.  Once it looked good, I simple copied the x, y, z values and stored them as private variables in this class.

And voila! The helmet is now instantiated, placed on the head, and made to stay there by setting transform.parent = charHead.

5. Attach the Weapons

This is almost identical to attaching the helmet, the only difference is instead of attaching it to the unit's head, you attach it to their hand.  For the sake of brevity I'm omitting the code, but I've uploaded the entire file here if you would like to see how the sausage was made.

6. Attach the armor and boots

I saved this part for last, because I'm not really proud of how it was done, and I know in my heart of hearts there's a better way to do it, but it works, and if it ain't broke don't fix it, right?

When Anthony created the armor, he was generous enough to attach it all to the same skeleton as the base unit model, and animate it in the exact same way.  This made my job extremely easy, as all I had to do was instantiate the armor at the exact same spot as the unit, and any time an animation is run I just animate both the unit's model and the armor's model.  The same was done for the boots.

So! This was pretty much the entire process of building a dynamic model from scratch.  I hope this can be useful to someone, and if anyone has any questions or wants to say, "Hey that was a stupid way to do that, you should do it this way..." and then provide some awesome way to do it, feel free to leave a comment here or hit us up on twitter, @verusgames.  After all, the purpose of this post is to help people in the future with the same problem!

-Nick

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.

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.

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.

 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.

 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.

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.

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.

 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.

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