About this blog
Chronicling the development of the Fountaindale video game
Entries in this blog
Jakub finished up the third look & feel concept scene:
This scene is actually direct out of the first demo. Note how there's nearly nothing in it; this is just the way the first demo will be: very spartan. We intentionally kept the number of models low to reduce the time required to push the demo out. In the proof-of-concept (2nd) demo, the city of Nahelam will populate this area and the area behind the camera. The number of models required will massively increase, as will the number of NPCs and static objects.
James and Danny continue work on the engine and some shaders to achieve the look of these pieces. The outlook is good, and it'll be exciting to see what we come up with. Stay tuned!
For further updates, visit the Fountaindale website.
The completed second "look and feel" scene came in:
We'll have a third shot in about another week that will be representative of the specific atmosphere and setting of the first demo.
As mentioned previously, it looks like coders will have a fun time implementing this look. We're looking for a shader programmer right now, so if you're interested, please send me a message.
Other development continues...trying to finish up the architecture (hopefully our new modeler will be able to knock those things out). Terrain implementation is proceeding as well. Some heavy work will be going into the GUI really soon. We're still shooting for an end-of-May release for the first demo, but we've got quite a bit of work to do on the art asset side to meet that deadline. The requirements are fleshed out...we just need a few people to help on development.
The GDD has undergone a pretty good revision. I've solidified the twist band and battle system concepts, and the character development system is pretty firm at this point. There's still some work to be done, but I think we've got a pretty good system going now; there shouldn't be anymore huge revisions to the gameplay concepts from this point on. All of this work is in preparation for the proof-of-concept demo we'll start work on after the first demo rolls out.
Shouldn't be too many more weeks before we'll have actual screenshots to show. Wow...won't that be something?
Long overdue, we've finally got our first scene to give the team a solid idea of the overall look we're shooting for in the game. Thanks to Jakub Kujawa for his efforts on this piece.
It'll take quite a bit of effort to come close to this look in the actual game, but the overall visual look is one of the big ticket items that will make Fountaindale different from everything else out there. I don't know about everyone else, but I'm sick and tired of seeing the same old tired, boring, and plain 3D rendered look in so much stuff out there. If we can get something close to the piece below, I think we'll have something really special and unique on our hands.
We're back with a force, with refocused effort on asset creation and a huge boost in the programming side with James Kleinecke, who has brought with him his "Firefly" game engine. James is doing great work and has integrated the Ogre 3D rendering engine into Firefly. The coders will be working on the rest of the Fountaindale requirements over the next months.
While our art team is still thin, we're making some decent progress and should be dropping our first model into the engine very soon. It's a big step for us!
We're working on finishing up modeling and texturing on the humanoid models for the first demo, then quickly from that into animation. We'd like to get some animations running in the engine as soon as possible, so that's where the asset creators are focusing their concentration.
Work continues on the character development system. The "Essence Flow" character development system, as I've dubbed it, is coming aong well. The picture I've posted here shows the entire "board," as it were, in the inset. Comparing the main graphic and the inset, you can get an idea of the sheer scale of this thing. In total, there are 565 anchor points with an average of six or seven unique "powerup nodes" per anchor point. That yields over 3,500 individual powerup nodes. That gives plenty of opportunities for players to vary the development paths for the six main player characters currently slated for the game.
The real work in the system design is putting together all of the data. Each anchor point, it's relation to other anchor points, the nodes and anchor points it contains, and the attributes of the nodes themselves (point value and powerup value) must all be created. Designing the calculations to manage the interdependencies is pretty fun, but time consuming. Lastly, and proceeding side-by-side with creation of all of that, I've had to create a system to evaluate/test all of that data. This sub-system will save loads of work in the future in the tweaking and testing phase by enabling evaluation of all of the choices the player could make. We've got to do this to 1) ensure the player is able to develop characters comparable to the battles being fought and time spent in different areas, and 2) ensure there aren't any areas a player could gain an undue advantage early on in the game ("cheating" the system). It's a blast!
None of this work will be reflected in our first demo, but some of it will be in the second (proof of concept) demo. In the code, the handling system will be fully implemented, but only a small portion of the essence flow will be available for player use...enough for players and reviewers to get an understanding of how the system works...and enough for the players to actually have fun using it.
For those interested people, an online version of the game design document is now posted at http://www.fountaindale.net/gdd Take a look if you're curious - we always appreciate feedback.
The Fountaindale Team
Having somewhat solidified concepts for the battle engine (though not fully), I've moved on to designing a new system for character development. I hadn't devoted any time to this part of the game's design, and as it is closely related to the battle engine (as far as what skills, spells, etc. characters will be able to use), I figured that I needed to do so.
In the old game concept, I hadn't given players any control over how the game's player characters (PCs) developed. They each followed a linear path, with all of their skills hard-wired into their characters, slowly gaining abilities as they gained experience. It's the old-school style, really, but even this is more restrictive than the first Final Fantasy game. (In that game, you had to choose which spells you purchased for your mage; while the choices were very limited, the element of choice was present, and the player's choices had real consequences, i.e. the inability to use a spell from a particular level when the mage's "spellbook" was full).
In RPG game design, and particularly in the storytelling aspect, character design is of central importance. As a designer, I've developed PCs with specific characteristics and leanings...warrior, mage, what have you. Not only does the graphic design of each character depend on these characteristics, but so do the sorts of actions they perform and the dialogue they say within the story. From the design standpoint, I therefore have a vested interest in having PCs develop along these lines - to gain skills that are consistent with their design.
However, that leaves the player with little real choice in how PCs develop in the course of the game. Without designing an absolutely huge set of skills from which to choose within each character archetype (for example, having different skillsets within a warrior class that the character could choose from), a designer, if he wants to give the player choice, is forced to allow the player to develop PCs in a way that is inconsistent with their original design.
Systems like this aren't unprecedented. In the later games of the Final Fantasy series, players have generally been given the freedom to develop characters in any way they want to. Players are given nearly unlimited choice in which path to develop each PC, no matter if its consistent with their designs. Finaly Fantasy X, though, offered a nice compromise between hard-wired development and complete player freedom.
"Guided character development" is a term I use to describe such a system. While players have a significant amount of freedom in how to develop characters, including having them completely cross-over into "unintended" classes, the character development system design strongly suggests to the player that perhaps the best way to develop a particular PC is also the easiest. This "optimal" path is designed to be consistent with the character's intended design. In such a system, players are still given wide latitude in how to develop characters, but the paths that lead to the fastest development (and the strongest characters) are the ones that are consistent with the characters' overall designs.
Such a design is nearly critical for an RPG in this day and age. I've started to design a unique implementation of this concept for Fountaindale. While not revolutionary, I would call it evolutionary. This system, combined with what will hopefully be fairly innovative battle gameplay, will help to make Fountaindale stand out from the background noise. Once I solidify the concept more in the coming weeks, I should be able to showcase something here.
After some work on the battle GUI, it seems that having a unified display method for health, skill points, and essence makes the design sleeker and easier on the eye than anything else I've come up with. So the twist band has evolved from a double-helix to a triple-helix, with one band representing health, one representing skills and skill points, and the last one being the one that essence is held in (which also doubles as the wait timer during battle). Jakub is working on some sketches to illustrate the whole concept. The ones shown below, while not true to our visual style, show the revised twist band and an essence weapon:
The sketch on the right is truer to our overall desired look (thicker lines, more comical).
Here's a shot of a battle GUI mock-up:
The elements are explained in the picture, but for anyone who's reading this, I'd really love to hear any feedback or suggestions you have about this sample GUI - namely if it makes sense or not. Even though you may not understand everything about it, does it make sense with the text explanations? Can you tell what is what (specifically with the representation of the twist band)?
You can see that the essence band of the twist has four slots to hold essence. I think that having a large icon to show the type of essence in each slot is a good way to go. While it will take the player a little while to get to know all of the different icons and their meanings, the game should introduce them at a learnable rate; that, combined with intuitive depictions (i.e. a little flame icon = fire elemental essence), should make the display easy to understand.
One element in the picture that may be slightly misleading is the presence of large numbers in the upper right-hand corner of each essence slot box. These numbers aren't numbering the slots; the number "1" will pop up when essence is drawn into each slot, indicating level 1 essence. If the player "boosts" the essence (to make it more powerful), the number changes to "2" and so forth. This gives the player a quick visual snapshot of the complete status of each character's twist band, and what's available for him/her to use in battle.
As always, comments are welcome. We're here to serve you, and the more input we get, the better the end product will be. :)
Alright, so I've decided to let the cat out of the bag a bit to those of you who read this journal (who, based on the number of hits, number few). Originally, the Fountaindale game project's combat system had no unique quality - it basically consisted of your run-of-the-mill computer RPG point-and-click interface, with weapons, armor, skills, and magic, and all of the other standard aspects of RPGs. Well, that's just too boring, and in the emerging market of indie games, it certainly won't help a game stand out from all of the white noise. Furthermore, indie games are supposed to tread new territory - places where the mainstream game industry is unwilling to go based on its risk-vs-reward calculations. In short, we needed something different and exciting.
The Use of Magic
Early in the concept development process, I had decided I wanted a robust magic system that enabled players to customize spells. Concept development went down several paths, but one idea in particular stood out: giving certain player characters (PCs) the ability to draw elemental properties from the surrounding environment, similar to a geomancer in some RPGs on the market. As I went down this road, I was able to eliminate standard elemental magic spells (fire, ice, earth, etc.) from the repertoire of magicians in the game. This got the wheels turning in my head, and I thought of eliminating the entire standard magic system and replacing it with something similar to geomancy, where PCs could draw out "magic" from either the environment or enemies in battle.
A concept similar to the one I was developing was already in existence in a mainstream game (Final Fantasy VIII), so I knew I couldn't simply copy it. Not only was the whole draw system a real drag (in my opinion), but it completely eliminated any kind of PC specialization vis-a-vis magic. An idea then popped into my head: give PCs the ability to manipulate the elemental stuff they draw out of the environment or enemies. Once a PC drew essence, it could have the ability to change its properties, make it more powerful, or do a number of other things to it in order to change its effects once it was used (on either an enemy or a companion PC). I'll explain more of this a bit later.
Following in the footsteps of eliminating the standard magic system, I was taking a look at the huge list of weapons I'd created for the game. Again, this list had nothing really original in it. So I extended the concept of drawing out elemental and other magical abilities from the environment and enemies into the realm of weapons. In my mind, if a mage can obtain everything needed in battle from the environment and enemies, why shouldn't a warrior be able to do the same? I was attempting to create some consistency in the entire battle concept, something that could span the entire spectrum of different character classes. So the concept of drawing some sort of "attack material" out of enemies was born. But I needed a physical object to hold whatever all this drawn-out stuff would be...
The Birth of the Twist Band
At this point, I felt like I was on the cusp of creating something truly unique, but the concept was still very lofty and unrefined. If I wanted to eliminate all traditional weapons, I needed to have something to replace them; specifically, I needed to create something that was customizable...something the player could quest for...something that could be upgraded, or that would grow in power, in order to give the player a sense of fulfillment and satisfaction.
The twist band started out as a simple "container" to hold the stuff that would be drawn out of enemies. It was originally a simple object that PCs would wear; this object would enable PCs to draw out and then use "essence" from the environment or enemies in the battlefield. In the simplest form of attack, a player would draw out "physical essence" from an enemy (which would be stored in this object), and then "throw" the essence back at an enemy to attack it. Well, that concept is quite rough, and a little too ethereal for actual gameplay. I still had quite a bit of development to do...
Away with Weapons...Why not Armor as well?
Now that I'd started down the path of eliminating all traditional weapons (swords, axes, etc.), I thought to myself, "If there aren't any weapons, there shouldn't be any armor, either." This is where the twist band concept really took off. By eliminating both weapons and armor, I was able to create a single object that held both offensive and defensive characteristics. Even further, I decided that the twist band could actually represent the characteristics of the PCs themselves. The twist band would be a physical extension of the bodies of the PCs - a separate object, but bound to the PC, inseperable for the entire game. Given all of these ideas, it didn't take long to come up with a visual concept for what the twist band would look like - as we all know, DNA takes the form of a double-helix; it seemed fitting to have the twist band object take the same shape...a double-helix that wrapped around the PCs entire arm - one side representing offensive power, one representing defense, and the entire object an external physical representation of the collective power of the PC.
Concept development for the twist band:
Refining the Concept
Armed with this new concept and having turned my back on virtually all of the mainstays of traditional RPG battle, I thought I had a pretty good launching point for developing a unique combat system.
The idea of drawing essence out of enemies, manipulating it, and then using it back on enemies to attack is a good starting point, but it isn't enough to allow variance and strategy development in actual gameplay. Further, we needed more definition in exactly what was what on the twist band if we expected the player to actually understand what this thing was. So this is what we came up with:
One half of the twist band represents the inherent skills a PC will learn throughout the course of the game. As the game proceeds and the player fights in battles, the power of this half of the band grows; over time, the PC gains specific skills, some of which are shared by multiple PCs, and some of which are unique to each character (hard-wired character specialization). In addition, this half of the twist band represents the amount of power available to the PC to perform these skills. Basically, it's like mana, or skill points.
The other half of the twist band (the more interesting part) also has a dual role. First, and most importantly, it physically holds the essence a PC has drawn out of the environment or from enemies. Second, this half of the twist band acts as the "wait timer" in battle, which determines when it's a PC's turn to act. We are thus able to maintain at least some element of turn-based combat. (I won't go into the nitty-gritty details of how the wait timer works here.)
Drawing and Manipulating Essence
Now for some nuts and bolts. In combat, PCs are able to draw different types of essence from enemies. Different enemies will have different types of essences, and the types a particular PC is able to draw is dependent upon his/her twist band (again, hard-wired character specialization). Generally, essence falls into one of these categories:
Once essence is drawn into the twist band, PCs have the ability to manipulate it, as mentioned previously. Players can:
The range of skills listed here virtually eliminates the need for standard magic, and it allows the player flexibility in exactly how to use the essence he/she directs each PC to draw.
- "Boost" essence to higher levels to make it more powerful
- "Reverse" essence; reversing physical essence transforms it to have healing properties; reversing status essence does the same; reversing elemental essence transforms the essence into its elemental opposite
- "Meld" essence to PC's twist band to give it offensive properties of whatever kind of essence is used
- Give essence a "block" property to raise the defensive properties of a PC's twist band
- Give essence a "purge" property to remove any melded or blocked elemental, status, or physical effect currently on an enemy or PC
- Give essence a "weaken" property to lower the defensive properties of a PC or enemy against the type of essence used
- Give the essence a "volume" property to give it a wide-area effect
The ability to perform all of the manipulative skills above is gained as the player progresses through the game - not all are available at the beginning of the game. In addition, as stated before, not every PC will have the ability to perform all of these skills, and the types of essence they can use certain skills on is determined by their twist bands. For instance, only a couple of PCs will have the ability to reverse physical essence, and thereby heal other PCs. Determining which skills to give to which PCs, and at which point in the game to do so, will be finalized in the process of play-balancing and -testing.
In addition to the skills listed above, PCs gain power as the game progresses by building up the twist band's capacity to hold essence. At the beginning of the game, PC's twist bands can hold only one essence draw. As the game progresses, PCs gain the ability to hold more essence draws in their twist band, up to a total of four. These essences can be shuffled around and manipulated individually, giving the player the ability to build a complex "stack" of essence in PCs' twist bands to use.
From the battle concept development file:
I'm currently toying with a couple of extra ideas:
The Issue of Customization
- Combining essences in the "stack" - giving the player the ability to combine, say, a physical essence with some sort of elemental essence in the twist band could either open up doors to interesting gameplay, or it may be redundant with existing concepts.
- Passing essence between PCs - there's the potential to design gameplay situations in which having one PC draw essence, then pass it to another to manipulate and/or use it could be beneficial, or in some cases, required. It would, however, be dependent upon enemy design. Making more complex battle situations would, though, likely improve gameplay satisfaction and would probably require the player to devise different strategies to defeat enemies, based on their observations of what can and cannot be done at different times in battle.
In this day and age, character customization is vital to interesting gameplay. Most of the customization I've discussed thus far is "hard-wired;" in other words, the player himself/herself can't change it; the player's actions in the game have no effect on what the PCs in the party can do. In order to provide this vital gameplay element, we came up with the concept of a "crucible." The crucible is an object that attaches to the twist band itself (see picture above), and adds certain attributes to the twist band.
Each PC has one - and only one - twist band throughout the entire game (since it represents the powers of the PC). Crucibles vary in size and attributes, number many in the game, and are interchangeable. When essence in the twist band is used, it is channeled through the crucible attached to the twist band. For physical essence, the particular crucible attached to the band determines what sort of attack the PC will be able to conduct:
Again, the complexity of the system we end up with will be partially determined by how complex we are able to make enemies. Obviously, if blunt, edged, and piercing weapons have the same effect on all enemies, there's no point in having this sort of differentiation.
- As physical essence is channeled into the crucible, an "essence weapon" forms. The type of weapon formed depends on the crucible; this weapon can then be used to attack an enemy. Once the attack is complete, the weapon dissipates.
- At this point in time, we're using a fairly typical set of attributes to describe the types of essence weapons crucibles can form:
- Blunt, Edged, or Piercing
- Melee or Ranged
Further customization is enabled by inserting certain items into slots that crucibles have (the number of slots is specific to each crucible). Currently, we have two different types of items that can be attached to crucibles, although we may end up deleting one:
Simply put, the player will decide which crucible he/she wants to use for each PC based on:
- Animatia - this is quite an old concept in the life of Fountaindale. Animatia was originally designed to enable players to give elemental properties to weapons and armor. Chunks of animatia could be bought, found, or won in battle, and by fusing them to weapons, the player could give PCs' attacks an element-based property. By fusing them to armor, the player could give PCs increased defensive properties. While the way animatia are used in this concept is different from "materia" in Final Fantasy VII, the concept itself is fairly similar. For this reason, and due to the fact that this concept duplicates the "meld" and "block" manipulation skills listed above, we may drop this feature.
- Attribute Stones - these are basically "power-ups" that add certain trait boosts to PCs - HP bonuses, skill point bonuses, speed boosts, etc. While not a unique concept by any means, the twist band system enables us to come up with unique attributes (such as auto-boosting essence, giving PCs the ability to draw essences they otherwise wouldn't be able to, etc.) Further, attribute stones' power can be raised as the game progresses (we're still working on how exactly to implement this concept).
We have the ability to create a vast array of crucibles with different properties to give the player a plethora from which to choose the perfect fit for his playing style and strategies (some may increase the strength of elemental essence, while decreasing the strength of physical essence, for example).
- the strength of the crucible's essence weapon
- the number of animatia slots in the crucible
- the number of attribute stone slots in the crucible
- whether the crucible produces a blunt, edged, or piercing weapon, and
- whether the crucible produces a melee or ranged weapon
Say Goodbye to Menus
Nothing I've written so far has anything to do with actual battle gameplay. How exactly will the player interface with this crazy system? When talking with the concept developers I've been working with, one thing we determined we really wanted to stay away from was the use of menus. Menus are boring and tedious, and a player's relative skill in a menu-based RPG battle is based on how fast he/she can maneuver through menus to select a skill. We wanted to move away from that; we want to create something that players can "get good at."
We're leaning heavily toward using mouse gestures to direct the gross majority of combat actions. Once a PC is selected, a mouse gesture over an enemy will draw essence; the type of essence drawn will depend on the type of gesture executed by the player. (Still, only essences contained within the enemy can be drawn out.) Once essence is in the PC's twist band, the player can use a separate set of gestures to manipulate that essence according to the PC's abilities. Once engaged to an enemy, still further gestures direct different attack moves. Based on our designs, once a PC is able to conduct multiple, simultaneous physical attacks (by first drawing several physical essences into the twist band), certain moves could be conducted in quick succession to produce more powerful results and special/hidden moves.
Different gestures will also direct non-physical attacks (such as using elemental or status-based essence) and healing/curative/defensive skills.
As part of the hard-wired character specialization, some PCs have special skill sets independent of the essence-drawing system (represented in one half of the twist band, if you remember from before). Were we to design specific mouse gestures for all of these skills, the number would probably be too great for your average player to remember. Thus, we probably won't be able to completely sever the tie to some form of menu-based selection for these special skills. However, we do aim to greatly limit the intrusion into the core gameplay of whatever menu-based UI we come up with.
Well there you have it - a good overview of the battle system we hope to implement. This is quite a long post, but for those of you that made it all the way through, I'd love to hear what you think. We're aiming to completely solidify the entire engine in the next two or so months in preparation for starting on the 2nd demo. So in short, we have time to add features, delete others, and simply distill the concept into something really great and unique. Comments welcome!
Our new modeler, Tony Indindoli, is cranking out some great low-poly models for the static objects required for the first demo. Kudos to Tony for his great work.
We've filled the gaps in architecture concept art for the main buildings in the demo. Additionally, the majority of the remaining static object requirements have been fleshed out.
Mark continues to hammer out details of the terrain handling system.
James and I are tossing more ideas back and forth on the combat system, and I think we're coming up with some great stuff. We've got about four months before the entire system needs to be defined in preps for the 2nd demo, and I think we're well on track to meet that goal.
Ryan, Kjell, and I are also working on revamping sections of the website to make them more interesting, informative, and more visually appealing. We may have something to show along these lines before Christmas.
All in all, we continue to make slow and steady progress. Thanks for everyone's help and support so far. As always, we love hearing comments and criticism from anyone out there!
A demo commoner work-in-progress:
We lost one member and one won't be able to work on the first demo. Mark and Jason are capable of handling the coding requirements for the time being. Jason continues work on the front end while Mark is hammering out the terrain handling system.
Main architecture models are underway, as are static objects. The Areth model is 90% complete based on the last word from Tito.
Turnaround sketches for all demo characters is complete. Main building models are nearing completion.
Music and Sound
Most of the sound requirements have been filled. Two of four music themes are complete, with the other two coming quickly.
We're still looking for a few people. See our post in the Help Wanted board.
How did it take me so long to come to grips with the concept of task management?
For the longest time, I've known that two things I've needed to do as a producer is to 1) create a complete asset list, and 2) create a production schedule for all of the art team members. Several months have passed since I realized this, and yet it hasn't been until the last several days that I've made concrete progress on these two items. Why did it take so long?
In retrospect, it really surprising, as I've got a good six years of real-world experience managing projects, creating task lists and schedules, and slowly making daily progress on very large projects. Granted, the types of work I've managed before (and currently do) are not at all similar to video game production, but the basic concept is the same. It's infuriating that it has taken me so long to get an asset production schedule down on paper.
The good news is that we are nearing completion on such an asset list and production schedule. This will accomplish several vital functions: 1) It will give the team clear guidance and deadlines. 2) It will help identify gaps in human resources so we can conduct targeted recruiting. 3) It gives us a better idea of when the demo can be completed.
Creating the schedule was a bit of a chore, and I'm confident it will change as we go along. I understand that with time, one increases one's proficiency in gauging how long it will take people to complete tasks. Since I don't have much experience in this particular field, the schedule will be fairly fluid for the time being. This'll be especially true given that our team works only part-time.
All told, it looks like we'll be opening up our Help Wanted post again in the very near future. The clarity provided by the asset list and production schedule should alleviate, at least to a certain extent, the lack of productivity we've thus far experienced.
Who else out there thinks running a virtual team is hard?
I guess I should consider myself lucky, as I actually got some real-world, hands-on experience running virtual teams. Working for the government, I got the opportunity to coordinate a load of people located all over the world to achieve common goals. Of course, it's relatively easy at work as we have tons of fancy-shmancy communications gear that we can virtually reach out and touch someone.
Remove the fancy equipment, or more accurately, remove the massive budget (thank you, taxpayers) required to acquire and use this equipment, and you're left with the indie game developer conundrum: How do I get my team to communicate effectively?
That's a tough one. I've been struggling with it for a while. My team is currently stretched all over the world - England, Eastern Europe, all around the US and Canada, and Australia. We even had a temp team member from Japan. Getting everyone together at the same time for a wonderful staff meeting is virtually impossible - I tried. Since I can't get everyone together at once, I'm forced to get only some of them together. In fact, I prefer to talk details chiefly with the leads of each section, leaving it up to them to communicate down the chain. This not only streamlines your team, but also empowers your leads. For this type of communication, email works alright, but IRC or an IM client works much better (for obvious reasons). VoIP is also a great, cheap way to get a quick and clear exchange of information between two (or a small handful) of team members.
For a virtual team spread around the world working on completely different timetables, I've found a web forum is critical for group communication. Ideas and issues can easily be aired by anyone on the team, and everyone else can chime in if they've got an answer or opinion. Beyond this, forums allow everyone on the team to see firsthand the level of activity of the rest of the team, even if they're not directly involved with certain areas. 3D modelers, for instance, can virtually see activity in a programming board; while the modeler isn't directly involved in coding, he receives a bit of reassurance that progress is being made in little 1s and 0s that will eventually give his model life in the game.
In order to provide a summary of activity and to keep everyone updated on the "big picture" of the project, I also put out a weekly newsletter over email that gives such info. It's short, so it doesn't take anyone much time to read; it's got neato pictures to attract the eye; it lets the team know that, even if activity in the forums has been low, the project is still alive and breathing. Finally, it gives me a chance to give credit where credit is due and to highlight specific accoplishments of specific team members. ...I hope it gives everyone a virtual warm-and-fuzzy.
So that's my little rant about communication in a virtual team. Bottom line: it's absolutely vital. Virtually.
Howdy doody everyone...
On the heels of our huge coding team change (read previous entry), I've finally been able to designate a Lead Artist. Up to this point, I had been playing this role (fairly poorly, I might add). Francisco Silva, who had been on an extended vacation, returned, and has decided to take up the shabby reins that have attempted to provide much-needed direction to the wonderful artists we have on the team. Over the course of the next couple of weeks, I hope that, with Francisco, we can create a great asset production pipeline and clarify every individual's place in that pipeline.
This is a much needed change, as my understanding of asset pipelining is pretty limited (I've read books, but I have no real-world experience). Francisco will bring in some real-world experience, combining it with other members' experience in order to (God willing) create a really kick-butt art team. The potential and talent is certainly there; it'll be my job, and Francisco's job, to coax the beautiful art out of these great artists.
So as the coders continue to hammer out all of the code for the base framework, they're also helping the modelers with the plethora of technical questions relating to the capabilities and limitation of the OGRE rendering engine. ...and there are plenty. Over the course of the next three to four weeks, the coders should be able to assemble that base framework, and we may even have some ultra, ultra-preliminary visuals from this. It may not look like much, but the amount of effort that would be reflected in that little executable is enormous.
I've attached a "for release" version of a labyrinth concept that has pretty much completed development. It'll be the first labyrinth of the game, and while it won't feature at all in our first demo, we do plan on implementing this beast for the "second demo," a.k.a. The Last Adventure of Nahelam. For y'all out there, this is more just a piece of eye candy than anything else. I hope you enjoy.
See the website: http://www.fountaindale.net
Ah, the biggest problem facing any business: finding and keeping good people; it certainly is a helluva task. Read any book about business, and it's probably in there, along with suggestions on how to deal with the issue. And yet, every business will struggle with the problem as long as it's in business - it's one of those cold, hard, facts of life.
My mother, who manages a small business, often commiserates with me about trying to find and keep people with a good, honest work ethic. (Her situation is infinitely more critical than mine: the business she manages depends on people to produce profit, whereas mine is just a hobby at this point.) Even with a rigorous hiring process, intense training program, and incentives up the wazoo, attracting hard working people is a tough job. Of course, the more you can offer, the better position you're in.
Enter the indie video game developer. What does this guy or gal have to offer? In most cases, almost nothing of the traditional forms of compensation can be offered, because the indie developer simply doesn't have access to the dough. Offers of future compensation based on any profit a finished game might make is about the only financial incentive an indie producer can offer, and on a project with a long timeline (like Fountaindale), that's normally not too terribly attractive.
So what's an indie to do? How does an indie attract good, hard-working game developers willing to commit to a big project? Well, in my experience, it's not too difficult to attract a glut of people who claim to be interested in the project. With just a bit of concept art, a website, and a catchy idea, the masses flock. But beware! Most of these are like moths attracted to a light that's just been switched on, and many may drop a project about as fast as they picked it up. Even for indies, a screening process for potential help is required. So far, I've had eight people leave at the drop of a hat, without a single word. (Others have left due to extenuating life circumstances and had the courtesy to tell me.)
As if attracting good people was hard enough, keeping them can be even more difficult. My mother refers to her office as a "revolving door," with secretaries and technicians passing in and out of employment so often she can hardly keep her head straight. Each new hire has to be brought up to speed (i.e. trained) and integrated into the office. The same goes for indie game development. Each person that leaves a project has the potential to leave a path of unfinished, possibly incomprehensible, and, in the worst case, unusable "stuff" behind (be it models, art, or code); each new person has to take the time to learn the entire project and integrate with the team. Ultimately, progress is severely slowed if turnover is too high. That certainly doesn't mean that you should just hold onto people that aren't performing, though.
For me, it seems the more interested in the project someone is, the more likely they are to stick with the project - through the good times and the bad. While it's nearly impossible for me to judge just how interested someone is (a situation exacerbated by the inability to talk face to face), the amount and frequency of communication is a good indicator. Someone that responds to emails or forum posts in a timely manner is probably more motivated and interested than someone that takes a week to respond. In the early stages, these are the people to keep - the people that can help generate cross-talk between a fledgling team. It's a big bonus if you get people with good heads and some experience - these guys can help answer questions other less experienced team members might have.
And thus, I've had to cut three members of the coding team for just this reason. Although they all seemed to be very interested in the project and motivated to work on it, they each disappeared without a word. Two months on, the coding team is looking to make great strides, but needs that extra, experienced help. Those who could have provided that help are no longer around, so we've welcomed Mark Johnston to the team to take over as lead programmer. Mark is already providing a much needed "push" to the project, and we look forward to working with him.
Ok, so after the long rant last week (thank you for the positive comments), I figured I'd give a few more details on our first project. We're creatively calling it the First Demo.
The Basic Idea
Drawing from a bare-bones design document that was itself derived from the full game's design document, the concept behind the demo project is to create a very small but complete, self-contained, and playable 3d RPG-style game set in the world of Fountaindale.
Reasons for undertaking the demo project include:
- To learn, troubleshoot, and refine the tools and processes we'll be using. While this mainly applies to the coding side of the house, it also applies to our asset creation pipeline and the mechanics of getting all of the models, animations, art, music, and sounds into the game itself. The coding team is doing a lot of hard work putting the basic framework together to make this happen.
- To solidify the team and build team cohesion.
- To prove to ourselves we have the ability to tackle the much larger Fountaindale project.
The first demo will:
- correctly display 3d terrain, objects and buildings (including three to four interiors), and animated characters contained in a designated section of the main city (Nahelam, shown in picture);
- have one player-controlled character, with input handling in accordance with the design document;
- have an automated, semi-player-controlled camera in accordance with the design document;
- apply basic pathfinding algorithms;
- correctly play all music, sound effects, and environmental audio;
- have a short storyline comprising three small quests, requiring correct handling of conditional tree user input and game state change handling;
- contain two pre-scripted animation sequences ("cinemas"); and
- contain all aspects of the full-game GUI (with the exception of battle-related GUI elements).
For the first demo, we will NOT implement:
- any battle-related functions; or
- saving or loading.
Our goal is to make a very simple, yet highly polished, playable little demo.
So What Have We Done?
So far, we've managed to make an executable with a start screen, cursor, and buttons. The coders are working on implementing the camera and terrain display functions, and we still have some stuff to figure out along those lines (like just exactly how we want to represent terrain internally). We'll be toying around with that over the next little while.
Concept art is driving quite a bit of the modeling production, and now that we've got a decent rate of concept art production, the modelers have a bit more stuff to work with. They're working on the characters, animals, building, and objects required for the demo. Although the requirements are fairly minimal, it's still a decent chunk for a new, small team to bite off.
Brian Moody has created some mood music for Fountaindale that may or may not make its way into the first demo. The music was actually written for the central forest itself, which unfortunately is not a setting in the first demo. He's currently working on a theme for Fountaindale as a whole.
How Long Will it Take, and What's Next?
We're shooting for a March 31, 2007 alpha for the first demo. That may seem like a somewhat liberal estimate for the size of the project and the number of people working on it, but based on the rate of work we've witnessed over the last several months, March 31 is probably about right. We'll press for that, at least.
After the first demo is complete, we should have a really good framework for implementing the rest of the game. The next chunk we'll bite off will be the first part of the actual game (whereas the short story in the first demo occurs before the full game's story). We're calling this "The Last Adventure of Nahelam," and it should incorporate around 4-5 hours of gameplay. We'll work on implementing saving/loading routines as well as the full-on battle engine. That will keep us plenty busy. We'll also fully model the entire city and castle of Nahelam, the underground of the city, and the first labyrinth of the game (the Cave of Four Seasons). At this point in time, I estimate it will take another 12 months after the first demo is finished to complete The Last Adventure of Nahelam. The current plan is to market and sell The Last Adventure for a low price.
So I thought I'd put the names of the folks that have or are currently contributing to the project:
Lead: Francisco Silva
Models: Tito Belgrave, Leonard Krylov, Dean Thomas, Tony Indindoli
Animation: David Landers, Tito Belgrave
Textures: Jon Nickel, Samuel Hyry
2D and GUI: [Vacant]
Music & Sound
Consulting and Design
Web Development and PR
Well, this is sort of a long time coming for me. For those of you brand new to this project, it actually started about seven years ago with a simple sketch. This one, to be exact:
That thing sat on the shelf for a while, there in that journal, just collecting dust. I took it out later, and when I looked at it, a flood of thoughts came to mind. These thoughts formed the backbone of the mythology of the world that would keep the name from the original map: Fountaindale.
In the years from '99 - '05, I occasionally took the map out and jotted notes down - sometimes in the journal, sometimes on pieces of scratch paper, or sometimes actually typing my thoughts out staring at a computer screen. I always managed to keep a hold of those papers and files, though.
Sorting out the world...
Then about a year ago, I finally decided to assemble and sort through all of the papers, files, and thoughts I had been collecting for six years. What came out of those several months of work was a cohesive mythology, history, backstories, and a front story that could be used in a game. After all of that was sorted out, I started in on the actual game design for another several months. After creating enough world, puzzles, labyrinths, and extra quests for the monster of a story I'd made, I slapped it all down on a scanner bed and zapped it in. I could now share it with others via the magic of the internet.
I made the first post gamedev.net in January of '06, asking for help in just about every area I could. The responses came slowly, but steadily, and I soon had a small team doing very little. Although I had a lot of content (a LOT of content), I hadn't yet decided exactly what to do with it, and just how to do it. Some of the folks left the project, so I took some time off, read a couple of books, and decided to bite off just one small chunk of the Fountaindale world and concentrate on that, leaving the rest to be uncovered at a (much) later date.
With the help of Alex, a guy who has become a real stalwart on this project, we narrowed my small goal down even smaller - to the size of our current demo project. It's a tiny little thing, but it's the right size for the team we now have; we expect to finish it sometime early next year. We're making slow and steady progress, which is just fine for a bunch of guys and gals working part time.
So here it is, about eight months after I put the original "help wanted" post up, and got me one o' these developer journals going. Feel free to drop me a line...in a project as long as this, encouragement is helpful. But this dream of mine won't die as long as I don't.