A few weeks ago we ran a small focus group among Deathfire fans, as you may remember. Many of you have been eager to hear about the results of this focus group and as I had promised, today I want to share with you a closer look at the outcome.

The focus group was designed to help us find a final name for the game. Deathfire has always been a spur-of-the-moment kind of name that we used as a project title for lack of a better alternative. In the time leading up to the focus group, we made lists of other titles that we liked, and began whittling them down. We voted over and over again to slim down the selections, and to get something that we felt represented the game the best.

Then we put together a series of questions that would allow us to gauge people’s response to certain keywords and names we had on our ultimate shortlist. And that is how we entered the focus group…

We asked people to give us impressions on titles such as Deathfire, Nethermancer, Endergast, Realms of the Beyond and Ruins of Nethermore without giving them any explanation what these words might mean in the context of a game. We simply wanted to get people’s reactions and thoughts on those words. The responses were very interesting and, in many ways, reflected our own impressions. But there were also some interesting and unexpected trends evident. For many, for example, “Deathfire” indicated a game that did not sound like a role-playing game at all. We had not expected that, but what was uniquely striking was the fact that almost everyone associated this particular title with an action-oriented game.

In the case of “Nethermancer” many of the participants felt the dark vibe this title gave off. Although many did not know exactly what a Nethermancer is, everyone understood that this is about very dark magic, automatically implying that magic would be the main focus of the game.

“Endergast” was an interesting one. It is the name of one of the villains in the game and we felt the name simply has a certain ring, even if it did not have a meaning per se. Most of the participants did not know what to make of it and responses were all over the place, as people drew from names that were familiar to them and remotely reminded them of the name. This often resulted in associations that had absolutely nothing to do with the game we are actually trying to make.

“Realms of the Beyond” also created associations that went beyond what we are making with the game, obviously giving participants an impression of a plane walker who travels different universes. In addition, it gave participants a sense of an epic adventure, of many worlds and mystical realms to be explored. Not quite what our game is, altogether.

The last option we explored was “Ruins of Nethermore” and, much as expected, it instantly created a classic RPG vibe with most participants. However, exact details fell into two ranks, essentially. One group consistently commented that they would expect a traditional dungeon crawler when they heard of a game with such a title, while the other group referred almost in unison about a mysterious city, lost civilizations and cultures, curses, magic wars and undead remnants. While neither exactly hit the nerve of what we’re doing – “Deathfire” is neither a mere dungeon crawler, nor does it truly explore lost civilizations – it was clear that it definitely hit the traditional fantasy role-playing mark.

At this point the participants still did not know, exactly what these terms/titles meant, so we took them to a poll where we asked them to grade a list of titles. This would give us a base line and also an indication how “popular” certain titles were, regardless of how they relate to the game. Participants had to assign a grade to each of ten titles. Each grade was unique so it was not possible to have multiple favorites. We really wanted participants to commit to which title they liked better than the others.

The titles in question were once again “Deathfire,” “Nethermancer,” “Endergast,” “Realms of the Beyond” and “Ruins of Nethermore,” along with “Neothera,” “The Beyonder,” “Flames of Nithera,” “Bones of Endergast” or any title of their own creation, which they were allowed to write in.

The results were stunning. Honestly. We were glued to our screens in fascination as we watched the results come in. I don’t want to go into too many nitpicky details, but it was clear that there were a few titles our participants were simply rejecting. “Endergast,” “Bones of Endergast, and “The Beyonder” were titles that received universally low ratings, whereas most of the others were a mixed bag. As expected from the comments before, “Ruins of Nethermore” received high grades, as did “Realms of the Beyond,” surprisingly.

Then came the moment of truth. We explained to our participants what all these names and terms meant, and let them grade all the titles once more. With a new understanding of the terms we expected some change in how people would rate the titles, but to our surprise, it became a completely new ball game!

The opinions became much more polarized. Suddenly people either loved or hated a title. A lot of the middle muddle was gone and people now had real opinions. For us that was great news. When looking over the graphs that we made from the grades, we could now instantly eliminate titles such as “Endergast” or “The Beyonder” from our list. They simply did not jive with people. “Neothera” and “Realms of the Beyond” suddenly had a big hump in the center, meaning virtually everyone was ambivalent about them, and “Flames of Nithera” did not fare much better.

But there were also clear winners, and one was “Ruins of Nethermore.” Not quite unexpected after the feedback we had received in the first round. “Nethermancer” suddenly became much more popular as well, but the ratings indicated that people were truly polarized over this. The grades for this title were either really high or really low.

The biggest surprise for us, however, was that suddenly “Deathfire” had become one of the favorites. With very few low grades, a clearly visible uptrend and a solid number of really high grades, the title “Deathfire” had, in fact, become one of the fan favorites.

For us this was every bit as satisfying as it was surprising. For months posters in various RPG forums had been ranting against the title, and the constant dissent over the name had truly raised concern in us. However, if the focus group has shown us anything, it is that one of the key reasons why people do not seem to like the title “Deathfire” is that they do not know what it means. The numbers clearly showed us that once we had explained to everyone that it is the name of a horrific, outlawed spell, suddenly people took a liking to it. And strongly so.

Overall it was very interesting to observe how a little bit of additional information created a real bias within participants, how middle-of-the-road undecidedness became opinion that people expressed. The comments that came with the re-rating of the title, clearly showed that now people felt quite strongly about the names, and in the feedback section that concluded our focus group, it became evident even more so how people felt about the title of the game.

I should also point out that there were some pretty good naming suggestions coming in as well in the “Suggest your own name” part of the grading. One or two of them we really took into consideration but ultimately felt they did not represent the game well enough.

So, where does all of this leave us? Well, with the game’s final title. After reading and interpreting all the result and after taking all those comments and advice to heart, we decided to call the game “Deathfire: Ruins of Nethermore.”

Logo

We decided to use a two-part name for a number of reasons. For one, it gives the game a more epic scope, indicating that it may be part of a series. While we do not have exact plans for future sequels of the game, there certainly is the possibility, depending on the game’s overall success.

The other reason we decided to use this two-part name was that it allows us to reflect the different aspects of the game. “Deathfire” is the part of the title that suggests a dynamic game, filled with combat and dark powers, while “Ruins of Nethermore” clearly plays up the traditional aspects of the game with a title that conjures up associations with classic computer and pen&paper role playing games.

As you can see from above, we also have a brand new logo for the game. It is a logo that we spent a lot of time tweaking and fine-tuning – and when I say “a lot,” I mean really, A LOT. We feel it nicely incorporates all the elements we think are important to understanding the game, while also having the power to stand on its own, representing the game we are making.

We hope you like the new title and the logo as much as we did and would certainly love to hear your comments, so don’t be shy and let us know.


With nailing down the name and the logo out of the way, now is the time for us to brand the game properly. This means, we need to get the word out into the world big time. And for that we would like to recruit your help once again. Help us spread the word about “Ruins of Nethermore” or “Deathfire,” whichever way you prefer to call the game now. Tweet it up, share the news with your friends, post the logo on your Facebook wall or your blog… just get active and help us tell the world about this exciting project we’re working on.

South Park / SpartacusTo make the deal a little sweeter for you, I’ll be giving away some movies again this time, among all those who help us get the word out. I will be giving away a copy of “South Park: Season 15” to one lucky winner, and a copy of “Spartacus: Season 2” to another lucky winner.

Interested? Well, just make sure you collect entries for the give-away below, and don’t forget, you can obtain more entries every single day for the duration of the give-away, simply by tweeting about Deathfire: Ruins of Nethermore. So, now, go out there and post the hell out of it. Spread the logo and the name all over the world!

a Rafflecopter giveaway

I recently did a lengthy podcast interview the great folks over at Darkstation and I thought I’d let you all know that the podcast is now live on their site in the “Darkcast” section.

Darkstation Logo

The podcast has the title Making Zombies with Fire and covers a lot of ground. Not only did we talk about my current game project, Deathfire, but also about some of the games and projects I’ve worked before, including a brief discourse into my literary forays with the Jason Dark dime novels.

Interestingly, the discussion also revolved around things such as general game design philosophies and how my approach has changed over the years, as well as other very interesting topics that fans of my games may find interesting. So, waste no more time. Head over to the Darkstation Darkcast and listen for yourself.

Let me tell you a story

One by one they are disappearing
Friends, brothers, sisters, mothers, fathers
When they return they aren’t who you think

They look the same. They sound the same
But they are no longer the same…

The most unholy of spells incanted,
Undead fire burns in its victims’ eyes…

The Nethermancer has spoken
His was the last voice they heard…
Before they were perverted into monsters with familiar faces

In a world without heroes
Who can you trust?

In a world where the dead are rising
Who can you turn to?
No one.
No one is safe

Can you save the world from everyone you ever cared about?

This, my friends, is the promotional snippet for Deathfire, designed to whet your appetites. Because of my vacations and all the stuff going on here, it has been a while since my last Developer Diary update, but today I thought, I’d give you a bit of a glimpse at the game’s story.

As you can certainly tell from the blurb above, there are some sinister things going on in the world. From villages, people are disappearing at random. Families are torn apart and the people are mourning and heartbroken.

But that is not all there is to it. At the same time, hordes of zombies appear and threaten the once peaceful villages. Flesh-eating monsters that tear into anything that lives. The worst part, however? These are the same people who went missing… These are the fathers, mothers, sons, sisters and friends… and they do not distinguish friend from foe. They simply… feast!

Rumor among the villagers has it that it is all the doing of an evil Nethermancer, who is hiding out in the hilltop runs of the old Apocryphic Temple. Abandoned long ago, haunted they say, and a cesspool for wicked and foul creatures, the Temple can no longer be reached directly. Thickets and forests, ravines and collapsed bridges make it all but impossible to reach the ancient structure. And yet, as its ruins claw at the sky like skeletal fingers, flickering lights can be seen among the walls. Shrieks of the tortured souls can be heard emanating from its crumbling walls and a strange, unholy glow permeates the place, as fell creatures prowl through the woods, spreading further and further, spewing forth the undead in a never-ending stream of walking death.

This is the premise of Deathfire, a story in which the Nethermancer Endergast has uncovered an ancient spell so devastating, so frightening that it had been banished for centuries. By burning his victims’ souls with an undead flame, he reclaims their bodies to do his bidding. He is gathering an army and soon, the legions of the undead will outnumber those of the living.

So this Nethermancer is really just a Necromancer, you may be tempted to think, but alas no, let me allay that misconception right here. The craft of Nethermancy is far more vicious. Unlike Necromancy it reaches out not only into the realms of the dead, but also… hey, what am I saying? I wont spoil this for you. You’ll find out in the game, because this is where you come in.

When your father has disappeared like so many before him, you rally a small group of adventurers. While you know there is no salvation for the poor souls taken and destroyed by the Nethermancer, at least you can try to put their bodies to rest and put an end to Endergast. And if you will find the same grisly end as all those around you, at the very least you died, trying!

This is only the “front end” of story, of course. The part that we present to you, the prospective player, in order to get you intrigued in the game’s premise. Once you enter the game you will very quickly find that there is a lot more to it. Nothing is as simple as it may seem and with many plot twists and turns, the story will quickly take on a much more elaborate and grander scope than you may initially suspect. In a way, I wish I could share with you many of the cool ideas we have prepared for the game’s plot, but that would truly spoil the fun for you. However, throughout the story there will be encounters with various other characters and I think in the weeks to come I may introduce you to a few of those. It may give you a better understanding of the various factions and key players in the game and hint at some of the dilemmas you may encounter as a player.

Meanwhile I hope this little glimpse into the game’s story has gotten your attention and will rev up your own imagination as to what Deathfire will hold in store for you. In my next update, however, I plan to give you an update on the Focus Group we did a little while back. Not only will I tell you in detail what it was about, but more importantly, I will break down the results for you so that you, too, can see how other role-players felt about some of the questions we posed. Naturally, the post will also let you know what conclusion we came to on our end, and finally reveal the actual title of the game. Remember, up to this point Deathfire has always been merely a project title, in reference to the Nethermancer’s horrific spell. So, stay tuned. Until next time…

While cleaning up my hard drive just now, I stumbled across a neat image that I thought I’d share with you. Here, for the first time, I assume, is a look at the original artwork for Shadows over Riva without any logo and without any cropping. This is the artwork that as it was delivered to us by Ugurcan Yüce, the artist who created the artwork not only for our Realms of Arkania computer role-playing games, but also for virtually all of the “Das Schwarze Auge” pen&paper games the “Reams of Arkania” games were based on.

Ugurcan is not only an incredibly talented artists but also a very nice guy and I remember visiting him in his home numerous times, watching and admiring him at work while his wife would serve me traditional Turkish treats. At Attic Entertainment Software, we commissioned the covers for many of our games from him, not only the “Realms of Arkania” games, but also covers for titles such as “Fears” and “Der Druidenzirkel.”

Most strikingly, every time Ugurcan did a cover for us, he was nice enough to actually allow us to keep the original paintings for good. This is something very few artists will ever do—or only at a significant cost—and shows you just what kind of a guy he is.

Anyway, I thought I’d share this little gem with you real quick because I know there are many die hard Realms of Arkania fans out there. Enjoy!

Shadows over Riva cover artwork without logo

Oh no, it moves…

After a lot of the talk about some of the basics of the game, I thought it would be nice to have Marian discuss some of the work the art department has been doing on their side of things. So without further ado, here is Marian with some shop talk for you. I’ll be back next time with more info for you.


Hey folks! We did it! The first monster is in the game! And it looks… well… unhealthy. As it should.

I want to take you behind the scenes for a bit and talk about the creation of this monster, but since you can easily read almost everything about the steps normally taken by modelers on a site like www.zbrushcentral.com, I won’t go too far into the boring details.

With our first dungeon sets finished, we noticed that pretty soon we would need something that moves around in these labyrinths, so we can play around with it, and test the game mechanics within. At this point we already have lots of ideas for cool enemies and monsters scribbled out for the game, but to fully flesh them out, design them and then build them in high quality from scratch will take quite some time. Usually you start the modeling process with a scribble that you draw or receive from your conceptual artist that defines how exactly the creature should look like in the end.

Unless, of course, you already have a clear vision, in which case you would simply set yourself loose and begin modeling the creature straight away with Dynamesh in Zbrush. Alternatively, you could just fool around with Zbrush long enough until you managed to produce something decent out of it. Each approach may work, but more often than not, the approach artists take begins with the scribble. Since nothing about Deathfire is truly ordinary, our case was an exception, of course. ;-)

I recalled that I had the concept for a monster lying around in a backup somewhere. It was a monster I had thought of about ten years ago but never had the chance to actually use it. I had begun to model it back then but never got further than doing a basic few tests and getting the proportions in place. For me, it was the perfect starting point. I went back, loaded the model and began to re-imagine the creature, skipping the scribble stage entirely.

Don’t be disappointed, though, I created one nonetheless… just for you… after the fact… which is a whole lot easier by the way, because you already know exactly what it looks like.

Scribble of the Daggerlisk

Once I had the scribble, I jumped straight into 3DS Max and took a closer look at the old model I had created… and realized that not only were the proportions wrong, but also just what a mess this 10-year old mesh structure actually was. Time is hard on digital content as technology is virtually a runaway train and can change requirements overnight.

I knew I could load it up in Zbrush and give it a complete overhaul but it would be a lot of work. Still, it would still be faster than building it from scratch, so I fixed all the bugs and reworked it, creating an entirely new surface for it, while also tweaking a lot of the proportions. When it was finished I showed it to Guido and André for their suggestions and reworked it once again according to the feedback I got.

The Daggerlisk in ZBrush

Once it was completed, I exported everything to 3DS Max rendering out proper skin colors (Fig.A), the depth information for the normal map (Fig.B), a shininess map and the ambient occlusion rendering (Fig.C). All very technical stuff but very necessary to create a polished model.

The different stages of the Daggerlisk

That should be it, right? One would think so, but the fact of the matter is that models coming out of ZBrush have an incredibly high level of detail. Too much for game engines to handle, typically, and the next step in the pipeline was for me to create a version of the model that has fewer polygons.
I built a completely new low-poly model that was based on the new high-poly version, and while doing so I got to do the job every artist loves to do the most… (In case you have not noticed, I am being sarcastic right now.)

If you are into puzzles and brain teasers, you might actually enjoy unwrapping UV texture coordinates, but it is every bit as tedious as it sounds. Honestly. Try to distribute the space on a texture as evenly as possible over all the polygons of the model, eradicating the texture from stretching or being pulled in the wrong direction. Remember, the texture map of an object is like a skin, essentially, and if you tug and pull on one end, invariably, it will affect the rest of the model. Tweaking the points where the texture is attached to the wireframe model will help minimize the impact, but is a process that is incredibly time consuming and not a whole lot of fun. We might be making games for entertainment, but the work that needs to be done to get there can oftentimes be testing your patience and become every bit as mind-dumbing as any job.

It is possible to speed up the process using some functionality built into today’s software, such as relaxing the unwrap modifier, but there are still lots of minute details that you just can’t fix except by hand. And even then, there will always be some glitches that will keep you going back over and over again. The process is actually so boring that I prefer to listen to TV shows or Audiobooks during the entire procedure. That way, you get some head space and you don’t get itchy while checking all the polygons for hours and hours on end, until you found the optimal solution that gives you the (hopefully) least wasted texture space (Fig.D).

The wireframe model

With all that out of the way, the next step is to check if the proportions are still the same in both models. In the case of our critter here, I bought the model from 9 million polygons (high poly) down to 9 thousand polygons. Not a bad reduction at all. You can see the difference here in the wireframe models (yes, the right half of the model is a wire frame too. It is just so dense that it looks like a surface.).

With all the details rendered to a texture, I am loading the textures into Photoshop and begin layering them on top of each other until everything is perfectly fine-tuned and I am happy with the results. At this stage, I always find that getting input from your colleagues is the best source of feedback at this point, in order to get the details right. It is all too easy for myself to get lost in the wrong details, and a different set of eyes always provides a new perspective, pointing out things I may have overlooked or became too complacent to care about. This kind of feedback is often the source of good ideas, as well. André was my second set of eyes in this case and together we tweaked the textures to get the most natural or — in case of our undead friend here — the most scary look out of it. I think it is easy to see the improvements in the following image.

Some modifications and variations

I have no doubt that we will still have to continue applying minor tweaks as we go along and utilize the model in our Unity environment. But for the time being, the Daggerlisk is complete and exported. Time to move on to some of the other denizens of our world, most of which will not be drawn from the animal kingdom, but lean more into fantasy lore.

The finished model of the Daggerlisk

That’s it for this time. I hope you like that you’re seeing.

Marian

P.S. Oh, and yes… it also moves…

As the development of Deathfire progresses, we have reached a junction in the development of the game where we would like to get direct feedback from the fans. We want to hear your opinions!

Since it has always been one of our foremost intentions to share as many aspects of the development with you, the fans, as possible, we feel that getting a feel for certain elements regarding the game from the fans is the logical next step.

This is your chance to become a part of Deathfire!

This is your chance to make a difference… we are putting together a limited focus group to evaluate one of the most critical aspects of the game. It will be a very easy task for those participating, that will require no more than a handful of mouse clicks and a few minutes of their time.

If you are interested in becoming a part of the first Deathfire Focus Group, please fill out the form below and we will add you to our list of interested candidates. From all submissions, we will then select 25 participants at random to move ahead with.

Update: We are sorry, but at this time we are no longer accepting submissions for the focus group. It has already been conducted, in fact.

A first look at the user interface

Before I get into the next Development Diary entry for Deathfire, I wanted to point you all to a new interview with me on The Nerd Cave. It is an interesting – I think – look at the different aspects of my career, not only the games most people are familiar with. But now back to our regularly scheduled programming… more Deathfire stuff. :)

It is a common occurrence in game development that you have to make design decisions based on incomplete information. Why? Well, because at the time you design many aspects of a game, the game itself does not really exist yet. You are merely projecting what you want it to be. Therefore you have to make a great many decisions based on whatever information you have at the time, and what you expect the gameplay to be like in the final product. It is probably hard to imagine for many people, but game design is a very iterative process. Especially as the complexity of the game and underlying systems grow, the requirements will most likely change as well. Somewhere down the line, play testing may show flaws and weaknesses that will have to be addressed, or entire parts of the system show themselves to be flawed, tedious or outright un-fun. No one has ever designed the perfect role playing game in a single attempt, ever. You make decision, rethink them, revise them, reiterate them, adapt them and then repeat the entire process until one day you ship a product.

While working on Deathfire, the other day we stumbled into such a scenario, which I think illustrates this very nicely in an easy to understand manner. The item in question were the character status boxes.

UI sketch These small user interface elements serve to give the player a quick overview over the characters in his party, their health, their mana, their condition, etc. They also allow the player to access more information and to make various character-specific selections, such as attacks and spells, among other things.

I made a list of components I felt needed to be part of this character box, mocked it up very quickly in Photoshop, and forwarded it to Marian so that he could think of a proper graphical representation for them. Instantly the question for him became, “Should we do it this way, or maybe make tall slim boxes, or rather wider ones?”

He worked out some ideas and showed them to the rest of the team. You can see the initial designs below. As you can see, they follow the same kind of general design pattern, but each version is created with a specific focus in mind. One focuses on the portrait, while another one favors the attack and spell slots, and so forth.

Once we saw these, it became clear that with our original premise, these boxes would use up a significant amount of screen real estate. Deathfire will have a party that consists of four heroes. In addition to that, the player can recruit two additional NPCs at any given time, resulting in six character boxes on the screen. With all the information displayed, this a not insignificant amount of screen real estate to deal with and the last thing you want is for these boxes to cover up vital areas of gameplay.

Different versions of the character status box

First versions of the character status box that we evaluated

While these were great first attempts, they felt a bit too design heavy and not what you would really need in the actual game. In addition, the important elements seemed to be drowned out a bit by the bulky borders and decorative elements. In a word, we felt we weren’t quite there yet. We decided that we needed to optimize this somehow and for that we needed to envision more clearly how the player is going to play the game. While we have the game engine up and running with our 3D environments and some basic core functionality, we have yet to reach the point in our prototype where it is possible to really get a feel for the way the game will play in the end. Therefore, we had to extrapolate and sort of play the game in our minds, and as we did so, a few things became obvious.

Another version of the character status box

An iteration of the character status box, but we felt it ran too wide.
Note, however, the lines are all much slimmer than before.
This is not final art and the portrait is merely a mock-up

There was a lot of stuff in those original character boxes that we didn’t really need. At least not all the time. So we thought that maybe we could create boxes the display the minimum of information and when the player moves the mouse over them, each respective box will expand to its full size, allowing access to the full set of features. The next step was for us to decide what that minimum of information actually is that we need to relay to the player at all times.

Small status boxDo you really need the character’s name, for example, all the time? One could argue that the portrait is enough, particularly if we allow players to customize them the way we have in mind, but since we are creating a game in which interaction with NPCs and among the party members themselves will be very frequent, we felt that it is, in fact, very important that the player always has an indication as to who is who, when they are being referenced by name.

But what about those attack and spell slots? Because we have a turn-based combat system in Deathfire, it is not essential for us to give the player instant access to his weapons and spells. In real time combat, yes, the player needs access to his weapons, which represent the attacks, within a fraction of a second, but in real-time combat, the combatants take turns, which means there is proper time for the player to make his selections without rushing things. If we automatically expand the box for the character whose turn it is, this should turn out to be pretty slick and efficient, actually, also serving as a visual guide as to whose turn it is.

The expanded character status box

The expanded character status box with weapons equipped.
Note: This is not final art and the portrait is merely a mock-up

Usually the on-hand weapon slots also serve the purpose to Use items in role playing games, such as potions or tools. However, we reckoned that while that is true, it is not an all too common occurrence, particularly not one that is typically time critical, so the brief delay that expanding the full box would incur during a mouse-over should be acceptable. There is also still enough meat for the player to grab the box and drag it to a different place so that the order of the party can be easily arranged in the game, while mouse-over texts will relay additional information, such as the actual points of health, etc.

In my original layout specs, we also had a small toggle that allows the player to switch between a panel displaying the equipped weapons and one displaying the hero’s quick-spells. (Quick spells are memorized spells that can be fired at a moment’s notice without further preparation. They are complemented by non-memorized spells that require significantly more time to cast.). Upon playing the game in our minds, we realized that this toggle, too, is really needed very infrequently. For the most part spell casters would want to have their quick spells accessible while melee and ranged fighters would want their weapons accessible. The player would then occasionally switch these panels, but for the most part we expect them to remain fairly static settings.

Therefore we decided the toggle does not need to be available at all times and could be safely removed from the mini box. Incidentally, as Marian was working out his designs, it turned out that we do not need the toggle at all, because we can fit the weapon slots and the quick spell slots all on the enlarged pop-under box.

UI sketchWith all that in mind, we decided that we really just wanted to display the portrait, and the health and mana bars at all times, along with the hero’s name and a small digit that represents the character’s level. Character states, such as poison, paralyzation, etc can be easily color-coded into the portrait, or displayed as mini-icons alongside, and damage markers can be painted right over the portrait. All in all a pretty neat affair, I would say. For now… because who knows? Once will begin actually playing the game in earnest, we may find that our assumptions were wrong and that have to re-design the boxes once more, but such is the life of a game developer. It is the nature of the beast. Game development is an evolution, even after doing it for the umpteenth time.

On my Twitter feed, as well as here on the blog, a few questions have arisen, regarding the “Bind item on equip” option displayed in the Item Editor. It is an option that is highly unusual for a single-player game, and some of you are wondering what’s up with that.

“Bind on Equip” has been brought to the table by massively-multiplayer online games in order to prevent players from using and then selling valuable and unique items to other players. It forces the player to consider‌—‌if only for a moment‌—‌if he’d rather use the item or make money off it.

In retrospect, I find it strange that this feature has never come up in single-player games before, because at its core, the rationale remains the same. Perhaps we have all just been too blindsided to realize its existent potential. After all, they are not uncommon in mythical lore and popular fiction. James Bond has a gun that is attuned to him, and so does Judge Dredd, and even the magic wands in Harry Potter work that way. Excalibur, the mythical sword from the Arthurian saga or Ulysses’ bow are also perfect examples of bound or attuned weapons, so it is only sensible to carry the concept over into games.

When we bind items in Deathfire, it will be mostly for the same purpose. While buying and selling items in the game may not be the driving factor for item binding in our game, other aspects of it are. In Deathfire’s game design I want to use it to force the player to think about certain decisions. In this case, which party member should I give the item to?

If you give it to the wrong character, you’re robbing yourself of another character’s opportunity to make better use of it, perhaps, because the item can no longer be traded among party members. If you give it to an NPC, he or she might run away with it at some point. More importantly, it prevents that you take a truly powerful, unique weapon from an NPC who just joined the party to give it to your favorite character and then boot out the NPC. If you equip it, you’re no longer able to sell it or barter it away. What if the item is unique and part of a quest, and in the end you learn that only a certain character can use it, all the while you already bound it to someone else? On the other hand, the binding weapon you just found might be so powerful that the lure of it is simply so strong that you throw all caution in the wind and equip it anyhow, against your better judgement, because you hope it will help you overcome that mob of Golem Guardians awaiting you.

Decisions, decision, decisions… the lifeblood of a good role-playing game.

These are aspects the player has to consider, and like a cursed item‌—‌which is bound, though it does not come with the warning label of a bind-on-equip item‌—‌it can have consequences to equip such a weapon or piece of armor. It is that decision-making that I think has an interesting value, because it adds depth to the role-playing aspects of Deathfire. Giving away this additional layer of complexity and player involvement, simply because using bound items in single-player games seems unorthodox, would seem silly to me, now that it’s on my radar. Who knows, this may even turn out to be a feature other games will pick up as well… and why not?


Catch Me If You Can book coverDon’t forge that we are still running a give-away for those who are willing to help us spread the word about Deathfire. This time around you can win a copy of the ”Catch Me If You Can: The Film and the Filmmakers” Pictorial Moviebook. This full-color book includes not only the entire script of the Steven Spielberg movie starring Tom Hanks and Leonardo DiCaprio, but also various photographs and behind the scenes tidbits about the making of the movie, as well as an introduction by Frank W. Abagnale, whose unique life story the film is based on. You’re interested? Well, just make sure you collect entries for the give-away below, and don’t forget, you can obtain more entries every day for the duration of the give-away, simply by tweeting about Deathfire.

a Rafflecopter giveaway

For the past few days I’ve been working on some exciting things in Deathfire, that have propelled the game forward quite a bit in my mind. Items. Sounds trivial, I know, but items are the salt and pepper of any role-playing game.

It started when I decided to make a weapons list for the game. We have been working on parts of the user interface for the past two weeks or so, and it got to the point that I wanted to see some weapon icons in the respective slots. In order for Marian to begin drawing some icons, we began making a weapons list. It started out quite innocuously, but once I got into it, the list grew very rapidly, and at the end of the day we had a list of over 150 weapons for the game. And that is just the first go at it, not including any quest items and not including any unique, named weapons, which we plan to feature prominently in the game.

Adding all those will easily double the number of weapons in Deathfire, and I have no doubt that on top of that I probably forgot a good number of cool weapons that we will want to include in the game as we go along. All things said, in the end, I would estimate that we will have somewhere between 300 and 400 weapons. Just to give you a comparison, Shadows over Riva, the third of the Realms of Arkania games had less that 100 weapons. In fact, looking over the game’s source code showed me that the entire game contained a mere 480 items. So, in essence, it looks as if we will have nearly as many weapons as Shadows over Riva had items. Nice!



Here are few examples of the weapons from Deathfire
(Temporary artwork)

But a weapons list like this is useless, of course, if the items don’t actually make it into the game. I mean, anyone with a spread sheet can make a list easy enough. Especially, when Marian sent me a number of weapon icons a few days later, I really wanted to see these items in the game. It is quite interesting to note at this point that even in this day and age, there are no really qualified tools in the market for game design. (I am aware of articy:draft, of course, but since it is a Windows-only application, and horribly overpriced at that, it is of no use to me – or many other game developers for that matter, aside from the fact that it uses a very specific approach to game design from what I’ve seen, that seems to shoehorn you into specific patterns.)

The reality of game design is, that it really is a jungle out there and that to this day, most designers still use a lot of tools that are not really meant for the job, such as regular word processors or spread sheets. These inadequate tools typically create their own set of problems, especially because the data have to be somehow transferred from these document or spread sheet formats into data the game can actually use. It is a process that is tedious and error prone and often results in a lot of extra work, not to mention that designing item lists with item properties inside a spread sheet is anything but a satisfying process in and of itself. So I set out to write an Item Editor to make our lives easier.

Among the endless list of cool things about Unity3D, the middleware engine we’re using for the game, is that you can fully program it, including the development environment itself. So I began writing our Item Database Manager as an Editor Extension which works right inside the Unity environment. Not having to switch to external tools is an incredible boon that can not be overstated.

I wrote an item class, specializations for it to handle things such as weapons, armors, keys, consumables, etc and then began to write the editor that would allow us to enter the items in an internal database where the game can directly access them. Here’s a little screenshot for you to see what it looks like.


As you may notice there’s a bunch of drop-down menus that allow us to make key selections and depending on these selections the editor window will actually change, as weapons have a different set of parameters than armor, for example.


Just by means of comparison, take a look at what one of the external editors looked like that we used for the Realms of Arkania games. Bit of a different world, isn’t it?


When you take a look look at this Deathfire Item Editor I wrote for Unity, the window also gives you a good idea for the level of complexity we are building into his game, I think. This is a first go at the weapons, of course, but already you can see that there is tremendous flexibility built in to customize these weapons in many ways.

Nonetheless, I am certain that I’ve forgotten certain fields that we will need to add to the items as development progresses and requirement change or grow. Magic items, for example have not yet been properly tackled in the editor, as I will need to provide a hook to the magic spells/abilities the item may have. However, one of the truly great side effects of having this item editor and database right inside Unity is that it can grow with the game. Unlike static data formats imported from external tools, where you always have to be very aware of changes and additions to the data fields, here we are working with much more organic data that will adjust easily – and mostly automatically – to new requirements as we work on it. The amount time that procedure saves is invaluable while it also minimizes effort and hopefully errors – though that is always a double-edged sword. In development terms, convenient does not always equate safe.

To round out this post, I thought I’d give you a quick glimpse what the player might see in the actual game in the end, when calling up the stats for the weapon. This image is entirely temporary art, of course, but I think it illustrates the point nicely.



Temporary art for illustrative purposes only. Not an actual game item

Items may not be the most glamorous of things to talk or read about, but as you will agree, they are an integral part of any role-playing game, and how many of you have ever thought about the actual process of getting these items into a game? Well, now you know…

I hope you found this peek behind the scenes interesting. Feel free to let me know what topics you are most interested in and what subjects you’d like me to cover most in future blog posts.

Please make sure to also read this follow-up article with more details on the bound and attuned items in the game.


Catch Me If You Can book coverAt this point I would like to congratulate Kevin N. as the winner of the last give-away. Kevin won himself a copy of “Sons of Anarchy,” which he should find in his mailbox soon. But do not despair, you can be a winner, too. I have prepared another give-away for everyone out there, willing to help us spread the word about Deathfire. This time around you can win a copy of the ”Catch Me If You Can: The Film and the Filmmakers” Pictorial Moviebook. This full-color book includes not only the entire script of the Steven Spielberg movie starring Tom Hanks and Leonardo DiCaprio, but also various photographs and behind the scenes tidbits about the making of the movie, as well as an introduction by Frank W. Abagnale, whose unique life story the film is based on. You’re interested? Well, just make sure you collect entries for the give-away below, and don’t forget, you can obtain more entries every day for the duration of the give-away, simply by tweeting about Deathfire.

a Rafflecopter giveaway

The technology behind “Deathfire”

As I promised, I want to talk a little more about the technology behind Deathfire today. I mentioned on numerous occasions that we are using Unity3D to build the game, but of course that is only a small part of the equation. In the end, the look and feel of the game comes down to the decisions that are being made along the way, and how an engine like Unity is being put to use.

There was a time not too long ago when using Unity would have raised eyebrows, but we’re fortunately past that stage in the industry and—with the exception of some hardliners perhaps—most everyone will agree these days that it is indeed possible to produce high end games with it.

For those of you unfamiliar with Unity3D, let just say that it is a software package that contains the core technologies required to make a game that is up to par with today’s end user expectations. Everything from input, rendering, physics, audio, data storage, networking and multi-platform support are part of this package, therefore making it possible for people like us to focus on making the game instead of developing all these technologies from scratch. Because Unity is a jack of all trades it may not be as good in certain areas as a specialized engine, but at the same time, it does not force us into templates the way such specialized engines do.

In addition, the combination of Unity’s extensibility and the community behind it, is simply unparalleled. Let me give you an example.

The character generation part of a role-playing game is by its very nature a user interface-heavy affair. While Unity has solid support for the most common user interface (UI) tasks, that particular area is still probably one of its weakest features. When I started working on Deathfire, I used Unity’s native UI implementation, but very quickly I hit the limits of its capabilities, as it did not support different blend modes for UI sprites and buttons, or the creation of a texture atlas, among other things. I needed something different. My friend Ralph Barbagallo pointed me towards NGUI, a plugin for Unity that is specialized in the creation and handling of complex user interfaces. And his recommendation turned out to be pure gold, because ever since installing NGUI and working with it, it has become an incredibly powerful tool in my scripting arsenal for Deathfire, allowing me to create complex and dynamic interactive elements throughout the game, without having to spend days or weeks laying the groundwork for them.

While you can’t see it in this static screenshot, our character generation is filled with little bits and animation, ranging from the buttons flying into the screen in the beginning, to their respective locations. When you however over the buttons, tooltips appear and the buttons themselves are slight enlarged, highlighted by a cool corona effect and when you select them, the button icon itself is inverted and highlighted, while a flaming fireball circles the button. While none of these things is revolutionary by itself, of course, it was NGUI’s rich feature set that allowed us to put it all together without major problems, saving us a lot of time, as we were able to rely on the tested NGUI framework to do the majority of the heavy lifting for us.

Interestingly, it turned out that some of NGUI’s features far exceed immediate UI applications and I find myself falling back onto NGUI functions throughout the game, in places where I had least expected it. It now serves me as a rich collection of all-purpose helper scripts.

When we began working on Deathfire’s character generation, one key question we had to answer for ourselves was whether we should make that part of the game 2D or 3D? With a user interface I instantly gravitate towards a 2D approach. For the most part they are only panels and buttons with text on them, right? Well, Marian asked me if we could, perhaps, use 3D elements instead. After a series of tests and comparisons we ultimately decided to go with a 3D approach for the character generation, as it would allow us to give the image more depth, especially as shadows travel across the uneven surface of the background, and offer us possibilities with lighting that a 2D approach would not give us. Once again, I was surprised by NGUI’s versatility, as it turned out that it works every bit as impressive with 3D objects as it did with the preliminary 2D bitmap sprites I had used for mock ups, without the need to rewrite even a single line of code.

Another advantage that this 3D approach offers is the opportunity for special effects. While we haven’t fleshed out all of these effects in full detail yet, the ability to use custom shaders on any of these interface elements gives us the chance to create great-looking visual effects. These will hopefully help give the game a high-end look, as things such as blooming, blurs, particles and other effects come into play.

These effects, as well as many other things, including finely tuned animations, can now be created in a 3D application, such as Maya and 3ds Max, so that the workload for it can be leveraged across team members. It no longer falls upon the programmer to make the magic happen, the way it is inevitable in a 2D application. Instead, the artist can prepare and tweak these elements, which are then imported straight into Unity for use. It may not seem like a lot of work for a programmer to take a series of sprites and draw them in the screen in certain sequences, it still accumulates very quickly. In a small team environment like ours, distribution of work can make quite a difference, especially when you work with artists who are technically inclined and can do a lot of the setup work and tweaking in Unity themselves. We felt this first hand when Marian and André began tweaking the UI after I had implemented all the code, while I was working on a something entirely different.

This kind of collaboration requires some additional help, though, to make sure changes do not interfere with each other. To help us in that department a GIT revision control system was put in place, and it is supplemented by SceneSync, another cool Unity plugin I discovered. SceneSync allows people to work on the same scene while the software keeps track of who made which changes, so that they can be easily consolidated back into a single build.

Together, these tools make it safe for us work as a team, even though we are half a world apart. Keep in mind that Marian and André are located in Germany, while Lieu and I are working out of California. That’s some 8000 miles separating us.

While it may seem intimidating an prone to problems at first, this kind of spatial separation actually has a bunch of cool side benefits, too. Because we are in different time zones, nine hours apart, usually the last thing I do at night is putting a new build of the game in our GIT repository so that Marian and André can take a look at it. At that point in time, their work day is just beginning. They can mess with it to their hearts’ desire almost all day long, without getting in my way. When necessary, I also send out an email outlining problems and issues that may require their attention just before I call it a day. The good thing is that because of the significant time difference, they usually have the problems ironed out or objects reworked by the time I get back to work, so that the entire process feels nicely streamlined. So far we’ve never had a case where I felt like I had to wait for stuff, and it makes for incredibly smooth sailing.

But enough with the geek talk. I’ll sign off now and let you enjoy the info and images so that hopefully you get a better sense of where we’re headed. Next time we’ll take another dive into the actual game to see what’s happening there.


On a slightly different note, I wanted to congratulate Tobias A. at this point. He is the winner of the “Silent Hill” Blu-Ray/DVD give-away I ran with my last Deathfire update. But don’t despair. I have another give-away for you right here… right now.
Sons of Anrachy coverJust as last time, help us promote Deathfire and you will have the chance to win. This time, I am giving away a copy of Sons of Anarchy: Season One on Blu-Ray Disc. In order to be eligible for the drawing, simply answer the question below. But you can increase your odds manifold by liking my Facebook page, the Deathfire Facebook page, or by simply following me on Twitter. It is that easy. In addition, tweeting about the project will give you additional entries, allowing you to add one additional entry every day. Good luck, and thank you for spreading the word!

a Rafflecopter giveaway