|
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 #71030, posted by Phlamethrower at 13:40, 25/10/2005, in reply to message #71029 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
With any luck I'll be able to get some semi-intelligent friendly peds to follow you around and help you out. Like most NPCs in games they'll probably have infinite ammo, so providing they shoot at the right targets you shouldn't need massive amounts of ammo yourself |
|
[ Log in to reply ] |
|
Richard Goodwin |
Message #71031, posted by rich at 13:43, 25/10/2005, in reply to message #71030 |
Dictator for life
Posts: 6828
|
With any luck I'll be able to get some semi-intelligent friendly peds to follow you around and help you out. Like most NPCs in games they'll probably have infinite ammo, so providing they shoot at the right targets you shouldn't need massive amounts of ammo yourself Have you ever played Syndicate? How intelligent were the peds with guns in that? They ammounted to little more than a human shield...
Nope, I loaded my agents with as many miniguns as their robotic little limbs could handle, and got the job done myself. ________ Cheers, Rich.
|
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71032, posted by Phlamethrower at 15:27, 25/10/2005, in reply to message #71031 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Well, yes, but at least it's marginally better than going at it alone |
|
[ Log in to reply ] |
|
Richard Goodwin |
Message #71033, posted by rich at 15:34, 25/10/2005, in reply to message #71032 |
Dictator for life
Posts: 6828
|
Well, yes, but at least it's marginally better than going at it alone They got in my way! That's worse! ________ Cheers, Rich.
|
|
[ Log in to reply ] |
|
James Shaw |
Message #71035, posted by Hertzsprung at 15:42, 25/10/2005, in reply to message #71028 |
Ghost-like
Posts: 1746
|
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.
So will we be able to have flyovers and suchlike then? |
|
[ Log in to reply ] |
|
Tony Haines |
Message #71050, posted by Loris at 18:01, 25/10/2005, in reply to message #71028 |
Ha ha, me mine, mwahahahaha
Posts: 1025
|
I want to keep the game fairly arcadey, so it's simple to get into and learn how to play. In that case you could use lock-on. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71054, posted by Phlamethrower at 18:49, 25/10/2005, in reply to message #71035 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So will we be able to have flyovers and suchlike then? Yes |
|
[ Log in to reply ] |
|
James Shaw |
Message #71072, posted by Hertzsprung at 08:20, 26/10/2005, in reply to message #71054 |
Ghost-like
Posts: 1746
|
So will we be able to have flyovers and suchlike then? Yes How do you represent two different heights at the same (x,y) coords, then? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71101, posted by Phlamethrower at 21:53, 26/10/2005, in reply to message #71072 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So will we be able to have flyovers and suchlike then? Yes How do you represent two different heights at the same (x,y) coords, then? By using (*shock*) Z coordinates!
Each X,Y coordinate contains a pointer to a vertical stack of blocks. These blocks can be solid, filled with air, etc., thus dictating the heights of the different surfaces at that point.
On a related note, I may rewrite the block definition in a day or two so that the top surface of a block is built from two triangles instead of one rectangle. This will allow for more complex slopes, e.g. the 'corners' of hills or where two sloping roof sections meet. There shouldn't be any real performance impact, but I haven't worked out the math for the height-at-point code yet so aren't entirely sure.
*adds BLOCK_WALL_TOP to the definition, just like he added BLOCK_WALL_NORTH and BLOCK_WALL_WEST a couple of days ago* |
|
[ Log in to reply ] |
|
Richard Goodwin |
Message #71153, posted by rich at 16:40, 28/10/2005, in reply to message #71028 |
Dictator for life
Posts: 6828
|
http://www.ugo.com/channels/games/gallery.asp?img=1&gallery=gtalondon_games ________ Cheers, Rich.
|
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71156, posted by Phlamethrower at 17:31, 28/10/2005, in reply to message #71153 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
http://www.ugo.com/channels/games/gallery.asp?img=1&gallery=gtalondon_games That's a single block with a sloping-effect texture on it, not an actual sloping roof
Evil slope-effect texture Lots of fancy slopes in GTA2, including walls at a 45 degree angle Car deltas, with and without the base sprite. Red is forced transparency.
[Edited by Phlamethrower at 18:35, 28/10/2005] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71253, posted by Phlamethrower at 02:04, 31/10/2005, in reply to message #71156 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Guess I'd better do some more stuff about this...
Also a while ago I realised that the 99 ammo limit in GTA 1/2 isn't always 99 ammo. Automatic weapons like machine guns appear to have about 10 rounds of ammo per 1 unit displayed on screen.
Game names
While bored one day I came up with a suitably OTT name for the game: Death Dawn. This would then lead onto several sequels, including Death Day, Death Dusk, Death Dark, and finaly Death Days.
Basic vehicle stuff
Each vehicle is likely to contain the following state data: * A reference to the vehicle type * X, Y, Z location & rotation (Just 1 rotation variable) * X, Y, Z velocity & rotation velocity * Colour data * Sprite flags (Damage sprites, door animations, etc) * Vehicle damage * Gearbox info (e.g. current gear & engine revs) * Seat/passenger states * Weapon data (e.g. ammo counts) * Turret data (Tank turret, mounted guns, helicopter blades. Probably just a rotation angle needed for this) * Fire strength, for if the vehicle is on fire * Other misc stuff like sound states, whether the car alarm is set/going off, fireproof/bulletproof/etc. flags, etc.
Each car type would have the following data: * Vehicle class - car, boat, bike, etc. * The base set of sprites & palette * Vehicle dimensions * Engine data, tyre grip, etc. * Seat & door data * Sound names * etc.
Collision detection - cars
Micron Machines uses a fairly simple collision detection. For each frame we can calculate where the 4 corners of a vehicle are. A simple bounding box check (formed from the min & max coordinates of the corners) is the first stage of the collision detection. If the vehicles are possibly colliding then it moves onto the more complex bounding box checking: Each corner of each car is compared with each side of the other car. A side-of-line function is used to perform this check, if (at least) one corner of one car is inside the 4 sides of the other car then the cars have collided. Of course this does mean that two cars at the same location but one rotated 90 degrees won't be detected as intersecting, but that occurence is quite rare.
Collision detection - peds
Peds are likely to be represented as either a small box or a circle. In either case the same technique as above can be used; for a circle you can calculate the distance the center is away from each side of the car, and work out of it intersects from that data.
Collision detection - the world
Micron Machines uses the same kind of algorithm for this as it does with car collisions. For this game a similar technique can be used.
Using the min-max corner bounding box of the car, a list of blocks can be made which the car intersects. These blocks can then be checked to see which are solid, and the side-of-line routine used to check for collisions.
However the code is complicated somewhat by the BLOCK_WALL_ flags; collision detection for those flags is likely to be performed during the car movement code. The sloping ground/ceiling of some blocks may also cause problems.
Edit: When checking which blocks the car has collided with, it's probably going to be a good idea to build a set of bitflags to flag whether there has been a collision on the north/south/east/west/top/bottom sides. This way a collision with two walls to the north of the car will be properly handled as a collision with one wall to the north.
Cars on slopes without supporting the rotation to allow it to sit on the slope or something like that
This will be a tricky one. One solution could be that when a car is on a slope, its Z value is that of the highest point under the car. The car will also have an 'on ground' flag set, so that any car underneath it (e.g. if two cars on a slope try to drive up/down into each other) will know that the car extends down onto the area of slope directly beneath it.
It could also be possible to replace this Z value with minimum & maximum bounds, which are retained from frame to frame instead of a single Z value. The car could also 'bend' to fit the slope, so that the lower end of a car on a steep slope does not extend up to the same height as the end of the car at the top of the slope.
[Edited by Phlamethrower at 23:22, 31/10/2005] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71275, posted by Phlamethrower at 16:42, 31/10/2005, in reply to message #71253 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I drew some diagrams to illustrate stuff.
Blocks & stuff Block stacks & content type inheritance Cars on slopes, it's a bitch |
|
[ Log in to reply ] |
|
James Shaw |
Message #71277, posted by Hertzsprung at 17:41, 31/10/2005, in reply to message #71275 |
Ghost-like
Posts: 1746
|
*dodgy physics alert* |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71316, posted by Phlamethrower at 23:55, 31/10/2005, in reply to message #71277 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
More collision detection hell
After thinking about it for a while, I think the best way of handling cars on slopes is for the car to be modelled as a simple box which can rotated around the Z axis. If this box is dropped onto a slope then it will stop falling as soon as it hits the slope, as in method 1 on the diagrams above. Then when performing collision checks against cars, a larger collision box will be used (e.g. about half a unit deeper [*]). For 90% of slopes this will have the same effect as seen in method 2, where the collision box extends to the ground. However it will also solve the problem of cars driving off of cliffs, because it places a hard limit on how deep the collision box can become when compared to the true location of the car.
While the car is in the air the extended collision box will still be used. This does have the side effect that cars which try to jump over each other may collide when they shouldn't, but this shouldn't have an adverse effect on most gameplay.
A workaround for that problem is also possible in some situations - a check could be performed to see if there is any solid ground in the extended collision box. If the ground is there then the extended box will be used against other cars, but if there is no ground then the small box will be used. This small box will be retained until the car reaches the ground. The extended collision box is meant to model how a car tilts to lie on a slope, thus it makes sense that the large box is only needed if the car is ontop of (or has just left) a slope. Once it's flown through the air for a while (i.e. the large box no longer intersects the ground) the car may have levelled off, hence the switch back to the small box.
[*] - Actually it only needs to be as deep as the diameter of the car, since the steepest slope possible is a 1:1 incline.
[Edited by Phlamethrower at 13:39, 1/11/2005] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71341, posted by Phlamethrower at 14:26, 1/11/2005, in reply to message #71316 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
How to kill a car
In GTA 1, the performance of a car would decrease as it gets more and more damaged. This would coincide with a change in the engine sound. Eventually if the car got too damaged it would blow up.
In GTA 2, I *think* the performance stayed about the same. Instead smoke and fire was introduced (or at least fire was, not so certain about smoke). After receiving enough damage a small fire would start on the car. A few minutes later the fire would grow, and shortly after that the car would explode.
In GTA 3+, the performance of a damaged car would remain unchanged (Except for burst tyres). Smoke and fire is used to indicate the condition of the car. However rather annoyingly cars explode only 10-15 seconds after catching fire, which combined with the crap "exit car" conditions usually results in you getting blown up.
What I'm thinking that we (I) should do for this game is to have the cars behave more like they did in GTA 2. Once on fire a car will burn for a few minutes, giving you plenty of time to escape before it explodes, instead of leaving you to die by a stupid game mechanic (The rules which govern how you can exit vehicles). Generally speaking, enemies in GTA 3+ only use projectile weapons, wheras in GTA 2 they are fond of grenades, flamethrowers and rocket launchers. These can make them much tougher to take down, thus balancing out the fact that cars are more durable.
I'm also thinking that there should be other methods of disabling vehicles, beyond them getting blown up. Being able to pop tyres will be a bit too detailed for a top down game, so that's out of the question. However engine wear and damaged radiators are quite possible. I envisage the cars as having the following attributes:
* The remaining armour level of the car * The remaining engine health of the car * The strength of the car fire (0 for none) * The engine temperature
Driving the car too fast for too long will raise the engine temperature. Once it reaches a certain point steam will start coming from the radiator, and the engine will take damage, decreasing its performance.
Shooting the car or crashing it into objects will decrease the armour level. Once the armour reaches 0 the engine will start to take damage; once the engine receives enough impact damage (gunfire, crashes, etc) there is a chance that it will catch fire.
The fire attribute will be used to model car/engine fires. Torching a car will start a fire, as will shooting a damaged engine. If the fire is small it will be classed as an exterior fire, and only damage the car's armour. Over time the fire will grow, until it gets classed as a large fire - at which point it will damage both the engine and the armour. If the armour level is at 0 then the armour fire damage will not seep through to the engine; the fire will just be cosmetic, burning on the remains of the chassis.
Once the engine health reaches a certain level the engine will stop functioning all together. Once the engine health reaches 0 the car will explode, killing the occupants. Due to the formulas involved, this is only likely to happen through impact damage or fire, as opposed to through overheating. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71396, posted by Phlamethrower at 16:10, 2/11/2005, in reply to message #71341 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Did someone say collision detection?
Here we go again, this time tackling the BLOCK_WALL_ flags.
Point-based collision detection
This requires to points, unimaginatively called point 1 and point 2. The line between these points maps the path of the object between two successive game frames. If you're checking for a collision against a north or west wall, then the procedure is as follows:
1. Check that the two points lie on different sides of the wall. This requires simple X (or Y) coordinate comparisons. 2. Calculate the point on the line between p1 and p2 where the line hits the wall. This can be done using some very tasty code in WOUM, the vec16_movetox and vec16_movetoy functions. These functions take two points p1 and p2, and returns a 3rd, which will be somewhere on the line between p1 and p2 and have the given X (or Y) value. 3. Using that point, make sure that you are within the boundaries of the block with the wall. 4. Calculate the height of the ground at the X,Y position and make sure that the point is at or below ground height.
E.g. for a block with BLOCK_WALL_NORTH flag at location (2,4,1) you'd want to: 1. Make sure p1 and p2 are on either side of the Y=4 line 2. Calculate a point p3 between p1 and p2 where p3.y = 4 3. Make sure 2 <= p3.x < 3 and 1 <= p3.z 4. Use the to-be-written height of ground function to get the height of the ground at (p3.x,p3.y) in block (2,4,1). Then make sure p3.z is less than or equal to this value.
If all those checks succeed then the point has passed through the solid wall on the north side of the block.
For checking against the top side of the block (blocks with BLOCK_WALL_TOP set), the checks would be:
1. Make sure that at least one of p1 & p2 lie within the X, Y cross-section of the target block stack. If neither of them lie in that area then you can just assume that the point has missed the block (Although sometimes it may not have, so it might be best to avoid that advice) 2. If p1 is outside the X,Y boundaries, use the vec16_movetox and vec16_movetoy functions to find a point between p1 and p2 which is just inside the boundary. The same applies if p2 is outside the X,Y boundaries. 3. You should now have two points inside the X,Y boundaries of that blockstack. Now you can calculate the ground heights at p1 and p2. If one point is above ground and the other is below ground, then the point has clearly passed through the ground during its motion.
A possibly better alternative to the above would be to work out the plane equation of the block top, and use the side-of-plane equation to check if the line between p1 and p2 passes through the plane. If it does pass through then you can use a line-plane intersection function to calculate the exact point it intersects, and then check this against the X,Y boundaries of the block to see if it did infact hit it.
Point based collision like this can be used for small objects such as bullets, scenery items like traffic cones, etc. It could also be used for the player. However the player is larger than 1 pixel so multiple checks would be required (e.g. checking the new and old locations of each corner in turn. This will be a simple unrotated box shape).
Polygonal collision detection
For cars, a more complex method will be required, since their collision box can rotate. (Rotating boxes with ped-style checking could allow, for example, a car to slide some distance sideways into a sticking-out corner before the collision detection notices it). Cars can be modeled as a 3D box, whereas peds only need to be 2D. A simple solution to the car problem would be to translate each BLOCK_WALL_ segment into a polygon. This polygon can then be counter-rotated to lie in the same coordinate system as the car. Simple polygon clipping functions can then be used to clip the polygon against the unrotated car collision box. Any part of the polygon left inside the car will then indicate that a collision has occured.
Cars on slopes, it's still a b***h
How can we make the game detect when a car drives up or down a slope, and have it react appropriately? (i.e. not make the car bounce off like if it had hit a wall). I think it's time you lot came up with an answer for this one
I'm sure there was something else I was going to say about collision detection, but I can't remember what
[Edited by Phlamethrower at 16:11, 2/11/2005] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71500, posted by Phlamethrower at 03:24, 4/11/2005, in reply to message #71396 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Cars on slopes, it's still a b***h
How can we make the game detect when a car drives up or down a slope, and have it react appropriately? (i.e. not make the car bounce off like if it had hit a wall). I think it's time you lot came up with an answer for this one Looks like I'll have to give you a hint
If a car is on the ground, then the movement code needs to make a map of the blocks which the car can move onto. The map will initially contain only the block(s) which the car is in direct contact with. Then by looking at the edges of these blocks it can be worked out if the car can drive onto the neighbouring blocks (The edge of the neighbour must be at a height below or equal to the height of the edge of the current block, no walls between them, etc). If a neighbour can be driven onto then it will be added to the map. Once the map contains enough data for the volume of space the car will be moving through, the map generation will stop.
Once the map has been built, the car will be moved across it in 2D. The Z velocity of the car will be ignored completely. Once the final X and Y coordinates have been calculated, the height of the map at that point can be read and used to give the car its Z coordinate back. This allows it to drive up and down hills. (Actualy it will be the heighest point under the car that we want, not just the height of the point under the car's origin)
However, it will also cause the car to jump straight to the bottom of cliffs. One simple solution to this would be to subdivide the movement delta that is being applied to the car, until it is less than 1 unit (block) in length. This small delta can be applied repeatedly, and the floor height calculated at each step. If the floor suddenly drops then the car will be given the previous floor value for its Z coordinate, thus placing it in the air just beyond the edge of the cliff. The Z velocity of the car can be adjusted also, by comparing the new Z value of the car with its Z value at the start of the frame (This may be a bit inaccurate though).
Subdividing the movement delta can also be beneficial to map generation (Movement maps will have a maximum size, probably 4x4), and will simplify the collision detection, allowing the Micron Machines car-wall collision detection to be used. This collision will replace the block content and BLOCK_WALL_ collision detection, using the movement map instead (The movement map will have already performed those checks before deciding if any blocks at a particular 2D coord are reachable).
This algorithm still needs some refining, in particular one problem I can think of is that it won't cope properly with bridges where the car can theoretically end up on of or under the bridge. Making the map generation recursive may solve this (allowing a map entry to be replaced with a new one if the new one is a block that is higher up), but care will be needed to correctly handle walls ontop of bridges. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71506, posted by Phlamethrower at 11:58, 4/11/2005, in reply to message #71500 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
If you've taken the time to understand the above post, then it's now time to forget it all, because I have a much better algorithm
First, some notes about subdividing the movement delta. Unless the car is travelling very fast (i.e. >25 blocks/sec on a machine that runs the game at 25fps) this subdivision won't be needed. This new algorithm relies on the subdivision as well, just to add an extra bit of accuracy when you're cruising along at breakneck speeds.
The new algorithm is fairly simple. It adds the X and Y deltas to the origin of the car, as well as the rotation delta. It then calculates which blockstacks the 2D shape of the car intersects. In each of these blockstacks it then calculates the intervals of air which the corresponding segment of the car can fit into. These intervals can then be merged into one list, giving a range of possible locations to check if the car can reach.
Starting from the highest interval, the block(s) that the car would touch will be checked to see if they are reachable, using a similar algorithm to the movement map generator. Once an interval is found with reachable blocks at its base, the Z value of the car can be set. If no reachable interval is found then the path must be blocked. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71633, posted by Phlamethrower at 01:28, 7/11/2005, in reply to message #71506 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I seem to be out of immediate problems to solve. Maybe I should have a think about the mission system/what type of missions there will be. |
|
[ Log in to reply ] |
|
John Hoare |
Message #71696, posted by moss at 20:16, 8/11/2005, in reply to message #71633 |
Posts: 9348
|
... |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71697, posted by Phlamethrower at 21:01, 8/11/2005, in reply to message #71696 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
... When??? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71888, posted by Phlamethrower at 22:00, 15/11/2005, in reply to message #71697 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The mission system
OK, how's this for the mission system.
Missions will be written using a custom scripting language. This has several advantages over writing them directly into the game source code, mainly:
1. No need to recompile the game as missions are written 2. The mission system will be fairly impervious to changes in game engine design 3. The mission system will work transparently with saved games 4. People can write their own missions for the game without requiring access to the source code
To a certain extent it will also be possible to modify missions without breaking existing save games.
"How is this possible?" I hear you ask. I think it would be easiest if we aim for an event based script system, much like the one Quake uses. A list of events & trigger conditions will be maintained; when a trigger condition is met, the appropriate event handling function(s) in the mission script will be executed. This means that there is only one thread of execution active at once (cooperative multithreading, essentially), and there are no thread states to maintain between game frames (making save games tolerant to mission script changes, because the event & trigger list will only contain the names of script functions). The simplest event will be the passage of time; more complex ones (e.g. the player entering a certain map area, a ped getting killed, etc) are also possible.
Script format
Assuming that we aren't going with an existing scripting language (TCL? I should probably remind myself how simple/complex it is), I propose something similar to the following:
* Variables will be typed. The variable type will be denoted by the first character of its name; e.g. i for int, f for float (possibly fixed point), p for ped ID, c for car ID, . for a code label, etc. * Execution will always start at a labelled section of code; it is impossible to jump to an arbitrary point in a routine * Execution will flow through from the end of one routine to the start of another. Essentially like in assembler programming, but without a directly modifiable program counter.
The basic format of a line will be:
[.label] <command> [arguments...] [; comment]
Where [.label] is the (optional) label for referencing the location of the instruction. <command> is the command to perform, [arguments...] the optional list of comma-seperated arguments, and [; comment] an optional comment string.
There'll probably also be support for the infix '=' operator for assigning variables to values.
Here's a quick script for a simple mission. For readability only the variables have been shown in lowercase; the rest is commands or arguments.
.mission1 SPAWN p1 OFFSCREEN ; Spawn a ped somewhere offscreen SETAI p1 RUNAWAY ; Give him the AI action of running away from the player (pplayer) SETTARG p1 pplayer ADDRADAR p1 ; Add a radar icon showing the location of p1 MESSAGE TITLE "Mission 1: Kill the ped!" ; Display a bit of informative text to the player MESSAGE INFO "That ped is running away. Go kill him!" ONDEATH p1 .mission1_part2 ; When p1 dies, run another part of the script STOP ; Stop execution for now
.mission1_part2 REMOVE p1 ; Flag p1's corpse for removal when it leaves the player's view. Will also remove him from radar etc. MESSAGE TITLE "Mission complete!" icash = icash + 10000 ; Reward player with money & increase count of missions completed imissionscomplete = imissionscomplete + 1 STOP
Obviously, some improvements are possible. E.g. SETAI and SETTARG could be replaced with p1.ai and p1.targ, as if the script had direct access to the ped data structure. This would also be a lot simpler when it comes to reading data about a ped.
Other things to note:
* Variable scoping (i.e. global & local variables) will be supported by the PUSH and POP commands. By default all variables are global; PUSH will push the current values of a list of variables onto a stack, POP will restore the last list of variables pushed. Also STOP will POP all variables from the stack. * Subroutines will also be supported, via GOSUB and RETURN. * When the mission script is loaded, it can be parsed and tokenised. A full list of variables & their types can be generated. The tokenised version of the script will most likely refer to these varaibles by internal ID numbers, but the real name must also be derivable in order for it to be written out to the save game file. * Mission state can be saved by writing the names and contents of all variables to disc, along with the current list(s) of events & triggers. There will be some conseccions, e.g. values of code labels will not be stored, as they will be rebuilt from the mission script when it is reloaded (to allow missions to be modified without breaking existing savegames). There may also be a special .onload label which is executed whenever a script loads, which can be used to override any current values of variables (e.g. to set the total number of missions).
There's probably some extra stuff I need to talk about here, BUT I'M SURE YOU CAN WORK IT OUT FOR YOURSELVES. |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71934, posted by Phlamethrower at 14:50, 17/11/2005, in reply to message #71888 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So... any other major things that people can think of? (Apart from the map generator, but that will require a working engine to test it with. And we (I) can always go to a manual map editor if random maps suck.)
Should we (I) start work on the storyline, mission descriptions, etc? |
|
[ Log in to reply ] |
|
James Shaw |
Message #71938, posted by Hertzsprung at 19:08, 17/11/2005, in reply to message #71934 |
Ghost-like
Posts: 1746
|
network play? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71939, posted by Phlamethrower at 20:36, 17/11/2005, in reply to message #71938 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
network play? Good question
Network play in GTA 1 (and 2?) was notoriously laggy and unreliable, and I'm not too sure what system they used. Liberty City Stories does have network play, but I have no idea how reliable it is. I suspect you're only able to play over the PSP's wireless connection, so they will have been able to design the game around known connection characteristics.
For this game though, the simplest way of doing it would be a strict client-server system. The server manages spawning & AI for peds and cars, then sends updates to the clients for those which are visible. Clients would be able to manage ped animations and do some ped/car movement prediction, but all the other decision making would likely be done by the server.
A more complex system would be a peer-to-peer arrangement. In GAT 1 and 2, around each player there is a pyramid shape giving the camera's field of vision. A larger pyramid then sits around that, giving the area in which peds and traffic will be spawned.
In a networked environement it would be possible for each client to individually manage the peds & cars within that area of influence. No communication would be required with the other clients, unless one of the peds/cars enters the area of influence around another player. If that happens then control of that entity can be handed to the other client.
If two players move towards each other and the areas intersect, one machine can claim superiority over the other and take control of all the peds & traffic in that area. It could even take control over that player, essentially making it a mini-server. Once the players move further apart the data can be split up again.
This system will probably reduce network traffic (and therefore lag) in all situations. If players are far apart there will be no lag because each computer will be managing its own player; as they move closer together the network traffic will be no greater than if there was a rigid client-server system. The only problem is that when two players meet one of them will have the advantage, because he will be playing on the server machine.
A solution to this problem could be for the server machine to be chosen at random each time the players meet.
Another might be for the server machine in each player cluster to change each game frame in a round-robin fashion.
And finally, some extra care will have to be taken to ensure the same ped ID/car ID/whatever isn't used for different objects at the same time. The simplest way to do this would be to give each client its own unique pool of ID numbers it can use when making a new object. E.g. ID numbers will be two bytes composed of the one-byte client ID and one-byte object ID.
Of course this is all assuming that the game will support multiplayer, which it probably won't (Unless someone with more network programming experience than me and a couple of networked RISC OS machines appears and volunteers to do some coding & testing)
[Edited by Phlamethrower at 20:42, 17/11/2005] |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71940, posted by Phlamethrower at 20:43, 17/11/2005, in reply to message #71938 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
network play? Surely you could have worked that out for yourself, or is this some kind of test? |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71952, posted by Phlamethrower at 03:31, 19/11/2005, in reply to message #71940 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Tomorrow (today) I'll write out as much as possible of the engine in pseudocode. This should provide a good reference for when the real coding is done, and help reveal any bits of the design which still need work doing. |
|
[ Log in to reply ] |
|
James Shaw |
Message #71953, posted by Hertzsprung at 10:06, 19/11/2005, in reply to message #71940 |
Ghost-like
Posts: 1746
|
network play? Surely you could have worked that out for yourself, or is this some kind of test? Actually, a 'yes' or 'no' would have sufficed |
|
[ Log in to reply ] |
|
Jeffrey Lee |
Message #71957, posted by Phlamethrower at 20:30, 19/11/2005, in reply to message #71953 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
network play? Surely you could have worked that out for yourself, or is this some kind of test? Actually, a 'yes' or 'no' would have sufficed You could have said
The beginning
main() { loadconfig(); initialisewimp(); runwimp(); }
loadconfig() { // Load user config file - control options, screen mode, etc. // Load game config file - contains lots of random bits of info like the size of the megamap, // what mission scripts to use for each area, etc. }
initialisewimp() { // Initialise the wimp interface, using LimpX // - load templates & wimp sprites // - create iconbar icon, proginfo window, saveas window, etc. // - create iconbar menu // - attach LimpX event handlers }
runwimp() { // Run the LimpX Poll function until it's time to quit // For this I usually use the LimpX abort flag, which will get set when the user chooses the quit // option from the main menu, the program receives a shutdown event, etc. // The abort flag will then cause it to break out of the poll loop and return from the runwimp function }
Event handlers
menu_item_selected(item) { switch (item) { case MENU_ITEM_QUIT: if (gamenotsaved) { if (confirm("Quit without saving?")) LimpX_SetAbortFlag(); } else LimpX_SetAbortFlag(); return; case MENU_ITEM_VIDEO: open_video_options(); return; case MENU_ITEM_SOUND: open_sound_options(); return; case MENU_ITEM_CONTROLS: open_control_options(); return; } }
...etc.
MORE LATER.
[Edited by Phlamethrower at 01:52, 20/11/2005] |
|
[ Log in to reply ] |
|
Pages (22): |< <
2
> >|
|
The Icon Bar: The Playpen: Slightly cold news on page 10! Phlamey breaks the server. |
|
|
|