Stuff to avoid:
- Powerups, health, and other goodies laying around in boxes. Life is nothing like that.
- Muscular no-necked jocks. In reality that sort is usually too stupid to cause significant effect.
GAME ENGINE
-
Add Collision detection
Support is in CS, but not implemented in the Yerushalem code
- Input
- Use AWS in CS for user configuration menu
- Mouse Control
- More Keyboard Control
- Joystick
- AI
- Where possible use Quake 3 bot AI
- More advanced AI to try. Create a genetic code that consists of simple actions a bot can take. Allow to mutate. Use neural nets to correspond game world 'sensory' inputs causing reactions. Good bots get to mate with other ones, the bad ones die off. There will be an online collection of these guys which will be auto downloaded by game.
- Skeletal Animation system (extend Cs's)
- Inheritance system so we can do something like: male,80y,Italian, Pope Romeo. Each word adding flavor to how Pope Romeo moves.
- Motion coordination system-inhibit,blend or exagerrate co-movements For instance Nick would look funny doing the fingernail tooth flick gesture while running from an enemy.
- shoulder moves upper-arm which moves lower-arm which moves hand something should manage this so we don't have to worry about it all the time.
- Networking (extend CS networking plugin)
- Get someone who knows about security to look this over
- Client Server
- Peer to peer (if can be done securely) And if it can be done intelligently. If A and B are in the same room, C in the hallway and D is a room away, then A and B are peer to peer, server keeps an eye on C to see if he gets close to A|B|D. No one is close to D, so the server just observes waiting.
- Explosion plugin if missing
- player should be able to plant an amount of explosive at a location and the object be destroyed reasonably close to the laws of Physics. Perhaps course meshed finite element analysis could be done while timers on bombs count down. Maybe cache FEA meshes for key buildings.
- General Object Useability
- Objects--trash cans, dogs, dismembered limbs, etc, should have a list of alternate uses so that in a fight it would be possible to beat your opponant with the wet end of a severed arm.
- Breakable glass. It should be possible, though bloody, to punch your hand through windows.
- In general things should be much like their real life counterparts.
- Multimedia
- Make use of AVI, Ogg Vorbis...
- Use 3d positional sound
- Start-up video. Short history of Israel. Start in biblical time at the beginning of Israel. Gloss over next few thousand years, stopping to mention the Roman invasion, the Crusades. Focus on 1949, how the Brittish favored the Moslims. The threat of war caused both sides to escalate toward war. Get the 7 days war. Then focus on the current situation.
- GUI System
- Where practical support English, German, Hebrew
- Keep it simple...use AWS
- Misc
- Be sure it will always be possible for users to add new areas of the world that blend seemlessly together with our work. For example the city wall's gates wont open now, but should have hooks so that others can easily cause them to open to their own levels.
LEVELS
-
(Actually these aren't levels in the typical sense but are just
areas of the entire game world that are loaded dynamically to
save memory. There are no goals to meet before changing levels)
- Temple Mount
- Old City Jewish,Armenian,Christian,Moslim Quarters
- Old City anyplace I left out
- For simplicity, in areas where walls have fallen, put them back up.
- Don't use skybox. Use skydome with animated sun/moon/stars
- Use mostly Hebrew for signs. A touch of Arabic and English.
- Consider Moore's law, it will be at least a year before final release. Gamers tend to have high end systems. So optimise, but don't leave out important details.
MODELS
- foreach race generic people ages 80,40,20,15,10 male and female
- Police
- Mossad officials
- Goat herder
- Military personel
SOUND
- Hebrew, Yiddish, Arabic voices
- Traffic sound
- Crowd sound
- birds, goat&sheep being worried sounds
RESEARCH
- Modern customs arab men often seem to kiss eachother in greeting, do others involved in this game? Who shakes hands? Gestures, mannerisms, gait.
- Where would gaurds typically stand?
- street signs
Architecture
This section pins down how we meet our requirments.
YERUSHALEM
game-structure
========
CONTENTS
========
1. STRUCTURAL OVERVIEW
1.1 SERVER (sv)
1.2 CLIENT (cg)
1.3 WORLD (world)
1.4 sv/cg CONNECTION (ServerCon / ClientCon)
1. STRUCTURAL OVERVIEW
=======================
There are over all 4 classes that interact with each other:
CLIENT is the client interface
SERVER is the server that handles all client-interactions and sends them to the clients
and his WORLD. sending data is done through the CONNECTION, where the client only has
a single one, while the server has one for each client.
this structure makes it possible to have a client and a server running simultaneously on
one machine: the connection will not be a network-connection but possibly something like a
simple socket or even just a function-call. the world will be the same for both sides.
because of this the client has to check if he is a pure client or a server-client-combo.
if he is a combo, he possibly won't be allowed to call the world to update itself (as the
server does this)
DATA FLOW
=========
CLIENTS SIDE SERVERS SIDE
---------- ----------
| CLIENT | XXXXXXXXXXXXXXXXXXXXXXXXX | SERVER |
------------------------------------------------------------------
| X sv/cg CONNECTION X |
-----------------------------------------------------------------
| WORLD | XXXXXXXXXXXXXXXXXXXXXXXXX | WORLD |
--------- ---------
data will flow -
- from clients to the server (containing all clients interactions)
- from the server to the servers world (changing the world due to clients
interactions
- from the servers world to the clients world
(updating the clients status or requesting new sector-data)
- from the clients world to the client (e.g. when looking which interactions
are possible)
- from the server to the client (global messages (chatting) may be exchanged that way)
1.1 SERVER (sv)
the main server-loop will look something like this
{
- retrieve player-state information from clients
- take care for players that want to (dis)connect.
- call the world so it cares for itself
- loop through all DYNAMIC ENTITIES 'ent' {
- look if ent needs to change due to a client-event,
timer or other events
(!! BUT NOT DUE TO SPEED OR FORCE as the world does this itself !!)
if so, change its status and mark it.
}
- all marked objects` status need to be send to the clients.
(in form of a 'game-snapshot' which would be a complete status
- or in form of single entity-specific information)
- if there is a request to stop the game, break.
}
for easier handling lets call one iteration of this loop a single cycle.
be aware that events happening in the same cycle will possibly not
affect each other the way we think, as we go through the virtual world
entity for entity. interactions of separate events will possibly
need a multiple of 1 cycle. but that shouldn't be too bad, as in
one second the server should (hopefully) calculate hundreds of cycles.
1.2 CLIENT (cg)
due to the event-driven character of the engine, the client-structure needs to
look different:
when using CS to render grafics, we need to enter the csDefaultRunLoop().
due to this, we have to use the EventHandler.
=============================================================================================
bool Client::csEventHandler(iEvent& ev)
/** this function is our major entry from CS
* for a list of all predefined events, look CS/include/iutil/evdefs.h
* for a little description on event, look the CS/docs/html
* especially 5.2.4, which talks about cscmd***Process
*/
{
if((ev.Type == csevKeyDown) || (ev.Type == csevKeyUp)) {
/// here we can easily handle keypresses and
/// possibly UI-events
self.ProcessClientInteractions();
return true;
} else
if(ev.Type == csevBroadcast) /// cscmdXX are broadcasted
if(ev.Command.Code == cscmdPreProcess) {
/// here we can communicate with the sv
Connection.Interact()
/// or something like that
/// and ask the world to recalculate itself
World.Calc();
return true;
} else if(ev.Command.Code == cscmdProcess) {
Self.SetupFrame();
return true;
} else if(ev.Command.Code == cscmdPostProcess) {
/// add a HUD onto the image
self.DrawHUD();
return true;
} else if(ev.Command.Code == cscmdFinalProcess) {
self.FinishFrame();
return true;
} else return false; /// event wasn't handled
}
=============================================================================================
someone may argue that if the client is structured this event-driven way, it may also
be better to structure the server that way too. i'm not sure, yet, but i think we
can save at least a bit of overhead that way. i am also not sure if we must use
the csDefaultRunLoop() to work with registry and other CS-internal data. if so, we
must use the event-handler on the servers side, too.
1.3 WORLD (world)
as on both sides (the server and the client-side) movements and the effect of forces can
be calculated, we can do it on both sides to reduce network-traffic and packet-parsing.
WORLD will be a class holding all entities. we can easily replace the above mentioned tree
of all entities with the world. furthermore the world will calculate continuous changes of
itself (like a bullet flying with a constant speed in a constant direction).
WORLD will do a lot of things related to CS.
1.4 sv/cg CONNECTION (ServerCon / ClientCon)
the CONNECTION will take care for all interactions between the client and the server.
it will possibly split into a ClientConnection (the server may hold one for each
client) and a ServerConnection (one on each clients side).
YERUSHALEM
client/server architecture
========
CONTENTS
========
1.0 SECTOR-USAGE TO INCREASE PERFORMANCE
2.0 DISTRIBUTED SERVER NETWORKS
1.0 SECTOR-USAGE TO INCREASE PERFORMANCE
========================================
with CS a level is organized into sectors, which will make our work much easier.
a server (still need to think about a multi-server-network) will know the complete
world, while a client only needs to know about all entities in its immediate area.
so lets say client enters game and starts in sector F6:
(a 8x8 2-dimensional matrix)
a b c d e f g h
8 . . . . . . . .
7 . . . . . . . .
6 . . . . . c . .
5 . . . . . . . .
4 . . . . . . . .
3 . . . . . . . .
2 . . . . . . . .
1 . . . . . . . .
distance is the number of portals between two sectors
depth(n) is 0<=distance<=n. Or a distance between 0 and n inclusive.
sector_sum(n) is the sum of sectors reachable within some depth n
// much better, greg. thx
with a depth=1 he will only need to know about sectorsum(1) == e7,f7,g7,e6,f6,...
with a depth=2 he will also need to know about sectors e8,f8,h8,..
the higher the depth, the more information need to be exchanged with the server
and the more things need to be rendered
keeping the depth low will reduce network-traffic and increase
rendering performance.
BUT: for a small depth: the smaller the depth, the less realistic the game will
be, as events happening in the other sectors (like sounds, explosions, quakes whatever)
will not affect the player if the distance is too high.
so sector-width and/or depth should be chosen according to this.
/*
Gregged.
Perhaps depths could vary according to event type? For example an earth quake may need to
be distributed across many sectors, while a conversation between two people would possibly
stay in the sector of origin. Maybe the event object could have a varible associated with it.
As the event passes from sector(or server?) to sector(or server) the var--'s. Once var==0 it
dies on it's server.
*/
/* fleshyCPU
first i thought a client connected to a server would request data of specific sectors, but
that doesn't actually make a lot of sence. you are right. it will be much more effective
if the server sends event-data according to the position of the clients.
/*
2.0 DISTRIBUTED SERVER NETWORKS
===============================
possibly this will also be the key to a distributed server-network:
a b c d e f g h
8 a a a a b b b b
7 a a a a b b b b
6 a a a a b b b b
5 a a a a b b b b
4 c c c c d d d d
3 c c c c d d d d
2 c c c c d d d d
1 c c c c d d d d
this would be a possibility for a distributed server-network. we have 8x8 sectors and
4 game-server. each of them takes care for 4x4 of them. a client only would have to
contact multiple servers while being near a border. the servers themselves would only
need to exchange game-wide information like the playerinfos or the global game-status
(if someone has won etc) or if a single object moves from one sector into another,
where another server is reliable. this would reduce traffic to a minimum.
/*Gregged:
I like this concept. I'd add to it the possibility to vary depth by event type (which is alluded to
here) and use priority queques.
*/
YERUSHALEM
entity architecture
========
CONTENTS
========
1.0 INTERNAL ORGANISATION OF ENTITIES
1.1 IN CRYSTAL SPACE
1.2 OPTIMIZATION HOLDING ENTITIES IN A TREE
2.0 ENTITY PROPERTIES / FUNCTIONS
1.0 INTERNAL ORGANISATION OF ENTITIES
=====================================
1.1 IN CRYSTAL SPACE
entities should be organized - as CS says - with CS-internal structures
(see docs/html/* chapter 5.7.9: Attaching User Objects to CS Objects).
name of the interface should be iEntity.
this class iEntity could have an embedded interface iActions,
that holds all actions that a player can do with it.
possibly a single action would be defined something like this:
struct Action_s
{
const char* name;
const (void*)(do)(void*);
}
but for optimization purposes we should possibly use a global
table that holds all available actions someone can to. if
someone wants to act, we will look in the table, what
his character can do with the specific object he wants to act on.
1.2 OPTIMIZATION HOLDING ENTITIES IN A TREE
this way all objects will be in CS`s
object-registry (struct iObjectRegistry) and we don't have to create
our own container for them
/* fleshyCPU:
using this method it would be necessary to retrieve a complete
list of entities each cycle and free() or DecRef() it at the end of the
cycle. this is very ineffective.
in the beginning we should retrieve a list from the object registry (WITHOUT o->IncRef())
and from this we build a tree sorted by sectors containing all entities. this will also help
during collision detection: as we only have to check for collisions in sector-bounds we can
use this reduced entity-list.
when an entity is destroyed, we will remove it from our tree and o->DecRef() it out of the
object-registry.
another question is: should we handle static and dynamic entities in the same way?
(static entities will be things that can not change during the complete game, like
walls etc [destroying walls can be done using portals] ; dynamic entities are objects
that may interact).
at the second level of the tree we could split between dynamic and static entities
and thus when iterating through all entities we only need to check the dynamic ones.
*/
2.0 ENTITY PROPERTIES / FUNCTIONS
=================================
specific objects like the players should be able to 'hold' or contain
other objects. for example a player can hold a weapon.
the player could have a specific ability to hold a special number
or special 'weight' of objects.
should we take care of objects specially-believing
people would't touch/carry?
/*Gregged:
If an object can be touched or can be carried, it should be possible. It could become a
memory problem though. Imagine this situation: Player throws rock at glass window. Window
shatters, glass shards fall to ground. Player picks up a shard and slashes another player's
throat. Now perhaps we could make the window a fairly normal CS thing. But when player hits it
with rock, the engine reads additional properties from a file, finds out glass shatters, that
it makes a usable weapon (although cuts into users hand) etc. Once the glass is no longer
being used, these extra properties are freed from RAM.
*/
/* fleshyCPU
such an object could contain the action 'break',
which would window->DecRef() (destroy the window) and spawn() new glass falling down, destroying
itself after a period of time being not used. once it was used this timer should be reactivated
when the user drops it. this glass needs to be of different material, though, as it needs further
actions like 'useShortRangeWeapon' 'useThrow' etc, while the former material/glass would only
have a single action 'useBreak' or 'useDestroy'.
*/
skeleton-based movent
for a description of the human skeleton, see various books
or arch.skeleton.gif (one of you english guys may write down
the english names for the various bones).
if we want that our characters perform realistic movements,
we can choose between different levels of authenticity:
the less realistic, the higher will the performance be.
-the most realistic version one can choose is to simulate every bone
and every muscle, but thats of course impossible for us.
but this version gives us the possibility to create descriptive bodies,
we could generate skeletons based upon descriptions like
"20 year old 1.80 meter high, male, ..."
-the most efficient would be to use animated models, as games
like quake and half-life and most others do. but using this way
we would have to generate different models for different looking
people (except the skinning)
i don't know if this will be possibly with the performace someone may
have:
we will reduce the skeleton to a number of important parts and
create basic physical formulas to set up the correlation between them.
using these formulas we can calculate movements and animations.
a client 'C' will possibly consinst of an entity 'CE'. each bone-part B may be
an entity 'BE' itself, as a child of the client:
CE { BE (skull)
BE (arm)
BE (leg-bone)
...
}
for animation the client may have a seperate embedded interface iMovements
(or iAnimations or...) which will hold functions of different complexity:
go (direction, distance)
step (direction, length)
move_lower_leg (angle)
move_higher_leg (angle)
move_foot (angle)
...
this way we can simulate a lot of activities, like a person just going
somewhere or kicks, grabbing a thing, interactions between people
(like: one person giving a thing to anotherone, as the hand
may hold an entity). furthermore we can use realistic collision-detection
for the body and create hit-zones.
the question then is:
how do we wrap the skin above these entities?
hopefully someone of you has an idea.