To understand what RuinValor is you must first gain knowledge of how it came to be. The roots of my desire to make video games can be traced back to Neverwinter Nights; while the singleplayer certainly leaves something to be desired the multiplayer was the jewel amongst the stone in my mind. Packed with a toolset editor, the ability to create, modify, and share worlds of your own is what interested me the most. Couple that with an in game Dungeon Master mode to enhance story telling for the hosts player base and what you obtain is a powerful set of tools that assist in maintaining interest in a game long after its initial release. I have long believed that if you put the proper tools in the hands of the people who make content ( modders and such ) the life of the game can be infinitely extended. game. Throughout the design process I have ensured the core concept for all systems put in place rely on the single factor of customization.
| Posts | ||
|---|---|---|
| Skill system | Locked | |
| Thread Options | ||
| Jan 30 2013 Anchor | ||
|
This week our focus has been on the development of the skill system. Unlike most games the server owners will have near full control to make their own abilities. To do this we must define a very robust system with very basic rules that will govern all other aspects. The idea is to provide them with spell/skill types and let them mix and match as they choose or use the basic ones we will add throughout the development process. Our biggest hurdle is to come up with the foundation that will define all of this. Our first task was to sit down and define categories of spells so that they can be classified into groups. Once the basic classification type was set we could define the spell further by talking about how it might react. To do that we needed to define types of skill/spells. Here is what we came up with:
These behavior types would define a set of parameters that could then be used by the serverowner ( spell maker ). To be able to manage this properly we needed to define aspects of code that would be referenced through these spell/skill documents. Sort of like an instance that could be easily called. We started to come up with the most ideal route to handle this and realized that the best option would be to define these elements to be pulled via some form of API at a later point in time. The complexity of this is rather daunting but at its current state we have a working architecture of it all. It is our hope that within the next two weeks we could have a completed skill/spell system in place that would be near 100% modifiable within a measurable means of ease. I will keep you posted as we gain more information. In other news we have added our project onto IndieDB and some other sites to gain some more exposure. Pass us around if you like our project! |
||
Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.