HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.

Author Topic: deciding to use spec system or other approaches for your game system  (Read 3732 times)

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile

A lot of forum topics are answered with "use spec system". The justification,
why its used, is not transparent. Thats why i started a small decision list
with hints, when to use "Spec System" vs "Prototypes/Scripts."
Reading -data storage options- in the HEwiki is a good prerequisit.



When you are close to do sth. that in other languages is done by use of "global" values

When the amount of data is "overviewable"
  say 70 skills with 8 attributes
  say 20 areaeffects with 20 attributes

When your derived objects are easy to manage
  say you spawn ~2 different classes out of the definition

When your own knowledge is limited with HE Systems
  say be true to yourself and even if you handle HSL the dependencies of HE frameworks are not
  your deepest knowledge

When you prefer direct access in coding (synchronous)
  function a) calls and gets values immediate

When you dont need editors to "change constant values"

=> you should go with prototypes / scripts



When you are close to do sth. that builds complex objects (mutable,non-mutable data in objects)

When your amount of data is "big",
  say  500+ dialogdata
       1000+ Items with lots of categories
       120+ NPCs with different attribute sets (shop npc, boss npc, regular npc, trainer npc)

When derived objects are architected in strong OO manner
  say main class: task
        derived classes: killtask / findtask / talktotask / delivertask
        optional decorator classes: timedtask  / rewardedtask / collectingcountertask

When you dont hesitate to use indirect access in coding (asynchronous callbacks)
  function a) calls
  function b) retrieves callback

When you need editors for teammembers to change constant data

When you support the category based browsing of big number of data (300NPCs,1000Items....)

=> you should go with SpecSystem



Note 1)
I didnt mix more storage options. But remember you can use them.

Repository
Repository is shortly spoken a filestorage possibilty that exists for server n client.
Normal Text or even serialized complex objects can be saved/loaded as XML/STRINGS.
Infact the Whole SpecSystem is a mixture of Prototypes/Repository Storage,
with interal synchronizing features.

Using Repository standalone:
- For Saving "Player Customized" GUI/CHAT Settings. (Clientside)
- Generating timed Reports "ItemDrops per 24hours" (Serverside)
- Filebased data (remember: DB persistancy for objects is given by DOM flags
                            and the createpersistednodefromclass)


Note 2)
The spec system is harder to setup, to debug und to understand.

-You will write more classes and lines code. The code itself will be scattered around in MANY
different places. The factory of different "nodes" that represent the same object on server / client
is a major point in all of this. It is solvable in many fashions.

-You need to care about the editor. When you use complex datatypes (path references, lists of "objects", 1:n relationships) the standard editor is limited. DO think how much time you want to spend on developing "developer tools".

-There are many base concepts to be understood before diving into spec world
GOM/DOM Handling
Debugging and Using /commands
Replication vs RPC
Event Handling (Events with Observer/Listener)
GUI Creation
Startup/Shutdown Callchains (Areaserver, Character Loading, Entry Points)
Persistancy


###
I wrote this initially many month ago, then stopped a bit with HE.
I still think, a valid discussion when to use what is a benefit to many coders.
Especially to people, that are using HE in the first month.
Basically i dont want to convince that one system is better than another one, but i want to give a bit realistic view on what awaits you.

Maybe some experienced coder can add their views on "when to use what".
Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

I like some aspects but also want to point out others. In regards to if you are building prototypes and scripts to drive those prototypes, and using scripts to make calls to retrieve the data, then you are basically building a weakend spec system to begin with. So why dance around using the spec system instead.

the spec system is really simple to use, people just need to step back and think about it, and design their systems mentally before code wise. It promotes responsible logic patterns. I think people don't like it cause it can start to quickly show those that know system design versus those that don't when it comes to large scale data intensive programs. 

Lets take on the example of the 70 skills with 8 attributes. That is fine but as a player there will most likely be some form of variation to that skill that needs to be stored. So for example fireball. It has name, damage, cooldown time, damage type, distance, mana consumption.

Well with a prototype it's the same for every player in the game, so if you had something lets say a chest piece that has reduced cooldown. With a prototype you would have to store the value of the reduction on the player, which is fine, but when you go to cast the spell you have to read the prototypes cooldown value figure the variance the gear provides and save the time to next cast value on the player. So you added having to constantly keep running an extra equation for every single cast to figure out the prototypes cooldown value versus what your players cooldown value is or storing two extra pieces of data per skill per person. Times that out by 2 million and it's a lot of extra data storage. not to mention calculations.

With spec system you would set the fireball spec to have the cooldown being changable so as the player equiped the cooldown gear that piece of the spec would update. Then you don't have the extra calculation to perform. You also don't have the added storage need of holding the cooldown variation. You also add complexity should you want to have multiple options on reduction. So you want to have gear with reduction to melee skills versus casting skills. With a prototype script setup, would have to hold added values for those reductions on some player node, even if they were never used. So you end up storing a bunch of added data, and doing a ton of extra calculations that aren't needed.

So only time a prototype / script set should be considered is if there is zero player variance in the data. I'm talking about absolutely no way a player will provide the need to have that data be different in regards to them, versus someone else.

The reason for spec system is the combination it provides, you get to cache and off load static data, so name, distance, damage type that won't change, while having flexibility to change damage, cooldown, and mana consumption on a per user bases. Without building complex two tier systems where you store the prototype data then store almost a copy of it again to allow for variances to the base prototype for the player. And keep in mind you want to be able to set and forget values as much as possible. IE cooldown time being flexible for player so when you change gear you set it and forget it to say instead of doing calculations to modify what that value is for the player and storing it over and over. Or doubling up data to store the value on the player.

Not to mention code reuse becomes key. with a prototype / script, code gets re-done / worked over. So for example with a spec system you can have a Skill_IS_AOE class that you glom onto the base skill class. That script adds the fields, and code needed to make a skill become Area of Effect. So no matter what skill you create that code is always tucked away in that glommed class. Now I here you saying yes but I can do that with prototypes / scripts you can, but you end up doing it at the dom level which makes it much harder to manage. As you have to look through every skill, it's code and see what gets glommed on. Also it makes it a requirement your coder affects the skills in game, instead of your game designer.

With the spec system and editor your game designer can simply make any skill they want. glomming classes together to make millions of unique combinations. Without having to write any code. That is a huge piece. even with 70 abilities, that would be 70 individual scripts, with values that need changed, unless you build in classes to glom onto it to build up the base item into a more complex one, but that brings me back around, to the issue you basically end up building out a lower featured spec system.

Every time I hear people coming up with ways to not use the spec system, they tend to explain / build out the exact same thing the spec system is doing. They just don't have it built out nearly as well. So stop trying to justify a reason to build your own version of the spec system. I have to say out of the few things HE has nailed down the spec system is one of their best tools for coding, large scale data, that has to have lots of customized variances.


Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile

Sorry to say, yet your post is exactly one of those posts that i meant and thats why I came up with the given decision helper. Please dont turn this thread into a: Solve everything with specs. Even though i saw indy developers fail heavily on understanding and debugging those intervowen systems properly. In fact i saw more than 30 ppl coming n going on our team and some of them even dont understand easier parts of HE. Most of them never really got to the point to truthfully handle complex spec constructs.

Your assumtions are misleading on some parts. Mutable data is nearly always stored with persisted nodes in DB.
Speaking of skills, it doesnt matter if constant data comes from spec or from prototypes. The mutable per player data(skill-xp-counter, skill-level...) will be managed by you as a coder and will be safed directly with playernodes or some hard-association constructs. This is not the main point of spec system.

Difference is: You ll write lots of code for it to work within spec-world and all of my points are valid. You ll have heaps of scattered code (base classes,derived classes, decorators, oracles... ), high OO-dependencies, editors classes to keep care of and a lot of asynchronous access clientside. So you ll have infact a good system, but one only trained HE developer will really customize well. And at certain scales all those points make a rethinking valid.
Rethinking towards "useability" for small indy teams.

>> So stop trying to justify a reason to build
You really got me wrong. I tried to give a help. Yet you show strongly, that you fell in love with exactly one system and you ll likely give the same answer. Not considering all other options that HE gives.
Not considering state of developers or really need based approaces. Sometimes a mix of other outpasses plain specs a lot. And just a tiny note: I implemented many different ways already. With or without Spec. Guess which ones are easier to maintain for newcomers...

>>a Skill_IS_AOE class that you glom onto the base skill class.
please dont mix advantages of "Glomming" or compostion of objects with spec system.
you can write OO classes and glom them on objects. doesnt matter which approach you follow for constant data.
thanks to HE we have "Glomming" - "live introspection of nodes /sn clicommand " - "rdy to use replication" -" rdy to use persistancy"  etc. a lot things that are used within specs and can be used without and really give advantages over other engines

>> the spec system is really simple to use
I say: In my career i have seen many languages and frameworks. I vote for the opposit and say: they are good, but they need deeper knowledge and handling skills in HE. There are many engines with concepts that are much easier to follow and to implement.

Just a rough estimation: Setup and access of a constant values in a prototype is five times easier.
Access to prototypes is what coder from other realms understand as constant/globales
They need 1-2 lines to access them. They are intuitive.

$GAMESKILL[fireball-lvl1].dmg 
$GAMESKILL[fireball-lvl1].range
$GAMESKILL[fireball-lvl2].dmg 
$GAMESKILL[fireball-lvl2].range




















« Last Edit: Jun 21, 14, 11:30:38 AM by Tarra2012 »
Logged

Thazager

  • General Accounts
  • *
  • Posts: 1160
  • Never stop learning
    • View Profile

While I have not set up our spec system, I do use the current spec system as is. I use the spec system for some of the flashy in game features which I have not yet set up, like playing the special effects and animation with the ability when that is triggered. The spec system was designed for ease of use, however it was not made easy to set up. It was made for those who are new to making games to keep track of data. If one is able to make their own data lists and maintain them, then either is just as good.

I also however, use individual scripts with data lists for setting up all abilities and things that will go along with these abilities. Most of these are base values and can be hard coded. Things like buffs, boosters, and ability modifiers can then be added as the player adds them to that base value. I find it much easier to modify data list in the same script, where you can see the values 5 to 10 abilities all together, rather then flipping through 5-10 different scripts trying to compare those values.

Mostly when building your systems, it is a matter of choice. Sometimes its who is going to maintain the data, whether you have extra people coming into change them or you will be doing it all yourself. Sometimes its which way you find easiest to set up and use. It can also depend on how many you will have. Data lists can be good for massive amounts, where specs can be good for a few and involved systems.
Logged
Lead scripter for EO, Repop helper.
HSL Video tutorials:
https://community.heroengine.com/forums/index.php/topic,1719.msg36858.html#msg3685

HE-Cooper

  • *****
  • Posts: 2221
    • View Profile

The answer of "I hard coded it all because I'll only ever be the one touching it" leads down a dangerous dangerous road.
Logged

JoshHalls

  • Founding Professional
  • *****
  • Posts: 335
    • View Profile
    • The Repopulation

I think the approach with spec oracles and using specs is pretty logical (short of the async nature on the client, which  just tends to eat up more development time putting in proper code if it isn't cached yet, then again I have never seen what the alternative would of been synchronously).

In general as the game evolves and more members enter the team you will have people working in entering data into them and trying to cram it into a bunch of scripts is not the answer. Then as mentioned, you could use prototypes and push the data and build UIs for it, but you are pretty much reinventing the wheel at that point.

It really isn't documented well, but we also batch enter data into the oracles using some server calls and can dump them as well to compare data in a spreadsheet.
« Last Edit: Jun 21, 14, 05:45:53 PM by JoshHalls »
Logged
Co-Owner/Programmer - The Repopulation

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

sorry if my wall of post seemed off and tarra I appreciate wanting to open the discussion. And sorry I got one sided there.

was late and I know better than to post when its late. :)

The point I was making is with prototypes you have just as much complexity as you do with the spec system. You aren't saving yourself any complexity at all, and generating just as much. Sure the core concept of simply accessing what is essentially global values is easy for new coders, not use to "complex" code constructs. Problem though is they aren't maintainable, or scalable. They will wreak havoc on your bandwidth as well. Their synchronous nature is one of ease but one that can generate lag for the client and or the server.

Since the client has no way to store the data of a prototype, and must query it every time. You take a huge traffic hit.

So
Skill1.name (string fireball) 8bytes
skill1.range (int 20) 8 bytes
skill1.damagetype (string fire) 4 bytes
skill1.damageAmount (float) 4 bytes
skill1.cooldown (int) 8 bytes
skill1.manaCost (int) 8 bytes
skill1.AOERange (int) 8 bytes
Total 48 bytes of data. of data to be sent to the client when they need to read that data. This would be common for any tool tip, ability tip, user interface element. So you get 1 million players, and they all want to see what fireball data is. They all mouse over the fireball skill to see the tool tip. The client makes a call to retrieve the prototype object. That has now cost you. 48,000,000 bytes of data to stream to the clients so they can get the one tool tip for fireball. So your prototype method cost you 48MB of data so your players can look at the fireball skill for the first time. So you have 70 skills times 48 mb. of data to stream out for your players to view the skill data of your game 1 time each.
Ok managable for your skills or is it?  Not bad, but wait you have your gui so that when you mouse over the skill see fireball name show up. So now you will query that 8 bytes of data over and over and over again. Sucking up bandwidth with each mouse over for attack.

Now the problem becomes is what if I have a large number of people wanting to make that same query. The server treats calls synchronous and for good reason, Well I have to wait till all of those calls are made to pull that data, before I get my turn. Now this would of course be broken up by each area, but still puts a lot of wasted load on your server, just looking up and sending back the name fireball.

So how do you stop that from happening meaning the wasted data transmission and the wasted server load for a demeaning task of providing the name fireball to show up? Well you put it on the client. But how you do that, well you can get the client to use a client prototype but that means you have two places to maintain skill data and information, you now need a server prototype and a client prototype and they have to stay in sync, so now you have two separate places to maintain and update the same data. For 70 skills, Hope someone doesn't make a change in one and not the other.  Also the coders now need to make calls to the client for just fyi data, and make different calls when they need to send commands to the server. Once again not a big deal but hope one doesn't mess up and accidently makes the call to the wrong one, IE server versus client. They shouldn't but just something to keep in mind of.

So now we have built out server prototypes, and client prototypes, and built two different means for calling the data from each of them seperately in different calls. And still have no means to deal with any mutable data at all. Just read static text. When we go to update we have to update the same skill in two locations. The two different means of calling I'm a bit torn on with picking on, cause client stuff versus server stuff really a wash. if you build your game correct. But I want to point out it's not just as simple as doing
$GAMESKILL[fireball-lvl1].dmg
$GAMESKILL[fireball-lvl1].range

Cause you will need to call it via the client prototype, or by server commands.

So now that we defined some base issues with why a prototype only setup is actually rough around the edges, when dealing with any data the client needs to access it's not a solid feasible solution.

So lets take a look at the spec system, and how it functions.

at it's heart the spec system uses prototypes. yeap a simple prototype is the heart of the spec system, it stores all the static data of a spec. It allows the spec to have multiple variable nodes created from it via instantiation. Just like prototypes do. So to this point the static data is no different then what a prototype is.

Now enter the need for players to access that data. ah here is where things change. The spec system is able to cache it's prototypes into the repositories of the client. This means at the first request for the data the server can send the data to each player one time and cache it, should their version be out of date, if not then no data is needed to change hands.

This frees up your bandwidth costs. that I described above and removes the server hit for simple read task. When the player mouses over the ability for fireball no data is transferred and the server has no care in the world that the player moused back and forth across the ability toolbar a million times. The player has only their machine to blame for any lag that is created, as their network and your servers are taking out of the equation. The data is read locally and is easily managed purely client side.

When you make the update to the one spec definition you make it for both client and server copies, so you no longer have two places to manage the same data. Also don't have to ensure both client and server prototypes are always updated properly.

We can skip the mutable, aspects as it's mainly storing data with a node, which is what you will end up doing anyways, in either case. Even though the spec system does it in very clean way. that is connected as a core setup where as having prototypes causes the two pieces to become disjointed and not tied together in any form.

Lets look at managing your prototypes versus managing the spec. So you want to see what skills you have, well you have to query 70 different prototypes to do that. Granted you could look through the list of prototypes in your editor and see them, but to look at what each of them have you would need to query them and read the output in the console. With the spec system you get an easy to view and quick to click option for seeing the data and making changes to it. anyone can make an adjustment, not just your coder base. I know that doesn't seem like much, but your coders shouldn't me making skills. They should build the bits and pieces that define how skills work, and then your game designers should be actually building skills. Leaving the coders to the real work.

I know this part seems to get overlooked in small indie teams but it's a key aspect really, once the skill system is coded at it's root, the coder needs to move on, not spend time running command lines to adjust server and client prototypes. Especially in smaller teams with less resources.


But lets take a look at it this way.
Quote
When your amount of data is "big",
  say  500+ dialogdata
       1000+ Items with lots of categories
       120+ NPCs with different attribute sets (shop npc, boss npc, regular npc, trainer npc)

When derived objects are architected in strong OO manner
  say main class: task
        derived classes: killtask / findtask / talktotask / delivertask
        optional decorator classes: timedtask  / rewardedtask / collectingcountertask

When you dont hesitate to use indirect access in coding (asynchronous callbacks)
  function a) calls
  function b) retrieves callback

When you need editors for teammembers to change constant data

When you support the category based browsing of big number of data (300NPCs,1000Items....)

=> you should go with SpecSystem

So as you pointed out there is a really good chance you will have to use the spec system for at least some system in your game most likely. So your team will end up knowing how to use them.

Add on the fact that above I showed why the spec system is in place - to solve the problem of client read only data caching in an effective manner that is tied out to a consolidated system. Along with the spec oracles a way to group 70 skills together so they aren't just randomly listed in a no-nonsense alphabetical order of all of your other prototypes. It starts to make sense to use spec system.

So to recap the spec system is prototypes that have a user friendly editor built in for managing, come with ability to categorize and group together code options to simplify code management, provide a built in mechanic to deal with static data on the client side without eating up bandwidth, and have built in code for instantiation of data for mutable data on the player nodes.

So if you need a prototype that isn't user friendly to edit, has no means to be accessed in a bandwidth friendly manner, can't be grouped together, and have to build all of your own instantiation code. Then yeah I guess you could use a prototype only option. But why?

What value does it provide to you or the coders?
beyond having to eventually custom code all of that in yourselves.

















Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile



>>batch enter data into the oracles using
I think this is a generally good idea, but you loose the track why there are editors for spec data. Because non coders can use em to define game-data. If you use coder constructs and have have excel lists that define constant data and push them into the system, żou wont need to care about editors much. I like those things too, but you miss category based browsing or "very extended editor, like shown in hj ref, where you link ids, customize on the fly appearances for npc etc."


>>The answer of "I hard coded it all because
I wonder how this generalized statement fits here and how it helps newcomers to decide in the broader context.
Typing game definitions is mostly done "hard written". (if not procedural data) Weather the data is in files/repos/scripts/lists doesnt matter.


>>Total 48 bytes of data. of data to be sent to the client when
Data on the wire. Thats an issue to speak about in constant data realm and sharing this data to client.
Yet if i get it correctly. Clientside prototypes dont need any of your described "send data via network" operations.
Because they are clientside. Only important mutable data will (with or without spec) come from nodes that origin in server environment and thus need network transfer. This is unavoidable.

Avoidable and what specs do in their nature is: Only transfer an ID for some object and then get all constant data out of a repository (ID=400 for an item is transferred to client: then all properties like item_name, item_image,item_stats come from the already on client residing storage - if its filled, if not spec system will sync).

This base mechanism works too with prototypes.
Transfer ID over network and get all constant data out of repository/prototype.
The base mechanism is usable with much less effort. But of course (i mentioned it many times) you lack some other benefits of the spec system, while need less time and knowledge to set it up.
In not too large things, its yet a lot easier to start and even to develop.

What has not been mentioned is memory consumption server side:
This is maybe a bigger thing with specs. have the most reduced representation of objects in server environment.
And use constant data totally constant/globalized. In mmo its usefull e.g. if skill-constant-data for calculating damage are only held 1 time in memory for all people. The mutable data needs to be held for each player anyway.
Otherwise no calcs are possible.

But I still only see a small disadvantage of prototype. As (if i recall correctly) they are stored for each area.
So again my inital decision helper is ok. If the amount of data is overviewable.




Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

I'm bolding my response not for tone, but to just help separate it visually.

>>batch enter data into the oracles using
I think this is a generally good idea, but you loose the track why there are editors for spec data. Because non coders can use em to define game-data. If you use coder constructs and have have excel lists that define constant data and push them into the system, żou wont need to care about editors much. I like those things too, but you miss category based browsing or "very extended editor, like shown in hj ref, where you link ids, customize on the fly appearances for npc etc."


His point was when you want to run damage modification values for 70 skills and do number simulations on paper for all 70 at once. So lets see what happens if we modify damage buff from 5% to 10% what does that do to all of our skills damage values. So he can export it to excel run the figures, and import the data back. To try and do that with prototypes would be nearly impossible. Would have to know the name of every prototype build it into a script then have it pull the data out and into script and make a log file. Do able and not far off, problem is 1 misspelling in a prototype's name and it falls apart. You also have to keep a file somewhere that lists all of your prototypes name. With the spec system you get the spec oracles which can provide great amount of control over their specs and provide a consistent grouping mechanic. Which leads me to the next below issue.



>>The answer of "I hard coded it all because
I wonder how this generalized statement fits here and how it helps newcomers to decide in the broader context.
Typing game definitions is mostly done "hard written". (if not procedural data) Weather the data is in files/repos/scripts/lists doesnt matter.

Hard coding any type of raw data is never a wise decision in any language. It makes for sloppy code, that is unmanagable, and extremely hard to debug. So you got your prototype you named it Skill1_Fireball. You made it work in all of your code as $gameskill.fireball.dmg. As you get to alpha your players say hmm you know what we hate the word fireball, please change it. You decide you know what we will change it. Well now you have skill1_fireball prototype that is actually named firebolt in the game. Now you have to keep a spreadsheet keeping name changes and adjustments. With a spec you could at least add a field called, spell name to your editor so while it might be skillFireball in code still, you know it's name is firebolt. As far as values go. It's even worse. I hard coded it is horrible, cause you never know that you will be the only coder ever. So a new coder joins and you go oh the damage values are all in script skill details. They go oh ok, and work with that, well you also forgot to mention that in skill buffs are the modifiers for buffs on skills, and player modifiders script has the values you need to adjust for player levels etc, and in this other script. Well how the heck a coder going to know and keep up with all of that. Also when it's time to change those values, you have to open up 8 different scripts. With the way the spec editor manages glomming and auto adding the fields to the editor so you can easily gain access to the values in the sub scripts you have manageable code in a nice package for new coders to grab from.



>>Total 48 bytes of data. of data to be sent to the client when
Data on the wire. Thats an issue to speak about in constant data realm and sharing this data to client.
Yet if i get it correctly. Clientside prototypes dont need any of your described "send data via network" operations.
Because they are clientside. Only important mutable data will (with or without spec) come from nodes that origin in server environment and thus need network transfer. This is unavoidable.

A few issues, with that 1.) you have to maintain two sets of code now, one for client prototypes and server prototypes, also you have to manage two prototypes instead of one. Add on the above issues with the code management nightmare discussed with simple name change of name of the skill. And you know have 3 or 4 excel sheets keeping up with all the changes, and disconnected code.



Avoidable and what specs do in their nature is: Only transfer an ID for some object and then get all constant data out of a repository (ID=400 for an item is transferred to client: then all properties like item_name, item_image,item_stats come from the already on client residing storage - if its filled, if not spec system will sync).

This base mechanism works too with prototypes.
Transfer ID over network and get all constant data out of repository/prototype.
The base mechanism is usable with much less effort. But of course (i mentioned it many times) you lack some other benefits of the spec system, while need less time and knowledge to set it up.
In not too large things, its yet a lot easier to start and even to develop.

But it's not any less effort, you have to keep client prototypes matched up, provide your own instantiation code, something you keep overlooking. That is a bunch of code to instantiate the prototypes for each player and implement that instantiation for all of the skills, which since they aren't grouped means you have to create long lists of code lines in scripts which creates large blocks of unmanageable code.

What has not been mentioned is memory consumption server side:
This is maybe a bigger thing with specs. have the most reduced representation of objects in server environment.
And use constant data totally constant/globalized. In mmo its usefull e.g. if skill-constant-data for calculating damage are only held 1 time in memory for all people. The mutable data needs to be held for each player anyway.
Otherwise no calcs are possible.

As I've pointed out server side specs are treated for the most part just like prototypes, as they are just that a prototype.


But I still only see a small disadvantage of prototype. As (if i recall correctly) they are stored for each area.
So again my inital decision helper is ok. If the amount of data is overviewable.



Well lets list the disadvantagers out of prototypes only.

1.) no spec oracle - this means you have no way to easily do group operations against your prototypes. Want to add 10 damage to all of your skill, with the spec oracle grouping the specs (aka prototypes) together you can run operations against all of the specs inside the oracle
2.) have to maintain two different prototypes. Server and Client prototypes. This means you have 2 totally separate locations to maintain your code. Never a good thing to have to multiple places to update the same data.

3.) Only your coders can make changes to your prototypes, or people with ability to run command lines and know that there are ones for client and server. This greatly hurts your ability to quickly make adjustments when play testing. Ties your coders down and makes the whole game take longer to release.

4.) No way to easily read the data in the prototype without building out complex scripts to pull the data, insert it into a formatted output to the console. So even trying to review the dps of all your skills becomes a coder building out a script that has to be manually modified every time a new skill is added cause the prototype has to be added to the format script. Well scripts cause you need one for server and one for client. Adding a new property to the
prototype becomes massive in scope as each one has to be modified manually, twice.

5.) Time savings. With prototype only you want to change a value for a skill, you have to know the skills name, the exact spelling of the property name hoping it's not misspelled, run a command line to modify it, then turn right around and run another command line for the client prototype. OR with the spec system, you double click the spec, type new value hit save. A whole heck of a lot less typing, and I don't even need to know the prototypes name or the property's raw name. Heck I even get a tool tip option that explains exactly what that value does if I so choose to put one there. If not no biggie still super easy to do, takes like 3 seconds instead of 30. Doesn't seem like much till you change it to and you lose 30 minutes of time. 27 seconds times 70 skills.

6.) No worry about inconsistency. With each prototype being it's own free will and thinking node, it can have mistakes in it. Someone could leave a single letter off a prototype's property and you would get an odd error message when trying to debug that it got a null reference, so the first thing a coder would think is hmm well why did I get that? Must be pulling something wrong or not finding the node, so then he spends a few hours figuring out the field just has a misspelling. Now I could be off I'm trying to remember if client and server side prototypes come with code sense or not. Even so since your programmer is going to be making a ton of repeating calls to things, since they can't batch call the spec oracles and retrieve all the specs in it. And have to manually call each of them instead, he will probably be ctrl pasting a few hundred times, and if one is off will miss it till after he runs code. Point is it makes debugging much harder as well.


There are some more nit picky ones but I think you get the point. All you are doing is creating a ton more work, and for what reason? your too lazy to build 5 scripts that already have prebuilt templates for you? I mean seriously you create script pick the template and get to work. Takes less time to make a new spec oracle and spec system then it does to open excel and start listing off the prototypes you going to make. So you can keep tabs on the whole list.

Now I know your first reply, is well I said overviewable, but that is false, everything that has any scale should really be in a spec, and by scale. I mean if there is need for more than 1 copy of the prototype template. then put it into spec system.
If not you are just duplicating a ton of work that isn't needed to be done manually.

So then comes in the but it's easier for new coders to pick up. Ok going to lay this out here, and will probably get scoulded by the masses, and I believe everyone can and could learn. but....

YOU ARE CODING A MASSIVE MULTIPLAYER ONLINE GAME.  not hello kitty. If you don't understand complex data constructs, deep inheritance, massive data management, code management, large scale system design, and a few dozen other code design concepts. You are going to be in a world of hurt. Now with that said EVERYONE CAN LEARN IT. even if they don't have the experience. What they don't need though is to spend 3 months doing things the "wrong / hard way" cause it's a tad easier to grasp for new coders. Either they dig down, figure it out or they aren't meant to be a MMO programmer. You have to think massive large scale. You need to realize even small simple components need to be thought of in large scale management. Sorry to get offensive, but it's a harsh reality I fear a bunch of people over look.

Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile

My initial thoughts about not posting were realistic. I am not much attached to it. Yet this thread is going in the wrong way. Its not a helper when to use what, but its a "i defend specific systematics in programming". Sadly. I should have kept it.

This is my last post, as we dont help people to qualify when to use what.

>>His point was when you want to run damage for 70 skills
I didnt want to discuss pros n cons of lists and batch loading. I did it a lot and know where strength and weaknesses are. Your points about how this could work with prototypes are semitrue. But i dont want to mix it in here.

>>Hard coding any type of raw data is never a wise decision
Thanks about a wall of text about a widespread knowledge. My point is, that someone should think before throwing in "one liners" with no real connection to topics. I can throw in 10 more general coding rules that are always true and dont care about thread titles or connection to it.

Now to make it short: Constant data is somewhere set. DialogText1="haha". In terms of constant data definition it doesnt matter where. In terms of programming with hardcoded vars and using them everywhere it is. Latter one was never my point. And should not be done. But how does it affect the thread? Did i call for it? Did i say use hardcoded approaches?

>>instantiate the prototypes for each player
Guess how many prototypes are clientside instanciated. Right, all the time for every player. (even in standard engine a lot) It doesnt matter much. They are running as a clientside ressource. Make them, use them. If you follow a general rule too look HOW big your different data get. (deciding rules).

>>4.) No way to easily read the data in the prototype without
Really? You say a synchronous read data from prototype one liner is not easy, but spec are?

>>5.) Time savings. With prototype only you want to change a value for a skill, you have to know the skills name, the exact spelling of the property name hoping it's not misspelled

Time saving is on prototype side if you follow decision helper. Even batch editing and (oha! versioning comes ontop) is your friend, if you keep your definitions in scripts. And those definitions create a prototype. Time saving is not on your side if you exeed some limits / amounts. AND IF you need category based browsing AND if you need some Guys that can only use editors. to do fireball[dmg]=3 etc.

Your correct on possible mistakes. As a spec editor might catch/handle mistypes. Yet all this is bought by time spend for creating dev tools. Sometimes this overhead is not justified. There is even a good article about this out there in google world. Use it wisely and when its appropriate i suggest. Thats why the thread was born.

The thread was not born to many discussions that now went off (coding massiv multiplayer and needed skills).
Sorry if i step on some feet. I didnt intend to. I should have kept the decision help away from newcomers...

Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

tarra we aren't "just defending our special way" we are pointing out that your original thought with prototypes only isn't the best way to go in any case when there is any amount of repeating data that needs to get managed.

And as I pointed out in details prototype only has a long list of items you have to build / implement yourself just to support them.

YOu have yet to provide anything back to the contrary other than they are easier to work with when calling.

You even contradict yourself in your last post.

Quote
Time saving is on prototype side if you follow decision helper. Even batch editing and (oha! versioning comes ontop) is your friend, if you keep your definitions in scripts. And those definitions create a prototype. Time saving is not on your side if you exeed some limits / amounts. AND IF you need category based browsing AND if you need some Guys that can only use editors. to do fireball[dmg]=3 etc.

If you keep your definitions in scripts and those definitions create a prototype. (that is the clearest definition of the spec system you could have).
I mean not sure you could make it any clearer. A group of scripts that create prototypes for use in game.
All the devs did was remove the hassle of dealing with those prototypes on the client side as they know that data management client side is key, and can make or break your game, and your costs.

So in the end you are basically saying hey people if you have just some data, it's ok to not use tools provided to make your life easier, do it the manual way. It's almost like telling new people. You know placing assets in the game world with the widgets is hard you should write library commands that set their coordinates, and if you need to change them, update the library commands. Cause darn that movement widget is hard to learn.

I know I'm being over the top dramatic but that is the exact same thing. The devs provide you with a very nice built in tool for managing complex data, and cause you don't want to use it, you tell others not to. And tell them not to for the wrong cases / scenarios. All we are pointing out is hey feel free to do it your own way, but there is no reason to do it that way. Unless you really enjoy pain and suffering.

The spec system is not hard at all, it's not complex, you can make a spec oracle, and system that will allow for unlimited prototypes of data. in about 3 minutes of time. The only thing complex about spec system, is thinking out your actual code design for your systems.

THAT is the real problem. I tend to find people that shy away greatly from the spec system, are ones that don't have their game figured out and are just winging it, as they go. They haven't thought about all the data components, how they end up affecting everything else in their entire game, what data each feature on the feature list will require, where it's best stored and accessed. Those people tend to dislike the spec system, cause it sort of forces them to do some planning ahead of time, code wise. With a MMO though you have to do it. I have helped numerous teams out with figuring that part of the equation out. That you really have to know all your roughly planned features, and how they all interact. Once they see the big picture about how things all interact in a global sense, they go oh... I get it, and start building out specs that help them modularize all of those components instead of just a mass collection of scripts sitting around in a horrible to manage repository. And while it's an over generalization, it's the common theme, that after 2 years of trying to help as many people as I can. I have come to the conclusion on.


Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

Tarra2012

  • General Accounts
  • *
  • Posts: 113
    • View Profile

To clearify again the intention - and why i better stop writing -

If at any time you encounter anyone that says, that system1 is always to use, no matter what prerequisits your system/your customers/your skills/your dependencies have, i can assure you with long time expierence over many IT projects, its a wrong attitude. Whoever says it, fell in love with a single idea, blending out other possibilities. Or he is a marketing guy :)

Each system has pros and cons. What i wanted to give is a decision HELPER when to use what. I never said NOT to use spec.  I use specs myself. I say its a disadvantage when used in wrong cases. When used by people with less background. When used for things that are close to "global vars" ... just read my first post....

I can find as many systems where i would use them, as systems where i wouldnt. ALL that matters in my post was, to find identifying points, when to use what. And nothing of the rest helped sofar identifying them...

This is a BIG difference keeper, to what you claim i say.





Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

and my only point back was your example of when to use a prototype only is not correct.
That is not when you would want to use a prototype only situation.

Prototypes are a templating tool not a coding tool.
Using them as data / code constructs is not their purpose and has never been their purpose. Prototypes are used as templates for spawning other nodes from. They just happen to also be nodes themselves, but that is more in their nature of being a template. It's hard to not be a template of something if you yourself are not that same object.

But their intended to be used as a means to spawn other nodes from. While they might hold data and be accessible, and have a purpose to that effect in regards to having a piece of template data that is useable for other means. They shouldn't be the focus of your code. Take a look at the existing ones, they are all used to basically provide the ground bases for other nodes that get created.
They get referenced when a new node of that prototype gets created, that is their purpose. you are taking an aspect of it and bending it to your purpose which isn't their main function.

Is that bad, eh up to you, but to post to others that might be learning or trying to figure things out, your misunderstanding of what a prototype is. Is where and why you see everyone pushing back.

I guess that might be the direction, that needs to be had, straightening out the real purpose of a prototype, and how to use it properly. In the means you are using them isn't how they are suppose to be used.
Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

FI-ScottZ

  • General Accounts
  • *
  • Posts: 1407
    • View Profile
    • Forever Interactive, Inc.

I only skimmed this thread, but I think I saw enough to doubt that these screeds are very helpful to anyone.  Please let's just let it drop. ::)
Logged
Scott Zarnke
Lead Programmer, Visions of Zosimos
CTO, Forever Interactive, Inc.