[Updated 13/9] Making an off-road racing game

User Code & Projects
1

Video capture 2012-09-10



Part 1

http://www.youtube.com/watch?v=rnkgP3hutXQ



Part 2

http://www.youtube.com/watch?v=NgJUw4T_XIc



Part 3

http://www.youtube.com/watch?v=Lr5Si6w2C1s



Part 4

http://www.youtube.com/watch?v=qQMV_w4yLkw

4 Likes
2

As long as you don’t have a problem don’t fix it :slight_smile: just curious if it was only me or if it happens to others also. Yeah, CCD does nothing for raycast vehicle (seems like it ignores the body collision shape) I tried different masses for the vehicle, did not make a difference either, neither did switching to native bullet. Guess it’s just one of those quirks the vehicle control has. I got the feeling there was something weird with the ray test and if a wheel fell below ground either the solution got stuck or the whole shebang tunneled.



I even tried attaching a rigidbody box beneath the vehicle body from stopping it falling through, very strange results :smiley:

3

Hey, @androlo,



I myself DID spend some time to make a game to test JME3 physics. My game is also focus in generated world terrain, city with road,building… I’m planning to make It more mature so for now no opensource yet!



I know you want to make something cool, here i have some idea to share:

4

@atomix

This is also just a regular game, no open source or anything.

5

but will it be free to play? 8)


Thinking about adding roads to the map, eventually. The river system has functions for creating catmul-rom splines from a set of points, splatting textures onto terrain along that curve, and also modify heights (including flattening). This could be used to either generate a road along the track, or to generate roads randomly across the terrain that one can choose to use or not use, depending on waypoint locations. There are some complications when working with tiled terrains tho, but it’s worth fixing. I think this would be fun. The roads would work in two ways – the flattening makes the car a lot easier to handle, and by giving the road high friction that helps with the driving too.


splendid idea imo.

it could save a lot of time making maps. (if you plan to make many)
6

Videos with some explanations and stuff.



Part 1

http://www.youtube.com/watch?v=rnkgP3hutXQ



Part 2

http://www.youtube.com/watch?v=NgJUw4T_XIc



Part 3

http://www.youtube.com/watch?v=Lr5Si6w2C1s

1 Like
7

What a great idea, it must be, because I’m slowly hacking away at a similar thing. Well, at least vehicles and procedural terrain is the same basic setup. There is something really alluring about procedural terrain, you just want to drive around in it :slight_smile:

Anyway, did you run into tunneling problems with the vehicle falling through the terrain? I ran into some of them when using the vehicle control. I guess I might have set my objects going to fast but it was (I think) way below what should cause problems. The vehicle tunneled much earlier than ordinary boxes did when I simply dropped them from a height.

Maybe you aren’t using a heightmap (don’t remember what you ended up with for BioMonkey) and that is a difference?



http://hub.jmonkeyengine.org/groups/physics/forum/topic/jme3-beta1-vehicle-tunneling-through-terrain-what-to-try-next/

8

It’s heightmap. Falling through has happened once or twice, I think at like 250+ km/h, which I guess is logical and can be fixed by increasing physics updates per sec or ccd motion threshold or something. Haven’t checked tho, as this isn’t really a problem for me.



Weird that boxes works better tho… I’m using a very accurate vehicle simulation, which probaby helps. I guess using weird values for suspension etc., may cause problems.



EDIT: Maybe it’s the suspension force? I think there’s a note in the setMaxSuspensionForce (or whatever it’s called) that if the vehicle is too heavy, that value has to be increased.

9

Here’s another biomonkey environment btw. This is the kind of maps you need a great car and special equipment to be able to handle. Gonna make a set of “epic” extremely hostile environments like these, where the highest level items can be found. Wanna put more stuff in there as well, lava lakes, rocks falling from mountains etc. Chasms.



http://jamtlandoutdoors.se/images/dist2/epic_hard.png

10

New vid, guns added.



http://www.youtube.com/watch?v=qQMV_w4yLkw

11
@androlo said:
New vid, guns added.


this is starting to shape up pretty well. i like the forces from the gun, it gives a very realistic effect.
12

Yeah it’s an important part. Physics affects how the game is played, that is one of the cornerstones. If I wanna use a heavy weapon, I’ll have to use a heavy vehicle, otherwise it’ll not be able to handle the forces. The vehicle should become heavier through better protection (armor plates), because weight makes it loose engine power. It is harder to hit a moving target, and the faster it moves the harder it is. This means a slow, heavy vehicle will be hit more.



I think there will be two main type of vehicles. At least under the basic system (as it’s looking now). One will be a slow, heavy vehicle with powerful weapons and strong protection. It’ll focus on over-powering enemies. The other will be a light, much more agile vehicle that focuses on out-maneuvering enemies instead. Logically this would mean that powerful vehicles should focus more on the weapons/armor part, while the faster vehicle should focus more on tweaking the car (engine, gears etc.).



There will definitely be classes, and maybe sub-classes as well, but I don’t know exactly what they’ll be, because it depends on what weapons & tech is added, and what is practical. Classes will be designed around “need”, not templates. I’m not even sure how these two main classes will turn out.



Gonna add some more videos in a while, showing the basic combat system (added turrets and targeting system now) and talk about weapons/ballistics.

13

I wouldn’t even design classes. Just provide tools and let players sandbox whatever vehicles they want from those tools… then provide some “starting templates” to give newbies a place to get started.

14

@zarch

I agree, there should not be specific classes. Instead different equipment and abilities etc.



To everyone:



I got a great, clean system now for mobs and items and inventory etc. It’s based on the coffeemud system, but is using something similar to the jME system of controls, and also changed some of the old crappy stuff.



Btw. I write long posts like this for myself as much as anyone else (get to get a more clear picture of stuff, ideas etc). Don’t really expect people to read.



Objects



There are two main type of objects in the game - world objects and item objects. Generally speaking, mobs, items etc. - all kind of game objects - are simple data classes. A mob for example, which is a world object, has got:


  • 1 id.
  • 1 CharData object (name, stats, abilities etc.).
  • 1 PhysicalAgent object (different classes depends on whether its a rigidbody or w/e). It contains the model and some other stuff.
  • 1 Inventory object (keeps track of the items it carries).


  • 1 Controller object.



    Controllers



    A controller has a set of control-units. Control-units aren’t grouped according to what they’re used for, but whether or not they require an update. There are control units for example that works through listeners, and those that just alter some data when added, and changes it back when removed.



    A few common control-units are the targeting-unit and inventory control units.



    Inventories



    The inventory is a data object and has its own control-units. An inventory slot can’t be accessed from the inventory itself, only through a control-unit.



    Items are similar to mobs and other world objects in that they contain some data and have an id, but they have no controllers. Instead they have a list of control-units, and those are only updated when attached to a “parent world object”. Technically this happens when they are put in an equipment slot of a world object. The parent can be a mob, but also other things like a block of the world itself.



    The way this works in practice is - when an inventory control-unit adds an item to an inventory, it automatically takes the item control-units and adds them to the controller of the object - provided the inventory slot is an equipment slot (it doesnt happen if the slot is just for storage, like a bag). The inventory controllers sort this out themselves.



    Turret example



    Lets say I have a turret, and the turret has an inventory containing one slot which is used for a cannon (which is a weapon, which is in turn an item).



    The turret has a PhysicalAgent object that contains its 3d model, methods for setting its position, and other things. It may be of a few different types depending on if its a vehicle, a rigidbody, just a model etc., but the interface is the same.



    The CharData object contains its name (“ConcreteTurret”), health/resistances, some other stuff, and a list of actions - backed by abilities. One of the turrets actions is to fire a cannon.



    The controller has a few different control units. Those are:
  • An inventory control unit.
  • A targeting unit.
  • An AI unit that makes it scan the surrounding area for enemies.
  • An AI unit that makes it fire at targeted enemies.



    The cannon



    The cannon has some data, a model etc., and a set of control units.



    One control-unit is a subclass of WeaponsControlUnit, which makes it possible to fire the cannon (among other things). Firing the cannon is done as part of making an attack, which is an action. More on that later.



    One control-unit is used to point the cannons 3d-model towards any target that the parent object may have. When added to the parent controller, this control-unit sweeps the controller for a targeting-unit, and sets itself up as a targeting-unit listener in case there is one. Otherwise it’s simply not added.



    It also has a third control-unit which adds/removes the cannon to/from the mob-model. The model of the parent mob has got a node named “GunNode” - that is part of the “contract” of having an inventory slot for cannons. The mobs model is accessed through its physical agent (all control units keeps a reference to the controller, which keeps a reference to its parent object. This control-unit works automatically when the cannon is added/removed from the slot. With AI mobs this normally happens only when they are created/destroyed.



    After being added, provided everything went well, the cannon is “primed” - meaning it’s in sync with the mobs target manager, its model has been added to the model of the mob, and the cannon is ready to be used.



    Firing the cannon



    When mobs attack eachother, they do so by performing an action. The attack action is just one out of many actions. A player (or player mob, rather) would do it by pressing a key perhaps, and an AI mob does it through an AI control unit. To attack something they need to target it first, which is done through the targeting-unit. Again, the player would find targets through a keypress or something, and an AI mob through an AI control unit.The cannon itself can be used by any player or mob, as long as they have the proper abilitys, model setup and inventory slot.



    When the attack action is performed, it is handled through the combat system. It starts by checking that the attacker is in a state allowing it to attack (not dead, for example), that the target is valid (also not dead, for example), and stuff like that. It then fires of an attack-event and passes it to the combat event handler. The attack event is an object containing a bunch of references needed by the combat system - for example who the attacker is (a link to the mob object), who the target(s) is/are and what weapon is being used. Actually its a reference to the weapons control unit, seeing how the weapon itself is just a clump of data.



    Attack events are controlled by a very simple finite state machine, and has an initial stage, a perform state, a resolve state, and a cleanup state. Most often the perform and resolves states are the only one used. When it enters the perform state, some data is calculated (chance to hit depending on movement speed and other stuff), and the weapon control unit is used to fire the cannon.



    Firing the cannon applies an impulse to the shooter, if it’s a valid physics object (like a player vehicle). It also creates an effect. In this case it’s just a flash of light at the muzzle and a shooting sound. The first time this happens a new event is created. In this event, the emitter and sound is created and set up. The firing event is then sent to the event manager. What happens there is the event manager calls its execute() method, which attaches the emitter and a sound to the “BarrelEnd” node of the cannon model. All cannons has that node. Part of the execute() method is also to call emitter.emitAllParticles().



    Next, the event manager updates the event each frame until it’s flagged as done. The time for this particular event is 1 second. When the event is flagged as “done”, the event manager has the event removed from its list, and calls the events cleanup() method. The cleanup is just a call to emitter.killAllParticles() in this case, and removing the emitter and sound from the cannon. This is the normal flow of a general event - execute(), update … done, cleanup(), although in some cases (like this), its good to just repeat the event instead of creating a new one each time the cannon is fired (including creating an emitter), so there’s also a reset() method that events may use - in this case just set the time to 0 and set done = false, making it ready for another go, and another etc.



    Anyways, when this has happened (provided it actually did happen and wasn’t canceled for some reason), the next step of the attack action is to resolve it. Bullets has no physical objects attached to them atm. (like a sprite or something), which means this particular type of attack will just wait for 0.5 seconds or so, then resolve. A rocket attack for example would create a rocket if successfully performed, then the attack would just wait for the rocket to hit the target before going on to the resolve state. The resolve is handled by the combat manager and does the damage calculations etc, uses the hit values and stuff that was calculated at the perform stage to determine if the attack hits or misses. Stuff like that. If the attack hits, there’s a particle effect on the target, and some more stuff.



    It also notifies the target that it has in fact been attacked (or targets, if there is many).



    When the attack is done, and the cooldown on the attack ability has worn off, it’s ready to be fired again. The final state - cleanup, usually does nothing and just finishes the attack. Certain attacks may stay on the target - for example a DoT attack that passes the perform state successfully has a resolve state that is repeated once every x seconds until canceled, etc. That is why the attack event is a proper FSM instead of just a simple sequence.



    I’m gonna add a “inCombat” state later



    So basically…


  • World objects are “independent” objects that sits around, or runs around and targets and kills eachother.


  • Actions (and abilities), along with Control-Units determines what they can do and how they do it.


  • Items has an effect. They may be required to do certain things, they may change the way things are done.


  • Events are used to carry everything out - i.e. actually change the game state. Some events are small and doesn’t have to be encapsulated into an actual event object, and some do.


  • Attacks are carried out as a special type of event, and is handled by a separate manager.



    Gonna post more images and videos later.
15

Got a system for adding 3d models to vehicles and other stuff now, and linked it with the inventory system. In the picture is an example of a car. It has a body and a few slots. This is a regular car, so it has got four wheel slots (to be compatible with the vehicle control) and also a gun slot. The boxy shape next to it is the collision shape. Empties are used to link item slots to the 3d model. Adding items/equipment/weapon to mobs and other world objects is done through the inventory and inventory control units of the objects, but I have a naming convension for nodes (“GunNode” etc.) so that models are properly mapped to objects (through their inventories).



Using the blender importer btw, exclusively. Works great.



http://jamtlandoutdoors.se/images/dist2/vehicle.png

1 Like
16

The game is back up… now with templates that makes it easy to add new vehicles, mobs, guns, items etc. Here’s a car with a turret cannon on it for example…



http://jamtlandoutdoors.se/images/dist/working_again.png



Now hook everything up to the combat system, then it’s time to start adding trees and grass and stuff.