Introduction | Beta Testing | Particle Engine | Warning

What is EDuke you may ask? Well EDuke is a new Duke Nukem 3D executable file. The file contains numerous updates including newer Build libraries (from newer Build games) and an extensive update of the CON language to allow more extensive modification than was ever possible before. At the moment, it is not available for public consumption. However, I am a member of the Beta testing team and as such I have the opportunity to try out all the new features that Eduke allows. Here you can read my insights and maybe learn something helpful by the time you can get hold of it.
 

Beta Testing
For EDuke I have one major project, the implementation of particle, lamina and spheroid physics into Duke Nukem. Basically, it's a way of making realistic behavior for actors and such.
Along the way however, there's just too much cool stuff that can be done, even in these early Beta versions, not to play with the other stuff.

As I was thinking about the particle code, before I was even a beta tester I wrote this code as a way of planning out how I might write it:

/*
Particle Mechanics Engine v0.00
Single particle experimental engine
No collision detection, no slope accounting yet.
Written by Cyborg
*/

gamevar GRAVITY 100 0 // Gravity constant of level
gamevar MASS 100 2 // Mass of actor 100 is default

/*
X plane is 0deg angle plane in BUILD
Y plane 90deg angle in BUILD to it
Z plane is vertical movement
*/

/*
If values equate to m/s then the amount moved by an actor in meters is the meters represented by the movement of one game unit divided by time represented by one game cycle. This may be useful for calculating realistic values for the below later.
*/

// Velocities

gamevar VELOCITY_X 0 2 // Velocity in X plane
gamevar VELOCITY_Y 0 2 // Velocity in Y plane
gamevar VELOCITY_Z 0 2 // Velocity in Z plane

//Accelerations

gamevar ACCELERATION_X 0 2 // Acceleration in X plane
gamevar ACCELERATION_Y 0 2 // Acceleration in Y plane
gamevar ACCELERATION_Z 0 2 // Acceleration in Z plane

// Co-efficients

gamevar ELASTICITY 32767 2 // Range (0-65535) represents real range (0-1)
gamevar FRICTION 32767 2 // Range (0-65535) represents real range (0-1)

/*
e.g. Elasticity for bullets and such would be zero as they embed in the target, elasticity for rubber may be very high. Ice friction would be near zero, mud friction would be high.
Friction values for surfaces will be need therefore later on as at the moment it would be assumed that the floor has a friction the same as the actor (as the mean coefficients of both actor and surface is the working coefficient).
*/

// *Cool idea: increase friction of player with boots to allow him to climb slopes...

DEFINE PARTICLE 1

USERACTOR notenemy PARTICLE

// Unique particle variables

setvar MASS 100 2 // Mass of actor
setvar ELASTICITY 32767 2 // Range (0-65535) represents real range (0-1)
setvar FRICTION 32767 2 // Range (0-65535) represents real range (0-1)

// Movement code, basic movement and jumping

// Expect bad code now on in and made up primitives !

ifaiforward // Actor is told to move forward at its current angle
{
addvar ACCELERATION_X * cos ACTORANGLE 100 // If angle is zero X acceleration is maximum (cos 0 = 1)
addvar ACCELERATION_Y * sin ACTORANGLE 100 // If angle is 90deg Y acceleration is maximum (sin 90deg = 1)

/* 100 is an acceleration constant, the higher the higher the max speed and rate of movement, and can be changed for walking and running speeds etc...
Backwards movements are negative values of this.
*/

state MOVEIT // This state defined later actually calculates how the particle should move in X, Y and Z planes and does it
}
ifaijump // Actor is told to jump
{
addvar ACCELERATION_Z 100
state MOVEIT

/*
Much simpler. The actor will come back to earth when the jump is over. For a flying action this works too as the player will rise as long as the acceleration continues and fall under gravity when it ends.
*/

enda

/* The main code for an actor would now reside in its AI function where it decides HOW to move. The idea is that the code above just says how it DOES move. So remove the jump code and it cannot jump ever. Remove the forward code and it can't move in the X Y planes.
*/

state MOVEIT

/* General strategy: increase its velocity according to the acceleration, reduce actor's acceleration or movement force according to friction, then move the actor for its current velocity constant. From this basic principle any time of effect that models particles can be added, wind drift, water flow, different surface friction's and the effect of gravity of a slope (slippage like in Quake but realistic as you will only slip if you exceed the max angle for the friction before it is exceeded, this will also mean that now you can have really high sloped sectors that cannot be climbed which will make unclimbable scenery possible without the pain of blocking sprites of walls).

For the second engine version for two particles I will add the event of a collision and then in the next version wall, then floor/ceiling collisions. In this version it is assumed the particle will not collide ever. (This is a poor model as the actor should fall through the floor with no reaction force. This will be added later as well with the collision detection)
*/

addvarvar VELOCITY_X ACCELERATION_X
addvarvar VELOCITY_Y ACCELERATION_Y
addvarvar VELOCITY_Z ACCELERATION_Z

subvarvar ACCELERATION_Z GRAVITY // or have a negative gravity const, whatever it's supposed to be

//*Weird idea: anti-gravity?

ifactoronground
{
mulvar ACCELERATION_X 65535 // multiply it by 65535 so now FRICTION is as a variable 0-1 (I don't think fractions are alllowed so I've done it like this)
divvarvar ACCELERATION_X FRICTION // i.e. ground friction only works on ground (duh!)

mulvar ACCELERATION_Y 65535 // multiply it by 65535 so now FRICTION is as a variable 0-1 (I don't think fractions are alllowed so I've done it like this)
divvarvar ACCELERATION_Y FRICTION // i.e. ground friction only works on ground (duh!)
}

// In here would go other resistances to motion like air resistance and wind force etc...

moveactorforward cos ACTORANGLE * VELOCITY_X
moveactorright sin ACTORANGLE * VELOCITY_Y
moveactorup VELOCITY_Z

/* I have no idea how to do the above but basically the actor should now translate by a number of game displacement units specified by the VELOCITY variables. As these movements are relative to the angle of the actor sin and cos are in their to make the X Y plane variables have meaning in reference to the actor
*/

endstate

// END

Don't try pasting that code into Duke! It's incredibly poor coding, lots of mistakes for stuff already in! I did it as a guide, not as a final product.
You might find it useful to plan out your ideas like this even though it may not be clear how to do most of the coding yet. With the more recent betas I have started to replace parts of the code with the appropriate stuff from the new language.
I suggest you read my Eduke CON guide article for more information.