Plan for Stephen Zepp
by Stephen Zepp · 01/03/2005 (6:18 am) · 3 comments
Well, the new year has settled in, and I'm starting to catch up myself. The last couple of months have been pretty intense in development for Nemesis Vortex, and it's been really nice to have the time to be a full time Indy Executive Producer, although even "full time" isn't even nearly enough to do everything that needs to be done!
Without going into [soapbox] too much, the various .plans that have been posted from the more experienced Indy's have been very informative, so I thought that I'd add a few of my own personal notes:
Making a game with the intent to eventually release is a whole lot more than just coding some cool features. Team Management, Business Establishment, Business Development, Project Management, Game and Infrastructure Asset Management, Distribution Capability, Integrated Q/A, Financing, and tons more are all aspects of a successful project, and they take up a ton of time. Words to the wise: If you are both a Producer and have a primary role in any other aspect of your project's development, factor in 3x the "expected duration" of any task you assign yourself, because you are going to need it!
Terrain Deformation Resource
Several months ago we identified the need in a 3-D environment to be able to have players direct "peons" (worker units that can modify the environment) levelling, digging out, or building up terrain. For example, no castle is complete without a moat, so a player that builds a castle needs to be able to dig out a trench around their castle to fill with water. Also, structures placed by players need to have the ability to "terraform" the ground underneath the structures to avoid funky terrain underneath their buildings. In addition, terrain deformation based on major events in the game (siege weapon missile impacts, major explosions, etc.) should have a noticable and persistent effect on the terrain to all players.
This isn't a trivial functionality--even AAA MMOG games that allow for structure creation (Shadowbane is a prime example) have had issues with terrain deformation--in SB for example, you could get some really funky terrain artifacts when you placed barracks or siege weapons on the terrain, and it in some cases severely impacted gameplay--and even provided for some very beneficial "cheats" in siege situations. When you first placed a "tree" (the center of any city), they attempted to flatten all of the terrain in the city grid to a uniform height, but even that was very buggy--to the point where in certain configurations you could create some amazingly disturbed city wall structures.
As a lead up to the task, I posted a thread about Semi-Random Thoughts on Terrain Deformation to kick up some discussion on a design that might work with TGE. We got some good initial discussion, and within one day Robert Brower put together a networked terrain deformation object. I quickly emailed him about his code, and he sent it off right away. It took another two months before the task came to the top of my list, but over the last few weeks I've enhanced his functionality (which was very nice!) into a pretty effective and very network efficient configurable Network Deformation Object that meets both my needs, as well as allowing for very expandable configuration for just about any project. Here are just a few of the major (configurable in script/datablock) capabilities:
--network efficient: Only the "dna" of the deformation is sent across the wire, and the clients procedurally duplicate the current state of the server's terrain based on the deformation "dna".
--highly configurable: just a few of the parameters for procedural generation include deformShape, deformRadius/deformX-YSize, adjustType (flatten, raise, conform, modify), instant deformation (missile impact) or process over time (work is performed by "peon" units until the deformation is complete), sanity checks (script configurable) for deformations to keep players from deforming the middle of a mountain range for example, and several other parameters.
Here are some screenshots of the resource in action. NOTE: This is on a dedicated client-server environment, using the RTS-SK functionality as enhanced by some other resources and our own project requirements. The player has used one of his peons to request the construction of a "Town Center" as the beginning of his village with the desired location on terrain that is slightly uneven:
Scene prior to any action:
The "middle" of the foundation building duration. Note the raised terrain to the left of the image center, and it's altitude relates to the pre-existing terrain features to the right of center:
Mostly Complete foundation. Note how the altitude of the far-right side of the terrain deformation is making more sense now--it's matching up to the highest terrain that the deformation object (building foundation) occluded:
Just prior to completion:
Deformation Complete, building foundation is stable and level, building placed:
The entire process from building placement request to actual placement of the building took roughly 60 seconds, and the peon's movement rate (to each spot to be excavated), "work effort" (how much altitude he can change per tick), and the foundation's deformation parameters (for building foundations, we use deformShape = rectangle, adjustType = Raise, allowedExternalSlope (difference between deformation and pre-existing terrain altitudes) = 15.0, and a conformDistance (how close you can build to steep terrain) = 5.0) are all set via script, either in the datablock, or the deformation new statement.
The Terrain Deformation Resource is currently in final implementation/testing, and will be released here in the near future to the TGE community, with script examples specific to the RTS-SK community released in those forums. If anyone is interested in being a part of this community developed resource (we have 4 people working on it right now in some form or another), please email me--we could use some more procedural generation algorithms for different deformation parameters, as well as more testing!
Nemesis Vortex
We've tried to keep relatively quiet about the features and capabilities planned for our project, but since progress has been good to this point and we've gotten a good milestone projection plan set out for the next year, it's time to describe the project a bit more in detail.
NemV is what we call a "Massively Multiplayer Persistent Interactive Environment". The main reason for the concept name change is that there simply are no existing industry examples of the level of persistence, interaction, and "world change capability" that we have envisioned for the game--most of the concepts have been explored in published games in one form or another, but none of the published (or even planned, as far as our competition research can determine) games integrate the level of capability for the player that we feel is important to the "next generation" of MMOG titles.
One of the biggest criteria in our design is allowing the player to interact with the environment they way they want, instead of what the game designers want, and even more importantly, those interactions are not only persistent, but observable (or at least their effects are) to the rest of the environment. For example:
--In Everquest, you can certainly kill mobs over and over again, and they will hate you for it (while others will love you for it), but if you come back to the world a week later, those very same mobs are most probably still there. Even if you "clean out" Chardok for example, come back in a week and the King and Queen are still nestled safely in their chambers.
--In Shadowbane, you can create (and destroy) player cities, but only in certain world grid locations, and you certainly can't move in and take over any structures in the "mob zones". Additionally, even if you do kill off all the mobs in a zone (just like in EQ), they are back and ready the next day for you to do it all over again. Not only that, but how you interact with the various mobs/NPC's in SB has no bearing whatsoever on the viability, effectiveness, growth, and capabilities of the cities you create.
--In Worlds of Warcraft (it's new, so research is a bit spotty as yet), they decided to heavily use "instances" of raid level encounters, meaning that as far as we can tell, it's possible for two completely different organizations to be killing off the exact same encounters at the same time, with no world persistent effects of either of the raids.
Playstyle Choices: Again off and on, different games have allowed for different playstyle choices to "work" within their game.
--In EQ, once you built up your levels (via the forced "kill mobs for exp" treadmill), you could gather the resources to become a "tradecraft" style player, but you were still forced to use the underlying RPG/single Avatar playstyle to progress to the playstyle goal of trade/item crafting.
--In SB, you tended to have 3 or 4 playstyles apparent. PvP only, PvE only, Organizational Admin (guild/nation leaders), or city development (train/item cities). While there were cross-over interactions (PvP player might attack a city development player's assets, PvE players might be used by a Organizational Admin player's army for sieges, etc.), the playstyles themselves were very minor deviations from the root playstyle implemented by the developers: single player RPG.
Another of the primary goals in Nemesis Vortex is to integrate demonstratively different playstyle capabilities into a persistent world.
Very long .plan, and I apologize for that, but lots have been going on, and I wanted to share!
Without going into [soapbox] too much, the various .plans that have been posted from the more experienced Indy's have been very informative, so I thought that I'd add a few of my own personal notes:
Making a game with the intent to eventually release is a whole lot more than just coding some cool features. Team Management, Business Establishment, Business Development, Project Management, Game and Infrastructure Asset Management, Distribution Capability, Integrated Q/A, Financing, and tons more are all aspects of a successful project, and they take up a ton of time. Words to the wise: If you are both a Producer and have a primary role in any other aspect of your project's development, factor in 3x the "expected duration" of any task you assign yourself, because you are going to need it!
Terrain Deformation Resource
Several months ago we identified the need in a 3-D environment to be able to have players direct "peons" (worker units that can modify the environment) levelling, digging out, or building up terrain. For example, no castle is complete without a moat, so a player that builds a castle needs to be able to dig out a trench around their castle to fill with water. Also, structures placed by players need to have the ability to "terraform" the ground underneath the structures to avoid funky terrain underneath their buildings. In addition, terrain deformation based on major events in the game (siege weapon missile impacts, major explosions, etc.) should have a noticable and persistent effect on the terrain to all players.
This isn't a trivial functionality--even AAA MMOG games that allow for structure creation (Shadowbane is a prime example) have had issues with terrain deformation--in SB for example, you could get some really funky terrain artifacts when you placed barracks or siege weapons on the terrain, and it in some cases severely impacted gameplay--and even provided for some very beneficial "cheats" in siege situations. When you first placed a "tree" (the center of any city), they attempted to flatten all of the terrain in the city grid to a uniform height, but even that was very buggy--to the point where in certain configurations you could create some amazingly disturbed city wall structures.
As a lead up to the task, I posted a thread about Semi-Random Thoughts on Terrain Deformation to kick up some discussion on a design that might work with TGE. We got some good initial discussion, and within one day Robert Brower put together a networked terrain deformation object. I quickly emailed him about his code, and he sent it off right away. It took another two months before the task came to the top of my list, but over the last few weeks I've enhanced his functionality (which was very nice!) into a pretty effective and very network efficient configurable Network Deformation Object that meets both my needs, as well as allowing for very expandable configuration for just about any project. Here are just a few of the major (configurable in script/datablock) capabilities:
--network efficient: Only the "dna" of the deformation is sent across the wire, and the clients procedurally duplicate the current state of the server's terrain based on the deformation "dna".
--highly configurable: just a few of the parameters for procedural generation include deformShape, deformRadius/deformX-YSize, adjustType (flatten, raise, conform, modify), instant deformation (missile impact) or process over time (work is performed by "peon" units until the deformation is complete), sanity checks (script configurable) for deformations to keep players from deforming the middle of a mountain range for example, and several other parameters.
Here are some screenshots of the resource in action. NOTE: This is on a dedicated client-server environment, using the RTS-SK functionality as enhanced by some other resources and our own project requirements. The player has used one of his peons to request the construction of a "Town Center" as the beginning of his village with the desired location on terrain that is slightly uneven:
Scene prior to any action:
The "middle" of the foundation building duration. Note the raised terrain to the left of the image center, and it's altitude relates to the pre-existing terrain features to the right of center:
Mostly Complete foundation. Note how the altitude of the far-right side of the terrain deformation is making more sense now--it's matching up to the highest terrain that the deformation object (building foundation) occluded:
Just prior to completion:
Deformation Complete, building foundation is stable and level, building placed:
The entire process from building placement request to actual placement of the building took roughly 60 seconds, and the peon's movement rate (to each spot to be excavated), "work effort" (how much altitude he can change per tick), and the foundation's deformation parameters (for building foundations, we use deformShape = rectangle, adjustType = Raise, allowedExternalSlope (difference between deformation and pre-existing terrain altitudes) = 15.0, and a conformDistance (how close you can build to steep terrain) = 5.0) are all set via script, either in the datablock, or the deformation new statement.
The Terrain Deformation Resource is currently in final implementation/testing, and will be released here in the near future to the TGE community, with script examples specific to the RTS-SK community released in those forums. If anyone is interested in being a part of this community developed resource (we have 4 people working on it right now in some form or another), please email me--we could use some more procedural generation algorithms for different deformation parameters, as well as more testing!
Nemesis Vortex
We've tried to keep relatively quiet about the features and capabilities planned for our project, but since progress has been good to this point and we've gotten a good milestone projection plan set out for the next year, it's time to describe the project a bit more in detail.
NemV is what we call a "Massively Multiplayer Persistent Interactive Environment". The main reason for the concept name change is that there simply are no existing industry examples of the level of persistence, interaction, and "world change capability" that we have envisioned for the game--most of the concepts have been explored in published games in one form or another, but none of the published (or even planned, as far as our competition research can determine) games integrate the level of capability for the player that we feel is important to the "next generation" of MMOG titles.
One of the biggest criteria in our design is allowing the player to interact with the environment they way they want, instead of what the game designers want, and even more importantly, those interactions are not only persistent, but observable (or at least their effects are) to the rest of the environment. For example:
--In Everquest, you can certainly kill mobs over and over again, and they will hate you for it (while others will love you for it), but if you come back to the world a week later, those very same mobs are most probably still there. Even if you "clean out" Chardok for example, come back in a week and the King and Queen are still nestled safely in their chambers.
--In Shadowbane, you can create (and destroy) player cities, but only in certain world grid locations, and you certainly can't move in and take over any structures in the "mob zones". Additionally, even if you do kill off all the mobs in a zone (just like in EQ), they are back and ready the next day for you to do it all over again. Not only that, but how you interact with the various mobs/NPC's in SB has no bearing whatsoever on the viability, effectiveness, growth, and capabilities of the cities you create.
--In Worlds of Warcraft (it's new, so research is a bit spotty as yet), they decided to heavily use "instances" of raid level encounters, meaning that as far as we can tell, it's possible for two completely different organizations to be killing off the exact same encounters at the same time, with no world persistent effects of either of the raids.
Playstyle Choices: Again off and on, different games have allowed for different playstyle choices to "work" within their game.
--In EQ, once you built up your levels (via the forced "kill mobs for exp" treadmill), you could gather the resources to become a "tradecraft" style player, but you were still forced to use the underlying RPG/single Avatar playstyle to progress to the playstyle goal of trade/item crafting.
--In SB, you tended to have 3 or 4 playstyles apparent. PvP only, PvE only, Organizational Admin (guild/nation leaders), or city development (train/item cities). While there were cross-over interactions (PvP player might attack a city development player's assets, PvE players might be used by a Organizational Admin player's army for sieges, etc.), the playstyles themselves were very minor deviations from the root playstyle implemented by the developers: single player RPG.
Another of the primary goals in Nemesis Vortex is to integrate demonstratively different playstyle capabilities into a persistent world.
Very long .plan, and I apologize for that, but lots have been going on, and I wanted to share!
About the author
Torque 3D Owner dsfsd