Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›620 »

Shavnir: Apr 5, 2005; A MAN'S DREAM CAN NEVER DIE

You probably want to look into the Visitor pattern, but its one that I always struggle with.

In a game I worked on recently we actually used a double visitor and had another class that just did the collision results (a CollisionHandler). That way we only had one class we had to modify when we added new types into our hierarchy.

# ? Dec 18, 2008 00:12

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 13:01

magicalblender: Sep 29, 2007

Morpheus posted:

is there any way to call collide() on it so that Player.collide() or Enemy.collide() or whatever is called, instead of GameObject.collide()?

How about making GameObject an abstract class? That might help, assuming that C# abstract classes are like c++ abstract classes. (If they are not similar, disregard this post, as I'm preaching outside my tiny circle of knowledge)

Some quick Googling gives an example:

code:

using System;

public abstract class Clock {
    public abstract void Play();
}

public class RedClock: Clock {
    public override void Play() {
        Console.WriteLine("RedClock.Play()");
    }
}
public class BlueClock: Clock{
    public override void Play() 
    {
        Console.WriteLine("BlueClock.Play()");
    }
}
class MainClass
{
    public static void CallPlay(Clock ms)
    {
        ms.Play();
    }
    public static void Main()
    {
        Clock ms = new RedClock();
        CallPlay(ms);
        ms = new BlueClock();
        CallPlay(ms);
    }
}

# ? Dec 18, 2008 00:49

Hamled: Sep 11, 2003

Actually, the base class does not need to be abstract. Just using the 'override' keyword on the child class method definitions (and making the parent class methods virtual) should be sufficient to get the behavior you want.

# ? Dec 18, 2008 00:59

Shavnir: Apr 5, 2005; A MAN'S DREAM CAN NEVER DIE

It really depends on what you want to do with this collide method, are you trying to detect collisions or resolve what happens when they collide?

# ? Dec 18, 2008 01:06

Morpheus: Apr 18, 2008; My favourite little monsters

Shavnir posted:

It really depends on what you want to do with this collide method, are you trying to detect collisions or resolve what happens when they collide?

Resolve what happens. Technically I pass collide() a parameter (the object it's colliding with), but that doesn't matter for this question. GameObject is abstract, collide() is indeed overridden in its inheriting classes. The problem is as follows:

I have a Player object, and I put it in the List of GameObjects. So, when I'm going through the list and checking to see what collides, I'm checking collision between two GameObjects. However, when I see that something does collide, and I run the collide() function in it, it calls GameObject.collide(), because it has not been re-cast as a Player. If I want to call Player.collide(), I must first recast it as such, then call the collide() function.

# ? Dec 18, 2008 02:43

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

Morpheus posted:

Resolve what happens. Technically I pass collide() a parameter (the object it's colliding with), but that doesn't matter for this question. GameObject is abstract, collide() is indeed overridden in its inheriting classes. The problem is as follows:

I have a Player object, and I put it in the List of GameObjects. So, when I'm going through the list and checking to see what collides, I'm checking collision between two GameObjects. However, when I see that something does collide, and I run the collide() function in it, it calls GameObject.collide(), because it has not been re-cast as a Player. If I want to call Player.collide(), I must first recast it as such, then call the collide() function.

Are you using the override keyword in the declaration of collide() in the derived classes?

# ? Dec 18, 2008 02:50

Morpheus: Apr 18, 2008; My favourite little monsters

PT6A posted:

Are you using the override keyword in the declaration of collide() in the derived classes?

You know what, it works now. I'm almost certain I didn't change anything, but I bet at some point after getting frustrated, I added in the override keyword and then forgot to test it again. Gooooo me.

Hurray poleemorfism :downs:

# ? Dec 18, 2008 02:52

biznatchio: Mar 31, 2001; Buglord

I just saw that there were other responses since this post, that'll teach me for not refreshing the thread before typing up a reply; but I'll post the reply anyway in case its helpful:

Morpheus posted:

I've got a program that has a structure similar to this (in C#):
code:
GameObject
     |
MovableObject
     | 
   Entity
   |     |
Player   Enemy
There's a function called collide() in GameObject that is overridden in each of the objects. I also have a List that holds a bunch of GameObjects in it, but they're really Players, Enemies, and other MovableObjects, just stored as GameObjects. Now, if I get an GameObject out of the List, is there anyway to call collide() on it so that Player.collide() or Enemy.collide() or whatever is called, instead of GameObject.collide()?

Yes. In fact it's a key part of object oriented programming, so it's vital that you understand how this works:

In GameObject, declare your collide() method as virtual. In any subclass where you want to replace or supplement its implementation, declare a method with the same parameters, but marked as override. That way even if you have an object that you've only declared in code to be of type GameObject, when you call collide() it actually resolves using the real type of that instance, and calls the deepest, most overridden version of the method.

For example:

code:

public class GameObject
{
    public virtual void Collide(GameObject otherObject)
    {
       // Some general code to handle collisions goes here
    }
}

public class MovableObject : GameObject
{
    // Note that we have the option of not overriding Collide() here
}

public class Entity : MovableObject
{
    // No override here either
}

public class Player : Entity
{
    public override void Collide(GameObject otherObject)
    {
        // Player-specific collision code goes here -- maybe the player
        // dies if he touches an enemy, etc.  If you want to call the
        // Collide() that's defined on GameObject as well, you can do it from
        // here by calling base.Collide(otherObject)
    }
}

public class Enemy : Entity
{
    public override void Collide(GameObject otherObject)
    {
        // Enemy-specific collision code goes here.  You can also call
        // base.Collide(otherObject) here as well if you want.
    }
}

Then, if you have a collection of GameObjects -- some are Player, some are Enemy, some are maybe of some other class, the following code:

code:

    foreach (GameObject obj in myCollection)
    {
        obj.Collide(collideObject);
    }

will automatically call Player.Collide, Enemy.Collide, or GameObject.Collide; whichever is the one that's most appropriate for each individual object's actual type.

In fact, if GameObject.Collide doesn't really have an implementation of its own, if it must be overridden by subclasses, you can mark it as abstract instead of virtual; and it works the same way -- except you don't have to give it a method body in GameObject, and the compiler enforces that you must supply an implementation for it in a subclass in order to create instances of that subclass. Just note that if a class includes any abstract members, the class itself must be marked abstract as well; and any intermediate subclasses that don't yet provide the implementations for abstract members must also be marked abstract.

# ? Dec 20, 2008 03:54

Mega Shark: Oct 4, 2004

Question for you XNA knowledgeable people. I'm a software engineer in my regular job and I'm looking to start working on another game on my off-time. This time I'd like to use XNA.

I already have Visual Studio 2005 Standard Edition and based on what I found on the XNA website I have to use XNA 2.0. Should this work fine for me or is it important to move to XNA 3.0?

# ? Dec 23, 2008 19:32

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Personally, in my own collision detection code, I have some sort of third party (EntityManager or GameWorld or GameModel or something) resolve all the collisions as it sees fit, and then dispatch an event to the events system for each collision pair. Each part of the program picks up the event so it can do what it needs to do. Example:

Player and Enemy collide

Player gets the collision event. He has a force shield on, so he barrels through the enemy. No change in behavior.

Enemy gets the collision event. Notices that the guy who he is colliding with (the player) has a force shield. Calls the code which subtracts damage/instantly kills itself. If it dies, it dispatches another event which is something like enemy_dies.

AudioManager gets the event. Notices that the player has a force shield on. Plays the "ramming into something with a force shield" sound.

EffectsManager / GameView / whatever gets the event. Notices that the player has a force shield on. Displays particle effects at the collision location that pertain to "ramming into something with a force shield".

etc ...

I've gotten really addicted to trying to keep everything very seperated and decoupled, so in many cases this might be overkill, and it is safe (and easy) to just have one object call all the code and be done with it.

# ? Dec 23, 2008 21:26

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

nihilocrat posted:

I've gotten really addicted to trying to keep everything very seperated and decoupled, so in many cases this might be overkill, and it is safe (and easy) to just have one object call all the code and be done with it.

Given that you now need to define "force shield" code in 4 places, I would say this is the opposite of decoupled. :pwn:

# ? Dec 24, 2008 00:36

MasterSlowPoke: Oct 9, 2005; Our courage will pull us through

ODC posted:

Question for you XNA knowledgeable people. I'm a software engineer in my regular job and I'm looking to start working on another game on my off-time. This time I'd like to use XNA.

I already have Visual Studio 2005 Standard Edition and based on what I found on the XNA website I have to use XNA 2.0. Should this work fine for me or is it important to move to XNA 3.0?

It should work fine as long as you never want to make Zune games, or don't need the new audio system in 3.0. You can always upgrade, too.

# ? Dec 24, 2008 02:40

Mega Shark: Oct 4, 2004

MasterSlowPoke posted:

It should work fine as long as you never want to make Zune games, or don't need the new audio system in 3.0. You can always upgrade, too.

Thanks for the response. I'm not targeting the Zune or needing the new audio system. I'll upgrade in time, but am just looking to get going at the moment with prototyping.

# ? Dec 24, 2008 03:17

Staggy: Mar 20, 2008; Said little bitch, you can't fuck with me if you wanted to
These expensive
These is red bottoms
These is bloody shoes

Avenging Dentist posted:

Given that you now need to define "force shield" code in 4 places, I would say this is the opposite of decoupled.

I'm not being arrogant, but how would you do it differently? I'm genuinely interested as to what sort of structure would work here.

# ? Dec 24, 2008 10:48

newsomnuke: Feb 25, 2007

Staggy posted:

I'm not being arrogant, but how would you do it differently? I'm genuinely interested as to what sort of structure would work here.

Make the force field a proper object, which defines its own collisions, sounds, effects, etc.

# ? Dec 24, 2008 11:06

Shavnir: Apr 5, 2005; A MAN'S DREAM CAN NEVER DIE

Staggy posted:

I'm not being arrogant, but how would you do it differently? I'm genuinely interested as to what sort of structure would work here.

I would dispatch the collisions to a seperate manager object that defines all the behaviors for every type of collision. Its a variety of the drum / drumstick problem, its not easy to solve with OOP.

# ? Dec 24, 2008 20:43

Spite: Jul 27, 2001; Small chance of that...

Contero posted:

Yes I meant RGB.

This is awesome. See, your code doesn't look insane and I can actually see what calls are relevant to the texture mapping. I'll give this a try. Thanks.

You don't need PixelStorei in most cases, and you're probably going to want to use GL_UNSIGNED_BYTE in your TexImage2D.

# ? Dec 25, 2008 04:11

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Spite posted:

You don't need PixelStorei in most cases, and you're probably going to want to use GL_UNSIGNED_BYTE in your TexImage2D.

You should always call PixelStorei regardless if you're going to be uploading RGB textures. I had some stuff mysteriously crashing on my laptop (but never my desktop) and spent hours trying to figure out why before I finally figured out that the texture data wasn't aligned.

# ? Dec 25, 2008 04:14

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

Staggy posted:

I'm not being arrogant, but how would you do it differently? I'm genuinely interested as to what sort of structure would work here.

Basically what ultra-inquisitor said.

Also, there's the whole "data-driven game engines" that game developers hype every couple years. (In other industries, this would just be considered "not being totally stupid".)

# ? Dec 25, 2008 04:31

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Avenging Dentist posted:

Also, there's the whole "data-driven game engines" that game developers hype every couple years. (In other industries, this would just be considered "not being totally stupid".)

I've seen this with stuff like SOF2 and COD4. It works great until you need to make something that doesn't conform well to the preconceived ways that things of that type should work, then it becomes a complete pain in the rear end.

See: Trying to make any weapon that fires something other than bullets or dumb explosive projectiles in SOF2.

# ? Dec 25, 2008 12:56

ValhallaSmith: Aug 16, 2005

ODC posted:

Thanks for the response. I'm not targeting the Zune or needing the new audio system. I'll upgrade in time, but am just looking to get going at the moment with prototyping.

You are far better off with just using c# express 2008 and XNA 3.0. 3.0 also supports C# 3.0, XBOX360 and a few other enhancements. Really, just start with the latest version since any recent community work you might use is going to be on that platform as well.

# ? Dec 25, 2008 19:05

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

OneEightHundred posted:

I've seen this with stuff like SOF2 and COD4. It works great until you need to make something that doesn't conform well to the preconceived ways that things of that type should work, then it becomes a complete pain in the rear end.

It's about a hundred times harder using a non-data-driven system.

# ? Dec 27, 2008 01:05

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Avenging Dentist posted:

It's about a hundred times harder using a non-data-driven system.

Not really, just provide tools to streamline common behaviors but allow them to be overrided with actual CODE. Unreal is a nice example of this in action.

# ? Dec 27, 2008 01:49

digibawb: Dec 15, 2004; got moo?

And have designers come to you to change a weapon's damage because they can't do it themselves? I remember the days of that, and I don't want to go back to them.

(I'm not entirely sure that *is* what you are suggesting, but that's part of what I'd consider "data-driven")

EDIT: I'm a little unclear on how what SoF2 had made it worse than previous games that didn't let you define anything outside of the code itself (Referring to Quake3 in this case, the engine on which it was based).

VVVVV I think we may be talking about different things, could you go into more details about the SoF2/CoD4 issues?

digibawb fucked around with this message at 02:46 on Dec 27, 2008

# ? Dec 27, 2008 02:03

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

digibawb posted:

And have designers come to you to change a weapon's damage because they can't do it themselves? I remember the days of that, and I don't want to go back to them.

(I'm not entirely sure that *is* what you are suggesting, but that's part of what I'd consider "data-driven")

This isn't being data-driven as much as not being an idiot and hard-coding things. Unreal provides access to the defaultproperties blocks within the UnrealEd GUI. For anything else, you put various numeric values in a single location so they can be edited if needed.

# ? Dec 27, 2008 02:35

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

I think you're conflating hard-coding and data-driven models. A good data-driven model will let you extend things however you like (within reason). The real issue is when the data-driven model doesn't let you extend the various data types that represent objects in the game world. That's an issue with hard-coding.

# ? Dec 27, 2008 08:26

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Avenging Dentist posted:

I think you're conflating hard-coding and data-driven models. A good data-driven model will let you extend things however you like (within reason). The real issue is when the data-driven model doesn't let you extend the various data types that represent objects in the game world. That's an issue with hard-coding.

It's easy to clearly define data within source code, it's not easy to define behavior within data. Take something like the weapons in Unreal Tournament for example and there's something I would definitely not want to do with a data-driven system, because each has fairly unique behavior that can't just recycle the same mechanics over and over the way you can with a realism shooter, for example.

# ? Dec 27, 2008 11:41

brian: Sep 11, 2001; I obtained this title through beard tax.

I'm really confused by what you guys are defining as data-driven and hardcoded, I mean all behaviour is more or less hardcoded but that doesn't stop it being data driven if it relies heavily on easily definable data. Do you mean having like one generic weapon class that you choose which behaviour it has through the data you supply it? Like a machine gun is the same as a rocket launcher but with different projectile behaviour? It just doesn't seem like anyone has defined what they mean when they say data-driven.

# ? Dec 27, 2008 16:10

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

brian posted:

I'm really confused by what you guys are defining as data-driven and hardcoded, I mean all behaviour is more or less hardcoded but that doesn't stop it being data driven if it relies heavily on easily definable data. Do you mean having like one generic weapon class that you choose which behaviour it has through the data you supply it? Like a machine gun is the same as a rocket launcher but with different projectile behaviour? It just doesn't seem like anyone has defined what they mean when they say data-driven.

I think part of the issue is that an idea like "data-driven" has two meanings. There's the meaning in theory, and there's the meaning in practice.

In theory, it means that the game engine is mostly static (the code itself doesn't change) and it pulls meaningful, game-effecting "data" in to characterize the behaviors in the game. When I think of something like "data-driven", I think of Red Alert 2. In that game, virtually every "value" that mattered was in an INI file. If you wanted to "mod" the game, you wouldn't write code, you'd make a new INI file. (And any Red Alert will use that new INI without "recompiling".)

Data-driven doesn't have an "opposite", and if it did, it might not be "hardcoded". The idea with "hardcoded" would be that all of the behaviors are compiled in with the engine. An example of this would be Quake 3. If you'd like to change the speed of the rockets, you go fine the appropriate variable declaration in the code and you recompile it. (When you mod Quake 3, the engine will load the compiled code from your mod *instead* of the code that came with the game. So you didn't need to recompile *everything*, but you still recompiled.)

A third option that kind of straddles that line would be games that have scripting engine interfaces, like Unreal Tournament. In an attempt to get the best of both worlds (an, in some ways, it does), your "configuration" for the game can also include programming. That is to say, that if you wanted to modify Unreal, you would load a data file that includes Unreal Script, write whatever *code* you want, which is loaded by the engine and executed in a sandboxed environment. You still don't actually recompile anything, but the engine isn't exactly static or "hardcoded" either. (I *think* that Unreal tech is still considered "data driven", because the Unreal Script is considered "data" and not part of the engine. I think it's more like something in between, but I know more about these things in theory than in practice.)

Maybe that explanation helps?

# ? Dec 27, 2008 18:37

krysmopompas: Jan 17, 2004; hi

Data is code. lisp lol

It's really quite irrelevant if you hardcode it or if you have some crazily over-engineered data system - iteration times and the suitability of the editing method to your audience matters. If you've got 15 programmers and 5 artists, then you're better off hand-coding shaders; if you've got 5 programmers and 15 artists, then you're better off making some kind of fancy schmancy DAG editor thing.

# ? Dec 27, 2008 21:14

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

tbradshaw posted:

A third option that kind of straddles that line would be games that have scripting engine interfaces, like Unreal Tournament. In an attempt to get the best of both worlds (an, in some ways, it does), your "configuration" for the game can also include programming. That is to say, that if you wanted to modify Unreal, you would load a data file that includes Unreal Script, write whatever *code* you want, which is loaded by the engine and executed in a sandboxed environment. You still don't actually recompile anything, but the engine isn't exactly static or "hardcoded" either. (I *think* that Unreal tech is still considered "data driven", because the Unreal Script is considered "data" and not part of the engine. I think it's more like something in between, but I know more about these things in theory than in practice.)

In Unreal, classes have a "defaultproperties" block which is editable within the GUI, and is not visible in the code editor unless you export the UnrealScript files, which makes it kind of a midpoint. I don't see this as particularly different of an approach from just lumping everything in a header for example, as long as the deployment is straightforward.

As an example of purely data-driven, I looked into modding SOF2 at one point and it turned out everything about a weapon is contained in the model file: How many shots it fires at once, rate of fire, burst size, magazine size, hitscan or projectile, contact explosive or fuse, blast radius, damage, etc.

Obviously this works great in a game where everything fits into that mold, and works like poo poo if you want gadgets and exotic weapons and other such things. COD4 follows a similar model but throws everything in CSV files instead (and I'm not exactly sure how they handle special cases like C4, claymores, and the javelin).

The opposite would be just throwing values where relevant into the gamecode (hard-coding), which you can see in, for example, Quake:

Rocket hits something?

T_RadiusDamage (self, self.owner, 120, other);

# ? Dec 27, 2008 23:20

Mithaldu: Sep 25, 2007; Let's cuddle.

OneEightHundred posted:

As an example of purely data-driven, I looked into modding SOF2 at one point and it turned out everything about a weapon is contained in the model file: How many shots it fires at once, rate of fire, burst size, magazine size, hitscan or projectile, contact explosive or fuse, blast radius, damage, etc.

That's not purely data-driven in my opinion. That seems to be in the hell between hard-coded and data-driven. If it was completely data-driven, the damage model itself would be definable outside the code and only brought ingame at load-time.

# ? Dec 28, 2008 00:25

ehnus: Apr 16, 2003; Now you're thinking with portals!

Mithaldu posted:

That's not purely data-driven in my opinion. That seems to be in the hell between hard-coded and data-driven. If it was completely data-driven, the damage model itself would be definable outside the code and only brought ingame at load-time.

I think what you're looking for is called a scripting language.

Call me cynical but whenever I hear someone propose a data driven solution for a problem in video games I get the feeling that it will end up being fragile, bloated, slow, poorly designed, not willingly supported by developers, and not willingly used by artists/designers.

# ? Dec 28, 2008 02:13

Mithaldu: Sep 25, 2007; Let's cuddle.

ehnus posted:

I think what you're looking for is called a scripting language.

That's one way to do it, yeah. I was talking in a more general way though.

Although personally i do agree, since one of the greatest games ever (Tribes) was completely scriptable and also resulted in the strongest modding community i have ever seen.

# ? Dec 28, 2008 02:30

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

ehnus posted:

I think what you're looking for is called a scripting language.

Call me cynical but whenever I hear someone propose a data driven solution for a problem in video games I get the feeling that it will end up being fragile, bloated, slow, poorly designed, not willingly supported by developers, and not willingly used by artists/designers.

A good scripting language (and API/framework) is a good example of a data-driven model. Data-driven programming isn't just "using INI/XML/etc files", it's considerably more involved.

This page has a pretty good summary: http://www.catb.org/esr/writings/taoup/html/ch09s01.html

# ? Dec 28, 2008 03:05

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

ehnus posted:

I think what you're looking for is called a scripting language.

Call me cynical but whenever I hear someone propose a data driven solution for a problem in video games I get the feeling that it will end up being fragile, bloated, slow, poorly designed, not willingly supported by developers, and not willingly used by artists/designers.

Either you use a data-driven system (which is a stupid way of phrasing it, really - wouldn't we be better off calling it a "script-driven system," since even hard-coded systems these days are never going to be as hard-hard-coded as the bad old days of Doom and Quake?) which artists/designers don't end up using right, or you have a more hard-coded system and your developers spend 80% of their time doing stupid bullshit that the artists/developers should have been able to do themselves / hate having to bother you about every time. Damned if you do, damned if you don't.

Frankly, I'd rather at least try for script-driven, even if they use it wrong - because at least then they (design) can TRY to do something before standing en mass behind my desk with desperate looks on their faces. I'm not sure anyone would consider a non-script system even remotely acceptable these days for precisely this reason, there's just too much other important code work for your core staff to be toodling around with making spaghetti code out of the thousands of different cases of this or that interaction.

(besides, eventually they get used to it - and I'd like to think more and more designers/tech-artists are up on using script - and then everyone, designers and programmers alike, is hugely more efficient with their time)

# ? Dec 28, 2008 05:38

Krenzo: Nov 10, 2004

OneEightHundred posted:

As far as physics synchronization goes, it is critical to do in properly in some games, especially those with VEHICLES, and there are ways to do it. BF2 does it by using delayed synchronous player movement, Unreal does it by running two simulations and using some hacky stuff to kick players out of vehicles when they get run over.

Are there any presentations or official info how BF2 and Unreal 3 handle vehicles and physics? I've only dealt with Half-Life 2, and they didn't even bother trying to implement client-side prediction for vehicles. HL2's vehicles only run on the server, and you end up with laggy vehicle controls when driving one. If you try to implement client-side prediction, then you find out that the client physics don't really match up with the server physics even when running your own listen server. BF2 and Unreal 3 on the other hand have vehicles that perform very well with no sense of lagging vehicle controls, and I wonder if it's just that one has to plan ahead of time for client-side prediction of vehicle physics.

# ? Dec 30, 2008 22:17

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Krenzo posted:

Are there any presentations or official info how BF2 and Unreal 3 handle vehicles and physics?

BF2 appears to use delayed synchronous player movement: The client simulates movement at the same rate as the server and the server handles that movement several frames later. It's consistent and fairly straightforward, but causes large reaction delays on everything which can get really annoying.

Unreal 3, don't know. Unreal 2 uses asynchronous player movement (where player movement is handled separately from the rest of the world and updates occur immediately, which is much more responsive) and runs a separate physics simulation for it. Objects either collide with vehicles, or don't. Players, for example, do not collide with vehicles, and if they wind up inside the vehicle hull then it attempts to kick them out and potentially deal damage to them.

HL2 runs a single simulation with asynchronous player movement, which is incompatible with both methods. There have been attempts at converting it to the latter system, with moderate success.

# ? Dec 31, 2008 00:59

jamal jenkins: Dec 18, 2007; by The Finn

I've been working on a game in Python for a while now, and it's about time to take a serious attempt at the GUI. Search is down and I don't feel like sifting through 10 pages for something, but I've been looking at Pygame and I think it will work. Any links for all things Python GUI or Pygame related that you think might help?

# ? Jan 4, 2009 08:04

Adbot: ADBOT LOVES YOU

# ? Apr 27, 2024 13:01

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

jamal jenkins posted:

I've been working on a game in Python for a while now, and it's about time to take a serious attempt at the GUI. Search is down and I don't feel like sifting through 10 pages for something, but I've been looking at Pygame and I think it will work. Any links for all things Python GUI or Pygame related that you think might help?

Consider pyglet.

# ? Jan 4, 2009 13:43

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›620 »