3D Editor Alpha

One of the best things about working with an experienced programmer (Bryan) is that he's able to build game design tools from the ground up, lickedy split - like his 3D region/level editor which I am calling the "Stryker Editor" (I feel like nicknames make us cooler, no?). For a more technical overview, check out Bryan's post here.

Building this editor is practically like building a game in itself, and in fact some games are essentially extensions of level editors. Having a functional editor is a keystone in development - slick animated models and a deep story are fun and important, but pretty much worthless if you can't place them in a tangible world. Having an editor that's been built specifically to create the world of Ophidian Wars, is like a a big bowl of beef stew on a cold winter night - delicious and meaty. Horrible analogy.

The couple screenshots you see here are an example of the editor and how that translates to the game itself. It's essentially a direct export, outside of important elements that are invisible to the player, like 'hotspots' and spawn points. And the editor allows us to tweak object and character properties, like what items are in a specific vase/pot, and how well a particular boss character can block attacks, etc.

So now the fun really begins. We have all of our art assets completed and functional in-game - now it's time to build a world for them. Up until now that world has only been imagined within my drawing pad. If this were a marathon, we just bashed down the wall and hit our stride. Stay tuned for more and more content in the coming weeks.

Box Art (take 2)

This will be a three part series. :)

It was great to get a bunch of feedback on the box art design concepts that Craig is working on (by the way - Craig is ultra talented if you haven't noticed and you can check out more of his work on his website). So thanks to those who posted on the forums and in the comments section.

As visually pleasing and sensual as concept #2 was, most people seemed to think that some form of concept #1 was the most sensible, while still eye-catching and beautiful. I have to admit though, it was a damn tough decision to let it go. So we've narrowed down the exact pose a bit further and I thought I would share.

There's much I like of this particular pose. It's amazing how much subtle changes in arm position can affect the tone of a piece. Here I noticed that by bringing arm across her body, it actually created a more intense and active pose than by keeping the arm partially extended out in in front. While still nice, she almost looked too relaxed. The opposite direction of her arm versus the cape that extends out as the background creates a hint of motion - and intensity.

As an added bonus, we have a secondary point of interest. Her rather cool-looking ornate gauntlet (which as some of you may know plays a large role in this game) is in full view and rotated - and the curvature of her shoulder/arm is accentuated.

Thoughts? Looking forward to showing you the final product next.

Gub Spectral

These nasty little bastards were once helpful 'bottom feeders' of the Pampali desert. But with the Shift, they've become territorial and started using debris as a means to move faster and attack passerbys. Gub Spectrals are more intelligent than they appear and while they never truly integrated socially, they have a strong network that relies on a hierarchical structure.

From a game design perspective, Gub Spectrals serve as dangerous early threat to Maya that will need to be learned and respected. In small numbers they will not pose much threat, but they can be highly dangerous when swarming and when higher ranking Gubs are present.

For me personally, Gubs are a shout out to the blob-like creatures that often populate the early stages of action games and RPGs. I remember hacking Bits/Bots and Slimes to pulp and that's how we'd all cut our teeth before facing the tougher enemies.

With Craig's help, we were able to conceptualize a creature with a bit more personality. Bryan and I are working on applying A.I. that allows us to scale up the challenge they pose as they game progresses and Maya delves deeper into her adventure. I look forward to catching people off guard with situations where they say, "oh just a couple Gubs, piece of cake." (evil laugh)

Our Region Editor

I do not know if it is readily apparent to the casual observer, but things have been very exciting in the Small Cave Games these last few weeks.

Over the last few weeks we have gotten our animated models going, optimized a lot of code to achieve a 60 frames per second benchmark. We have gotten some awesome models in place by our talented artist and rig-meister. Plus we have added a ton of polish to make this game feel much more comfortable, natural and pleasing to you, the player. (I talk about you – yes, you specifically – in a lot in the comments within the game code. I say things like: “The player must select one of these”, “The player will want to throw their controller if I don’t change this section”, or "the player is not only good looking, but smart and talented as well" all over the place.) We have finalized our inventory screen (see screenshots in previous blogposts) and have made it intuitive, informative and visually appealing. We have even added some preliminary intelligence to some characters, and they can chase you around the screen.

In fact, I would dare say that we have made more tangible progress over the past 4 weeks than we have made during the previous 4 months. Maybe 6-8 months.

Notice that I distinguish “tangible” progress. We are currently at a point in the development of the game where there is a lot of front-end work going on. That is to say everything we are working on now will be visible by the user. And the reason the progress and momentum is currently so satisfying is due to the solid foundation of the back-end. That is, all the stuff you do not see. I went to great lengths in the design phase of the back-end to ensure that front-end development would be a snap. And it is paying off now.

The back end of the engine is almost so boring that I do not want to write about it. It is not boring to develop (in fact, I really enjoyed developing the back end to this game), but from a player’s perspective, it is probably very much like taking the cover off of your computer and looking at all the boards and storage devices. You know it is there, you know it is all important, but unless you work in there, you would just as soon leave the cover on your CPU and surf the intarwebs.

As it turns out, a very large part of designing (if not necessarily implementing) the back end of the engine was the development of a level editor, or a “Region” editor as I have been calling it (because our “levels” are not necessarily region-based, and region traversal is non-linear). About halfway through the design phase the tile-engine, an idea occurred to me that I should make it easier for the game’s level designer – that would be Carl – to design these regions, or else making regions is going to be unbelievably tedious, and unnecessarily complex. Since I am loading in the regions as content objects using the XNA Content Pipeline, the regions need to be designed in XML. And who wants to look at raw XML all day long? Not me.

It also occurred to me that if designing levels is an extremely unpleasant process, then the final results may suffer because of that. That is to say nothing of our sanity. I know that after pasting in the XML codes for the 5,000th Large Rock, I would probably snap and my poor neighbor would end up on the 6:00 news saying: “He was such a quiet guy. He mostly kept to himself. I don’t know what happened”.

So Carl and I thought it would be a good idea to develop a separate application that would allow you to design game regions, and be able to save them in a format that the game already uses. Our RegionEditor was born.

The region editor, unlike the game itself, is currently written in C++ and uses Managed DirectX (MDX), as opposed to XNA. I decided to use MDX instead of XNA because MDX doesn’t have the annoying VertexShader/PixelShader 1.1 requirements. This requirement was a serious hindrance earlier on in development because my computer was older than my oldest child, and the video card in it was even older than that – I have since upgraded to a newer model, but we kept the MDX software in place, in case we get a developer with a video card that is incapable of dealing with XNA.

I decided to write the editor in C++ because C++ is my native tongue. I prefer to write in C++, I write more efficient code in C++, I write code faster in C++ (believe it or not), and because the editor started life as a Win32 native app (using the native DirectX library) rather than a .NET app. I ended up switching to .NET and MDX for one very small (seemingly insignificant) reason. .NET has a PropertyGrid control built in and Win32 does not, nor were there any non-MFC freebies that I could find, and I didn’t have time to write a good one myself.

Here’s what it looks like now.






I think it looks pretty good, and it is definitely going to be easier to work with than straight raw XML data.

At first, this was a 2D editor. Instead of the 3D terrain in the workspace above, there was a 2D map. When you placed, say, a character on the map, you would get a little icon that indicated there was a character there. (Actually, you would get a hand-drawn circle to indicate there was a character there, and attached to the circle was a hand-drawn arrow indicating the direction the character would be facing when the region was invoked). In the 2D editor, characters and objects look identical except for coloring. The only way you can tell what type of object is specified by a given selection you have to refer to the property grid.

The 2D editor is functional, and that is what we are currently using to perform preliminary designs on a few levels. However, there are several mighty drawbacks to using a 2D editor.

First and foremost is the scaling of objects. If you want two adjacent rocks, you really have no way to tell if the rocks are too close together or too far apart, except for educated guesses and luck. Also rotation is a crap shoot. Oftentimes, especially with rocks, outlying vertices have wildly varying distances to the object’s centroid.

That could be fixed with clever manipulation of 2D sprites – and that is what I was going to do, except for the next drawback: A 2D editor simply cannot give you a good feel for what the final 3D level is actually going to look like. If you look at a map of New York City, you will see all the streets and avenues represented on the map. You can see Broadway on the map, and you can see 42nd Street and you can see Central Park – but in no way does looking at a map compare with standing on Lexington Ave. and E 85th Street buying a hot-dog and listening to a cab driver telling the squeegee guy to go !#%@ himself. The only way to overcome this problem was to create a 3D editor with the ability to actually enter the world and manipulate it.

The last problem, but by no means the least important, is the fact that using the 2D editor with lame visuals is almost as tedious as working on raw XML. As I mentioned before, if creating levels is an excruciating task, then the quality of the levels will suffer for it. Both Carl and I wanted an editor that would not only be intuitive and efficient, but also make designing levels a pleasant (even fun) experience.

I should have the first real draft of this region editor ready this weekend, and if all goes well, Carl will be cranking out areas left and right by Monday morning. This should bode well for screen shots that appear here. Right now the regions that we’ve shown you in screenshots have been designed in the 2D editor or are edited by hand in Notepad. With a fully functional 3D editor in place, we should be able to crank out stuff that is really pretty and have fun doing it.

Ok – I have babbled enough. I have a game to write.

Box Art (take 1)

The XBLIG platform is pretty unique in the way players access the games, and as the catalog grows bigger and bigger, it's getting more and more important to stand out. The first thing people will see is the box art, and if other people are anything like me I think it's safe to say that many games are being pre-judged on that first initial image. For people to take that next step, select the game to read more and download the demo, they first have to be drawn to the box art.

So we've started working on box art that will hopefully be appealing and help attract our to-be fans! Below are some concepts. The second one is probably going a bit too far on the sex appeal and doesn't really relect Maya in the most "pure" light, but I bet it would grab a certain kind of attention. Thoughts welcome :).

Experience System - Rethinking the Norms.

Ever sit down and wonder what exactly "experience" is? The classic RPG experience system has players striving for that next "level" - generally the more you do (or kill), the more experience you get, and the more levels you gain. It's a timeless character progression hook, and it works because we all like the idea of our character growing more powerful and legendary. We like to see our stats going up I suppose - we like to see advancement. But why so numerical?

The levels/numbers are mostly arbitrary. What is level 46 versus level 47? Why does killing monsters equal 45 experience points (for example), and why does a new level mean you can assign upgrades to stats like strength, dexterity, and intelligence? So because I killed 567 monsters worth 25,674 experience, NOW I am 3 points more intelligent? These questions nagged me, but also encouraged me to start with a clean slate when designing the experience (or rather "progression") system for Ophidian Wars. Obviously I didn't want to depart entirely from norms and assumptions that players enjoy and are used to, but also really felt that I had opportunity to start with clean slate and rethink things.

I set out with 3 goals.

1. Maintain the strong feeling of progression/advancement.
2. Keep the system simple - resist bogging it down with heavy stats.
3. Start fresh - logically approach how Maya would progress and grow throughout her journey.

Working towards those goals, the first thing I decided was to entirely ditch the concept that killing x monster gains x experience = level up = more stats. While it works like a drug I wanted to break that mold and not chain players to a number chart. I mentally sited games like Zelda: A Link to the Past (see screenshot) and Super Metroid which were able to strongly maintain the feeling of character progression while sparing players from any sort of arbitrary number/experience system (or the "grind" some may call it). While successful games like Diablo 2 (see screenshot) and Oblivion go the other route, I personally get irked by how much time in those games that I spend fiddling with my numbers and looking up player-made spreadsheets for stat optimization.

So then, with a bowl of Cheerios and fresh night of sleep, I started brainstorming on what traits logically relate to combat. What REALLY matters when you're toe to toe with an enemy? More importantly, are those traits able to be advanced through believable game actions? And if so, how?

Saving you details of how my brain works, what it boiled down to was Skill (how well-versed in combat you are, almost like summing up "experience"), Reflexes (how quickly you can act and react during combat), and Muscle (the most basic trait that leads to more powerful blows, and a more durable character). Not far from the most simplistic Strength/Speed setups, I like my organic terminology better, and avoided the trifecta of including "Magic" or "Mana." Skill became the savior - the way to take "experience" and contain it from becoming a statistical monster. Skill is quite literally... how experienced you are.

Also, what I like about those three traits was that each one could believably be advanced through combat, unlike common additional traits like intelligence/wisdom, charm, charisma, luck, vitality, etc that really don't have any relationship to combat or slaying enemies and often grant non-combat related bonuses (even "speed" often increases run speed which makes no sense, and isn't that based on leg strength?).

So in the end, Maya could gain muscle, increase her overall combat skill, and hone her reflexes simply by going on her merry way through the game fighting foes. Combat would logically increase these traits, and so might ally trainers, feats of strength, and specific quests. It felt natural. Best of all, I didn't need a back-end experience system - I could advance/level-up Maya's traits by tying them to specific in-game combat related achievements. (my lips are sealed on this until a later date)

The only problem that left me with was that all of Maya's advancement was tied only to combat-related traits and achievements. And in my opinion, a personal journey should include much much more than beefing up and becoming the ultimate ass-kicker (debatable, maybe). How else could she develop? Going back to some of those out-of-place traits like charm and intelligence, I realized what they are trying to accomplish. They are trying portray other forms of character growth - all good in theory but totally unrelated to combat.

So with a fresh bowl of Cheerios, I started thinking about other ways Maya would grow and advance beyond combat traits. How would she become more "intelligent" and gain "charisma?" Not by killing things! Thus, "techniques" were born - 8 of them to be exact that represent non-combat advancement. One of favorite examples is the "Green Thumb" technique which can be learned via a specific quest where she researches plant life. It allows Maya to better harvest healing Palmola fruits from Palmola shrubs. Thus, her research makes her more intelligent, and that allows her to be a more resourceful adventurer. It's logic at it's finest, and a cleaner methodology for advancing '"intelligence."

When you combine the 3 Trait system and the various Techniques that Maya can learn, I believe we have a simple, intuitive, yet highly satisfying route to character advancement. Throw in a cash of dynamic items/loot and we may just quench the RPG'er's thirst!

Hope you enjoy my babbling. Which kind of advancement system do you like better? Do you lean more towards the Zelda method, or the Diablo method? Is there a healthier middle ground?

Kilflame Soldier Follow-up

Like any good army, the Kilflame army has ranks. Here's a look at some of the variations Maya will encounter. Like the classic RPGs we all know and love, it's a fun practice to repeat enemy types of varying degrees of difficulty. As Maya grows stronger, so will her foes. Each one will have different strengths/weaknesses, tendencies, and methods of combating Maya. As the player, you will need to learn the habits of the different enemy types to keep Maya alive. Bryan is currently working on A.I. and we're excited to show some of that work in action soon.

Inventory Update

We've been putting a good deal of time into polishing the inventory to make it appealing and intuitive. And while our opinion might be a bit biased, we pretty much think it rocks. As you can see from the screenshot, we've implemented Craig's item artwork, and created a cursor that navigates around the four main areas of the screen (Items, Core, Traits, and Techniques). Then, the newly added info window in the center gives a brief description of whatever the cursor is on. You can see that the Stormpod has been selected, and pressing "A" will use the item. "Faded" items mean that Maya aint got any.

Pressing 'X' offers a dropdown menu that allows for game commands like saving and quiting. And the icing on the cake (mmm cake), we have some custom SFX and voice-over work that responds to commands within the inventory, but you'll have to wait for the game to hear those! Thoughts? Questions?