Pin Factor:The first game prototype for RF+Tokamak.

[federico]

As the name say, it is a Bowling game. I wrote the code for this game two or three months ago, and I though to release it when finished but really I haven't much time and I would need some collab and I don't like to be misterious and shy of something you could like.
The game basics are here (i need only to implement the rule system but the gameplay is complete). The lack is all in the graphics part. I've ripped some graphics from Anime Bowling babes but this isn't a road that can be allowed for an original game. My idea would consist in add different alleys and bowling balls and pins.
If someone is interested, let me know, otherwise enjoy this prototype and make that ball rolls!

Video: http://realitychess.altervista.org/vide ... actor.html

Download: http://hosted.filefront.com/RFfederico/

A note: you don't need to create a level using bsp now we have Tokamak collision also on staticmesh.

[Tabulanis]

A note: you don't need to create a level using bsp now we have Tokamak collision also on staticmesh.

How is this? Is .75a doing this or is there some I must do?

[Jay]

That's from the physics addition. However, physics isn't stable eneough to be released(=has bugs, crashes sometimes) from what can be heard.

federico, is the tokamak collision nearly as fast as bsp i mean is it faster than the staticmesh collision?

[federico]

the tokamak collision works only for physics defined bodies. These bodies belongs as well to the genesis realm. So yur physics body is identified by an EntityName as Genesis Actor (for example: "PhysicicsEntity1") and by a number, a BodyId (for example '1'), to be handled by the Tokamak engine. If you need to define the EntityLighting you should use the EntityName in a pawn script (in this example: SetEntityLighting("PhysicsBody", etc)). But if you need to apply a Torque on that body you shold use his BodyId (In this example SetTorque(BodyId, etc...)). So, the two realm exist in the same time but they aren't unified. This is a list of the possible collisions between the two worlds:

1) an Actor with only the Genesis Colision. The genesis bounding box is a cube.
2) a Body with only the Tokamak Collision. The Tokamak collision can be defined by three simple shapes, full scalable: a box, a sphere (not an egg!), a cylinder, plus an "Hull", a user defined convex(!) shape. The latter is quite unstable.
3) A body with both the collision. if a tokabody has a Genesis BBox then the other Genesis actor can collide with it (with his bounding box).

4) Genesis BSP or StaticMesh per-face-collision.
5) Tokamak terrain, a static body (ca't be moved in any way) that that usually is initialized with your BSP level. Thanks to Nout, now the Tokamak terrain can be extended with a combination of several staticmesh and/or staticentity everyone with a differnet physicsmaterial assigned (friction and restitution).

If the tokamak objects are moving the coliision with actors that have only genesis collision will fail due the different engines speed. This is the main problem integrating the player as physicsbody.

So The problem of the speed of the engine collision is totally unrelated to the visualization engine speed. If the toka collision on terrain are well managed then the speed can be optimal. Otherwise if the physics engine can't solve all the calculation then the framerate can lower istantly. I hope to have answered in a useful way.