Rincewind wasn’t kidding when he told me he was rusty in 3d modeling, etc… But, after a long time, he managed to finish the texturing of the main character of Grey:
Spent most of the weekend working on the RPG system of “Grey”.
The mechanics of “Grey” require a stable (C)RPG foundation, with all the usual systems, like primary attributes, derived attributes, talent trees, equipment and buffs/debuffs, and building that is a challenge.
Of course, I could have used one of the dozens of open/free RPG systems available and adjusted them for my own needs, but to be honest, this seems like something fun and making “Grey” is supposed to be fun, so that’s the route we’ve chosen to take, although it is a challenging one.
We’re aware that balancing a RPG is no small feat, and we decided to tackle that issue from the beginning, creating tools that will allow us to do so.
This is RPGTester, the application we’ve made to use as a sandbox for RPG-system related tests. It’s just a console window that incorporates a full Lua parser (since the RPG logic is all built using Lua scripting), that uses the game files themselves as a basis for testing and reporting. It even allows me to rebuild the data files that build the creatures and classes built from the database with just one command.
So, I have creature definitions (for example “Skeleton”). This “Skeleton” has a class associated with it (in this case, “WarriorDPS”, which means that it is a melee offensive character). This class will be used for at least two things: to select the AI to use on this character and (more important for our current discussion) to choose how the basic attributes of the character evolve with its level.
There are currently 5 basic attributes on “Grey”:
- Constitution (CON): This describes how built the entity is, and affects directly the health pool size.
- Strength (STR): This describes how strong the entity is, and affect how much damage the entity deals in melee combat, and how much damage he can absorb in melee defense.
- Dexterity (DEX): This describes how agile the entity is. It affects how good the entity is at dodging physical attacks, and how precise he is with ranged physical weapons. It also affects how fast the entity moves and how fast his action resource fills up
- Intellect (INT): This describes how smart the entity is, and affects how large the mana pool size is. It also generally affects the power of any spells cast.
- Willpower (WIL): This describes how powerful is the will of the entity. This mainly affects regeneration rates (for health, mana and others), the power of the some spells and more importantly the life-shaping component of the game
These will probably change over time, as we test out the game and tune the mechanics, but this will serve as a basic guideline for now.
Now these will evolve over time, and I had to find a formula for this. I decided on a linear equation, since I want these attributes to scale smoothly over time, since they serve as a basis for most of the others (like critical strike chance, etc).
To account for the different class/roles, I had to add some weighting that’s stored with the class. The reason for this is that it doesn’t make much sense to have a “Life Shaper” character having as much CON as a Warrior. This will make entities like healers to be squishy, while warriors will be very hard to kill but don’t deal that much damage.
I had also to guarantee that the classes were normalized. That means that for a specific level, characters of a specific class don’t have more attributes than characters from another class. To guarantee that, I created a test on RPGTester that checks for the normalization (in the screenshot above you can see a “test_attribute_normalization()” call being made to test it.
After that, I had to test the values of the attributes themselves, to see if they were being prioritized right depending on role. For that, I created a report (which is just a tab-separated value table) that lists the values of the attributes over the levels. Then I imported that data onto Microsoft Excel and plotted graphs that allowed me to look at the data:
In this case, 4 reports leads to 4 graphs, and you can see that for example Life Shapers will have more willpower, while mages have more intellect; and both of them have less constitution than warriors.
Since Excel has a sweet dynamic dynamic link system, so every time I want to see the impact of changing the computations of the the attributes, I just need to run the report tool and press a button in Excel to see the graphs changing. For example, in the next screenshot, I just changed the calculation of CON to be with the square of the level (kind of explodes, I know):
And because I can’t resist playing around, going with squared on everything:
I’ve only listed 20 levels, but episode 1 won’t even probably have that (we’re aiming for 10 levels, at this moment).
On top of this class-based evolution, each character itself can have modifiers for the attributes, so we don’t have to make a new class for a specific creature that should have more health or spell power.
Next step on the RPG system will be to add the health pool calculations and displaying that in-game; should take me the next couple of days, since we’re all so excited with the development of the RPG system… It gives us the feeling we’re actually working on the game, instead of the technology, which is great for motivation (and the lack of motivation is the number one enemy of any group of people trying to develop a game in their free time)!
Work has kind of slowed to a crawl lately, since our real jobs are stressful of late, and after a day of complicated programming work, my night-time coding really takes a hit.
Still, I managed to make some progress with the GUI elements of the game.
The way I’m developing the game is to use my bad programming art and stuff I have lying around in my hard drive from previous projects to drive it forward… This way I don’t have to wait for Rincewind, and I get to experiment with the Lua scripts and see any pitfalls we have to be careful with.
Currently, I’m working on getting the player to select an unit (a friendly one) and command it to move to a specific place in the game scene, using path-finding. At the moment, the player can select any creature in the game world and see its portrait and health:
This of course is not using any final art, just beautiful programmer art!
On SurgeEd, I just built an image bank with a mouse cursor and a “selection circle” (that thing on the character’s feet). I also created another image bank with the portraits of the two creatures available in this experimental framework (the dark and the red robot). Then I added on the game database (a simple MySQL database) the fields for the portrait image name and ran my data file application (all without leaving the editor).
The data file application grabs tables from a database and converts it to a Lua file with the definitions, so I can use it in scripting. An example of one entry would be:
Classes["TestEnemy"]= {
base_faction="Neutral",
editor_category="Test",
lua_id="TestEnemy",
portrait="massive_dark",
template_name="DarkMassive",
type="Human"
};
I can then use this freely in my scripts.
In this case, every time the player clicks on the screen, a function that I registered is called by the event, I do some raycasting (to find out what has the player clicked on), if it is a character, I update the GUI on the right side of the screen (the health bar and the portrait, accessing the Classes table I automatically generated from the database), and I add two new 3d objects: the text on top of the character (simple billboarded text, although I have a lot of control over the way it is displayed, like color, facing, size, distance scaling, etc) and the selection circle on the bottom (a 3d sprite).
This is all done through scripting, and the code for this doesn’t take more than 20 lines or so, which is pretty economic…
And since I use LuaJIT to run the scripts, it’s very fast (the slow part is the raycasting, which is done in pure C++).
Now, I’m working on finding out where the player clicks the selected unit to go (right-click on the environment)… Already have a rudimentary system working, but it was a challenge getting to work, because it was hard finding a way to transfer array/list data from C++ to Lua without making it overly complicated from an usage standpoint…
In the meantime, Rincewind is still working on the main character’s model, but he won’t let me show it yet (which might be a good idea, since he’s missing the top half of his head while he does the hair)… I’m very happy with the results of the normal mapping on the face, specially considering all the problems we had on the weekend with it…
On “Grey”, we want to use normal maps to add some detail to the basic geometry of the models; this is pretty common in modern games.
The way we do it at the moment is to create a texture that describes the bumps in the surface (white is for “high”, black is for “low”):
Then we process this with a tool by NVidia that converts this to “tangent-space normal maps” , which is fancy name to describe the distortions to the surface (from a lighting standpoint):
This image indicates a the distortion to apply to the normal of the surface (the normal can be thought as the way a surface is pointing). The base color you see (most of that texture) is the “neutral” color, which means no distortion… the more you deviate from that cover, the more distorted the normal will be and that allows us to simulate small surface details.
All this is done through some magic math that transforms the light properties into a local space called “tangent space”, that is calculated at each vertex of the model. You can read more about this at Wikipedia, for example.
Anyway, this is all fine and dandy, but we’ve run into some problems with it:
You can see the big seam along the middle of his shirt? That’s because we use “mirroring” on the texture coordinates (which is a mapping between the real world coordinates and the 2d image that we use to color the model). The mirroring allows us to use half the texture space than normal (we only store half of the model, the rest is “mirrored”), but it introduces this problem, because the tangent space mapping is no longer continuous (it goes one way, and instantly changes direction to the inverse one, simply put), and this shows in the illumination of the model…
This problem is very common, even in high-end engines, because it has to do with the mathematical model of normal mapping itself, and while it is easy to disguise it in static models, animated models usually show this problem at some point in the geometry.
There are ways to minimize this, by tweaking the texture coordinates, or doing some magic voodoo on the normal map texture, or any number of tricks, but we’re trying to figure out a way to minimize the time we spend on each model, since we’re a small team and time is our most precious commodity!
We’ve spent some hours in the weekend wrestling with this problem, trying to figure out why the problem occurred (from a mathematics point of view) and what we could do to minimize it, but we haven’t found a single solution to this issue that might actually solve it without increasing our workload; the best we’ve come up so far is to avoid using mirroring and just stretch the texture (which would allow us to add some more surface details, different on both sides of the shirt and robe).
We’ll keep on working on this, since it’s very important in this early stage to get a functional pipeline, even if it means delaying the initial models a bit…
Rincewind just started some 3d assets, and here is the initial results of the player character model for “Grey” (compared to the initial concept):
This is a render in 3d Studio (with a single light source). There’s probably better ways to do these renders, but we don’t want to lose time looking for something just for show-off.
This is just the base model, no texturing of any kind.
It has approximately 2400 vertexes, and 4200 triangles. Since this is the main character, we’ve stretched the budget a bit.
The main problem was that Rincewind was a bit rusty, haven’t modeled anything in more than 6 months… Another issue we’ve had some discussions about was how to model the hair… He decided for a polygon tangle that will be textured with alpha test. It’s not as dynamic as a physics based system, but it should be enough for the purposes of this game (since the camera is usually set in a bird’s eye perspective). Another discussion we’ve had was about rigging the face for facial animation, but since we still don’t know if we’ll have the manpower to actually do anything with that, we decided that if the need arises, we’re better off replacing this model with a more detailed one for cutscenes.
Another screenshot (now with two lights):
And the obligatory wireframe (polygons, not triangles shown):
He’s now texturing the model, so we’ll have a prettier version of this next week (hopefully).
Grey is a game that has a lot of Artificial Intelligence (AI), since the player is mostly on the role of a “general”-type of figure, commanding his minions.
One of the most important tasks in AI in this game will be the path-finding. Path-finding is the game subsystem responsible for finding out what’s the path a character has to take to reach a specified destination.
Although path-finding is something we humans do pretty easily, it’s another beast altogether to teach it to a computer.
On the simplest level, a path-finding system needs to figure out what are the “walkable” surfaces in the world, store them in a easy to access way with some additional information (what surfaces are connected to which other surfaces, etc) and then answer queries about the paths to follow.
I usually roll my own system, but this time I decided to do something different and use the open source Recast toolset. It has 3 different modules: building the “walkable” surfaces from generic models, answer questions about paths and a module to do dynamic obstacle avoidance (simply put, a module to make the creatures in the world travel without bumping into each other).
This has (so far) turned out to be an excellent decision, since Recast is very powerful and easy to use, even though the documentation is terrible. Thankfully, the API is simple and well designed enough for someone to pick it up and use it without any big issues.
So, I spent most of the weekend integrating Recast with SurgeEd.
First, I got the navigation mesh building:
A big slice of our development “budget” has gone into SurgeED, something I’ve been working on and off for the last two years…
SurgeED is a world editor with some “workspace” capabilities. The idea is that we don’t just author maps in it, we aggregate all our development tools and utilities into this unified system, which allows for compiles, change merges, automated tasks, etc.
At this time, it does most things world editors do, using Spellbook’s renderer for the viewport (so what you see in the 3d window is what you’ll see in the game, hopefully).
Then we have a tool, called SurgePlayer, which takes a workspace built with SurgeED (both in compiled and non-compiled form) and runs the actual game.
On the video below, you can see me mucking around several things, but mostly on the material editor… we almost didn’t put it in, thinking that the material editing would be done in the modeling tool, but after some debate, we started to see that we have much to gain in adding it in the editor… this way, we can make trees that are slightly different, without going into the modeler and creating a different tree, create objects that are just skinnable, preview shader effects, etc
Some features of the editor include:
- Standard object manipulation tools: move, rotate, scale, snaps, etc
- Support for meshes, helper objects (boxes, spheres, points, etc), lights
- Trigger system (helper objects with events tied to them, that call scripts)
- Automated backup system (no tool is 100% stable, specially one being developed “on-demand”)
- Full undo/redo system
- Custom object classes
- Custom object properties
- Template system
- Asset management
- Asset compilation
Happy new year, everyone!
Sorry about the lack of updates, but the holiday season is hectic for all of us.
We didn’t get as much work as we wanted on this season (but then again, we never do!). For my part, I just scraped enough time between eating and being with the family to write.
Write what, you may ask?
Well, flavor text and lore information. The lore information is mostly for us to keep us designing a coherent world, without many loopholes and such. The flavor text will be used in several books in the game world, which the player can find and read. There will be even some achievements for collecting all of the books (if we have an achievement system at all, but that’s another story altogether, and probably the material for another blog post).
For me, flavor text is one of the most important sources of lore information in a game, without getting deeply expositional (which breaks the flow of the game). Having books with the information about the game world and about the game mechanics (in a “disguised” fashion) helps the player feel inside a real world, without breaking the gameplay component. Books and scrolls that you grab in the game world give the player a sense of reward (you’ve achieved something), and he can read them when he feels like it, instead of stopping gameplay.
I even intend (still under discussion) to have a separate storage in the game for all the books and scrolls you get, so the player can track which are still missing and read them all in a more coherent fashion, without taking up inventory space.
You can read below one example of flavor text. It’s a piece of a book that will feature quite often, since in the game world it is considered the basic pillar of any magic training.
We’re currently working on some more stuff on the editor, and hopefully I can do a video to show off some features of the editor (with silly programmer art, since our artist is just starting to work on the 3d models).
Principia Magica
By
Loremage Salvyo Korntak, First Principal of the Calabeth Archives
First published: 711 Age of Magic
Introduction
The nature of magic, like its origin, has been a source of debate for centuries. From an experimental point of view, magic can only performed by living creatures, so the link between life and magic becomes self-apparent.
But what is magic? Well, this author tends to agree with the definition of magic as Grand Wizard Antxonius Grey stipulated, back in the founding of Calabeth: “Magic is the manipulation of energy through the power of the mind to achieve results impossible through the application of manual or mechanical labor”.
If we hold this definition of magic to be true, we can extend the nature of magic to be the manipulation of life energy to achieve impossible feats.
Of course, the existence of undead mages can complicate matters further, since they don’t have life of their own, being tied to the life energy of an external creature, object and focus of power. This author believes that it doesn’t change the basic nature of magic, since there is manipulation of life involved, either in the empowering of the undead, or the feats of the undead itself.
Another source of discussion is the potential for magic. It’s apparent that every sentient (and some non-sentient) creature have some ability to manipulate life, but the extent in which they are capable seems to wildly vary. Some authors will defend that this is due to the “purity of the race/people/creed” or other such nonsense, but for me, the ability to wield magic is no different from the ability to wield a sword or create a song; it is due to different backgrounds and inclinations. That explains why the ruling casts are more prone to use magic in their day to day, since the “easy power” afforded by it *deliberate burn marks* the coddled.
In the following chapters, I intend to delve into all of these topics more profoundly, from the nature and types of magic, the history of magic and the fundamentals of life-wielding.
We’re still working on the architectural elements of Calabeth, and something very important from a game design perspective has come up: the map layout.
Episode 1 takes place in several areas, all centered around the mystical ruined city of Calabeth, birthplace of the Conclave and now overrun by an ancient evil. The player will be able to explore the city of Calabeth, some caves below it, the graveyard and a beach. While most of this is pretty straightforward to design in terms of art, the city itself has a series of difficulties:
- Scale: How large was the city? If it is too large, we have to cut it down and block access to certain areas, since we don’t have the resources to create a large city. If it is too small, we don’t have enough space for the main storyline and the side-quests.
- Do the city architects prefer open spaces, or more narrow alleys?
- What’s the architectural style? We’re still trying to distant ourselves from the usual western medieval style used in so many RPGs.
- What are the lore-based buildings that have to be present (for the suspension of disbelief to work)
- Modularity of buildings: this is a more technical consideration, but the idea is if we can build pieces of geometry that can be reused to build a series of buildings, instead of modeling a whole city! This requires good discussions between artist and programmers, since we’re still considering making a system to build the base city layout automatically.
- Environmental art: besides the buildings, what kind of props are visible, what kind of lighting is on the scene, fog, etc
Building the city has the added challenge of some of the engine technology not being ready yet, namely the decal system. The decal system will be very important to guarantee that the world is “real”, with dirt, and weeds, and cracks in the walls, etc.
These are just some of the discussions that we have at the moment. These have to balance out the time it will takes us to do things and the look we want to achieve, which are usually conflicting with each other…
We’ll be on vacation for the next two weeks, but hopefully that will give us some time to work on the game (although with Christmas is always difficult to find the time). Anyway, we should have some blog posts for your reading during Christmas!
15
Dec
So, what are we doing?
By Covenant | Filed in Art, Development, Game design, Games, General, Grey, Technology
Since we’ve decided to go forward with this project, we’ve been working like madmen, that’s what!
We’re currently in a design stage. This means that we’re currently working on game design and concept art, besides getting the technology on the point that we can use it to make this game.
There’s several different vectors in the game design work we’ve been doing, that complement each other:
- Lore: This is the definition of the world in which the game takes place, and the story of the game itself. Lore describes the history of the world and its denizens: gods, creatures, demons, the nature of magic, rise and fall of civilizations, etc. It provides us with the background necessary to create a cohesive world in terms of gameplay, even if most of the work there won’t be readily visible in the game (except by its consequences, of course). This has relatively low priority compared to the other game design tasks, since its not very concrete in terms of the game. Lots of things that are already part of the lore (needed to justify some game design and art concept choices) aren’t even written, and most are still very mutable according to our needs.
- Main storyline: This is one of the selling points of the game (I hope). The main story arc (a series of stories that make up a larger story) is already defined in broad terms, with the key events laid out, but the main storyline for episode 1 is still being written. Although we have the discrete important events designed already (the bosses, the rewards, what led to the confrontation), the writing itself is still missing (dialogues, voice overs, etc). This means that we already have a general layout for the locations in episode 1, but we’re still need to fill up the locations to really flesh them out.
- Side-quests: At the moment, this is only a collection of ideas; locations like “the haunted lighthouse”, or “the caverns below Calabeth”; characters like “the betrayed lover”; items like “the cursed book”; battle mechanics like “teleporting skeleton magi”. We need to work on this to create more coherent stories that Grey will have to explore to get some bonuses (like experience, creatures, etc). This will allow us to flesh out the locations a bit more, since they become more than just transition areas for monster bashing.
- In-game books: This will be the main source of background information in the game, and as such we need to write these “book excerpts” that will reveal more about the game world. I’ve not even started on this!
- Game mechanics: We’re designing a RPG, which means that I have to develop an entire battle system, and that means going over the mathematics of combat, besides “what feels fun”, while trying to steer clear of the main RPG influences (don’t want to rip off anything). I could try to get an “open-source” RPG system and adapt it to my needs, but that wouldn’t be so much fun!
All of this information is being written in our own internal-use wiki, so that we have everything cross-referenced and easy to access. Organizing information for everyone on the team (even a team as small as this) is a challenge, specially since changes must be easy to track (still working on this).
This wiki is mainly accessed by Rincewind, which turns the material into concepts.
He’s been mainly working on creature design, and he just recently started working on the architectural design…
We’re trying to create a distinct identity to Calabeth (the ruined city where the first episode takes place) from an architecture standpoint. Currently he’s doing experiments crossing arabic and germanic architecture.
On the creature design front, there were a lot of discussions about on how to build the art assets: should we use mount points for pieces of armor for the skeletons, or just create a specific model for each of the skeleton types? How do we create variety in monsters without too much work being put on the shoulders of our only designer? How do we make the pockets of poison in the Unstable Zombie, do we use bone scaling or just a pulsing emissive channel?
This has direct impact in the technology and as such should be discussed early. For example, we decided that it would be useful to add some level of material animation to the objects (which the engine already supports, of course), but we want that material animation to be viewable on the editor, which means that I have to add authoring tools on the SurgeEd for that… but we have to see if that will be used in more than on the the Unstable Zombie to make it worth our while to develop a system that will take about a week developing… This is the kind of decisions we keep running into.
On the technology front, we’re working mainly on the editor and in the editor/player integration. Although the editor is already a very powerful piece of software, it still misses some features that will make it more useful… For example, my last 4 or 5 hours of programming were spent getting object scaling integrated with the engine/editor, with correct collision detection… Next steps include creating the concept of a geo-cluster, which is a single object that aggregates the static objects that share some properties. We need geo-clusters for optimizing render calls (the main geo clusters), optimize shadowmap rendering (shadow clusters) and collision detection (collision clusters).
This in turn will be necessary to add the first piece of gameplay-related technology (until now, it’s all rendering-related): the navigation mesh that will support movement within an area.
The main goal at the moment, from the technology front is to get a prototype ready as fast as possible, so we can start playing around with the different concepts of the game, to find out exactly what is “fun” and what is “boring”, what level of micro/macro management is interesting, and which of these just seems like another job…
Most of us are currently out of the country for the company retreat (on our real jobs) for a couple of days, so I don’t expect much new stuff to get done in the next days, but keep coming to the blog for more information on the development of Grey!