Building a World From Scratch

Creating your own world is sort of a game in itself (Sim City). And that probably explains why building the Ophidian Wars world is a big keg of fun juice. Or fun beer. All beer is fun? Except Rolling Rock?

I just wanted to share some glimpses of the vast land we're currently creating. If you can't tell, or haven't been following along (catch up already!) much of Ophidian Wars will be based in a vast desert.

This first scene is a warm break from an often lonely mood. A pond-side dwelling with some bow leaves and palmola shrubs offers Maya a break from fighting her way across the sands.

The second shot is of Maya stumbling upon a strongbox full of loot. I can hear you drooling.

"Core" Mechanics

It would be pretty silly to create a RPG and not have some cool loot to collect. Some of the most powerful items in Ophidian Wars are called Core - and finding Core will not be made easy.

Sidenote: See what I did there with the title of this post? I took my clever pills this morning, oh yeah.

In regards to the lore of Ophidian Wars, Core is absolutely crucial - it's the lifesource of each Spectral being. All Spectrals have Core, and it's believed that's it not only their lifesource, but a direct bond to the planet itself. When a Spectral is killed, the Core is usually shattered and returned to the planet to be "reseeded." In more rare cases, the Core has been maintained fully intact, appearing like the examples above. As you might imagine, fully intact core is quite powerful, and therefore highly coveted. If you want a bit of a puzzle, see if you can match up the core above with some of the Spectrals you've seen on the main website.

From a gameplay perspective, Core is essentially high-end loot. Maya will be able to find it and use it to buff her gear - namely the spear, gauntlet, and amulet that was gifted to Maya by her sister as the game begins. If you scroll down to the inventory screen in the previous post, you can see the three items, and how Core will be socketed in to each piece of gear.

If you're avid action/RPG fans like we are, I can assure you that it will be a blast messing around with different combinations of Core and finding the best effects for your playstyle. Questions and comments welcome as always!

I have sloppy joes waiting for me and they are calling my name. Jealous?

HUD

One of the most intricate and important pieces of any game with RPG elements is the HUD. Our goal was to keep it as simple as possible, clean, and easy to understand. However, as with other pieces of the game, we wanted to breath some life into the old standards.

As you check out these shots of a couple HUD pieces you'll notice some twists placed on things like the "health bar" and "stats."

I never understood what healthbars where really trying to convey. What are "hit points" really? What are little hearts? What is a globe full of blood? They obviously reference 'life' in some manner but why not rethink this? In my mind, survival (life and death) is based on a series of injured states, until death occurs. I always liked the way Wolfenstein introduced the avatar that gets more battered as you take damage. Our health bar represents something similar. Each color represents a state of injury, and when you've become critically injured, it's fatal. And on the flipside, you can find ways to heal injury. Makes sense to me!!


Moving to the inventory shot, you might be able to make out the three main stats in the big circle - muscle, reflexes, and skill. To me, it's those basic traits that govern outcomes like strength, attack damage, evasion, etc. I wanted to find the most basic traits that govern the elements of combat, and start there. It keeps the number of stats managable and believable.

We're extending this thought process through other RPG elements like 'experience' and 'leveling,' trying to start from a fresh perspective rather than just accommodating standards that maybe never had a ton logic or common sense behind them - it's just what we've become used to.

And the last thing I always come back to is....keep it simple stupid. Because we're making some tweaks to the existing preconceived RPG notions, we want to make sure that the game is still accessible and easy to pick up. Barrier to entry can be a massive pitfall when RPGs become to complex and dare I say it...hardcore. On flipside, lots of tough end-game elements will be included to keep the more hardcore crowd on their toes - don't you worry.


What do you think of the HUD design?

I present to you... Maya Tempra

It's usually Carl's department to make announcements or post screenshots and things like that. Today, however, I'm going to go ahead and do it, because I'm very excited about this, and I think the world needs to know right this minute!

Maya has entered the building.

What you see here is the first published screenshot featuring an animated Maya. In this image, she's facing off with a Vos Spectral who's guarding the entrance of a cave.



There she is. She's mid-swing here. She's swooped her spear in a counterclockwise direction, and what you're looking at is the follow-through. The Vos, caught right in the midsection by this attack, is getting ready to retaliate with a right-hook.

Here's one more where Maya is having a friendly conversation with a Pon Spectral. Don't let the position of the spear fool you. She's not aiming it at him. She's just standing at ease. The Pon's relaxed dancing should let you know there's no hostility between the two characters who are probably getting ready to engage in some sort of mutually beneficial financial transaction.




Since my posts to date have been technical in nature, I feel obliged to add some technical geekish mumbo-jumbo for this post to be complete.

What we have here are models that are rigged and skinned by our artists, and we use a modified version of the SkinnedModelSample from the XNA Creator's website. There is still some modification that needs to be done.

I'm making a custom model class which will contain information about the animations. The models contain all the animations in a single timeline. If you're familiar with the SkinnedModelSample, you know that the timeline is loaded and cycled in the display. In FBX format, all the animations available are contained on this single timeline. So, what I'm going to do is isolate the frame-ranges of each individual animation along this timeline and play a single animation clip by calling a function such as Idle() or Attack1(). These animations will have loop or noLoop specifiers.

Later on, I'm going to add a mixer which will allow a blend of animations. This will provide a smooth transitional effect when switching from one animation to another. That way there's no popping effect when switching between animations. It wouldn't look right if Maya was idling one second, and suddenly she's mid-stride the next. It should be a smooth acceleration/blend in order to be natural looking.

I've always loved Cal3D and I have some experience animating characters with this library. So I'm probably going to use some of the techniques used in that library for mixing animations, and hopefully the techniques I garner from this library will compliment the SkinnedModel sample to give us a very robust, realistic, smooth and professional look to our animated characters. I do not plan on duplicating the behavior of Cal3D, nor do I plan to write a Cal3DXna library. I merely intend to study some of the desired behaviors used in Cal3D and mimic it within our existing software.

I have to mention that the models I'm working with now, are of much higher quality than the models I used when I was playing with Cal3D. Higher quality by several orders of magnitude. Kudos to our artists who made these characters! They did a great job and I hope the screenshots convey that to you as thoroughly as it should.

The User Interface

One of the most important parts of any game - or any program for that matter - is the User Interface, also known as the UI. It is also called the Human Computer Interface (HCI) or the Man Machine Interface (MMI) or the Human Machine Interface (HMI). We don't usually call it a Man Computer Interface (MCI) to avoid ambiguity with the Media Control Interface and the Medical Council of India.

It's a lot easier for me to type UI, so that's what I'll call it.

The two base portions of the UI are the Input and the Output. In our game, all user input is registered through the game controller. All output is directed to the player from the monitor, speakers and force-feedback on the game controller.

There is an extremely well-done starter UI available from the XNA Creator's Club called the GameStateManagementSample that is a very popular jumping off point for a lot of XNA games.

We didn't use it.

Well, I shouldn't say that we didn't use it at all. I garnered a lot of useful ideas from that project - including the concept of a ScreenManager component class and a base Screen class used by the ScreenManager component - although we decided early on that we want almost everything to be data-centric, including the UI. The GameStateManagementSample is not data centric. Everything in that project that drives the behavior of the UI is hard-coded in the source.

The upshot of writing a data-centric game like this is that if we ever need a non-programmer type to adjust pieces of the game (without disturbing the very busy - and extremely good looking - programmer) they should be able to do so without running into too much trouble, provided they possess the knowledge of reading and typing, and have even the most rudimentary deductive reasoning skills.

Every screen that you see in our game - from the title screen, to the splash screen to the screen where the game itself is played - all are configured using external data that can be modified by anyone with a text editor (and access to the game content, of course. However, I'm afraid, that is a very short list of people).

Another excellent benefit of writing the game like this, is that it saves tons of compiling time when we're making changes to the contents of the game, without having to change the source code.

When a project reaches a critical mass, compiling to software becomes a time-consuming and quite boring task. If you make a typo when making a menu item that needs to be fixed, or if you need to add a new contributor to the credits, you can make these changes in a configuration file, and rebuild the project without having to compile everything again. This makes tweaking little things in the game much less frustrating. And fast.

I said above that the GameStateManagementSample has much hard-coding to define the behavior of the UI. For instance, if you select a menu item, a handler is written in the source to determine which menu item is selected and what should be done in response. Our design, being much more variable in nature, does not define these behaviors in the source code. So the software needed a mechanism for determining what to do in response to, say, the player making a menu selection. Or the splash screen timing-out. Or the player skipping the storyboard narrative. Or anything that signals the next part of the sequence.

Enter the Sequencer.

I'm not going to go into all the details - on account'a I don't know how Carl feels about me spilling the proprietary guts of our operation on the interwebs - but I'll try to give you an overview of what it does without invoking the words "Magick" or "Miracle".

Basically the Sequencer is a class that loads a list of sequence items that defines the flow of the game. Different items within the sequencer can be called up by performing various actions in the UI. For instance, on startup, you will see our splash screen (the Small Cave Games logo + a groovy signature sound effect), which is Sequence Item Zero. Item Zero is the the default sequence item, and all future sequence items are launched after that. After the splash screen, the Title Page sequence item is invoked, either by the user clicking the "Skip" (B) button, or waiting until it runs its course, which includes admiring our logo and listening to the Small Cave Games sound effect.

The title page sequence item allows the user to invoke one of several different sequence items, by choosing different menu items. Selecing "Start New Adventure" will invoke the Start Game sequence. Selecting "Load Game" will invoke the Load Game sequence, etc.

That's about it for the sequencer. All the sequence items are stored in a sequence configuration file, and every player input action that causes a sequence item to be invoked is also stored in a configuration file. It's all about the data. Very flexible. Very scalable. Very slick.

If I do say so myself.

The last part of the UI that bears mentioning in this post is the Transition Manager. One of the things I noticed about the GameStateManagementSample is that everything transitions from one state to another. There is no "state-popping" in that application. I cannot express in words how much I agree with this approach. Objects should never pop from one state to another. They should glide smoothly from one state to another over the course of time. Even if that time is 1/10 of a second, it's better than a jarring instantaneous mode snap.

However, I don't use this apparoach only in the UI. I use it everywhere. I use it to transition our in-game camera from combat mode to navigation mode (I'll tell you all about that some day), I use it in-game when the player exits one region and enters another. I use it with narrative storyboards and subtitles. I use it in the game when the player opens or closes an auxilliary screen. I use it during HUD transitions (I'll also tell you about that some day). I use it ... pretty much everywhere.

So instead of writing all these transitions into the source, I extracted it all into a neat tidy little package called the Transition Manager. The transition manager allows for any game element to switch from one state to another smoothly. The element defines the amount of time it takes to transition in, and the amount of time it takes to transition out. It provides a property that indicates amount along the current transition (if any) the transition has elapsed. And although it pained me to do so, I allowed for instant transitions. (Just in case).

Hopefully we won't use that. Ever.

That's about the long and short of the UI. The rest of the UI is pretty basic stuff. If I stumble across a part of the UI that I forgot and bears mentioning, I'll stick it up here. I'll probably write a long-winded rambling post soon about the tile engine.

Gaining Perspective

Ever play a great game that is ruined by a wonky camera? Ever read a review that chalks up poor gameplay to that same wonky camera? How many leading questions before I get tedious?

Right, so we're making it a priority to create a camera system that is not a barrier to enjoyment - that would suck. It's typical for developers to NOT want you to notice the camera, they just want it to silently do it's job and go unnoticed. We'd like to accomplish this basic functionality, but also have it ADD to the adventure experience. I'll come back to this goal.

When talking about "camera issues" we often think of third person action games (i.e Tomb Raider, Ninja Gaiden, Prince of Persia, etc) as the primary culprit. But top-down action RPGs are not free of guilt either. With an isometric view, players often find their character hidden behind the landscape while trying to battle off a horde of zombies, or run for cover (stressful, not fun). With a pure top-down view, players sacrifice a sense of depth and the world tends to look flat (not attractive).

On the flipside, both views offer benefits. An isometric view allow for a better sense of depth and viewing full objects/characters within an environment. A top-down view can be advantageous when navigating through the world (hence the helpfulness of a "mini-map" feature).

Our solution? Allow for both - choosing the best camera angle for a particular situation. I've always liked having the option to see the world from multiple points of view - I was the guy who played Oblivion over and over testing out the first person view versus the third person view. Not because one was really "better" but because I was getting twice the experience and could mess around with how different scenarios played out. I realized how much the different views created new enjoyment. This often holds true for racing games as well.


Back to Ophidian Wars, the two screenshots shown here are a preview at the two in-game views and you can see for yourself what each one has to offer (exact zoom level is still being tweaked). We're also considering adding a "dialogue view" for up close conversations so we enjoy close ups of our [hot] models. :)

Thus, we hope to accomplish a camera system that is certainly not a hindrance, more than just functional/effective, AND adds to the experience. We're confident that we'll get there.

AND AS A BONUS, we've snuck in some new graphics in to these screenshots just to see if you're paying attention. As always, feedback is welcome.

Technical Introduction

Welcome.

I hope this post finds you in good health. My name is Bryan Ecker and I am the programming lead in this project. There are links to our project website all over this page, however, I feel somehow obliged to point you to it anyway. There are lots of great pieces of viewing material on that website. You can also keep up with what the artists are doing because there's a section there showcasing our art assets. As well as some glimpses into the plot and the rich tapestry of the world of Avagar, where you will hopefully begin your journey later this year. (Or early next year depending on how fast I can make my fingers wiggle across my keyboard).

Ok - I'll leave the rest of that kind of talk for Carl, who's got dibs on the design talk. As for me, my world revolves around the programming aspect of the game. I will pop in occasionally to give you some glimpses into the back-end.

If the game was a car, I would be talking about distributor caps, pistons, and head gaskets, and it probably wouldn't be of much interest to those of you who like to get into the drivers seat, turn a key and drive to the mall without thinking about the combustion and suction that goes on underneath the hood. But if you're the kind of person who likes to change your own oil and you know exactly where your fuel filter is, you might get down with this.

When Carl was explaining to me what he wanted in this game, the words "nostalgia" and "retro" came up a few times. When he described his vision in more detail some images solidified in my head. The first image that solidified was the original Final Fantasy. After more talking a better analogy presented itself: The Legend of Zelda. Not in terms of plot and gameplay, but in terms of genre. It is a top-down tile based game where you engage enemies in the same environment that you explore regions. It is a game that will have secret areas and secret rewards and just secrets. (I love this stuff). It is a game that you can cut down bushes and sometimes receive money, and sometimes reveal a hidden cave rich with treasure... which, of course, will cause you to look for every bush in the game and obsessively cut each and every one down looking for glorious loot or new areas to explore.

But technology is so much better now than it was when Princess Zelda first enticed Link with a little leg and cleavage with the promise of more. How cool would it be to make a game that has the nostalgic and familiar look and feel of classic 2D tile games (that we old-timers all know and love almost as much as our wives) and yet still use the XBox360's top of the line graphics to their full potential to attract the whippersnappers who whisper amongst themselves "Zelda who?"

So that's what we're doing. We came up with an (I believe) unique blend of 2D action in a 3D world with camera angles and reminiscent of the old-style tile engines, complete with auxiliary screens (like maps and inventory screens) also reminiscent of those same games. With a little RPG thrown in for good measure. The gameplay action will be all done on a 2D plane. Combat will consist of walking right up to an enemy and bludgeoning the piss out of them, and getting kicked in the head a time or two yourself. The terrain that you traverse will be 2D and contain untraversable bodies of water, untraversable mountainous areas and other obstacles (like rocks and trees).

The game is written in C# using the XNA platform, specifically for XBox Live Community Games. We're using the Farseer 2D engine to handle the collision and physics within the game. Everything else so far has been written by Yours Truly.

My next couple of posts will go over the first few software milestones, and the actual design and implementation of the game. First I'm going to review the GUI framework, and then I'm going to review the regional tile-engine.

World Map

Remember when you'd buy a new game, open up the box, and you'd get to unfold the hand-drawn world map? You'd get a taste of all of the areas to explore and a feeling of how vast your adventure would be.

We wanted to make sure to offer a similar sense of expansive adventure when you play Ophidian Wars, and so we carefully crafted this map above (click to enlarge). You will have access to this map in game, so you can find your way to key locations and maybe uncover some secret areas.

Macabre (he brings the death)

When dreaming up a boss character, I often reach in to actual nightmares that I have. Enter Macabre. Yes I have odd nightmares, I know.

Craig and I had a great time conceptualizing Macabre, as an unstoppable, cold, merciless killer. What makes this guy frightening is that he's more than just brute force and sharp spiked fists - he's actually intelligent, and void of compassion. He works for the highest bidder, and enjoys his work.

Macabre is a "Lok Breed" which is a sort of mutant race that was once a type of Spectral. But when they broke the rules and began to replicate in ways that went against the natural order of the Spectrals, they were shunned, rejected, and decided to build their own civilization with their own set of rules.

Lok Breed learned to reproduce asexually and without Core, quickly building a substantial population and army. Some "purebred" Lok Breed still exist though, meaning those that still have Core - and Macabre is one of them. He is larger than most of his kind, and one of the most feared mercenaries across the land. Some won't even speak his name in fear of becoming his next target. What makes the Lok Breed different is also what makes them dangerous - able to morph their bodies to create organic weapons and armor at will. Macabre has fashioned custom armor over most of his body, but also wears a fitted faceplate to protect a vulnerable area.

With the advent of the Shift, and the presence of the Ophidians, some believe Macabre is hunting for a new top bidder. And after a recent shaky, but effective, truce with the Lok Breed, a worrisome number of Lok Breed are amassing outside of their homeland in the East.

Animation Demo Reel

My mom always taught me to share (except for steak, I don't share my steak), so I wanted to provide a link to Robert's new demo reel. He's a fantastic animator, and a swell fellow to boot.

Check it out to see some of the cool work he's been doing, along side Ophidian Wars of course.