#1 2015-09-12 01:12:56

chasester
Member

PHYSICS

I Eventually got bullet physics into cube.

Video

if you are curious on how this integration works or how to fix or improve your integration just comment i will do my best to help.

chasester

Offline

#2 2015-09-12 07:51:52

Pritchard
Member

Re: PHYSICS

Looks really cool! Are you planning to release this modification?

Offline

#3 2015-09-12 12:55:34

ThaOneDon
Member

Re: PHYSICS

This is awesome, would like to try it out.

:)

Offline

#4 2015-09-12 16:04:21

chasester
Member

Re: PHYSICS

what form of it would you like, exe or what. The source is a bloody mess, saying that half of angelo code was super messed up.

Offline

#5 2015-09-13 10:32:30

ThaOneDon
Member

Re: PHYSICS

Well...

See if you can keep it simple. Something that you can just start with one click if you can.
Source would be awesome. License it if you want to. Up to you.

Offline

#6 2015-09-13 20:43:32

chasester
Member

Re: PHYSICS

I would just upload the files i have but it is far to large and would take a day or so. I will just upload the exec and the libs needed to run it. And the source changes i made to angelo's code.

You should be able to piece it together with that. Basically you will need to include the bullet.h files (in the bullet source). Then take the lib files and put them in the lib directory, take the files in the engine folder put them in the engine directory and the same with game. Then build and solve the errors that arise.

IF you just want to run the exe simply take the exe drop it into any tess version of the game and run. It should find everything ok. if not use the svn version. IF you run into errors print them and ill try to help you.

Various in-line fuctions:
PHYSKill: stops physics (once stopped it willnot restart with out erroring out. This will be fixed at some point.
PHYSDebugDraw: draws the outline this is always on you must turn it off. On large poly maps it will error, only showing fragments of the outline, this is due to a max on the particlles.
PHYSInit: this starts up the physics, you will not need to ever to call this
setangleimpulse: this will rotate all object on the screen with an inital angular impulse of (yaw, roll, pitch) this is mostly for debuging reasons.

angel script is partially implemented you can remove it by simply unincluding the halo.h wings.cpp and angelscript.lib. Angel script will not work in this version because the startup and the shutdown functions are not placed.

chasester

zip file

Last edited by chasester (2015-09-13 21:08:28)

Offline

#7 2015-09-28 13:24:42

Hypernova^
Member

Re: PHYSICS

This is interesting stuff. I've been trying to get this to work but can't figure it out yet. I extracted your archive into my tess directory, and added the bullet source. I see that btBulletDynamicsCommon.h and btBulletCollisionCommon.h are included from AJMPhys.h, which themselves include most of the bullet .h files. Is this correct? Sorry for my noobness :)

Last edited by Hypernova^ (2015-09-28 13:33:26)

Offline

#8 2015-09-29 17:11:48

chasester
Member

Re: PHYSICS

lol no your not the inclusion is complicated as hell omg. You have to build the bullet library so you have to go use cmake to make the vpp or code blocks or what ever compiler you have then build the bullet source to get the various different lib files.

If you build using release and 32bit you cant use the lib files i included, else you need to build bullet in the verisons you want to use. (64 bit and or debug).

Easiest way to set it up is to, start with a blank tesseract (the svn version works) assuming your using 2013 vcpp on windows using the windows 7 os. Do the following:

download my zip, add all the files in the zip in the same place you see them in the src directory.

download bullet sources files, and put them in a folder called extralib/bullet.

open the vcpp project.

add the AJMPhys.cpp AJMPhys.h files to the project under the engine folder.

Add the AJMmovables.cpp file to the project under the engine folder.

open the properties window (right click on the project, then properties).

under c/c++ -> general, first item additional include dir add extralib/bullet/bullet3/include (or what ever path takes you to the includes in bullet

under linker ->input first item additional directory add all the bullet libs BulletDynamics.lib BulletCollision.lib LinearMath.lib.

then go to cube.h add #include "AJMPhysics.h" (so that it is part of the precompiled headers, DO this before igame  or iengine.

This should allow you to build the game, remember change the properties for release 32 bit mode not anything else otherwise your lib files will error.

If you have any errors just leave them in chat and i will do my best to help you resolve them.

chasester

Offline

#9 2015-09-29 17:49:20

Hypernova^
Member

Re: PHYSICS

lol I guess I just wanted to use it too fast before researching how thing worked. Thanks for your detailed help, it makes sense now. I'm gonna try building with the command line (I'm on Linux), I should be able to figure it out based on what you wrote. The main reason I'm looking into this is because I'm making a mod of Sauerbraten that relies heavily on physics in gameplay,  and atm uses cheap/fake physics because I didn't have the time to get a real phys engine working. I've been thinking about porting to Tesseract for a while now and you just gave me one more reason to do so ;)

Last edited by Hypernova^ (2015-09-29 22:37:35)

Offline

#10 2015-09-30 04:21:49

chasester
Member

Re: PHYSICS

if you are looking at that ill be including a port that allows the use of angelscript. This will basically work similar to unity, in that all objects will be written using base script. Basically allowing you to write your own ents in script, then compile them into compile time code, and encrypt them for security. This will reduce the need for building the code rather having a runtime language that can be changed on map load, on command or even on frame. Allowing you to design your code with no compile time. This combined with bullet physics and real-time lighting will make this engine marketable.

If you like when i finish this, i can help you with porting it to your project so that your code can be more robust and easier to change and design.

chasester

Offline

#11 2015-09-30 18:19:00

Hypernova^
Member

Re: PHYSICS

Wow thanks for the offer man :O I'm not too familiar with how bullet works atm, I will have to do some research before starting anything :) Most interactive physics objects in my mod are map-specific entities, what I'm looking to do is utilize bullet for those items. If I can get time, I'll port my mod to Tesseract (it's really big and will take a while) and backport your changes. It could use the gfx upgrade at this point as well ^_^ About the Angelscript library, is this better than using the built-ins for Cubescript?

Last edited by Hypernova^ (2015-09-30 18:22:51)

Offline

#12 2015-09-30 22:16:42

chasester
Member

Re: PHYSICS

angelscript has classes, and inheridence, and functions (not macros) and typecasting and like alot of things, plus it can be serialized and saved back to a map file, meaning ents can have any number of attr rather than just 5, and they can be any type of data, a class pointer, an int, a float, a short, a uchar etc. and you can add your own data types, or classes, or functions through the source or the script.

It makes it so i can say here is an empty object, go run code to make it work. Rather than having to modify the source. That means custom map varibles, custom game modes, custom basically everything. No more strings :) no more need to work in the source code, no more compiling issues etc.
Simple easy and robust :) but ya its kinda a big deal.

If you want help on your project on something you dont know how to impliment or do, be it bullet or cube or what ever, i could try and help :)

chasester

Offline

#13 2015-10-01 16:26:36

Hypernova^
Member

Re: PHYSICS

Ok great. I'm gonna try to get a working port of my game in Tesseract before messing around with the bullet part. My #1 problem though is that I need more content like weapon models and such xD

I'm still not sure what angelscript does. Is it a scripting language in itself, or is it to increase the capabilities of the existing scripting language? My first thought was that it did things like the *COMMAND*, *VAR*, etc macros existing in Cube already.

Offline

#14 2015-10-02 01:41:28

chasester
Member

Re: PHYSICS

its a scripting engine like that seen in the command.h and .cpp files. It is vary similar. Yesterday i wrote the code that basically uses COMMAND like macro to exec angel script

So it would look like:

string getname(){ return player1->name; }
VAR("string teamname", player1->team ? "red" : "blue;)
COMMAND(string, getname, (void));
ICOMMAND("void echo(string s) { conoutf(s)}

some of the other var and command types are illrelevent at the moment because you can just simply state the return type. The only thing is that there are no VARPs cuz there isnt a way at the moment to save the values back (that will probably come soon) for right now i am simply just allowing cubescript and angel script to accesses eachothers functions and variables.

Angel script allows for something called shared its similar to js global. it can be declared to any data type class or function (they will be adding it to varibles soon from my understanding).

So you could allow this to be written in the halo files (angel script files) or uses cube script to register angel script functions.

My plan eventually will be to get rid of idents (an ident is just a storage pointer holding a function(macro), or alias (variable). And then allow the consol to call cube script like syntax to call angel script functionality. Making it easier when editing.

so like setfog(r, g, b); would be allow to be stated as fog r g b making syntax easier for artist. Then all config files will be replaced with angelscript code, making cubescript an interface on how to acess angelscipt.

But the shadder mess will have to be fixed before i can even start that.

chasester

ps: ive been trying to work on my modeling skills so if you give me some kinda description of what you want ill try to make something for ya, worst to worst i get some expirience out of it.

Last edited by chasester (2015-10-02 01:48:25)

Offline

#15 2015-10-02 13:14:50

Hypernova^
Member

Re: PHYSICS

Ah I get it now. Thanks for the explanation. I just wanted to make sure that an angelscript implementation wouldn't deprecate cubescript usage.

I haven't said much about the game yet, but it's very similar to Half Life 1/2 deathmatch. Here's a little representation:
https://www.youtube.com/watch?v=I2w7KeM6Se4
Just imagine this in Cube 2. This is what my game is like.
Note that the competitive community has turned HL2DM completely upside down by finding and using 'bugs' in it (such as bunnyhopping), which now defines the game for many people. I've done the same thing with mine, except the 'bugs' were added intentionally.  Some fancy things I haven't done yet, like the dsp audio effects.

I have alot of small modeling projects that I could use some help with. Here's a list of things I could use:
-A grenade hudgun model with throwing animation using snoutx10k hands
  example:
  https://www.youtube.com/watch?v=EyGrcYg … U7&index=4
  I already have the flare and timer click done, it would be cool if the muzzle tag for the hudgun could be at the bottom of the nade (where the flare will come). The weapon switching animations are coded at the moment.

-A grenade projectile and pickup model, you can probably use the hudgun without hands for both. No need to tag the projectile model for flares at the moment.

-A Spas-12 shotgun (without stock version) hudgun model with 2 firing animations: one for semi-auto single barrel (no   pump animation) and one for firing "both barrels" (pump animation and more jump), also using the snoutx10k hands. This video has a demo of most hl2 weapons in usage:
https://www.youtube.com/watch?v=5n7BweL5ADw
Perhaps something like this :) http://shop.ehobbyasia.com/tokyo-marui- … g6d362350w
A reload animation would be cool but not necessary, though I would create the code to wrap it if you wanted. My game does have weapon reloads but the animations are done cheap with code instead of model animation (I still use alot of Sauer hudguns)

I'll keep it to that for now. If any of these things interest you or you have any questions let me know :)

Last edited by Hypernova^ (2015-10-02 17:27:36)

Offline

#16 2015-10-02 18:28:45

chasester
Member

Re: PHYSICS

So to put your idea in non video, non copy cat form:

You want to create a game were players uses the environment of the game to position them self with advantages. Be that throwing a box at a player, a grenade, blocking bullets with a piece of scrap metal etc. You main selling point is a "tactical" form of game play, rather than the usual twitch based game play sauer like games are associated with.

I feel like you have a feel issues with your game. One is you have no clear vision. Although it is a good idea to base your game off of a widely popular and extremely expansive game, and company (vale in general) the clear problem is that you seem to lack any originality (at least from what Ive seen).

Second an i feel is a bigger issue is that you have no selling environment. From a strict marketing stand point you have no selling base. Trying to recruit ppl to stop playing a cult classic like half-life, to play your very similar version of the same game will be hard. Especially when the base community is not mad at or wishes that vale would change or fix things with the game. See in vales case, they used the quake 2 engine to create a long and very well thought out story, with matching hard, unforgiving, and very well written sp gameplay. Your game offers non of this, only offering a mp version that will rely on players to even play the game, meaning you need a player base before even releasing the game.

I would highly suggest, as daunting and unappealing as this sounds, to write a game design document. This will allow you to have a much better understanding of your game, and therefore make a better more rounded fluid game. It basically asks the hard question for you and this will give you a better understanding of your vision and make sure there are not any flaws in your current gameplay ideas.

Lastly the ideas of allowing "bugs" is very hard from a game play point of view. Meaning that new players, players that have just downloaded your game, will not know your bugs and are put at a major disadvantage. If these things look too buggy they may just write the game off as a bad game, or a under polished game.

Your game definitely is intriguing , and seem like a very interesting and fruitful game, if done right. Small things kill good games.

chasester

On a side note unrelated to the above points:

Weapons seem like a major aspect of your game, how are you handling your weapon classes (guninfo)? Is it just enums with a large case statement? The following sudo code is how ive handle this issue in the past to make weapons less complex and much easier to handle.

//#in game.h
struct basegun;

struct dynent : physent, gameinfo { // i think thats right :P
...
basegun *guns[MAXGUNSATONCE];
 //this could be changed making guns a static class but this makes things easier so you dont have to store the ammo and all that stuff.. two of one half dozen of another.
uchar curgun;
...
};

//use gun info to descript the base attributes of your gun, damage, reloadtime etc
//#inweapons.cpp at the bottom probably;

struct basegun 
{
guninfo *gunref;
int reloadmillis; //at what time are you done reloading, so reloadtime+lastmillis = realoadmillis; if reloadmillis < lastmillis reload is done
int shootmillis; //same as above
int switchmillis;
bool reloading; //am i reloading so i know to add to may reload and take from my ammo
int ammo // howmany total shots do i have


//note basegun could just be an interface, if you would rather handle it that way
basegun(int gun) {
 //simply copy over the gun here for reference
gunref = guns.length() > gun ? guns[i] : 0; 
}
void shoot(vec from, vec to){
//this double as an update function as well just like the the original shoot command
//update stuff
//check to see if the player is actually shooting (holding the button down)
//check if they are allowed to shoot if not just return
// ok now lets add the particles and stuff
// and lets do the ray test and return the valid info
// then lets add the hits to the hit buffer and send that to the server (basically every thing that the shoot function does)
}
void reload(){
//do the reload animation
//set reloadmillis
}

void switch(){ } // this is called by the dynent class to switch to this weapon. so just set the animation and the switchmillis
};

//so now lets write some actual code 0.0

struct raygun : basegun  //we will just make ray gun our base class for any gun that uses a ray test to signal a hit
//so this includes pistols, shotguns, rifles etc basically if it has a bullet. we could expand this later but for now we'll keep it simple
{
raygun(int gun) { basegun(gun); } //aww the beauty of inheritance.. we could use this to keep tract of the particles we are using too if we need to later but for now all guns are bullets and all bullet traces will look the same :)
void shoot(vec from, vec to)
{
if(reloading && reloadmillis < lastmillis){ //basically are we done reloading
reload = (gunref->reloadamount + reload) > gunref->reloadmax ? gunref->reloadmax : (gunref->reloadamount + reload);
reloading = false;
if(reload != gunref->reloadmax){ // this means we can continue reloading
reloading = true;
reloadmillis = (gunref->reloadtime + lastmillis) - rereloadtime; //rereloadtime makes it shorter if this is the second reload cycle
}
if( switchmillis > lastmillis || shootmillis > lastmillis // note we dont care if we are already reloading cuz we will just cancel it below
   || !reload || ! ammo || !shooting) return;
reloading = false;
reloadmillis = 0;
reload -= gunref->ammopershot;
shootmillis = lastmillis + gunref->shoottime;
//addparticles use the guninfo to reference these. 
cuberaytest(to,from) // i forget all the args here but its in the shoot command
sendmsg(N_SHOOT, ... .. ... ); //i forget all the take ins;
//the main class will handle the animations
return;
}
void reload(){
reloadmillis += gunref.reloadtime + lastmillis;
reloading = true;
}
void switch(){
//so basically we have just been switch to so just simply set the switch time
switchmillis = gunref.switchtime + lastmillis; //this will stop shooting
//we could player the animation here or in the base class or have an animation class handle all gun animations (honestly this is up to you)
}
};

//so all the above code basically make this code SOOOO MUCH EASIER
struct shotgun : raygun {
shotgun(int gun) {raygun(gun);}
void shoot(vec from, vec to){
loopi(gunref.numberofbullets){
   vec nf(from), nt(to);
   randomspread(&nf, &nt); //should already be a function for this
   raygun.shoot(nf,nt);
}
//now do the animation here;
}
//since we inherited all the above functionality we dont need to redifined it unless we want it to be different (in this case we dont)
};

// so now lets say we want a pistol like that in cube
//we can just simply create a gun from the gun info and then just simply create a raygun
//so it would look like this

basegun *gun = raygun(GUN_PISTOL);

done :)

so this allows for the easiness of a simple guninfo static struct array with the flexibility of class based inheritance


on a side note: i wrote this all from memory so its not C++ ready its glorified sudo code.

Offline

#17 2015-10-02 22:39:59

Hypernova^
Member

Re: PHYSICS

Thanks for your detailed reply. You made some good points that I forget to keep in mind :P

Focus/direction:
   Yeah you're mostly right about this. Too often I change things without having thought it out for a while. Having a design document like you suggested later would help this alot. However, this is kinda my "fun" project which has happened to grow quite large, and this flexability is something I've really enjoyed since starting.

Originality:
   This is a hard one for me because I basically want to replicate the hl2dm experience in a different enviroment. Probably the only thing that makes this original is because of one thing I like to do, taking unique features of other games and mashing them together here. There's some Sauer, UT, Bioshock 2 multiplayer, Quake 3 CPMA, Brutal Doom, and others.
   The other reason why this isn't too original, is because I haven't really felt the need to make it so. For example, how many games since 1996 have been a 100% ripoff of Quake 1? How many have carbon-copied COD or UT? Yet HL1&2dm (talking specifically about the multiplayer) have stood in a category of their own ever since released. And they are both dying quickly. Compare the modern games Toxikk and Reflex to Quake 1 and UT99. Nothing has improved, and many things have gone backwards.

"Selling" enviroment:
   This ties in a bit with the originality. I'm not too familiar with the state of the HL1dm community, but I know the HL2dm community well. In 2006, HL2dm was in the top 5 most played games on steam, and many of these were competitive players. Then Valve released the Orange Box update, which was essentially a Source engine update, and collection of bug fixes. Valve did not realize that their bug fixes would greatly affect the competitve community, as all competitive players enjoyed the bugs that existed. Instead of helping the HL2dm community as it did other Source games, the update completely destroyed the game as it was known, with about 90% of the players quitting because of the bug fixes. My game brings back all the these things that existed in Source before Orange Box. The people who left the old HL2dm might make a good "marketing" base.
   On the topic of bugs, you mentioned that hiding 'features' in the form of replicating bugs will make it hard for new players. This is exactly my intent. The original HL2dm is arguably the most difficult fps game to play, and players love it because of that. There are so many hidden tricks with the weapons & physics, movement, maps, etc and most of them I have replicated in my game. I'm not trying to attract a large player base; I'm trying to attract a beyond-hardcore player base.

Weapon code:
    tbh my source code is a real mess xD If I port to Tesseract then I'll definitely do a refactoring in the process. Thanks for the suggestions - I'll probably make use of some later.

Thanks for spending so much effort helping me out, I can tell there's alot I can learn from you. I'm really enjoying this conversation, but we should probably offline it at some point ^^ (this is for Tesseract general discussion anyway)

-hypehypehype

Last edited by Hypernova^ (2015-10-06 20:37:57)

Offline

#18 2015-10-03 03:20:55

chasester
Member

Re: PHYSICS

Hypernova^ wrote:

Thanks for spending so much effort helping me out, I can tell there's alot I can learn from you. I'm really enjoying this conversation, but we should probably offline it at some point ^^ (this is for Tesseract general discussion anyway) -hypehypehype

Lol Not to many people actually use this forum :P

As to the above, i see what your saying this is a pet project to help you with your abilities and to hit a very select nitch group audience. But the concepts are actually not half bad, and could be made into something for a wider base. Rather than just allow players to "have certin bugs exist" add a cs:go like money system in allowing players to buy hack, giving them the ability to "force push" or to double jump, hover jump, fly for a short time, see through walls, etc. make the weapons less serious and more wacky, using the same base concepts as before. I feel that an enviroment based custom class based, money system could prove very good game play and provide somthing similar in ensense but different in nature, allowing your game to be both original and familiar. Making it easy to pick up, for new players, fun addicting but still offer cool tricks and stratagy for hard core gamers.

Personally gearing a game to a community of another game, but only for the hard core competitive market seems to be very very hard, to make any kinda player base stick.

But idk. As to your point about 100% of games being a rip off of quake, yes and this is why most fps game (even those made by big companies) have about a 5 year life spand. There are few exceptions to this. Most of them being vale games, and then halo (But thats mostly cuz they came out with a new version every few years). Same could be said of cod and a few others. But each of those games brings something to the table that hadnt been done before so its not really fair comparison.

My main point is that i feel that your idea is strong your game concept is strong but your implementation is misguided. Now if you end goal is really just to get a few people for a short bit, or just to have fun coding something then awesome. BUT i feel you have some pretty sweet concepts, if orchestrated correctly could make something at least semi popular.

Obviously you are a long way off before you can even make most of the decisions but just think about it as you continue forward.

chasester

PS: I think i will have a version of the angel script port with entity controlled by script by next month. And then i will be working on a server port for multiplayer. If you want the source for that just let me know ill see what we can work out.

PSS:
my email is wennerc@sirinc.net
my skype is chase.wex
my kik chasester123 // idk if ppl actually use this but what ever

If you have any questions, want my opinion on gameplay or implementation of something, or if you run in to some error on my code you cant solve just give me a message Ill see what i can do.

ill leave you with this:
CATGUN: shoots cats that chase a targeted enemy for a bit, if caught claws the enemy in the face (stuning, and reducing visuals), does small amount of damage.

Offline

#19 2015-10-06 01:37:49

Hypernova^
Member

Re: PHYSICS

Thanks for your support. I will definitely consider the things you mentioned. I realize I should have said from the beginning that this was more or less a recreation of HL2dm in Cube 2, you were probably wondering why I was spamvertising for HL2dm :D
Your project is very cool as well, definitely let me know when the multiplayer is ready and I'll port.
If you still have any interesting in making models let me know, I can provide better/more detailed information.

About the catgun, yes, I seem to remember something like this in Half Life. xD

-hypehypehype

Last edited by Hypernova^ (2015-10-06 21:06:58)

Offline

#20 2015-10-07 05:20:33

chasester
Member

Re: PHYSICS

@catgun
I know once i got that, that's all i used the rest of the game :P

Offline

Board footer