wodinoneeye

Make your graphics sufficient to help you debug your object's behaviors  (you to visualize the world situation and to be able to use the mouse to select one object to get information about its internal state and possibly the logic it runs)

 

Simple rectangles with a test entity type name inside it  is good enough.  Render a window into your world (which you can traverse with arrow keys initially)

 

Start deciding how complex your object behaviors will be, even NON sapient animals have conflicting goals that have to be resolved and you may be suprised by how much logic it will take  to analyse the entities local situation  figure which goals/solutions/actions are appropriate and pick the best one to carry out.

 

Figure out a common metric calculation for priority of the decisions (so you can use it across all the objects and then be able to reuse common behavior analysis and decision coding.

 

 

Make sure that periodicly the object's situation is reevaluated so it wont get stuck doing one thing when that thing is no longer the priority (this allows opportunistic behavior)

 

----------

 

start with plants which are largely reactive to their environmnet

then do animals that have basic survival behaviors

 

later harder will be objects that cooperate with each other (the complexity of their logic goes way up)

 

---

 

some file logging of execution of the behavior logic is a good idea so that  you can trace what decisions were made (what the object saw as its situation and then the calculations to decide whats inmportant for it to consider an dthen to decide what to do ).   I usually do this to a seperate window for one object Ive selected on the screen  and add various control buttons to dump specific  info about the object (including special debug code when I am trying to figure out what the logic doesnt do what I thought it would do)    

Just off top of my head

 

You need a list of professions/'roles'/positions that need filling and for each in order of importance the attributes needed/useful for them  (if more than one NPC is needed for the role then a count has to be part of the data -  size of the organization that uses the role sets and how many in each is a seperate task that would have to be done first)

 

The roles (if multiple quantum positions in same profession exist) should be ordered highest expertise to lesser     (ie guildmaster first, guild members, apprentises, lackeys last)    Some numeric value is needed to force sorting by highest expertise needed to rank them for sorting

 

 

You will have a list of canidate NPCs with attributes determined (probably using bell curve to help create a reasonable set of variations)

 

Attributes might be predefined skills as well as the basic 'stats'

 

You calculate/score an attributes value (higher better...) required for a role   numerically as a multiplier or by a curve  (higher ability in skill most needed will generate higher attribute score than  ability in less important attribute or lower value in a attribute)

 

You would sum up all the scores for all the required attributes for the role

 

--- ---

 

Doing the assignment :

 

Loop - You work your way thru list of all roles (sorted by highest expertise needed (ie- all guild masters first))

 

 1) For all candidate NPCs you calculate (score and sum) and sort  by top "score for that role" order.    building a temp list

 

  2)You   assign the best available candidate to the role (highest score)

    (and closing out that role or decrementing number personnel needed for it)  

    (the one assigned candidate is removed/marked unavailable)

 

 IF there is no potential candidate then the role will have to be left unfilled  (or filled as much as they can be - some there may be no qualifying candidates - 0 score)

 

Endloop - You continue til all roles are processed

 

---

 

Some checking for ties may require random assignment  from set of  all who score a  tie for the  role (as current highest score)

 

---

 

If two attributes are equally needed  for a role you may have to normalize the  score calculation  multiplier values

 

---

 

if there are PreRequisits for a role (a minimum value for each of the  list of needed attributes)  you may need logic to discard/filter-out  candidates.

 

---

 

Can get uglier if your NPCs can hold more than one 'role'   then the whole process need to be done seperately for independant sets of 'roles')

 

---

 

Local variations

 

If you have alot of high skilled people for one possible industry/activitty (and the resources needed to scale it large( you might add logic to have that local group specialize with more emphasis in that particular industry  (assuming there is a need for the product  --- thats another seperate auto-decision mechanism...)  This usually has group teams which are set of roles which have to work as a complete group to operate correctly .  Elaborate on that  for you game later

 

^^^ this gets messy if you somehow have to figure out if what CAN be produced NEEDs to be produced (like if everyone makes it and the supply would greatly exceed demand --- you would need to prefigure   that demand which is hard to do when you havent yet defined which areas have the personnel to generate the output (using roles)    ---- chicken befor ethe egg problem that usually takes an organic stepwise growth buildup to allow the patterns to grow themselves (done before you reach the steady-state environment the player plays in)

An emperor (and kings for that matter) are political jugglers that play one faction off another. There are lots of underlings to get things done but he probably holds his position because he maintaines support of sufficient factions or was neutral enough (and thus has not much real influence)  to the most powerful which wouldn't allow someone from the other factions to be emperor.

Historically 'great' emperors did significant things to get to their throne (and/or while on their throne), while others inherited the position and may do very little.


Being a 'space' emperor may not matter much to differentiate from any other kind

Emperors of course denote some kind of 'empire' which is generally 'large' as entities go (means there can be BIG factions also as well as big territories to be controlled and possibly large numbers of people out there who might not like being ruled or the way they are ruled)

It also often means that there are 'kings' below (vassals of) the Emperor which owe some kind of fealty and recognition to the 'emperor' (there also can be locations which no longer have their own political entity in charge and are run by governers who owe allegiance to the emperor (or his empire).

May also depend on your target hardware (minimum requirement you wish to have work reasonably at lowest quality settings)

 

Tablets and Smartphones  ...   Basic computers with default low-end (on motherboard) GPUs ....

 

Also another  consideration is texture sizes that will be aplied to those triangles.  Some MMORPGs Ive played recently have started getting aborts on DirectX  when new game areas with more details (Expansions) have been added recently  (which never had any such problem at max settings years ago).

 

Fancy animated textures for clothing...   Cloth effects maybe also.

 

 

There is also - what budget do you have for the models after whatever the terrain budget is found to be ....

 

Also can you count on some forced maximum number of player objects (models)  SHORT of the 64  or will their be a possibility all 64 will show up so that they will be in view at once for a client??

As I recall the GPUs still make you do a lockstep instruction sequence of 32 data sets in parallel.

 

?? Partial patrallel processing for the step you find adjacents to add to the Open List ??  in 2D thats 8 on a regular grid and 26 candidates for a 3D regular grid

 

You may be able (for a single Agent thread) to employ a HeapQ which will keep your Open list tree best candidates in sequential order in the same memory space. (to be processed in lumps in parallel)  the adding back to the HeapQ unfortunately would have to be sequential

 

A significant part of the A* processing will still be irregular (and lower the pure use of the parallel nature of the GPU alot)

 

You more definitely could  have  A* paths being calculated in parallel for Multiple Independant Objects  (or multiple targets being considered for the same Agent/object)

Sounds like you need to break your AI logic into two parts :

 

1) a goal selection system that analyses the current situation and picks the highest priority goal.+ solution  (evaluation of this is often the most difficult to come up with equivalency metrics for situational factors)

 

2) an executor for that goal+solution which is specific to the solution - you could continue to use your Behavior Tree method here - just one 'tree' for each specific solution

 

Effectively you break up you one ginourmous tree to mutliple specific use trees  - with one run when its matching goal+solution is active  (this  gets rid of excess logic outside its own domain)

 

The (1) analysis + goal selection does not have to run each cycle, though you may need to do so when certain significant events happen (triggering a general reevaluation...)

 

If the same goal+solution is selected again it should be resumed (to restore the progress made)

 

Each BT should have 'cut' checks that would be reevaluated frequently to see if the current solution is still valid (situation hasnt changed) which on failing would push execution back to the goal selection (1) stage

Mechs made out of Tumbleweeds with a rockem-sockem-robot game mechanic - turning and shuffling is slow so player has to try to predict opponents moves (perfect for network/internet play).    Sorry no real AI with A* and Influence mappings and a planner for the strategy.

 

Weird indian shaman magic to create tumbleweed golems ?? 

Keep in mind classes are an (easy) way to balance the game out.
right now you have the classes weaver, rogue, berserker, weaver-berserker, rogue-berserker, weaver-rogue, a weaver-rogue-berserker and anything in between and none of them are under any special restrictions/buffs. All these (well, at least the three specialized and i quess the all-round) should be balanced and offer a different playing style.

most games solve this by giving a certain trait/bonus( + X% damage on attack-type Y ) that can later on be changed somewhere in the game if the player chooses so.

another way could be to make certain skills related to each other.

though having skills go up individually does give some good control over skill-gains
 

 

 

Maybe a hybrid multi class system   (instead of monolithic single classes).

 

Some kind of mix and match that allows more combinations of 'synthesized' classes  without a much more complex 100+ skills developer has to balance and the players get endlesslly confused about .

 

 

May or may not be easy for a particular game mechanism to break sets of skills up like that.

Some of your ores/products of ores will be used as 'tools' to extract/process the actual target material.

 

 

As mentioned, Limestone (certain type with certain quality and composition) is used to process iron  (as is coke which is processed coal)

 

Mercury is used to process gold/silver for example

 

Lead ore is used to extract silver from another kind of raw silver ore

 

Fuels are a obvious 'tools' to use in many of these processes.

 

Water actually is another.

 

A normal mechanism in the real world is that strenuous activity bring increased capacity and normal difficulty activity sustains the current ability ('normal' relative to the current ability).

 

SO not just any activity leads to growth, but exceptional activity.

 

I recall in Ultima Online withe their 100 point skill system  (versus stats) that you only went up when you fought with swordskill against an opponent exceding your own level in that (or equivalent) skill.     Defensive skill would go up when player was subjected to attacks at a higher level skill.

 

There also was as part of the mechanism that as you got closer to the higherst value (100) it took more and more activity to get an increment (0.1 each) to your skill.

 

Unfortunately UO was NOT able to do that with all of the skills and there still was grinding that could be done cheaply.

 

Some qualifiers to using the skill might also be made as in 'attacks' having to have a real target and not a passive wall

 

Having negative (failure) 'accidents' that are usually possible when using skill at a difficult task might be a way to dissuade players from grinding.

 

Another mechanism used on some systems is a daily advancement increment cap (so to spread out the advancement and limit grind exploits)

The nature of your  'idea' will significantly effect any answer you can get.

 

Is it a paradigm shift that noone in the industry will seriously consider (maybe even for 10 years)...

(I have BIG ideas that a whole generation of tools would need to be developed to make happen)

 

Is it some nifty game mechanic that any company would want demonstrated before they will understand it is doable...

(someone mentioned using mods of existing games to short circuit prototyping your idea)

 

Is it something that could be put on an APP (and thus rarely make a single buck of profit, thus cutting out all but hobbyist development).

 

DO you know it will work ?   Thats sometimes the hardest of all -- to realize an idea just wont work (or rather work in the right way  so players would actually want to play it).

 

---

 

Ideas ARE a dime a dozen, but demonstratable ideas cost alot more...

Dont forget some kind of LOD level of detail mechanism that cuts down an  then ends any high/med/low detailed grass at varying ranges  (instead of a monolithic grass everywhere rendering).    Even with many of the methods mentioned, there still is a significant cost to drawing,  and any time you DONT have to draw areas of grass frees up resources for other things (or really nice looking super-duper detailed grass at your feet)

Something from writing/fixing others code :

 

If there is some parameter flags that cause variations of behavior of a subroutine - clearly comment this  at the parameter definition and down in the code where trhe different modes take action.  (Im not talking about simple subroutines but ones hundreds and thousands of lines long that it may not be productive to have a variant copy customized for each 'mode'.)

 

Especially if the scope of the differences cause odd side-effects or have important limitations.

 

Document those (if not anything else) becase of the amount of the time/effort it takes to trace thru the code again  to figure out what it does and once you find it (as when fixing other peoples poorly documemnted/commented code)  it can save the effort or repeating the detailed logic tracing.

 

Anything with weird/atypical/convoluted behavior should get priority for comments if there is little time for any done systematically (its just a fact in the real world that you dont always have the resources to do a full commenting/documentation).

 

----

 

 

And when I make many such comments I make them very plainly stand out so that its hard to miss  (indicating that the codes behavior is something to be wary of)

One of the problems with generating near-realistic detailed terrain for a water/land planet - the erosion patterns (air or water), the rivers/water drainage is a complex  and high processing cyclic mutation of the base seed generated data.    All those continuous features that are the cumulative result of interaction across a usually large area.  You often have to calculate the whole (hard to do it ''in parts' because of use of intermediate data from outside the desired 'part'.  If you suddenly need an adjactent 'part' to be generated it may turn out disjoint with the existing 'part' and you can get trapped in a non-deterministic series of 'patchings' to try to resolve the inconsistancies.

 

The ecosystems (including weather) are  dependant on altitude/slopes/latitudes/proximity to water.

 

Take a look at a topo map of the earth to see the complex  patterns (some river systems drain land areas of a significant percentatge of the surface)

 

Depending on how often you come and go from a 'planet' (or a set of them) you may want to build the resulting data and cache that to avoid the huge processing cost/delays.

 

Of course if that kind of detail level or need for cohesion in the extended patterns isnt needed, then generating the final terrain in 'parts' is possible (you just have to decide how much adjacent recursive stepped data is needed.to be 'good enough'.

On a system with save points, Have long cut scenes just after the save point which is right before a VERY difficult (very easy to fail) game action sequence that on average will have to be repeated 30 times. Oh and of course there is no 'skip' feature for the long stupid cutscene.

Might be even better if between the cutscene and the difficult fail point you have 5 minutes of uninteresting game play to go thru (with no intervening save point) just to make the 30-odd tedious repetitions all the more enjoyable.