log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Git client updated to 0.07 (News:2)
- Archive Edition 27:1 reviewed (News:)
- Rougol April 2024 meeting on monday is Anniversary time (News:1)
- WROCC April 2024 meeting o...changes to our phone lines (News:1)
- April developer 'fireside' chat is on saturday night (News:)
- March 2024 News Summary (News:4)
- WROCC Newsletter Volume 41:11 reviewed (News:)
- WROCC March 2024 meeting o... Hughes and Peter Richmond (News:1)
- Rougol March 2024 meeting on monday with Bernard Boase (News:)
- Drag'n'Drop 13i2 edition reviewed (News:)
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server.
 
  Slightly cold news on page 10! Phlamey breaks the server.
  This is a long thread. Click here to view the threaded list.
 
Jeffrey Lee Message #70840, posted by Phlamethrower at 17:34, 21/10/2005
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
...Because of the programmers rule. (Although at the moment it's at the design stage, so might attract some people). (And even if it does fail, it's at least saved me the effort of moving 6 feet to my right, turning on the RPC, and creating a directory structure for another game which will probably never get beyond the design stage).

What we (I) shall do is work on a design for this post-apocalyptic GTA clone thingy using the revised Escape from LA/New York/wherever storyline. If the design reaches a suitable stage of development, then we (I) will program the game (Assuming we (I) can obtain a crapload of artwork to use).

First, some number crunching. The minimum target machine will be a StrongARM RiscPC. This means we'll have about 32MB/s of memory bandwidth. So that we don't have to work with a crappy palette, the game will be designed to run in a 16bpp mode. At a target frame rate of 25fps, this will give us a maximum screen size of 327k pixels. 320x256 (81k pixels) will give us lots of overhead, but won't be displayed at the proper aspect ratio on some monitors (e.g. mine :P). 640x480 would be nice, but will almost max out our memory bandwidth at 307k pixels. 512x384 will probably be the best resolution to design the game for, containing around 196k pixels per frame. Of course faster machines (e.g. Iyonix) will be able to go higher, and there's the possibility for slower machines to use 320x256 or 8bpp colour. 8bpp (or 24bpp) support will be incredibly simple to provide, since the intention is to use GnarlPlot for all the graphics.

Now, onto the basic engine structure.

First of all I'll start by describing the maps. Levels in GTA 1/2 can be likened to cities made out of giant lego blocks, fitting in a large (approx 256x256x6) array. Each block has a top & 4 side textures. The textures are all identical in size, 64x64 pixels. The block can also slope downwards in either of the 4 cardinal directions. If memory serves there were about 4 different inclinations possible. And of course each block will have several flags available, to control if it contains air/water/concrete/soil, the direction of the road, etc. A 256x256x6 array of such blocks would require a lot of memory, so they used a fairly simple compression method. Each unique stack of blocks was stored in an array, and a 256x256 array was created to index the block stacks. Thus a 256x256 map with only 1 type of block stack would use close to just 256k of memory.

Now, onto our (my) version of the map. I want to keep the same basic structure, but allow almost limitless height in the block stacks. This will allow us to add very tall buildings/cliffs/etc. To do this we can change the code so that each block stack can be as tall as we want, and add a value to the 256x256 map array to control the height of the bottom block in the stack. Also rather than 4 different inclinations, arbitrary inclinations (in the 4 cardinal directions) will be supported. Each stack will be an array of block pointers, not of block definitions; this allows even further compression of the map data. The only downside of having so much compression is when finding appropriate block and stack definitions to use during map creation/generation.

The basic structure of the map data will be as follows (Using the fixed point math code from WOUM):


typedef struct {
gp_spr *top,*north,*south,*east,*west; /* The textures for the 5 visible sides */
int flags; /* Flags */
f1616 h1,h2; /* Heights of the two edges */
} block;

/* Block flags */
/* This would work better using a proper bitfield type */
#define BLOCK_ROT 3 /* Mask to use when reading/writing rotation of top texture */
#define BLOCK_ROT_NONE 0 /* No rotation */
#define BLOCK_ROT_LEFT 1 /* Rotated left 90 degrees */
#define BLOCK_ROT_RIGHT 2 /* Rotated right 90 degrees */
#define BLOCK_ROT_180 3 /* Rotated 180 degrees */

#define BLOCK_CONTENT 28 /* Mask to use when reading/writing contents of block */
#define BLOCK_CONTENT_AIR 0 /* Block contains air */
#define BLOCK_CONTENT_SOLID 4 /* Solid ground */
#define BLOCK_CONTENT_WATER 8 /* Water */
#define BLOCK_CONTENT_DIRT 12 /* Grass/dirt */
#define BLOCK_CONTENT_RADIATION 16 /* Deadly radiation */
/* ... etc */

#define BLOCK_SLOPE_HORZ 32 /* h1 & h2 are the heights of the east and west edges of the block,
as opposed to the heights of the north & south edges */
#define BLOCK_PED_PATH 64 /* Pedestrians will try and stick to these blocks */

#define BLOCK_ROAD_NORTH 128 /* Road goes north */
#define BLOCK_ROAD_SOUTH 256 /* Road goes sorth */
#define BLOCK_ROAD_EAST 512 /* Road goes east */
#define BLOCK_ROAD_WEST 1024 /* Road goes west */
/* Set multiple flags to create junctions */

#define BLOCK_WALL_NORTH 2048 /* Flags to control if the north/west sides of the block are solid */
#define BLOCK_WALL_WEST 4096 /* e.g. to create a solid fence between two blocks */
#define BLOCK_WALL_TOP 8192 /* Top side is solid, useful if the block below must contain air */

typedef struct {
int height; /* Number of blocks in the stack */
block *b[0]; /* Blocks (Using GCC variable length array wotsit) */
} stack;

typedef struct {
f1616 base; /* Base of the bottom block in the stack */
stack *s; /* The stack */
} stack2;

typedef struct {
int width,height; /* Map size in blocks */
stack2 m[0]; /* width*height array of block stacks */
} map;


Each block is 1x1x1 unit in size. h1 & h2 must be between 0 and 1. Example function to return the contents of a coordinate:


int contenttype(map *m,f1616 x,f1616 y,f1616 z)
{
int ix,iy,iz;
stack *s;
stack2 *s2;
/* Get integer coords & apply limits */
ix = x >> 16;
iy = y >> 16;
if (ix < 0)
ix = 0;
else if (ix >= m->width)
ix = m->width-1;
if (iy < 0)
iy = 0;
else if (iy >= m->height)
iy = m->height-1;
/* Get stack data */
s2 = &(m->m[ix+iy*m->width]);
/* Get index into stack */
z = z-s2->base;
if (z < 0)
iz = z = 0;
else
iz = z >> 16;
s = s2->s;
if (iz >= s->height)
iz = s->height-1;
/* Examine slope data in the block */
x &= 0xFFFF;
y &= 0xFFFF;
z &= 0xFFFF;
if ((z > s->b[iz]->h1) && (z > s->b[iz]->h2)) { /* Above the surface? */
if (iz == s->height-1)
return BLOCK_CONTENT_AIR; /* Assume everything above the map is air */
else
return s->b[iz+1]->flags & BLOCK_CONTENT; /* Return content of the next block up */
} else if ((z <= s->b[iz]->h1) && (z <= s->b[iz]->h2)) /* Below the surface? */
return s->b[iz]->flags & BLOCK_CONTENT; /* Return the content of this block */
else if (s->b[iz]->flags & BLOCK_SLOPE_HORZ) /* We are in the sloping section */
x = s->b[iz]->h1+f1616_mul(s->b[iz]->h2-s->b[iz]->h1,x); /* Surface height at our coords */
else
x = s->b[iz]->h1+f1616_mul(s->b[iz]->h2-s->b[iz]->h1,y);
if (z <= x)
return s->b[iz]->flags & BLOCK_CONTENT;
else if (iz == s->height-1)
return BLOCK_CONTENT_AIR;
else
return s->b[iz+1]->flags & BLOCK_CONTENT;
}


Simple, eh?

Now the only problem with a design this flexible is that drawing the screen could be tricky. In GTA 1/2 you could simply draw the blocks from the bottom to the top, using overdraw to hide the ones which should be hidden (Making sure you draw the cars etc. along the way). However with this design you can't quickly calculate what the deepest point in the level is, and thus how large the area of the map should be that you need to consider for drawing. One solution would be to use a top-down approach, essentially ray casting into the level. With the right optimisations (e.g. a beam tree system) this could be done quite quickly, but the complexity of casting the beams into the map could cause implementation problems. It also might not be so easy to draw the cars and other objects into such a scene, and may not fully support transparent block textures.

A suitable compromise might be to use the following algorithm:
1. Set the 'to draw' area to the block directly under the camera
2. Extend a pyramid down from the camera position, until its base reaches the same height as the lowest point in the 'to draw' area
3. The blocks which touch the base of the pyramid (in terms of their x & y coords) become the new 'to draw' area
4. Repeat steps 2-3 until the 'to draw' area becomes no larger

This should then provide you with the rectangular subset of the level which needs drawing, much like can be calculated for GTA 1/2. You can then add all the blocks, cars, peds, etc. into a suitably sorted list and draw from back to front, using overdraw to hide stuff which shouldn't be seen. The sorting algorithm to use in the list might need some tweaking, but as a rough guess you could translate each block, car, etc. into a list of component sprites and just Z sort them.

So, that's (hopefully) the map structure sorted. Any comments?

Who wants to have a go at designing the next bit? (Car/vehicle system, peds, destructible objects, map generation algorithm, etc.)

If anyone knows a good way of adding lighting effects to such an engine (e.g. streetlamps & headlights at night) then that would be nice :) As well as lots of 64x64 16bpp artwork :)

[Edited by Phlamethrower at 22:54, 26/10/2005]
  ^[ Log in to reply ]
 
Tony Haines Message #70843, posted by Loris at 19:03, 21/10/2005, in reply to message #70840
madbanHa ha, me mine, mwahahahaha
Posts: 1025
Why do you want such a deep map? Won't it affect (reduce) the playablility? If not, how will it improve the game?
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70844, posted by Phlamethrower at 19:30, 21/10/2005, in reply to message #70843
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Why do you want such a deep map?
So I can have big buildings, mountains, and levels which gradually get higher (or lower) the further you travel from one side to another.

Won't it affect (reduce) the playablility?
How could it?

If not, how will it improve the game?
By letting me have big buildings, mountains, and sloping levels! :P

Big buildings are useful for cities. In the future new land could be hard to come by, so people will build up instead of out. It might be possible to have multi-layered cities in the game, which you may remember from such sci-fi films as The Fifth Element. Rich corporate skyline -> average joe congestion -> abandoned/sewer level for all the homeless/criminals/mutants/etc.

Big mountains/ravines are useful for wasteland areas - e.g. having a big ravine which needs to be crossed. There might be a bridge, or you might have to drive down one side and up the other.

Sloping levels are useful for pretty much anything. Sand dunes in the desert (Although they may look crap because of lack of support for sloping corners), hilly countryside, etc. Basically for those leves you'd want unlimited height/depth so that you don't have to worry about keeping the map on a certain base line.

Plus not having to store 6 (or 7, 8, etc.) blocks per stack can reduce the memory requirements for the level. Most stacks will probably only be 1 block tall.

And as for the fully variable base height for the stacks - that's just there because it can be :)

It could also be an easy way to implement earthquakes, lifts, etc.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70845, posted by Phlamethrower at 19:43, 21/10/2005, in reply to message #70844
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Since it's somewhat relevant...

The game world

The game world will (probably) be a set of identical size maps, forming a small grid. Driving far enough off one edge of a map will cause the next map to be generated/loaded. This allows you to travel back and forth as you wish, but for the most part the storyline will be linear.

At the moment I can see the gameplay progressing through maps in the following order:

1. Prison. This will be where you start. Either surrounded by water or desert to stop inmates escaping.

2. Prisontown (for want of a better word). This will be the small town next to the prison that all the guards live in. The town also acts as a supply base for the prison. Will probably be surrounded by desert, with a road and/or rail link indicating where the next level will be.

3. Wilderness area. Probably has a couple of small settlements. Full of bandits/criminals/etc.

4. A megacity in a state of anarchy. The city was devestated by the nuke/killer virus/whatever, and has various criminal organisations/rival corporations/mutants/whatever roaming the streets.

5. More wilderness.

6. A megacity in good condition. It's been able to hold out against the nuke/killer virus/whatever, so there will be lots of corporate security forces roaming the streets looking for you. This will probably be the last level in the game, assuming I stick to my plan of a rigid storyline. In which case it would contain the end goal, e.g. getting that fiver back from your mate.

So as you can see, the game needs to be able to do big flatish areas as well as crowded tallish ones :)

Map generation

Unless someone wants to write a map editor and spend hundreds of hours making maps, I think the game will be using computer generated maps. This shouldn't be too hard, either for the cities or the wilderness. The prison itself will be a converted city, so that can use the same generator. I suspect that if you took the map generator from GAIO, changed the rooms to buildings and the walls to roads, then you would have a fairly decent city generator. Once the city has been generated the locations of the mission items, etc. can be chosen fairly easily (Much easierly than the locked doors & keys in GAIO).

[Edited by Phlamethrower at 19:48, 21/10/2005]
  ^[ Log in to reply ]
 
Andrew Message #70846, posted by andrew at 19:51, 21/10/2005, in reply to message #70840
HandbagHandbag Boi
Posts: 3439
[Snipped feckin huge quote - RG]
Yes. You're a genius. :P

Also, what exactly does ray casting mean? Calculate a distance based on stored coordinates? Always wondered this.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70847, posted by Phlamethrower at 20:03, 21/10/2005, in reply to message #70846
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Yes. You're a genius. :P
Good :)

Also, what exactly does ray casting mean? Calculate a distance based on stored coordinates? Always wondered this.
If you envisage the camera object as being a torch, then ray casting is the process of "casting" each ray of light from the torch onto the world and working out what colour the world is at the point that the ray hits it. You send out one ray per screen pixel, casting it in the correct direction so that the image makes sense once it's complete :)

Beam trees/beam casting/etc. is an optimisation of that where you group the rays together into a beam shape. The beam will start out as a pyramid shape growing out from the camera. This will then get split up when it collides with the closest object; the remaining beams will then get split further when they collide with the object behind that; etc. Eventually all parts of all beams will have collided with an object, and you'll know exactly which parts of which objects to draw on each part of the screen.
  ^[ Log in to reply ]
 
James Shaw Message #70850, posted by Hertzsprung at 22:26, 21/10/2005, in reply to message #70845
Hertzsprung
Ghost-like

Posts: 1746
[snip game world description]

this sounds a bit like flashback :)
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70855, posted by Phlamethrower at 23:39, 21/10/2005, in reply to message #70850
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
[snip game world description]

this sounds a bit like flashback :)
Heh, true :)

I was hoping to include both hovercars and regular cars, but no planet hopping or shapeshifting aliens :P
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70880, posted by Phlamethrower at 15:24, 22/10/2005, in reply to message #70855
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Vehicle graphics

Focusing on the cars here, but pretty much the same thing can be done for trains/planes/helicopters/bikes/segways/sheep/whatever.

In GTA 1/2, cars consisted of a set of sprites which would be overlayed ontop of each other to show the car in different states. The first would be the base sprite, showing the car undamaged and with all the doors closed. Then there were 6 damage sprites, showing what the car looks like when different parts of the body have been damaged - the front left, front right, left side, right side, rear left, rear right. Then there would be several sprites showing the doors in different positions (About 3 sprites per door IIRC). Finally vehicles with flashing lights would have 2 extra sprites showing the 2 states the lights would be when they are turned on. The car editor utility would then take these sprites and compare them to the base sprite, creating delta sprites. These delta sprites can then be drawn ontop of the base to show the car in any state - no damage, fully damaged, all doors open, etc.

To allow cars to be recoloured, each car was given its own 256 colour palette. About 32 of these colours were set aside for the car recolouring - 16 for the main colour and 16 for the secondary. The game could change these palette entries to recolour the car. In GTA 2 there were also a few additional colours, used for the head & tail lights.

This basic sprite structure will be retained for this game. Anticipated sprites will be:

* An optional floor sprite
* The base sprite
* The 6 damage sprites
* 2 optional flashing light sprites
* 3 sprites per door, up to a maximum of 4 doors

The sprites will be plotted in the order listed above. The floor sprite will only be used in convertible/open top cars; first the floor will be plotted, then the passengers, then the remaining sprites. This allows for certain parts of the car to be drawn over the top of the passengers, which was not possible in GTA 1/2.

The per-car palette will consist of 188 regular colours, 2 head & tail light colours, 2 mask colours (see later), 32 colours for the main recolour block and 32 for the secondary recolour block. 32 colours per recolour block is being used since we are running in a 16bpp colour mode, e.g. this will provide the full 32 shades of blue for a blue car.

Optimisations:

Obviously converting the car images to 16bpp and recolouring at the same time won't be a very fast way of drawing the cars, especially considering that there may be between 1 and 13 sprites to draw per car. Also drawing the sprites one at a time to the screen won't allow for dents in the car caused by damage - the old shape of the bodywork will be visible behind the damage sprite.

Instead, car images will be cached between frames. Cars won't change appearance very often, so caching the data like this will make sense. For each car type, the master set of sprites will be stored in memory. For each car, a set of bitflags will be used to indicate which sprites need drawing (As well as the palette data for the redefinable entries). If the state bitflags, palette data, or seated peds have changed between one frame and the next, the car image will be regenerated. Computing the car image involves creating a 16bpp sprite large enough to contain the (unrotated) car, and plotting the component sprites to it in the correct order. For convertibles/open tops, passengers will also be added to the car at the correct stage in this process.

By storing a seperate 256 colour palette per car the recolour process will be quick and simple. If cars are stored as 8bpp unmasked sprites then the palette can contain two mask entries: Real mask and forced mask. Real mask will be used for all areas outside the car, and will have no impact on the contents of the cache image. Forced mask is when a coloured area of the cache image needs to be changed back to a transparent one, e.g. when a damage sprite creates a dent in the bodywork. The 256 entry palette will index directly the 16bpp colour value to use in the cache image.

This palette will probably be generated two 16bpp colour values to control the recolour blocks, and a flag to control of the head & tail lights are on (Possibly replace these with two more colours so custom head & tail light colours can be used). The source palette will be read, converted to 16bpp, and copied into the per-car palette. The recolour colours will then be filled in their appropriate slots, by fading them to black over the 32 different entries. The head & tail light colours will then be filled in, and the forced mask colour will be set to 0x8000 (The value used by masked 16bpp GnarlPlot sprites to indicate a masked pixel).

A quick bit of assembler to add to a cache image would go as follows (Assuming source & dest images are the same size):


; R0=Source 8bpp
; R1=Dest 16bpp
; R2=Number of pixels in image
; R3=Palette ptr
.loop
LDRB R4,[R0],#1
MOVS R4,R4,LSL #1 ; Using index 0 for real-mask
LDRNEB R5,[R4,R3]!
LDRNEB R6,[R4,#1]
STRNEB R5,[R1],#1
STRNEB R6,[R1],#1
ADDEQ R1,R1,#2
SUBS R2,R2,#1
BNE loop


(No doubt Adrian can spot something I should be doing different, but I said it was a quick example, not a fast one :))

Source images on disc can either be stored in their pre- or post- delta format; the conversion process is fairly simple. It also doesn't matter much if they are stored with or without a mask, as any masked pixels can be easily converted to the mask palette value.

Pedestrian graphics

There will only be a handful of different pedestrian types; pedestrians will make heavy use of recolouring to appear different from one another.

One approach could be to copy and recolour the ped sprite sets for each ped. If there are 64 different ped animations 16x16 pixels in size, each set will take about 32k of RAM. If there are 64 peds in the world then this will take up 2MB of RAM, a fairly large amount.

A much more memory friendly approach would be to use a similar caching method as for the cars. Although most peds will change animation frames every other game frame or so, the caching process will not cause a significant hit to game speed as the sprites are small and the algorithm simple.

A peds sprite state can be represented as the animation number, frame number, and the ped colours. Peds are likely to have 4 recolour blocks - the shirt, pants, skin and hair. This means a ped palette will consist of 127 main colours, 1 mask colour (No need for a fake mask, as no overlaying is required), and 4 blocks of recolour entries, containing 32 colours each.

With a cached image generating algorithm that takes into account sprites of differing sizes (e.g. delta sprites for cars may be very small), peds in cars can be translated straight from their source image into the car cache.

Additional sprites

Other sprites such as explosions, bullets, movable objects such as rocks, traffic cones, etc. won't change colour, so their sprites can be converted straight to 16bpp and plotted to the screen as normal.

Now who wants to work out some vehicle physics algorithms? :P
  ^[ Log in to reply ]
 
Richard Goodwin Message #70881, posted by rich at 15:41, 22/10/2005, in reply to message #70880
Rich
Dictator for life
Posts: 6827
So presumably (because I only understood about half of that ;)) you draw the car in one direction, and rotate it as you need it? How many rotations (16? 32? more?)? Do you have to cache loads of rotations?
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70882, posted by Phlamethrower at 15:48, 22/10/2005, in reply to message #70881
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
So presumably (because I only understood about half of that ;)) you draw the car in one direction, and rotate it as you need it?
Yes, same with the peds :) I probably should have made it a bit clearer :)

How many rotations (16? 32? more?)? Do you have to cache loads of rotations?
Infinite! Bear in mind that for each frame, any car/ped is likely to change rotation and scale. Caching those images isn't likely to be worth it. I might however need to write a faster version of my scaled/rotated sprite plotter, or some code for special cases. I don't think the general purpose algorithm will cut it when used to draw the entire screen.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70883, posted by Phlamethrower at 15:51, 22/10/2005, in reply to message #70882
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
GTA 1 car delta tutorial for pics of what it should look like :)
  ^[ Log in to reply ]
 
Andrew Message #70898, posted by andrew at 21:09, 22/10/2005, in reply to message #70883
HandbagHandbag Boi
Posts: 3439
16bpp
:drool:
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70902, posted by Phlamethrower at 22:01, 22/10/2005, in reply to message #70898
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Yes :)

And with all those 256 colour palettes knocking around, it should be easy to do global lighting changes such as a day/night cycle.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70986, posted by Phlamethrower at 19:42, 24/10/2005, in reply to message #70881
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Tsk, you lot are lazy :P

So presumably (because I only understood about half of that ;)) you draw the car in one direction, and rotate it as you need it? How many rotations (16? 32? more?)? Do you have to cache loads of rotations?
Which bits didn't you understand btw? I could probably rewrite it to make it clearer.

User interface

No need for anything fancy here. Iconbar icon when the game is loaded, with iconbar menu to show program info/change options/save the game/quit/etc. Could probably reuse some code from Dark Matter, e.g. the controls config window. Going ingame will switch to a fullscreen mode. Games can be paused; pause menu will probably have its own options menu, containing the same options as the WIMP version. Could also include a save game option to allow the current game to be saved over the last save file. Players can also jump between the game and the desktop whenever they want.

I think the next bit for us (me) to work on would be some detailed designs for the gameplay, so that we (I) can work out all the stuff the engine must support.
  ^[ Log in to reply ]
 
Richard Goodwin Message #70989, posted by rich at 20:30, 24/10/2005, in reply to message #70986
Rich
Dictator for life
Posts: 6827
Which bits didn't you understand btw? I could probably rewrite it to make it clearer.
The bits where my brain isn't set up to handle technical stuff? Which is pretty much all of it.

Please rewrite the entire thread with single syllable words using only concepts I'll understand ;)
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Phil Mellor Message #70991, posted by monkeyson2 at 21:17, 24/10/2005, in reply to message #70989
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
Which bits didn't you understand btw? I could probably rewrite it to make it clearer.
The bits where my brain isn't set up to handle technical stuff? Which is pretty much all of it.

Please rewrite the entire thread with single syllable words using only concepts I'll understand ;)
Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook.
Ook! Ook. Ook. Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook! Ook? Ook? Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook. Ook? Ook! Ook! Ook? Ook! Ook? Ook. Ook. Ook. Ook! Ook.....
  ^[ Log in to reply ]
 
Jeffrey Lee Message #70996, posted by Phlamethrower at 22:02, 24/10/2005, in reply to message #70989
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Please rewrite the entire thread with single syllable words using only concepts I'll understand ;)
*goes off on a tangent trying to devise a program to convert websites to single syllable sentences*

Probably just need some kind of dictionary to map polysyllabolic(?!?) words to monosyllabolic(?!?!) ones. Preferably words which exist, as well :o
  ^[ Log in to reply ]
 
Adrian Lees Message #71009, posted by adrianl at 01:28, 25/10/2005, in reply to message #70996
Member
Posts: 1637
-ol
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71011, posted by Phlamethrower at 01:35, 25/10/2005, in reply to message #71009
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
-ol
Is that all you have to say? :)
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71015, posted by Phlamethrower at 03:02, 25/10/2005, in reply to message #71011
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Random gameplay stuff - Peds

Peds & the player will use exactly the same game code, to ensure simplicity & fairness. The player will be a ped, just with a special flag/whatever to flag him as the player.

Each frame the peds will call their input-getting function - for AI peds this will be some AI code, for player ped(s) this will read the keyboard. The input function will return a set of bitflags representing what keys are pressed; anticipated flags include:

PEDKEY_LEFT
PEDKEY_RIGHT
PEDKEY_FORWARD
PEDKEY_BACK
PEDKEY_RUN
PEDKEY_JUMP
PEDKEY_ATTACK
PEDKEY_ENTER /* Enter car */
PEDKEY_ENTER_THIS /* Enter specific car; the controls bitflag or some other special variable will contain the car ID */
PEDKEY_WEAP_NEXT
PEDKEY_WEAP_PREV
PEDKEY_WEAP_CHOOSE /* Select weapon; another part of the bitflag will contain the weapon ID */

These input flags will then be processed by the ped handling code. Peds can move up slopes up to a certain steepness; this can be calculated just by measuring the height difference between the peds old and new location. Peds can also jump over obstacles such as cars and low walls. Following the trend from GTA 2, it would also be good to have peds able to jump from one rooftop to another if they are on the same level and have no more than 1 block of air inbetween them.

The attack key will obviously cause the ped to attack with its current weapon; weapons are likely to include close combat ones (Fists, chainsaw), handguns, automatic rifles/SMG's, shotguns, grenades, rocket launchers, flamethrowers, lightning guns, etc. Unless anyone has any objections, it would be simplest to have each weapon use a unique ammo source, with a cap of 99 ammo per weapon. Each weapon will use 1 unit of ammo when it fires; if the ammo reaches 0 the weapon will become unavailable; weapons with infinite ammo (fists, chainsaw, etc) can have their ammo set to 100 to signify this. Thus the weapon availability & ammo for a ped can be signified as simple array containing the current ammo count for each weapon. Fairly obviously each weapon will have a different rate of fire, and it's OK for weapons to share/repeat the same sprites in their animations. The ped animation system must support these repeats, without duplicating the sprites in memory etc.

Ped types - it is possible that each ped type could have different weapon firing abilities (e.g. ROF or accuracy), but the main differences are likely to be in appearance, health/speed/etc stats, and the AI code (e.g. making paramedics heal people and madmen go on killing sprees). Anticipated ped types include:

* Normal
* Mutant/zombie
* Corporate police/prison guard/etc.
* Paramedics
* Gangster
* Junkie
* Security robot/android

The PEDKEY_ENTER key will cause a ped to approach and enter the nearest car. This will be used solely by the player ped, so in most cases the ped will chuck out the current driver and take over. AI peds will use PEDKEY_ENTER_THIS, to allow them to enter a specific car and remove the complexity of making sure their desired car is the one closest to them, etc. Some extra flags may also be needed, e.g. to control if the ped should enter as the driver or a passenger.

Car controls, weapons, and other car related rambling

Each car will have a list of seats; each seat can hold 1 ped. The first seat will be the drivers seat, if a ped is here then the car handling code will call the appropriate input function (AI or player) for that ped. This input function will return a similar set of bitflags as the ped one, e.g.:

CARKEY_LEFT
CARKEY_RIGHT
CARKEY_FORWARD
CARKEY_BACK
CARKEY_HANDBRAKE
CARKEY_HORN
CARKEY_SIREN /* Toggle siren */
CARKEY_EXIT
CARKEY_ATTACK
CARKEY_WEAP_NEXT
CARKEY_WEAP_PREV
CARKEY_WEAP_CHOOSE
CARKEY_WEAP_LEFT
CARKEY_WEAP_RIGHT

Keyboard configuration for the player will allow different key sets to be used when inside & outside a vehicle. Car weapons will include things like bombs, machine guns, tank turrets, etc. It may be possible to have multiple weapons per vehicle, hence the selection controls. As with ped weapons, it's anticipated that 99 ammo will be the max per weapon and 100 can be used to flag infinite ammo (e.g. water cannon on a fire engine).

Peds who aren't in the drivers seat will also have an input function called, but all but the CARKEY_EXIT key will be ignored, to allow the ped to leave the car.

Car seating

This is a bit tricky, since multiple doors may lead to the same seat(s) (e.g. both front doors can be used to access the drivers seat), some seats may block access and others may not (e.g. peds can easily get into the back of a van if there are already occupants, but can't use the passenger door to enter the drivers seat if there is already sat in the passenger seat), and some seats may need animated ped movements associated with them (e.g. swapping from one seat to another in an open top car).

The simplest solution may be the following: Each seat has a set of bitflags showing which other doors and seats are available from that position. This will place a limit of 32 doors and seats per vehicle. This should be fine for coaches, buses, and trains (and trains can use multiple carriages). Each door will have a set of coordinates defining its location on the outside of the car, and its orientation. Each seat can have a set of coordinates defining its location also (only required in open top cars). This location will be used to draw the ped seated, and if it slides from one seat to an adjacent one. A search algorithm can be used to find the quickest way to a free seat when a ped needs to get in a car, or the quickest way to a door when a ped needs to leave. This algorithm will take into account the distance to slide between seats (providing they have coordinates), distance to walk around the car to reach the door required, etc.

Car & ped definitions

It's likely that cars and peds will be defined in text files on disc. Some of these definitions will be mandatory (e.g. ones used in missions), others will be automatically loaded and added to the game world in traffic/crowds. Savegames can store car & ped definition file names (or other identifying info), to make sure the right files exist when a game is reloaded. Some information, such as seat positions, could be stored in image form. The game can then scan the image for the right pixels and match them to the seat definitions.

[Edited by Phlamethrower at 02:05, 31/10/2005]
  ^[ Log in to reply ]
 
Richard Goodwin Message #71018, posted by rich at 08:37, 25/10/2005, in reply to message #71015
Rich
Dictator for life
Posts: 6827
99 ammo max? You're 'avin a larf aintcha? That's only three and a third clips for an SMG (e.g. MP5) or automatic rifle (e.g. M16). It's less than two clips for a P90 (SMG)!

Add at least one extra digit. Or make a distinction between hand guns and larger weapons.
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Phil Mellor Message #71020, posted by monkeyson2 at 11:02, 25/10/2005, in reply to message #71018
monkeyson2Please don't let them make me be a monkey butler

Posts: 12380
99 ammo max? You're 'avin a larf aintcha? That's only three and a third clips for an SMG (e.g. MP5) or automatic rifle (e.g. M16). It's less than two clips for a P90 (SMG)!

Add at least one extra digit. Or make a distinction between hand guns and larger weapons.
I'm coming to the conclusion that ammo is a bad idea in a game, especially if the trade-off between strategy and petty collecting is wrong.

Metroid Prime 2 had an interesting take on limited/restricted ammo for the light and dark weapons. You had up to 250 of each; killing things with light gave dark powerups and vice versa. Towards the end of the game you got a weapon that fired light and dark simultaneously (good because you could cause more damage and not worry about weapon type, but used up your ammo stores more quickly).

The best bit was this: if you ran out of ammo, you could still fire that weapon, but had to hold the fire button down to charge it. So instead of bang-bang-bang-bang you had baaaaaaaang.... baaaaaaannng...

Meant that bosses weren't unkillable because you ran out of the wrong type of bullet.

[Edited by monkeyson2 at 11:02, 25/10/2005]
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71023, posted by Phlamethrower at 13:30, 25/10/2005, in reply to message #71018
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
99 ammo max? You're 'avin a larf aintcha? That's only three and a third clips for an SMG (e.g. MP5) or automatic rifle (e.g. M16). It's less than two clips for a P90 (SMG)!
What is this 'clip' of which you speak? ;)

Add at least one extra digit. Or make a distinction between hand guns and larger weapons.
99 ammo seems plenty, considering that most people you'd want to shoot will be armed with a gun, thus allowing you to collect their ammo once you've killed them. For zombies and stuff you can use infinite ammo weapons (chainsaws!). Or just run the buggers over. It's a little thing called strategy ;)
  ^[ Log in to reply ]
 
Richard Goodwin Message #71024, posted by rich at 13:35, 25/10/2005, in reply to message #71023
Rich
Dictator for life
Posts: 6827
Add at least one extra digit. Or make a distinction between hand guns and larger weapons.
99 ammo seems plenty, considering that most people you'd want to shoot will be armed with a gun, thus allowing you to collect their ammo once you've killed them. For zombies and stuff you can use infinite ammo weapons (chainsaws!). Or just run the buggers over. It's a little thing called strategy ;)
Crappy firefight - you get three clips and then you have to wander over to the enemy side to get more! At least in a proper battle you can ask one of your many squad mates for another clip!

The GTA series I've played (admittedly from 3 onwards) I usually like to have around 1000 rounds for any automatic weaponry. Then when a gang comes after you, you can hole up and pick them off without breaking cover. That's strategy.
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71025, posted by Phlamethrower at 13:45, 25/10/2005, in reply to message #71024
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
The GTA series I've played (admittedly from 3 onwards) I usually like to have around 1000 rounds for any automatic weaponry. Then when a gang comes after you, you can hole up and pick them off without breaking cover. That's strategy.
True, I didn't think about a siege situation. Maybe doubling the max ammo to 200 would be an idea, but any more than that might get to be silly. With the ammo cap that high, different guns will probably have different limits. And to keep the simple arcadeyness, there probably won't be any reloading of clips involved.
  ^[ Log in to reply ]
 
Tony Haines Message #71026, posted by Loris at 13:54, 25/10/2005, in reply to message #70844
madbanHa ha, me mine, mwahahahaha
Posts: 1025
Why do you want such a deep map?
So I can have big buildings, mountains, and levels which gradually get higher (or lower) the further you travel from one side to another.
In that case wouldn't a heightmap be useful? OK, so you'd still need stacks if you wanted tall buildings or steep slopes.

Won't it affect (reduce) the playablility?
How could it?
Well if you can be at the same (x,y) but at many different heights, I find it tends to be confusing. And this buggers the gameplay.

I may have misunderstood your description...
Probably around 2 or 3 possible heights max, with the average being close to 1 would be OK. Depending on the circumstances you use the stack in, and your display method, you may be able to have more possible heights I suppose.
Since you have a limited number of stack types (presumably around 256) you probably don't want them to be too complicated anyway.


Since each pedestrian is going to be cached separately, why not stack clothing etc. on them like you have cars? I like your forced mask idea, incidentally.

Regarding ammo, perhaps you could make it really scarce, so that the 99 limit wasn't significant. Like in the film Mad Max 2.
Why 99 anyway? so it can be displayed as 2 digits?
That number always struck me as obviously arbritrary. Why not make it less, particularly for large or heavy rounds? There should be a global weight limit too, really. If so make it a 'soft' one - carry to much and slow down.
If a vehicle had, say, a minigun, you might want to display an estimated firing time remaining, or something.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71027, posted by Phlamethrower at 14:09, 25/10/2005, in reply to message #71025
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
Ped type definitions, sprites and animations

Ped types will (probably) be defined in a series of text files. These files will contain:
* The name of the sprite file for that ped
* Possibly the basic ped stats (starting health & armour, weapon types it can use, etc.)
* Possibly some rules to govern what colour combinations the ped will appear as
* Possibly some other AI rules, e.g. how the ped should react to different things (hearing gunfire, getting attacked, etc.)
* Animation lists

The ped sprites will be unmasked 8bpp sprites, using a custom palette as described above. Sprite names will be of the form <name>_<x>,<y> where <name> is the sprite name and <x> and <y> are the X and Y coordinates of the sprite origin. Only one sprite must exist per <name>; sprites are referenced in the animation lists by this <name> part.

An animation list will start with the name of the animation it describes. Following that will be a series of lines, describing the ped state at each frame of the animation. Each line will contain the sprite name, ped movement delta (i.e. X, Y and Z direction for the ped to move, relative to its current rotation), and one (or more) action flags (probably just the word 'ACTION') to indicate when something should happen. The movement deltas will be used to describe the peds movement speed and direction when walking, movement sideways when entering a car or sliding between seats, etc. Probable uses of the action flag will be to mark the frames at which a punching animation should perform the punch, a firing animation should fire a bullet, etc. All animations will be based on the same frame rate, most probably 25fps. If the game runs at a lower frame rate than this then the skipped frames will be properly processed. Additionally the Z delta will actually be applied to the peds Z velocity, not to its location. This is so that jumping animations will make proper use of gravity. In most cases the deltas will only be applied if the ped is on solid ground.

There are some disadvantages to using the action flags to dictate weapon firing, namely that the animation itself will dictate the firing speed and not the gun. Thus the action flags will probably be reserved for weapons with a firing speed dependent upon the ped, such as fists, the swings of a baseball bat, at which point to throw a grenade in a grenade-throwing animation, etc.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #71028, posted by Phlamethrower at 14:32, 25/10/2005, in reply to message #71026
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15100
In that case wouldn't a heightmap be useful? OK, so you'd still need stacks if you wanted tall buildings or steep slopes.
The base value in the stack2 structure essentially is a heightmap :)

Won't it affect (reduce) the playablility?
How could it?
Well if you can be at the same (x,y) but at many different heights, I find it tends to be confusing. And this buggers the gameplay.

I may have misunderstood your description...
Probably around 2 or 3 possible heights max, with the average being close to 1 would be OK. Depending on the circumstances you use the stack in, and your display method, you may be able to have more possible heights I suppose.
Chances are the rendering code will ignore anything a certain height above the player. That way you should be able to have large multi-layer cities without roads far above the player blocking out your view. Even if I don't make heavy use of levels with different heights, at least the capability is there for me to experiment with it.

Since you have a limited number of stack types (presumably around 256) you probably don't want them to be too complicated anyway.
There will be a practically unlimited number of stack types. The only limit is likely to be how much memory I decide to allocate for the levels. With stacks sharing block definitions it should be possible to have far more stack types than in a typical GTA 1/2 level.

Since each pedestrian is going to be cached separately, why not stack clothing etc. on them like you have cars? I like your forced mask idea, incidentally.
Pedestrians will be quite small, about 16x16 pixels. Cars will be about 32x64. This is the same scale as used in GTA 1/2, and seems to work quite well. With peds being so small, stacking clothes might not result in a significant enough change in appearance, compared to just recolouring the shirts, pants and hair.

Regarding ammo, perhaps you could make it really scarce, so that the 99 limit wasn't significant. Like in the film Mad Max 2.
Some bits probably will have scarce ammo.

Why 99 anyway? so it can be displayed as 2 digits?
Well, it's just a tradition :)

Chances are that there will be different ammo limits for each weapon. Having the ammo you carry affect your movement speed is a bit complex though, I'd rather keep it simple and arcadey.

If it was a fully 3D game then maybe it would make sense to go with a more realistic system with weight limits, estimated ammo counts, etc. In an ideal engine you'd be able to see your enemies approaching from a distance and be able to decide what course of action to take.

However with a 2D-ish game you won't be able to see that far around you, you won't have full control over your aim when firing, etc. Advanced gameplay mechanics would probably become more of a hinderance than an appreciated and worthwhile feature.

I want to keep the game fairly arcadey, so it's simple to get into and learn how to play.

Plus fancy features would be a b***h to balance during play testing ;)

[Edited by Phlamethrower at 14:33, 25/10/2005]
  ^[ Log in to reply ]
 
Richard Goodwin Message #71029, posted by rich at 14:35, 25/10/2005, in reply to message #71025
Rich
Dictator for life
Posts: 6827
A pistol or shotgun could probably max out at 64 - shotguns are much more damaging weapons, and pistols are last resort weapons. Although if you have pistol dual-wield, now, that's a different ball game...

I'd have the cap at 300 to 500 for weapons that spit lots of bullets (M16/M4, dual wield Uzi/Mac10, proper machine guns like M60/MiniMi etc.). Say you need to explode a car in this game (might happen!) - you'd probably want that to take more ammo than killing an NPC.

I'm playing a certain FPS at the moment that limits ammo to around 200 on all the automatic weapons and instead of concentrating on killing the bad guys, the main worry is that you gun will run out before you've cleared the room. You have to constantly switch around mid-firefight, not based on tactics, but on restrictive level design. Pistols have infinite ammo but won't take down a bad guy until well after he's maulled you to death; shotguns hold about 50 shots, but loads of shells around the place - so they seem to want you to take out bad guys way across a large room with a shotgun, which is silly. Rockets and grenades you get so few of that you have to save them for special occassions only.

Of course it's not my game, you do what you want - but I've played a few gun games in my life and I prefer higher caps on ammo. After all, it's not like these games are realistic in the first place! Let the poor bastard carry a few hundredweight of guns and ammo! :E
________
RichGCheers,
Rich.
  ^[ Log in to reply ]
 
Pages (22): 1 > >|

The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server.