Well thats one way to fly a J35....

[RainMotorsports]

Viewed best in HD thanks to youtubes compression... and err got the designation wrong lol.

<iframe src="http://www.youtube.com/embed/kcQwjLGU5Z0" allowfullscreen="" width="640" frameborder="0" height="360"></iframe>

Guess I am making fun of myself but i started recording when i went external and realized I wasnt just low to the ground I was taxiing across water.... then i hit a building and kept on going and tried to see about riding that shallow water again.

 

[marfig]

No, no no. It's important someone tells the developers that hitting a building makes the fighter explode and landing on water does not.

void collision_detection(player p, vehicle v, obstacle o) {

    /* ... */
    if (v = plane && o = building)
        kill p;    
}

I can understand the confusion though. The F35 was designed also for ground attack. It's possible that the developers don't know what that means.

 

[RainMotorsports]

No, no no. It's important someone tells the developers that hitting a building makes the fighter explode and landing on water does not.

Atleast it wasnt as bad as the A-10 that bounced off a building and landed haha!

Well the plane was submerged which auto kicks the pilot out of the vehicle same as jeeps. The wing killed me and once a vehicle is abandoned, especially under water it self destructs to allow the next one to spawn. Part of the general theme of the game play not the vehicle realism in that regard.


....funny I am pretty sure that code is from MS Flight Sim 98. Its so wrong since yes hitting a building at 2 feet per second would obviously completely destroy my 737!

I am super excited I haven't written anything since February of 2011 when I started gaming again!

The game is usually the result of 2 code bases. The engine and the game itself. So the code saying that the vehicle is to be destroyed and or its occupants to be killed is routine part of the games code. The collision detection, called by the game after moving something, a part of the engine, calls this routine after calling the physics routines to determine the amount of damage for that frame of movement. That code also affects the next frame of motion since it determines any changes in the objects momentum and path. I like to keep that to a seperate thread since if the object is destroyed the results are not needed for anything other than special effects. No need to delay calculating weather the collision has already resulted in the loss of the object with data that will be modified if it was destroyed.

The engine would support basic object types in which the games coder can create new classes that inherit those base classes properties. One type might be a vehicle whose moving parts do not rely on a skeletal structure for movement and is limited in its use of collision boxes. Another would be a soldier who has numerous collision boxes used for both weapon collision and vehicle collision detection and are tied to the movement of the skeletal structure. As you know we use these larger boxes to be cheap on the processor time for collision detection.


You will have to forgive me for what I am about to write. Its in my native language. Object Pascal. If the object the collision detection is responding to the games query about is a vehicle containing a passenger. It will call this function passing the damage result from the physics calculation. Other objects will call other functions in order to be damaged, destroyed, removed from the gamers render space.

Bring on some crappy code at 4 am....

[COLOR=Blue]// Not going to actually define the classes here properly for the example
// Just declaring their origin[/COLOR]
[B]type[/B]
TBattlefieldAircraft = TFrostBiteVehicle;
TFighterJ35 = TBattlefieldAircraft ;

[COLOR=Blue]//Plenty more missing declarations.  Game keeps track of the health of individual vehicles
// We will request that data out of thin air.... as well as have declared the existence and
// start values to the engine.[/COLOR]

[COLOR=Blue]// Called by collision detection in response to move query on object base class vehicle.[/COLOR]
[B] Function[/B] OnVehicleCollision(Vehicle : TBattlefieldAircraft , Damage : Byte) : Integer;
[B]var[/B]
   Health: Byte;
[B]begin[/B]
    Result := [COLOR=Blue]-1[/COLOR];
[COLOR=Blue]//Initial Call Error Handling[/COLOR]
    [B]if[/B] Vehicle.Handle = [COLOR=Blue]-1[/COLOR] [B]then[/B] exit;
[COLOR=Blue]//Lets start the good stuff[/COLOR]
   Health := Vehicle.Damage - Damage;  [COLOR=Blue]//Should be wrapped in better code[/COLOR]
   [B]If[/B] Health <= [COLOR=Blue]0[/COLOR] [B]then
   begin[/B]
      [B]if[/B] Client.InVehicle [B]then [/B]KillPlayer(Client);  [COLOR=Blue]//Calls Game code to kill player, induce stat etc[/COLOR]
      KillVehicle(Vehicle.Handle);
      Result := [COLOR=Blue]1[/COLOR]; [COLOR=Blue]//Tell the engine we are killing the vehicle[/COLOR]
[B]   end[/B] [B]else [/B]Result := [COLOR=Blue]0[/COLOR];  [COLOR=Blue]//Do not relay vehicle death to the engine [/COLOR]
[B] end;[/B]

The physics code will take care of how solid the surface it is hitting and how the speed will impact it as well as versus how the object itself affects the impact. So building or ground can be the same or ground can be much harder than a weak building.

If my aircraft taxi's into a wood shack whose base class is building which inherits a property of being destructible. It should not often cause fatal destruction. Yes if we want to simulate a little realism the engine is gonna suck up some particles and probably be out of commission. To be a video game we just throw a little damage to it and be on our merry way. This is why Vehicle + Building shouldn't always = Player death.

Not that you wouldn't know such a thing, I got carried away...... Needs work. Cant decide if vehicle destruction should be handled purely by the engines code automatically after the game design decides its done or allow the game code to make the calls itself.

 

[RainMotorsports]

I am going to wake up in a few hours and wonder what the hell I just wrote.... It happens alot I swear. Sorry for any mistakes but you will probably get the direction I am going in.

Wasn't saying anything about what you wrote. You wrote it as a simple example. Its the basic principle behind the result of the incident at hand. As I said pretty sure you will find it in Flight Sim 98's code because the game usually played exactly like that.

I should also probably feel stupid for trying to engage in conversation with someone who actually does this for a living being the idiot that co wrote and then re wrote the only truly unique and original application I have ever written:

Everything else I wrote before it was junk and things that had been done before. I was studying DirectX and C++ as well as RTS engine design before I decided I wanted to play some video games.... Was supposed to be writing my own version of a Memory Stick partition mover being the first one for Windows Vista/7 something for the legacy of the PSP's. Some day someone might need to repair a PSP and have a memory stick not compatible and no XP machine to be found.

 

[marfig]

I should also probably feel stupid for trying to engage in conversation with someone who actually does this for a living

Totally don't!
I enjoyed your post and was pleasantly surprised to have a discussion on the matter.

Everything else I wrote before it was junk and things that had been done before. I was studying DirectX and C++ as well as RTS engine design before I decided I wanted to play some video games....

Going hobby programming isn't an easy option, at all! You are not alone and I'm no exception myself. In fact, if you go to a programmers forum -- any programmers forum -- you will see that most people can only take programming seriously in a professional environment. Most of us can't ever finish any hobby project we set ourselves for. Those forums are filled with those stories of unfinished projects. I personally never ever finished a home programming project.

Consider this: The programming community is huge. And I mean huge. Today, to be a programmer you don't really need to go to University (although it helps because it teaches you project discipline and management). All the information on how to learn to program on a language is one way or another available on the internet (including pirating programming books). And yet, despite the fact there's quite possibly hundreds of millions of programmers out there, the actual commercial and freeware output is considerably smaller . The ability to stay on course when programming as an hobby is not for everyone.

Now as for your earlier post:

The collision detection, called by the game after moving something, a part of the engine, calls this routine after calling the physics routines to determine the amount of damage for that frame of movement.

Here you can optimize considerably if all the engine does is handle generic collision detection and then pass any relevant data on to the vehicle own Collide method, instead of a universal Collision function. Divide to conquer as they say. This simplifies considerably the collision detection routine and allows you to make use of proper inheritance, which in turn simplifies the addition of future vehicles on later patches/versions, facilitates the reuse code for later games or to make changes to the current code.

For instance, if the F35 class is a member of the Aircraft class (I'd probably do a Fighter class instead of a F35 class and make the F35 an object instead, but let's keep it simple), you can do a virtual method Collide of the Aircraft class that immediately exploded and killed the player. The F35 class would inherit this behavior and you wouldn't need to write any more code or check for damage. Any other fighter class would just inherit this behavior of the Aircraft class.

Because an M1 is not a member of the Aircraft class, but of the Tank class instead, it would not have this behavior, but that of the Tank virtual Collide method, which surely would already include damage calculation.

Another would be a soldier who has numerous collision boxes used for both weapon collision and vehicle collision detection and are tied to the movement of the skeletal structure. As you know we use these larger boxes to be cheap on the processor time for collision detection.

Indeed. This is a major problem on about every modern multiplayer game that requires huge amount of server-side processing and cannot (for security reasons mostly, but also to cut down on lag) rely on client-side processing.

In fact, the whole physics engine is a miracle already on modern games. But we all know how coarse it really is. We have seen it or experienced it ourselves (like the spring-flying tanks we've seen on a recent post on these forums). The actual knowledge to produce good-quality and close-to-reality physics exists and it's not even very complex. It's the processing time that stops programmers on their tracks.

One of the thoughts that always puts a smile on my face is how we tend to look at modern games and appreciate them for their realism (like we did in the 90s), but are in fact still essentially playing with very limited assets; and how in 10 or 20 years we will look at contemporary games and think that, despite being cool, they are worlds apart in terms of technology. Mostly thanks to added processing power, not so much newly acquired knowledge.

Note:
Curiously enough physics are mostly handled by the game client, not the server. All the server should do is send the 'this exploded' call to the client. And if the physics engine has some random variables attached (which it should on some cases), it's very possible for two players on the ground to see different particles when a plane crashes into a building.

if Client.InVehicle then KillPlayer(Client);

This is a problem as you may have noticed by now. The server game engine should have no concrete knowledge of game clients.

The glue between game engine and the network engine is on this case handled by a mid-tier layer of Events. The above could simply be managed by doing a simple call to, for instance:

Vehicle.Exploded();

Vehicle.Exploded() is a delegate function that calls the Exploded() event to any event subscribers. On this case, possibly, the Client objects of the network engine.

I'll admit at this point that I never did a 3D multiplayer game. But I'm not sure I'm far off base here. It's just that I cannot conceive all the complexity of frame-by-frame calculations (movement, firing, collision detection, etc) in a 3D environment -- or pretty much any other environment for sure -- without the use of the event-driven programming paradigm to greatly simplify the binding of the several layers of code.

That said, it is also one of the main reasons modern games have so many bugs.

 

[RainMotorsports]

Yeah I learned Pascal at 13 when I was loaned a copy of Delphi 3. I had knowledge of the concepts from knowing BASIC thanks to the VTech bs my parents bought me when I was 9. I studied the program code that came with the compiler and got a basic understanding of the language. Tried to teach myself C++ using a book a couple years later but I could not grasp it with my learning style. I later found that having a real understanding of the language I was using already was my biggest obstacle.

When I met ThievingSix I was not at a state even after several years, that could be called a programmer. Sure I was writing stand alone applications from scratch but I sucked. Had some noob that couldn't use a command line application that needed help. I wrote a windows front end for the application and hooked the output pipeline so when it finished we could diagnose the problem. I refined the app and posted it with a "Hope this helps more people". I was flooded with feature requests that were out of reach and thats when T6 took me to a different level.

He wrote a code replacement for the application I had to rely on. This way I could pull information directly and then do things the original application could not. The thing is T6 wrote all his code on notepad and then paste binned it to me. Nothing ever compiled or worked right off the bat. It was in the debugging of all of his code that was over my head that I learned so much. I could not use pointers at all starting out. After releasing the app we co wrote I lost the source and I also lost T6 (computer died).

I recovered a very early version of the basic code that made the whole damn thing work. But I had to rewrite atleast 90% of the application from scratch without any help. Sufficient to say I had already learned what was necessary.

Not to say I didn't have my own hand in it from the beginning. The code to detect whether or not the MS was attached to a PSP was something unique I had created myself for my range of apps. Can be done several ways I just queried the USB string but I have code these days that sends a SCSI command to the PSP and gets its firmware version among other things.

Vehicle.Exploded();

Vehicle.Exploded() is a delegate function that calls the Exploded() event to any event subscribers. On this case, possibly, the Client objects of the network engine.

I'll admit at this point that I never did a 3D multiplayer game. But I'm not sure I'm far off base here. It's just that I cannot conceive all the complexity of frame-by-frame calculations (movement, firing, collision detection, etc) in a 3D environment -- or pretty much any other environment for sure -- without the use of the event-driven programming paradigm to greatly simplify the binding of the several layers of code.

Should be pretty easy to say that you are more competent than I am despite any lack of experience or time spent. At this point I have never written something large enough to have worried about it but its easy to see where I need to go with that.

Going hobby programming isn't an easy option, at all! You are not alone and I'm no exception myself. In fact, if you go to a programmers forum -- any programmers forum -- you will see that most people can only take programming seriously in a professional environment. Most of us can't ever finish any hobby project we set ourselves for. Those forums are filled with those stories of unfinished projects. I personally never ever finished a home programming project.

Yeah well when I returned from a previous hiatus I pitched a space based RTS project to some friends. I loved Star Trek Armada from back in the day and its barely playable these days. I chose a space based RTS because it required the least amount of texture work of any game I could think of and it was something I could get started. I had sat down with friends and wrote down everything we thought was wrong with RTS games. We ran into many problems with fixing this right away. I pitched our ideas to someone else and the response came back "You mean like Sins of a Solar Empire". I bought the game and sure enough not only had they come up with a solution to everything I yet had it pretty much answered my prayers about the genre even though it is apparently at its core a mix of turn based and rts.

I have the basic pseudo code for ST Armada's AI and its pretty easy to see why its AI sucks ass. I felt this was where I would do best. I pitched the project to people I worked with and everyone turned me down. I had already wasted the year I was supposed to be learning C++ and decided it was bust. As a result of 8 days of studying I can now read C syntax and translate it into Pascal. I guess all was not lost.

Indeed. This is a major problem on about every modern multiplayer game that requires huge amount of server-side processing and cannot (for security reasons mostly, but also to cut down on lag) rely on client-side processing.

Curiously enough physics are mostly handled by the game client, not the server. All the server should do is send the 'this exploded' call to the client. And if the physics engine has some random variables attached (which it should on some cases), it's very possible for two players on the ground to see different particles when a plane crashes into a building.

This is a problem as you may have noticed by now. The server game engine should have no concrete knowledge of game clients.

As you can tell my 4 AM thoughts have already started to make mistakes. But for me the whole process is of trial and learning. In something this large there is definitely a wrong way to do this. At least for security and synchronicity sake. But I usually say there is no wrong way to do something if it works. There are just better ways.

Yeah I realize right off the bat if an aircraft hits an aircraft this requires everything to be done server side. This is less important with buildings but the game will be consistent in how it does what it does. I already know we send bullet trajectory information to the server and it does the collision detection. The main reason why what we saw happen was not what the server saw happen. Whether or not having sleep would have clue me into that without someone poking me im not sure.

By client I was referring to the local client since their game has no control over the other "clients". But even so yeah as you point out the server is calling for the client software to kill the player and other player models at death. Once called the game rag dolls the model and keeps on going.

Yeah while I 5 hours later pretty much understand why i wrote what I wrote its too single player minded and easily wrong.

 

[OriginalJoeCool]

I've been wanting to develop either an RTS or RPG as well. RTS's are probably more complicated due to there being so many entities on-screen.

I've found this to be helpful:http://www.cjgraphic.com/?page=rts-book. You can download the full source code for the RTS developed in the book. The game is very simple, but the elements are mostly all there, and it is the demo application I've ever seen in a book.

Also interesting are open-source graphics engines such as Ogre3D.

My Achilles heel is 3D modelling. I've tried a little modelling in Blender, but so far have failed completely.

 

[RainMotorsports]

Marfig I actually have to take some ground back

The client and game server should be doing collision detection depending on what its for. Bad Company 2, BF3 and others for example. BC2 the client does bullet collision detection to show the blood splatter on hit even if this hit is never recognized by the server. The server does its own collision detection based on position and trajectory data it has. One is for effect the other is for actual killing. In bad company 2 if your client shot someone but the server did not see the same player position you will get blood spray but no hit marker.

Collision detection involving 2 players bumping into each other is probably nearly exclusive to the client. The server responds to position data and does not immediately do anything to affect it. If some lag or someones lag switching (The kind where the player cuts the modem so they can move without being seen, not the kind where the player hosting lags everyone) the server will reset the player position to the last good position. This is the rubber banding effect. Mostly a response to cheating it keeps the player in check for better or worse.

Now I guess it would be up to the designer but terrain collision detection to aid in proper player movement over said terrain probably should be too much of a concern to the server. We want to prevent people from glitching into the terrain or cheating with it. But you will notice these games typically dont care if you fall through the map. Some will reset you once youve fallen beyond the range allowed others will do nothing.

Hard to say how physics should be kept in check with the server environment but I can tell you a single BC2 client does more physics calculations than the whole rack was doing for all games we had going. Obviously if our vehicle bounces off something we don't want the server to think our position change is abnormal. As long as there is a steady stream of telemetry coming it shouldnt take too much checking to do a proper job. But when your limited to a Dual Xeon Quads and expect people to be running a few servers for just that game on it there is not much cpu power to go around.

I've found this to be helpful:http://www.cjgraphic.com/?page=rts-book. You can download the full source code for the RTS developed in the book. The game is very simple, but the elements are mostly all there, and it is the demo application I've ever seen in a book.

I actually have that book, not bad but after having skimmed it I could do without it now lol. If I remember correctly while it does good for its example game. Its really not comprehensive on implementing collision detection etc.

My Achilles heel is 3D modelling. I've tried a little modelling in Blender, but so far have failed completely.

I took Aviation and Aerospace design as a career completer in high school. One of the courses was drafting. I sadly cant remember too much but if i need to model anything Google Sketchup gets the job done. I never could figure out Blender. Sketchup and AutoCads free junk does not do solid modeling which would make it easier for me to carve shapes out of things. But oh well.

I cant say anything but Rob is apparently looking forward to showing off what I am modeling right now. He has some hardware going into it