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:
Continue reading →
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!
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!
Making a game is for me the supreme collaborative effort: you have to involve programmers, artists, sound people, testers, writers, etc… Even if you’re working solo on a game, you always have other people giving their opinions…
So, the team is pretty important in any game development, and that is why I decided to present the team behind Grey.
There’s a common history for us, and that is Spellcaster Studios. All of us have worked in Spellcaster Studios (back when it was an actual company), and 75% of us are founding members…
So, without further ado, I give you the team:
Carlos “Elaiwon” Oliveira: The tyrant behind our efforts… Carlos does a bit of everything from coding to producing, but more importantly, he keeps me and the rest in line, focusing on actually making the game, instead of going “oooh, this is cool, what about if I can make another shader…”. He’s one of the co-founders of Spellcaster Studios, and he was actually the one that got us to take the idea of making a game into reality… before that, me and Rincewind would spend our time talking about making games, instead of actually developing them!
He’s got a background in telecom engineering, but one of his big dreams in life was producing movies… when I started talking to him about games, he found out that games are way better, and decided he wanted to produce games instead… Poor misguided soul… 
Diogo “Covenant” Andrade: This is me… I’m the (main) game designer, besides doing programming. I’m also the co-founder of Spellcaster Studios, an idea that was brewing in my head since I was about 10!
I’ve got a background in software engineering, and loads of work in about all fields of it (but mainly multimedia and telecom-related software)… I’ve been in love with game development since I saw my first ZX Spectrum game: “Tennis Cup”, but it took someone a bit more realistic to actually get me to do something in that field for real…
Diogo “Rincewind” Gomes: Le artiste… He’s the artist behind everything we make: concept art, modeling, texturing, skinning, animating, UI work, everything! He’s also a co-founder of Spellcaster Studios (and another victim of my game development ideas back in the 90’s).
He’s got the most eclectic background of us all, spanning from the the Naval Academy, physics, architecture and arts… Like all artists, he’s a bit spacey! 
Joana “Nimue” Gomes: Another programmer, she shares the programming duties… She was actually the first employee of Spellcaster Studios (besides the founders, of course). She came for an internship about 6 years ago, and she loves us so much she couldn’t leave!
She has a background in arts and in New Communication Technologies, which makes her the ideal person to work in GUIs all the time… 
So here it is, the team behind Grey… Of course, there will be more people involved in the game; we’ll need sound and music, testing, etc… But this is the core people that get together after work hours, wasting their free time to make Grey a reality!
Creating a game is hard work… You have to get art, programming, game design, sound, music all working together to form a coherent, expressive work… And all of these have their own stages of development, different for every developer and creator…
For example, art begins with the concepts, then goes onto the modeling, texturing, skinning, animating, world placement, etc…
But all games begin (or should begin) with an idea…
The idea for Grey started in August 2010. At the time, I was entering the Ludum Dare 18th 48-hour game development competition. The idea of these competitions is you are given a theme at a certain time, and you have to make a game from scratch with that theme, in 48 hours. You can’t use pre-built assets of any sort (graphics, sound, music), and the use of code is limited to some established engines or small frameworks without any game code in them. I really love participating in these, since I learn a lot about streamlining game development processes.
That time, the theme was “Enemies as Weapons”, and I did a game called “Conquest” (which you can download here – it’s buggy like hell, but it includes the full source!). The idea of the game was to take the old “Tower Defense” theme and use the creatures that are attacking as defenders. You have a castle and you have to defend it from hordes of enemies until the “super-spell” is ready and it wipes all enemies… Enemies have different types and move in predetermined ways. You can “possess” an enemy (by spending some mana) and he will attack nearby enemies in an automatic fashion…
The idea was crude and I didn’t have much time to implement it, but it got my brain thinking, specially three days after the competition ended: I was at the dentist and she was late, so I started writing down some notes:
Doesn’t seem like much, but at the time my brain was on overdrive… “What if I add a player character that has to be protected?”, “What if that player can move in a game world?”, “And if I add a RPG-type leveling system to the creatures?”, “What if we can control the creatures with more detail?”, “What if…”.
At this time, I was just thinking on improving the existing game, adapting it for the new things I wanted in it…
Unfortunately, I was starting a new job at the time, and I didn’t have time to actually implement any of the ideas I had, but they were kept in the backburner…
Some months later (can’t say exactly when), I was thinking about this game again, and I was planning a story that could support the game mechanics I was musing about… After some hours of thinking, it hit me: Grey (the character, not the game) was born! I won’t say what exactly attracted me to this character (that would be a huge spoiler), but I felt the character, he was powerful in my mind… I wanted to make a game with him! What was just a support for some game mechanics had become a strong concept by itself, and I really wanted to work on it. The idea was so strong, I was loathe to even share it (and the spoilers) with my closest friends, so that I could implement it and then could see their expressions when they found out the depth of the character!
I soon dropped down from the clouds and started “recruiting” some of the old Spellcaster Studios team, so that we could go back into game development. This was easy, since we all worked together at the new place, and we all still love games!
The main problem was that we only had our after-work time to work on anything, so we decided to start small… First we started designing an episodic shoot’em up game called “Ray Gunn” (similar at first glance to titles as Alien Breed and Shadowgrounds); while we were still in the concept/design phase, we had to do some iOS applications for work, we found it nicer than we expected and we shifted our focus from the (already megalomaniac) shooter to a more iOS/Android-friendly game: “Cell.Action”.
We completed the main code and art for the game when our artist fell ill for a couple of months… Needing him to progress on the game, and the fact that this kind of “casual” game doesn’t appeal that much to me, I started dabbling with my world editor application again…
All through this, I never stopped thinking about Grey (at the time, I thought of it as “The Summoner Game”), and I was musing about doing the game by myself, just as a proof of concept.
In the meantime, the rest of the team was looking at the lack of progress on “Cell.Action” and were considering about quitting (finishing an indie game is hard work, from a motivational standpoint), but we decided to do a last try.
We decided to do it a bit differently than most times: instead of thinking of a game that we could actually build and sell (in essence, a “commercial game”), we decided to think about a game that WE actually WANTED to build… a game WE wanted to play… a game WE wanted to see!
The rationale behind this was that we spent a lot of time on Spellcaster Studios trying to play it safe (we had other responsibilities), mixing games (that nobody paid us to develop) and applications (that we had clients for) : we had to put bread on the table…
That got under our skin, and made us have difficulty in thinking in any other way, and more importantly, stopped us from thinking like we did when we weren’t “professional”…
But now, we’re not professionals anymore: we have a normal paying job, and games are something we do for fun, so we should have fun developing them!
From this process, I decided to divulge my idea for Grey, and oddly enough, everybody loved it (oddly because normally the selection of a development idea is not unanimous by a long shot). We saw this as a good sign, and we proceeded to cull the idea so that we could actually implement it… from there, came the episodic nature, ideas for process streamlining, etc…
But the important thing is that an idea that I had for more than one year was finally underway to be implemented!
So, after the announcement, a question that I got asked was (obviously) “What is Grey?”.
Well, in a one-line kind of thing, Grey is a “an episodic RPG/RTS hybrid, set into a fantasy world”.
In Grey you control the titular Grey, a recently awaken dead person that quickly finds out that he is a “Life-Shaper”, a person (or in this case, an undead) that has the capability of creating life from nothing and control it. The player will be able to create different types of creatures, each with their own abilities, strengths and weaknesses and command them in battle.
So, the game is a kind of RPG/RTS hybrid. From the RPG, we took the heavy story-driven structure (albeit in an episodic fashion, but more on this below), the stat-building, leveling, questing and other paraphernalia associated with the genre. From the RTS we take the tactical nature of combat and the fact that we don’t depend only on our character for success, but rely on all the creatures that we create.
Continue reading →
Welcome to the new site/blog of Spellcaster Studios.
The launch of this new site marks a new beginning for Spellcaster Studios aswell, and what better way to celebrate this than with an announcement!
We’re currently starting the development of a new game, working title “Grey”.
But why is this different from what we’ve been doing in the last years?
At first glance, nothing… We love game development, and we’re always developing new things… But “Grey” marks the first time in the last years in which we’re actually doing a game that we actually all agree we want to make, un-pressed by the need to make something that’s within the current game development trends for small studios (mobile platforms, lo-fi games, advergaming, etc), but only constrained by our view and execution ability, in what we believe is a professional manner.
Of the four friends working on this, only one of us is working full time, the rest is working “after hours”, but we intend to keep following a development process that just looks at this as a time-constraint, and not as an excuse to do a worse job managing and developing this game.
About the game itself, for now I’ll just say that “Grey” is an episodic RTS/RPG hybrid game…
We still have no definite publishing/marketing/commercial approach defined, that will be decided in the near future…
Another thing in which this new project differs from previous ones is that we want to document everything we can, from the “normal” art and tech posts, to the more subtle discussions about game design, the proposals on the table and why we decided to go this way or another… We want to open a window into the game development process, not only to help us keep focused on the tasks and issues at hand, but so we can interact with our future audience and see what you, the reader, has to say about the ideas we have for the game!
For now, I bid you farewell, and until the next post!
