<random forum bug>The 'view post' didn't work correctly after I posted to this thread. My post started off page 3, but I was taken back to page 2.

Anyway, don't let me take this thread off on a tandem.</random forum bug>

Gaming development discussion, carry on now:

loadgame(file)
{
  if (gamenotsaved)
     if (!confirm("Current game not saved - proceed with loading saved game?"))
       return;
  open(file);
  if (!isasavefile(file)) {
    close(file);
    error("Not a save file!");
    return;
  }
  reset_engine(); // Get rid of old game
  graphics_start(); // Switch to configured fullscreen mode
  // Savefiles will consist of:
  // Map data for the current map (Probably a full copy of the map)
  // Ped list
  // Car list
  // Object list (Other junk like traffic cones, bullets, collectibles, etc.)
  // Mission script state (Variable values + event/trigger list.)
  // Mission script name
  // + probably some other stuff
  newgame = false; // Set newgame flag to false
  load_mission(GAMECONFIG); // Load game config script, run .onload
  // Load data
  load_map(file);
  load_peds(file);
  load_cars(file);
  load_objects(file);
  // Load mission state
  load_mission_vars(file);
  load_mission_triggers(file);
  // Load mission script
  load_mission(readstring(file));
  close(file);
  playgame();
}

newgame()
{
  if (gamenotsaved)
     if (!confirm("Current game not saved - proceed with starting a new game?"))
       return;
  reset_engine();
  graphics_start();
  newgame = true;
  load_script(GAMECONFIG); // Load config and run .onload
  playgame();
}

playgame()
{
  graphics_start();
  startsounds();
  rungame = true;
  t = clock();
  do {
    frametime = clock()-t;
    t += frametime;
    if (paused)
      frametime = 0;
    else {
      dopeds(); // Ped AI & physics
      docars(); // Car physics
      doobjects(); // Object physics
      checktriggers(); // Mission triggers
      dogamestuff(); // Other stuff - traffic lights, traffic spawning, animated textures, etc.
      gametime += frametime;
    }
    drawscreen();
    if (paused)
      dopausemenu(); // Draw pause menu & process keys for it
    wait(); // Wait for VSync
    swapbanks(); // Swap screen banks
  } while (rungame);
  return_to_wimp(); // Return to wimp mode, pause any playing sounds, etc.
}

• Game config file
• User config file
• WIMP sprites
• WIMP templates
• Ped definitions
• Ped sprites
• Car definitions
• Car sprites
• Map tile sprites
• Object sprites
• Mission scripts
• Fonts
• UI sprites
• Save game files
• Sound samples
• Music

• Game config file
  This file will give generic information about the game. By replacing this file or instructing the game to use a different copy, you will be able to run different user modifications/total conversions. This file will probably be a simple text file; it may even be a mission script. Exact contents of the file are unknown atm, but as a bare minimum I'd expect it to contain the names of the mission scripts for each level. It could also contain the pathnames of the directories to search when loading peds, cars, etc.
  Default location would probably be <DeathDawn$Dir>.gamecfg
• User config file
  This file simply contains configuration options for the game - keyboard settings, video mode, etc.
  File is likely hardcoded to be at <DeathDawn$Dir>.config
• WIMP sprites
  Any sprites used by the WIMP interface. This file might not even be needed.
  Location could be specified via the game config file, or just hardcoded to somewhere like <DeathDawn$Dir>.Sprites
• WIMP templates
  WIMP templates file. For consistency and simplicity of the UI, only one copy of the file will be supported, at <DeathDawn$Dir>.Templates
• Ped definitions
  Uses this format. The directory containing ped definitions will be given in the game config file; e.g. <DeathDawn$Dir>.peds
• Ped sprites
  Just in case two ped types share the same sprite file, each ped definition file will contain the filename of the ped sprite file. This name will probably be appended to, or used in conjunction with, a base path specified in the game config file. Default value will probably be <DeathDawn$Dir>.pedsprs
• Car definitions
  No full definition of this file format yet, but it will be a text file containing basic info about the vehicles (vehicle type, gear ratios, etc), as well as the name of the sprite file. The directory containing the car definitions will be given in the game config file, e.g. <DeathDawn$Dir>.cars
• Car sprites
  Uses this format. Similar thing to ped sprites - sprite file name will be given in car definition file, will be used with pathname given in game config file. Default value something like <DeathDawn$Dir>.carsprs
• Map tile sprites
  This will be a directory full of sprite files containing (multiple) 64x64 16bpp masked/unmasked images. Sprite naming system sill needs to be specified, to allow for animated sprites, integration with the map generator, etc. But for now basic details are that only the requested sprites/files will be loaded into memory; thus the game config file will contain the path of the directory containing the sprites (e.g. <DeathDawn$Dir>.tiles), and some further config system will specify what particular files need loading for a level.
• Object sprites
  Sprites for traffic cones/bullets/explosions/skid marks/etc. I'm not sure if there should be one sprite file per object type, or all sprites lumped together in one file. Or even multiple sprite files containing sprites for multiple objects which will then be loaded and merged.
  Either way, the location(s) of the files will be given in the game config file.
  Unless I go for some magic generic physics engine, object types & names will be hardcoded into the game. Which only makes me want to do a generic system even more
• Mission scripts
  Uses this format. Game config file will contain location of the directory containing the mission scripts, and/or the names of each script.
• Fonts
  Just a set of sprite files containing sprites for each letter, the same as every other GnarlPlot font file. Game config file will probably contain the name of the directory containing the fonts. Some font file names within that directory will probably be hardcoded into the game; it's possible that other ones could be specified through mission scripts.
• UI sprites
  Any other sprites used by the user interface, stored in one file. This file will be named in the game config file. Contents will include menu graphics, minimap icons, etc.
• Save game files
  Brief file format info is given here. Storage location will be fully user specified, as the game uses standard saveas boxes.
• Sound samples
  The game config file will probably contain the name of the directory to search for sound samples. Car/ped/mission files will then contain the names of the samples to use within that dir.
• Music
  Probably CD music or integration with AMPlayer or something. Don't ask me!

but potentially more complicated engine code (support for on-demand loading of files)

.onload
; Set paths
PEDDEFPATH "<DeathDawn$Dir>.peds"
PEDSPRPATH "<DeathDawn$Dir>.pedsprs"
CARPEDPATH "<DeathDawn$Dir>.cars"
CARSPRPATH "<DeathDawn$Dir>.carsprs"
TILEPATH "<DeathDawn$Dir>.tiles"
OBJPATH "<DeathDawn$Dir>.objs"
MISSIONPATH "<DeathDawn$Dir>.missions"
FONTPATH "<DeathDawn$Dir>.fonts"
UIPATH "<DeathDawn$Dir>.ui"
SOUNDPATH "<DeathDawn$dir>.sound"
; Load data
LOADFONTS "*" ; Load all font files
LOADUI "*" ; Load all UI sprites
LOADSOUND "menu.*" ; Load all menu sounds
LOADING ; Display loading screen
IF NEWGAME THEN .newgame
; .. else script is getting loaded with a savegame game
STOP

.newgame
imegamap[] = 16 ; Create megamap as an array of ints giving the random number seeds for each main map
; Map is actually 4x4, but is represented as a 16 entry linear array
smegamap[] = 16 ; String array naming the different mission scripts for each map
i = 0
.loop1
imegamap[i] = RANDOM
smegamap[i] = "desert"
i = i + 1;
IF i < 16 THEN .loop1
; Set start coords
imegamapx = 0
imegamapy = 0
; Initialise list of mission scripts
smegamap[0] = "prison"
smegamap[1] = "prisontown"
smegamap[10] = "town1"
smegamap[12] = "town2"
; Load the mission
i = imegamapx + imegamapy*4
MISSION smegamap[i] ; Will stop the current script and load the new one, preserving all variables

.onload
LOADTILES "generic.*" ; Load all generic map tiles
LOADTILES "prison.*" ; Load all prison map tiles
LOADCARS "generic.*" ; Generic cars
LOADCARS "prison.*" ; Prison cars
LOADPEDS "generic.*" ; Generic peds
LOADPEDS "prison.*" ; Prison peds
LOADSOUND "generic.*"
LOADSOUND "prison.*"
LOADOBJS "generic.*"
LOADOBJS "prison.*"
IF NOMAP THEN .makemap ; If there is no map, build one
; ..otherwise this is the .onload function getting called when the save game is reloaded
STOP ; Stop the script

.makemap
i = imegamapx + imegamapy*4
BUILDMAP PRISON imegamap[i] ; Build prison style map using imegamap[i] as the random seed
; Spawn the player and initial mission objects etc.
STOP

.nextmap
LOADING ; Switch to loading screen
; Insert code here to kill everything that you don't want transporting to the new map
KILLMAP ; Kill current map and all unused assets (ped, car definitions, tile sprites, etc)
i = imegamapx + imegamapy*4
MISSION smegamap[i] ; Load new script
; The new script will then relocate the surviving cars/peds so that they are at suitable locations

typedef struct {
  int type; // Object type
  vec16 p; // Location
  vec16 v; // Velocity
  f1616 rot; // Sprite rotation
  int animid; // Sprite/animation ID (see below)
  void *d; // Type-specific data
} object;

#define OBJECT_NONE 0 // No object
#define OBJECT_BULLET 1
#define OBJECT_ANIM 2
#define OBJECT_CONE 3
#define OBJECT_BOLLARD 4
#define OBJECT_MEAT 5

typedef struct {
  ped *powner; // Owner information
  car *cowner;
  int launchtime; // Time it was launched. Can be used to determine time of removal/detonation/etc
} bullet_data;

typedef struct {
  int time; // Base time to determine the animation frame from
  int death; // Game time to remove the object at
} anim_data;

typedef struct {
  int frame; // Current frame number. Frame will cycle/choose at random when the object is hit
  f1616 radius; // Radius of object in game units
  f1616 mass; // Mass of object
} cone_data;

typedef struct {
  int time; // Base time to determine animation frame from
  f1616 radius; // Radius of object
} bollard_data;

typedef struct {
  f1616 health; // Amount of health
  f1616 maxhealth; // Maximum health - used to determine frame number
  f1616 radius; // Radius
} meat_data;

typedef struct {
  int time; // Time to display frame at
  gp_spr *spr; // Sprite to display
} frame;

typedef struct {
  int nframes; // Num frames
  frame *frames; // Frame list
  char *sprname; // Name of original sprite
} anim;

anim animations[MAX_ANIM];

#define        animid      sprite base name
ANIM_BULLET    0           bullet
ANIM_ROCKET    1           rocket
ANIM_FLAME     2           flame
ANIM_WATERJET  3           waterjet
ANIM_SKIDMARK  4           skidmark
ANIM_SPARKS    5           sparks

• i - 32 bit signed int
• f - 16.16 bit fixed point
• v - 16.16 bit fixed point 3D vector
• s - string
• p - ped ID
• c - car ID
• o - object ID
• e - generic ID - Can be a ped, car, or object ID
• g - gang bitflags
• . - code label. Read-only!

• h - HUD element. Can be given the value of a vector, ped, car or object, and will cause a pointer to that location to be drawn on the HUD
• t - event/trigger combo. Will allow the mission script to give names to the events it creates, so that it can disable them later on.
• b - Map block. Is this a block coordinate, or a block type? Map code editing commands must be able to operate on either a specific block, or every instance of a block type.
• r - Map region. A simple 3D box. Each region can be given different properties, e.g. the name displayed to the user, the type of gang peds to spawn, the different vehicle classes that will spawn, etc.

EXPLOSION vpos 400 pped

would cause an explosion at vpos, dealing 400 damage, with pped attributed as the owner. This command will cause 3 things to happen:

1. Damage to everything near vpos
2. Set some objects near vpos on fire
3. Create an explosion animation object at vpos, with the appropriate animid and death time.

Cheers,
Rich.

How are you going to deal with radius/drop off of damage? Or just simplifying it by having 400 across the whole (square?) area of the explosion anim, and nothing in adjacent areas?

Do you have a "people blown off their feet" anim?

I suppose flipped cars are already catered for?

• WANDER - Just wander around the streets
• GO - Follow a particular ped/car/object, or head towards a location/region.
• PROTECT - Protect a list of peds/cars/objects from attack or theft
• GO_PROTECT - Follow and protect a list of peds/cars/objects from attack or theft
• KILL - Kill a list of peds/cars/objects
• JACK - Steal a car. If a ped is given as a target object, it will steal the car that ped is in. If a car is given as a target, it will steal that car. If no target is given, it will steal any car.
• EXIT - Get out of current car
• RIDE - Get into a specific car (or into the same car as a specific ped), travelling as a passenger

• COMPLETE - The ped has completed its goal (Reached target, killed person, etc.)
• FAIL - The ped has failed its goal (Been killed, allowed target to die, etc.)

• Cars
• Bikes
• Boats
• Aircraft
• Police/Military vehicles
• Only vehicles which the ped owns

• Ped pain - for when a ped gets hurt
• Ped heal - for when a medic heals a ped
• Ped death - for when a ped dies
• Ped touch - for when an object bumps into a ped
• Car pain - for when a car gets hurt
• Car heal - for when a car gets repaired
• Car death - for when a car explodes
• Car touch - for when an object bumps into a car (including crashing into walls)

*tries to resist the urge to start coding*

• AUTO - The ped will autonomously react to events around it, changing AI goals by itself
• MANUAL - The ped is part of a mission script, and will only change AI goals when told to by the script.

• WIMP interface - Can be covered at coding time
• Support code - hash/set ADT - Could do with writing that at some point.
• Map generator - Can be covered at coding time
• Ped, car, object data structures - Can be covered at coding time
• Mission script tokenised form, variable management - Can be covered at coding time
• Sound system - Use SharedSound!
• Spatial sorts - There will be lots of objects, we need to decide on a suitable spatial sort algorithm to keep things nice and spiffy

I inevitably find that I lose interest in something before it degenerates into an impossible to work with mess

Any other ped/car related events people can think of?

Cheers,
Rich.

PED_STOP_FOR_NICE_CHAT

PED_TALK_ABOUT_WEATHER

PED_SIT_AT_PAVEMENT_CAFE_SO_CAR_CAN_CRASH_THROUGH_SCENE

PED_SIT_AT_PAVEMENT_CAFE_SO_CAR_CAN_CRASH_THROUGH_SCENE

And that, although obviously it would activate the car moving rather than a message

Cheers,
Rich.

How about PED_SILLY_BLOODY_JOGGER

I was thinking more about telling the ped to sit; the car crashing through the scene would be me, at which point they'd be running screaming.

Perhaps an extension of RIDE - although that'd mean you'd need some kind of "vehicle" that appears to be a chair and has a top speed of 0mph.

:uploadyouruml:

• Iconbar icon
• Iconbar menu
• Fancy key reconfig window - will detect keys that have been used for multiple actions, except actions which can't be performed at the same time anyway (e.g. using the same key for jump and handbrake will work)
• Fancy graphics config window, including fancy menu listing enumerated screen modes (Including checks to make sure the modes are 16bpp and there is enough video memory for 2 screen banks). Even lets you choose the refresh rate!
• User config file loading/saving
• Saveas box for save game files

Isn't that a bit like designing the iPod case before inventing the HD and audio compression?

• Reserved word - Typically a command name
• Variable name
• Constant integer value
• Constant fixed point value
• Constant vector value
• Constant string value

typedef struct {
  int type;
  int data;
} token;

#define TOKEN_RESERVED 0
#define TOKEN_VARIABLE 1

typedef struct {
  int size; /* Array size, -1 if not an array */
  int data; /* Data value or pointer */
  char name[0]; /* Variable length array thingy containing variable name */
} mvar;

• i - mvar.data will be the int value
• f - mvar.data will be the f1616 value
• v - mvar.data will point to the vec16 value
• s - mvar.data will point to a char array containing the string (Or perhaps a special string data type, I dunno)
• p - mvar.data will be the integer ped ID
• c - mvar.data will be the integer car ID
• o - mvar.data will be the integer object ID
• e - mvar.data will be the integer entity ID. The top byte will be used to identify whether it's a ped, car, or object.
• g - mvar.data will be the 32bit gang bitflags
• . - mvar.data will be the index into the token array of the instruction which the label points at
• i[] - mvar.data will point to an array of ints
• f[] - mvar.data will point to an array of f1616's
• v[] - mvar.data will point to an array of vec16's
• s[] - mvar.data will point to an array of char *'s (or string *'s)
• p[],c[],o[],e[] - mvar.data will point to an array of ints giving the ped/car/object/entity ID's
• g[] - mvar.data will point to an array of ints giving the gang bitflags
• .[] - mvar.data will point to an array of ints giving the token array indexes of the instructions the code labels point at

Isn't that a bit like designing the iPod case before inventing the HD and audio compression?

[Edited by adrianl at 01:24, 25/11/2005]