It's also going to be realistic! Doesn't matter how many machine gun rounds you fire at a tank, you're only ever going to scratch the paintwork. But then realism isn't necessarily fun...
My own two pennies in general -- military technology favours miniaturisation, so ships basically get smaller as they get more advanced. Space strategy games always seem to get this the wrong way around! The only exception in modern navies are aircraft carriers, of course (for the obvious reason), and they never get anywhere near to actual combat.
Actually tanks arent perfectly armored (the typical tradeoff of design) and they still have weak points (like their top/rear where the armor is significantly lighter - usually there are some radiator openings )
Tanks have viewing ports that bullets can richochet down or their optics can be disabled (lowering the tanks efficiency to operate).
Other tanks have rubber road tires which can be eroded away (unlikely, but those arent impervious and sustained fire agiant the side of the tank which doesnt face the enemy)
So the spaceships (also with some relative weakpoints and various openings) hit by mass smaller gunfire may still get cumulative damage at a much lower effectiveness, but which still can impair the ships operation There may be a small probability that a lucky shot on a weak spot may cause catastrophic damage. Usually lighter units attempting this (requiring continuous firing) will be massively damaged/destroyed by the bigger hardened ships guns.
Its useful when you take the raw data and can 'fuzzy' process them into different degrees/gradualtion in a systematic way.
Use would be where you have different contingencies depending on the degree of 'whatness' -- very close do X, sorta close doY nearby do Z, far away do W, very far Ignore.
by changing parameterization of the fuzzy functions you can have different object types have custom adjusted ranges for these different responses.
On thing that often is ignored is temporal aspects where the values change and the judgements shift - when the behavior originally selected is no longer indicated and replaced with a different one. If the raw values start oscillating and the logic likewise oscillates its results the behavior can look eratic/be wasteful. So some derivative dampening factor (like fuzzy averaging across time) can help stabilize situations like that.
Its generic/broad enough - and its at the level where the technical/practical details of obtaining the 'evidence' and artifacts can be ignored and their importance and relevance to the universe can be worked upon. With odd new things sometimes it takes 'looking outside the box' to figure what something really is which gets into philosophy also.
Much archeology these days is finding all the interesting bits and then someone else figures out their relevance
A problem is how do you judge the effect of the various carrot and stick measures you can employ? Are there consequences which are not undoable (you misread and lose a valuable asset or weaken your 'team' simply because its too random/arbitrary/intricate to figure out...)
So any complicated mechanism would have to become a significant component of the game play (otherwise its just scheduling goodies/strokes to keep each characters 'happy' bar sufficiently high --- which might be a sufficient game complicating element ... but one more thing to do maintenance on - like maintaining ammo levels).
To me I would usually have all the preconditions handled first and then the main guts ( normal operation) of the subroutine - probably trying NOT to indent that additionally. Standardizing on that pattern does make the code quicker to visually inspect.
Usually the subroutine is more complicated with several required preconditions (clauses and if tests) to test and a then the block of operations to do when the example 'get' follows its normal function flow.
For terseness of code I usually even omit the extra block indent/brackets if the only statement is a 'return' and even put it on the if-then line itself (if it isnt too wide). All depends on what the code standards (if any) the company/whoever wants to adhere to)
Maybe the 'gimmick' would be that the decision progression is saved and you can go back to a spot and change your decision to see where it leads (and all your decision playthroughs are stored to allow you to pick where to restart).
Of course combinatorics of X decisions quickly becomes astronomical, so really alot of the decisions should have partial effect to add into certain final outcomes (and whaterver makes the game different in the middle of the plots too).
How much will the assets needed for these 'endings' vary (how much/many custom props or scripts or cutscenes) because THAT can be alot of work for them to be significantly illustrated in-game (hundreds of them most being very different with scenes and mood music and emphatic dialog/voice, etc...)
Now to make players WANT to go back and try different endings, you would want to have a mix of exciting or strange or beautiful or quirky endings -- probably with the selections of decisions leading upto them being made plain as being the reason for that particular ending happening. Having a minor decision play out very differently from almost the exact same sequence.
For the 'gimmick' to work you may probably want to hit the player in the face that THIS is a significant decision point and maybe there there should be a visual tree so players can see the paths they are taking - to be able to go down different ones when desired, and which ones you already did to the end (and reminders of what resulted).
They vary a great deal even from local player counts to the patterns of data flow (how much data, update frequency, and how surgey the flow gets) and how much processing is needed for the data (and possibly how much data has to be maintained per user)
I, of course, designed (sortof) an even better SortofPerfectMMORPG where you can DESIGN THE GAME YOU WANT !!!!
The main aspect is Player Creation of Game Assets (not just the usual mod terrain/objects/figures/animations, but also all the way upto Interactions, Quests and some parts of Game Mechanics/Engine and tool addons). Fundamental is to Tap into the reservoir of interest/effort/skills/time/imagination of the Players. Sure, only a fraction may bother to do it, but what they produce is then useable by the rest - still a resource 100X bigger than any game company's capacity/imagination/skill (there ARE millions of Players out there....).
The "Sortof' comes in because it depends on alot of collaboration for this 'creation' aspect (and all the problems and issues that brings in). But the idea is that good added things will be adopted, and bad things ignored, and good things borrowed and improved into being better things, incrementally. The biggest challenge is for tools and process that would be required to enable a large number of Players to collaborate and create their contribution . (and dont wave Second Life at me, its far too limited for what is needed).
You could have some (your) section of the MMORPG 'universe' have any (copyrights excluded) genre and content you want (whether anyone will go there is up to them). You see somebody produce something good, you can reuse it. If you think you can improve it, then go do so (and others then can take it further). The SortofPerfectMMORPG's collaborative system would support that. Yes, content coordination is required, but seperate 'worlds' would get as much as each subset of players want.
There are common solutions/mechanism shares by most games. Lets simplify/make accessible that part predone/selectable so that people can get on with the interesting/creative bits. Even the game companies could profit ($$$) from not having to reinvent the wheel constantly (game engine/tools/basic objects/animations/attribut systems). By pooling development of the common elements, they could instead concentrate on their particular game's own cohesive theme/motif/presentation (their concentration of talent for solo game experiences could still be beyond any 'community collaboration' - but now cheaper to produce). Popular genres are already owned and THOSE owning companies could control the direction they want their MMORPG game world to go, but now with bigger assistance from their fans (who are ALWAYS starving for new content).
How soon will it be before increasing production expenses and decreasing playthrough hours narrow the game producers field to nothing but mega-game compromise and banality ?? MMORPGs have actually degenerated from what the first generation was. A basics/common system is applicable from the single-man indie to the biggest companies (and potentially even well beyond "games").
Hard ? Impossible ? Never will happen ? Nobody will Pay for it ? Maybe, but then 'never is a long time' (and I would say better sooner than later).
Paradigm Shift ? (It is effectively the Computer Publishing Revolution now done for games.) Yep.
Note - in my SortofPerfectMMORPG you COULD have Cthulhu fight Ceiling Cat with all the fancy lights and exotic gibs you want - just YOU need to build it so that they will come. (note - you may have to pay copyright royalties if they are applicable for YOUR dream to come true...)
Really Early medieval (coming out of the dark ages)
Alot of wilderness, transportation/communications/technology had fallen apart/ was lost
Sea lanes - ships did not go far from land, so coastal paths might be your 'chokepoints', as would the few roads (the best roads, even in late medieval, were 1000 year old roman roads). The usual mountain passes, river fords (pick the scope where geography can be used if possible)...
C and C++ will teach you a great deal about processing data/logic/structure basics (actually make you do it - needed to properly learn...), which then can apply to other languages where more is done for you. For games, you will (most likely) be dependant on what libraries are available and the languages they are written in/for. They often WONT do everything you need, so you then can apply your programming skill to make what YOU need to code to get the game to do what you want. Making use of library routines/systems of data and logic will also be easier (to do right) when you understand what they are doing as compared to what your game needs to do.
The above has utility for just about any kind of modern programming - not just games.
Libraries are building blocks which then its up to YOU to stitch together effectively and fill in any missing bits when required.
All the elements you mention combined restricts what your project has to be.
Genetic Programming would be something you do at the coarse level because a Neutral Network becomes irrelevant when the problem it is solving changes too much . I could then see the GA setting up the parameters/coefficients defining a Neural Network 'build' (the node layer definition, the training coefficients, the situational interpretation rules/the good/bad result judgement functions, training set selection), which then is applied to build a candidate NN training session (building a NN doing the usual reinforced learning method ). A 'swarm' (swarm learning) of candidates are done with 'genetic' variations and a subset of the 'best' resulting NN then selected as the basis of the next iteration set of GA variations (working toward some 'bestest' resulting NN)
How much you can automate building the training sets depends on the game mechanics of the simulation. (whether it can be subjected to the GA methodology) Training sets can be quite large to cover the spectrum of cases the NN is expected to handle. If they have to be hand built that is a seperate problem in the project (maybe GA can be used to assist in the training set building as an independant part of this project)
Swarm intelligence GA variation control factors itself is something that might be manipulated at a super coarse level.
Get ready for some huge amount of processing - building just one NN can be a mass of computing, and multiple iterations of GA variations multiplies that by magnitudes.