|
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 |
|
|
# ? May 13, 2024 09:52 |
|
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:
|
# ? Dec 18, 2008 00:49 |
|
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 |
|
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 |
|
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 |
|
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: Are you using the override keyword in the declaration of collide() in the derived classes?
|
# ? Dec 18, 2008 02:50 |
|
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
|
# ? Dec 18, 2008 02:52 |
|
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#): 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:
code:
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 |
|
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 |
|
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 |
|
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.
|
# ? Dec 24, 2008 00:36 |
|
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. 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 |
|
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 |
|
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 |
|
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.
|
# ? Dec 24, 2008 11:06 |
|
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 |
|
Contero posted:Yes I meant RGB. 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 |
|
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.
|
# ? Dec 25, 2008 04:14 |
|
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 |
|
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".) See: Trying to make any weapon that fires something other than bullets or dumb explosive projectiles in SOF2.
|
# ? Dec 25, 2008 12:56 |
|
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 |
|
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 |
|
Avenging Dentist posted:It's about a hundred times harder using a non-data-driven system.
|
# ? Dec 27, 2008 01:49 |
|
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 |
|
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.
|
# ? Dec 27, 2008 02:35 |
|
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 |
|
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.
|
# ? Dec 27, 2008 11:41 |
|
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 |
|
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 |
|
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 |
|
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.) 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 |
|
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.
|
# ? Dec 28, 2008 00:25 |
|
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 |
|
ehnus posted:I think what you're looking for is called a scripting language. 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 |
|
ehnus posted:I think what you're looking for is called a scripting language. 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 |
|
ehnus posted:I think what you're looking for is called a scripting language. 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 |
|
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 |
|
Krenzo posted:Are there any presentations or official info how BF2 and Unreal 3 handle vehicles and physics? 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 |
|
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 |
|
|
# ? May 13, 2024 09:52 |
|
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 |