|
Can't wait for the next GameDev, my entry last year is still the only game I've ever actually finished in Python and I will be certain to get in on it again this year. Oddly enough I just checked the thread to get some quick feedback on a sequel I'm working on for my GameDev entry from last year! The original went for an MS-DOS looking style whereas this one is going to be Windows 3.1. Anyways my issue is that I'm going to have 10 different colors of buildings (giving them all unique graphics would probably help), and then up to 9 districts which will draw a border around them. Finding colors that all stand out is of course a nightmare, and having a colorblind friend who always complains about these sorts of things (rightly so) I want to be drat sure that anybody can play it. The first thing I'm doing is making it so the currently active district is white, while the other districts are all different colors. So right now I've got things looking like this.  I know right now the light gray district blends in too well with the white. Right now I also have a light transparent tint but I'm not sure if it's too much or too little. I want players to be able to easily "read" a building even when it's in a district. Also that map is randomly generated while the actual levels won't be, so it's more chaotic than a normal level would most likely look.
|
#
?
May 6, 2012 19:10
|
|
|
|
| # ? May 11, 2024 12:54 |
|
|
Just found this thread. I'm currently a year into on and off working on games - started off with AS3 (really, I came to this with pretty much zero programming experience), trying to do the flash sponsorship thing to get both experience and make some money while doing it. Working almost entirely with the Flixel library, though I checked out Flashpunk a bit. First game was Electrikill, kind of a real standard side-shooter and my first ever code project, and it shows. (Biggest mistake: Using the FlxSave system exclusively, so anyone who played the game with cookies disabled couldn't get past level one. Oops.) I've got another game done since then, no sponsors yet, and am now onto the third. I'm wondering a few things, if anyone cares to give advice. * Is it at all common for people to develop standalone games (as in something you'd sell directly, rather than go to a place like Kongregate to play) in AS3? I'm getting the impression it's entirely possible, but it may be a terrible choice as far as performance goes and that people would usually pick another language if possible. * Other than flash sponsorships, what's a good route for a small indie dev? I know about the obvious choices with Android and App Store development, but what about places like the Chrome store? Or are there better alternatives?
|
|
#
?
May 6, 2012 19:26
|
|
|
VictorGrunn posted:* Is it at all common for people to develop standalone games (as in something you'd sell directly, rather than go to a place like Kongregate to play) in AS3? I'm getting the impression it's entirely possible, but it may be a terrible choice as far as performance goes and that people would usually pick another language if possible. There are some notable games developed in AS3. The first version of VVVVVV was Flash (he rewrote it in C++ for version 2). Windosill was written in Flash as well. It's a bit uncommon, though, as Adobe is really trying to downplay the whole standalone Flash thing, and either try to get people to use AIR for desktop and mobile apps. Note that Flash is still a useful skill to have for any major game developer, as a lot of games use Scaleform for their UI, which is built around Flash.
|
|
#
?
May 6, 2012 19:52
|
|
|
Dr. Dos: You've done a good job so far emulating the Windows 3.1 chrome and widgets. Is it at all possible in PyGame to create a window without UI decorations so that you don't have two titlebars, etc? It would really complete the effect. If you explain what your game is about we might be able to provide more useful suggestions for creating visual contrast in the playfield.
|
|
#
?
May 6, 2012 19:58
|
|
|
Dr. Dos posted:One small suggestion: you might want to consider increasing the padding around each building so your district boxes don't cut off their rooftops and sides. Also, have you considered only drawing lines around the edge of a district rather than around every building in it? Your tint would make more sense in that case and you'd reduce the amount of visual noise quite a bit. That might help since it sounds like your gameplay depends on the color of the buildings. Other than that I'm loving your Windows 3.1 style. 
Paradoxish fucked around with this message at 20:11 on May 6, 2012 |
|
#
?
May 6, 2012 20:08
|
|
|
Dr. Dos posted:I know right now the light gray district blends in too well with the white. Right now I also have a light transparent tint but I'm not sure if it's too much or too little. I want players to be able to easily "read" a building even when it's in a district. Also that map is randomly generated while the actual levels won't be, so it's more chaotic than a normal level would most likely look. What about coloring in each tile completely with the district color, and then drawing the buildings on top of that? Just make sure each building type has a unique silhouette and transparency around the outlines and in any windows. Basically this is the TF2 style of Color->Team and Silhouette->Class which reads pretty well and would be less visually noisy than stacks of outlined boxes.
|
|
#
?
May 6, 2012 20:11
|
|
|
Paniolo posted:I'm far from an XNA expert, but it seems like you're intended to have one Game instance per application. Can you explain why you would want more? How do I get the second game object to do its rendering without ruining its encapsulation?
|
|
#
?
May 6, 2012 21:09
|
|
|
Paniolo posted:That isn't much better. You should not have any "umbrella" class containing a lot of junk. Yeah I'm not sure why but OOP has not clicked for me yet. I just can't think of ways to make things workand also be encapsulated. How would you address the problem I described earlier? An object needing to be drawn at it's x and y coordinates. Would you have the draw method within the object instead of in a dedicated graphics class? "Internet Janitor posted:
|
|
#
?
May 6, 2012 23:12
|
|
|
kaempfer0080 posted:Yeah I'm not sure why but OOP has not clicked for me yet. I just can't think of ways to make things workand also be encapsulated. How would you address the problem I described earlier? An object needing to be drawn at it's x and y coordinates. Would you have the draw method within the object instead of in a dedicated graphics class? A lot of people that used to like that now say this is a bad idea, as it leads to large inheritance trees and general inflexibility in a single-inheritance environment. I can't speak for most people here, but a lot of game frameworks/engines now advertise a composition/-based architecture. That is, you have an object that delegates out to something to draw itself. You delegate out to handle behaviors (so it acts like a shield). You delegate out to something that implements a specific physics policy (it's a cube, or a capsule, or a sphere).
|
|
#
?
May 6, 2012 23:20
|
|
|
kaempfer0080 posted:Would you have the draw method within the object instead of in a dedicated graphics class? I think the method that's more likely to be recommended here is more component-based, wherein rather than putting 'draw' methods into every class whose objects get drawn, you instead put 'draw' components into every object that gets drawn. That's the method employed by Unity, where an object is just a container for objects and components, and essentially everything that does anything is a component of some sort. I'm not entirely sure why this method is thought to be better, but it sure does make using Unity pretty easy! It seems like either way you'd still end up wanting a global-like list of all 'draw' components that the graphics call is going to be interacting with, so I don't see that it makes a lot of difference in terms of results. The alternative to having a graphics call that munches through all the objects' draw functions, is having 'draw' stuff that get called during the object's own behavior, and that draw call shovels data into a global-ish structure of some sort that the main graphics call deals with later. That way is more flexible in terms of optimizing, draw ordering, applying shaders etc. and sometimes simpler to use (eg. you can have an object dump out some debug info onto the screen even though you're not in a dedicated drawing function at the time), but also significantly more complicated to implement and I would say not even nearly worth it for a beginner project.
|
|
#
?
May 6, 2012 23:27
|
|
|
kaempfer0080 posted:That's awesome, going to have a look at your source to see if it can unfuck my brain. Let me know what you think. It may be a little intimidating if you aren't familiar with any stack-oriented languages, but at the very least it's one example of an aggressively non-OO way of coding the game.
|
|
#
?
May 6, 2012 23:33
|
|
|
Suspicious Dish posted:There are some notable games developed in AS3. The first version of VVVVVV was Flash (he rewrote it in C++ for version 2). Windosill was written in Flash as well. It's a bit uncommon, though, as Adobe is really trying to downplay the whole standalone Flash thing, and either try to get people to use AIR for desktop and mobile apps. Thanks. I'm not sure what Scaleform is, but I'll look it up. I wasn't aware of VVVVVV or Windosill using it. Even AIR and flex are things I'm only vaguely familiar with. I've also heard of something called Haxe for these projects, and have seen some interesting games making use of that. Ah well, lots for me to learn, that's all. I'll keep at the flash/as3, and see what other languages I can pick up while I do it.
|
|
#
?
May 7, 2012 00:05
|
|
|
roomforthetuna posted:I think the method that's more likely to be recommended here is more component-based, wherein rather than putting 'draw' methods into every class whose objects get drawn, you instead put 'draw' components into every object that gets drawn. That's the method employed by Unity, where an object is just a container for objects and components, and essentially everything that does anything is a component of some sort. I'm not entirely sure why this method is thought to be better, but it sure does make using Unity pretty easy! It's not that this is bad advice, but this is like going to a learning to swim class and talking about the right blutterfly technique. I frequent a few gamedev forums and it's amazing how many people are constantly asking about designing entity-component systems when they don't really understand basic OOP. Hard to learn the butterfly before you've mastered treading water. Entity component systems aren't even appropriate for all game types. If it can be made reasonably shallow, an inheritance tree often is the simpler and more robust choice. For simple projects this is almost always the case. kaempfer0080 posted:Yeah I'm not sure why but OOP has not clicked for me yet. I just can't think of ways to make things workand also be encapsulated. How would you address the problem I described earlier? An object needing to be drawn at it's x and y coordinates. Would you have the draw method within the object instead of in a dedicated graphics class? Yes. You'll still likely have a graphics class, if only to encapsulate the underlying API you're using, but it should be limited to low level primitives such as DrawSprite, and be completely agnostic as to the semantics of what it's drawing. (I.e., it should not know or care if the sprite is for an enemy or a UI widget.) Then, in your game object class, you define a Draw method, which does the actual drawing (using the primitive methods provided by the graphics class, so it doesn't need to interface directly with the low level API.) This eliminates the data hiding issues you were running into, because the game object has all of the information it needs in order to draw itself. Finally, whatever class you have that manages all of the game objects in the scene would also have a Draw method. All it would do is loop through all of the game objects and call their own Draw method. This is an appropriate design for virtually all beginner level games. At an advanced level, it's a good idea to separate out the drawing code from the game logic code, so they aren't in the same class. This is helpful when you have a large variety of game object types, or when you are using a data driven approach (for example, defining the characteristics of your game objects in XML files which you load at run time.) It's massive overkill for a simple project.
|
|
#
?
May 7, 2012 00:37
|
|
|
Can anyone suggest some good blogs/tutorials/open source projects to learn SlimDX from? I've messed with it a bit in the past, and while the SlimDX libraries are pretty good their documentation is beyond terrible. Everything always devolves into looking at the DirectX SDK and trying to translate the C++ into SlimDX language without ever really knowing if you got it 100% right since there's sometimes not a 1:1 correspondence. It takes 10X longer to do things that it would if there was even a sliver of documentation or example code.
|
|
#
?
May 7, 2012 01:12
|
|
|
Internet Janitor posted:Let me know what you think. It may be a little intimidating if you aren't familiar with any stack-oriented languages, but at the very least it's one example of an aggressively non-OO way of coding the game. Very interesting to see and unlike any language I've used before. I liked how the shield was implemented, being able to draw a binary representation of it was much simpler than how I went about doing it. Paniolo posted:Thanks, I might re-do my project for practice, and if not apply it to my next idea. I think I got stuck in a rut with the way I was thinking, since I worked on the project a little over a month and didn't have a Game class at all until more than half way in. Need to plan better in the future.
|
|
#
?
May 7, 2012 02:48
|
|
|
Paniolo posted:Entity component systems aren't even appropriate for all game types. If it can be made reasonably shallow, an inheritance tree often is the simpler and more robust choice. For simple projects this is almost always the case. A nice illustration I like to use is Quake 3. Quake 3 only actually has 5 classes of object: Players, movable map geometry, events, projectiles, and items. Paniolo posted:This is an appropriate design for virtually all beginner level games. At an advanced level, it's a good idea to separate out the drawing code from the game logic code, so they aren't in the same class. This is helpful when you have a large variety of game object types, or when you are using a data driven approach (for example, defining the characteristics of your game objects in XML files which you load at run time.) It's massive overkill for a simple project. This has problems with even VERY simple draw behavior. As an example, there's a part in the Zelda: Link's Awakening where you rescue a Chain Chomp. Now, one thing about the Chain Chomp is that the chain is always behind both Link AND the Chain Chomp. Think about how you would implement this if the Chain Chomp had its own Draw function though. How can you enforce that draw order? The Link object has no idea how chains are drawn. If you use separate draw primitives, then this would be a non-issue because your draw code could just bucket the objects by layer and draw the chain out of order. Using draw primitives lets your draw code conceptualize the entire scene and make smart decisions easily and doesn't bury information about how your scene is draw in the implementation specifics. Please do it. Don't put a Draw method on your game objects.
OneEightHundred fucked around with this message at 02:56 on May 7, 2012 |
|
#
?
May 7, 2012 02:53
|
|
|
kaempfer0080 posted:I liked how the shield was implemented, being able to draw a binary representation of it was much simpler than how I went about doing it. Every time there is repetitive structure to something you're doing, generate that structure in code. Some languages allow you to factor out patterns in very powerful ways that extend the syntax of the language- Lisps tend to have macro systems that transform source ASTs, while Forth and Factor let you hijack the compiler completely and patch in new functionality. (like this DSL that allows inline FORTRAN.) If there is a large amount of irregularity, try to restructure the problem until you can pull it out into lookup tables. Apply this principle recursively.
|
|
#
?
May 7, 2012 03:04
|
|
|
OneEightHundred posted:This has problems with even VERY simple draw behavior. As an example, there's a part in the Zelda: Link's Awakening where you rescue a Chain Chomp. Now, one thing about the Chain Chomp is that the chain is always behind both Link AND the Chain Chomp. Not that this is the "correct" or even a good way to do it, but there's certainly nothing stopping you from implementing a layering system while having game objects draw themselves. A simple way to do it would be to pass in a layer index to your draw function so that you can draw the chain on layer n and the head on layer n + 1. Or you could just have the chain and the head be separate entities.
|
|
#
?
May 7, 2012 03:09
|
|
|
Internet Janitor posted:Every time there is repetitive structure to something you're doing, generate that structure in code. Some languages allow you to factor out patterns in very powerful ways that extend the syntax of the language- Lisps tend to have macro systems that transform source ASTs, while Forth and Factor let you hijack the compiler completely and patch in new functionality. (like this DSL that allows inline FORTRAN.) If there is a large amount of irregularity, try to restructure the problem until you can pull it out into lookup tables. Apply this principle recursively. My original idea was to read the shield in from a file in a binary layout like yours. That way the shield file could be edited at will, or other files generated and changed in the code. For some reason I just went with a loop that creates each shield chunk 1 at a time.
|
|
#
?
May 7, 2012 03:10
|
|
|
OneEightHundred posted:Think about how you would implement this if the Chain Chomp had its own Draw function though. How can you enforce that draw order? By making the ball and chain separate objects. Or using a buffered drawing pipeline that allows you to specify a z order for each draw call. Also, the great thing about having someone do the simplest possible thing that works is that eventually they'll run into situations where it doesn't work, and then they'll understand why more complex architectures are useful. If they're bright eventually they'll stumble on design patterns themselves, or at least have enough knowledge that when they read about the pattern they'll immediately understand how it's applicable to the problem domain. The world needs fewer cargo cult programmers.
|
|
#
?
May 7, 2012 03:43
|
|
|
Gordon Cole posted:Not that this is the "correct" or even a good way to do it, but there's certainly nothing stopping you from implementing a layering system while having game objects draw themselves. A simple way to do it would be to pass in a layer index to your draw function so that you can draw the chain on layer n and the head on layer n + 1. Or you could just have the chain and the head be separate entities. Really, the "not knowing what order to draw things in" problem is only introduced by becoming quite object-oriented, and then can be fixed by becoming more object-oriented. If you didn't have the situation where things "don't know" about other things then the problem doesn't exist in the first place. Not arguing against separation of things, I do agree that it's a cleaner design, but for relatively simple beginner projects it still feels like massive over-complicated overkill that will likely stop you from actually making a game.
|
|
#
?
May 7, 2012 03:44
|
|
|
Gordon Cole posted:Not that this is the "correct" or even a good way to do it, but there's certainly nothing stopping you from implementing a layering system while having game objects draw themselves. A simple way to do it would be to pass in a layer index to your draw function so that you can draw the chain on layer n and the head on layer n + 1. Or you could just have the chain and the head be separate entities.
|
|
#
?
May 7, 2012 04:07
|
|
|
Does anyone have any tips on how to make something similar to this in Unity3d programmatically? I'm trying to dream up a way make the wave bits on the laser animate/pulse/change color and animate in sine wave fashion without relying on texture animations. My first instinct was to maybe use a segmented LineRenderer or build a Mesh, but I'm curious if there might be a better way. Edit: Seems this might do the trick - http://starscenesoftware.com/vectrosity.html Edit2: The above is exactly what I wanted. Here's a shot of 3 sine waves with different parameters governing them. Looks better animated, and is a work in progress of course. 
Azazel fucked around with this message at 13:44 on May 7, 2012 |
|
#
?
May 7, 2012 07:01
|
|
|
Finally had some time do work on a project again. I decided to mess around with Construct 2. As a programmer I should probably be coding in an actual language, but I just really like working with Construct. (And HTML5 support owns) I've been trying to use 2D physics to replace some animations, potentially saving a lot of work. This way most equipment, for example, can just 'float' on the character and all use the same physic reactions. But right now I've only got a simple slash, and that took a while. God knows how the hell I'm gonna manage to do a full combo system. Check out what I've got so far here. (you can ignore the art assets)
|
|
#
?
May 7, 2012 15:44
|
|
|
I don't understand why one would regard composition as being less OOP. There are sure going to be a ton of objects running around by the end of things, and they communicate with each other across prescribed boundaries. Arguably it's more like OOP than the traditional tree of inherited stuff. It's more in line with the Gang of Four's idea of design, and follows the convention that inheritance is a kind of polymorphism, and polymorphism is actually the king. From awhile back I was sometimes asking here in the thread about this stuff. My medium for practicing this stuff was writing my own game at a much lower level. That is, I wanted to play with lower-level stuff than necessarily write the game. I'm trying to learn new skills. Since that time I've learned a lot more about composition and see where I should apply it in my day job. Beyond that I've learned a lot about asynchronous programming by going overboard with it in my little engine project. So it still holds true that if you want to write a game, don't write a game engine. If you want to write a game engine, then write a game engine. But perhaps consider writing a game first.
|
|
#
?
May 7, 2012 18:36
|
|
|
Rocko Bonaparte posted:So it still holds true that if you want to write a game, don't write a game engine. If you want to write a game engine, then write a game engine. But perhaps consider writing a game first. I would say "Write exactly the game engine you need, not the game engine you might want later." The most dangerous habit that seems to come out of teaching OO early on is a desire to generalize everything and "reuse" your code later.
|
|
#
?
May 7, 2012 20:05
|
|
|
Even more succinct advice: write games, not engines. A "game engine" is more a marketing term than anything else: even the most common game engines (Source Engine, for example) don't host multiple games (TF2's Source Engine is not the same as Portal 2's Source Engine). The best thing I can tell you is to write a game, and finish it. Code cleanliness is only there to help you ease development - the end user doesn't care how clean the code is, only that the game works properly and doesn't bug out. It doesn't matter if it's all a jumbled mess by the time you complete it: a lot of games have a lot of hacks near the end because they had some leftover bugs and didn't want to come up with a proper solution. The important thing is now you've got the experience of finishing a playable game to the end (a giant feat in and of itself), and that you can figure out what parts of your codebase you should build into a library of things you can reuse later. Maybe you really like your drawing subsystem, or your physics subsystem. Maybe you think that your homegrown audio tracker is really neat, and you should improve and keep it for your next project.
|
|
#
?
May 7, 2012 20:50
|
|
|
Has anyone here done much with online multiplayer games? I'm working on a platformer and I'm trying to figure out if I'm doing this stuff right or if there is a better way to do it. So far what I have is based on this page. I have the client send key presses to the server (left, right, jump, etc) and then the server sends the key presses out to all the other clients, and when the clients receive them, they move around a local dummy character based on the key presses. Because of lag, the dummy players end up drifting from the correct positions based purely on the broadcasted input, so I have the clients send regular, frequent updates to the server with their current position, and the server broadcasts those positions to the other clients and I move the dummy characters 10% of the way to the position sent by the server to account for the differences due to lag and junk, and over time the 10% moves accumulate and (relatively) smoothly correct for the difference in position. It seems to work decently enough, but there is still a bit of jerkiness to it and of course its totally unsecure as the clients could just send whatever position, but according to the page I linked earlier, authoritative server/client side prediction stuff doesn't work very well for a game with dynamic stuff going on like explosions without a lot of rubberbanding. I'm primarily developing the game as a co-op game for a few people at a time, so if the choice is between smoother gameplay or more secure I'd rather have smoother gameplay with some sanity checks, but if anyone knows of a better way to go about this or knows of any good resources for this sort of thing I'd love it if you could point me in the right direction.
|
|
#
?
May 8, 2012 04:21
|
|
|
Paniolo posted:At an advanced level, it's a good idea to separate out the drawing code from the game logic code, so they aren't in the same class. This is helpful when you have a large variety of game object types, or when you are using a data driven approach (for example, defining the characteristics of your game objects in XML files which you load at run time.) Is there anywhere I can read about this or see an example of it done? How would animation factor into this? Would the objects still store the image resource their using and just have it be drawn elsewhere?
|
|
#
?
May 8, 2012 21:12
|
|
|
I would infer that whatever draws an actor could do the drawing based on its state, ie jumping & running, and how long it has been in that state / speed, etc. If the actor requires complex animation that needs to know its previous frames, state, then you make an object for the actor's representation that only handles drawing and drawing related attributes. I'm just spitballing here but this is probably how I'd approach separation to start off with.
|
|
#
?
May 9, 2012 01:05
|
|
|
Lucid Dream posted:Has anyone here done much with online multiplayer games? I'm working on a platformer and I'm trying to figure out if I'm doing this stuff right or if there is a better way to do it. Prediction correction doesn't usually "drift," you can construct a new prediction by taking the most recent confirmed state (which is in the past) and replaying all inputs since then.
|
|
#
?
May 9, 2012 01:18
|
|
|
Lucid Dream posted:Has anyone here done much with online multiplayer games? I'm working on a platformer and I'm trying to figure out if I'm doing this stuff right or if there is a better way to do it. Multiplayer game networking is essentially still black magic, in terms of learning it. You're relegated to digging through powerpoints and websites like Gaffers (which is a great resource). The real answer is that for arcadey network gaming, you pretty much can't send keypresses and wait for a response from the server to move a player, you're always going to feel laggy. For some games (RTS) this round-trip is fine, and you can smooth the laggyness by simulating the units turning towards their facing client side, and waiting for actual movement from the server. [e: FYI, this is not a limitation of the technology. You could wait one million years and you're still going to need client side prediction, since round-trip latency from asia to the US is >70ms even at the speed of light] For any real action game where a player has arcady control over their character, you're going to instead need to simulate the player directly on the client and send position updates to the server. i.e. you need to let the client 'own' the player's position, to some extent. One thing I found surprising was how little you can send per frame, even on pretty beefy modern broadband. You're basically limited to a few object state updates per frame (even at 20-30fps), so you end up having to prioritize which objects are the most out of date on each client, per frame. Then you need to be very careful about choosing and packing state. This is a whole magic art that has whole programming teams dedicated to it on big AAA games. Here's some assorted reading, some of which you've already found: http://gafferongames.com/ http://blog.wolfire.com/2011/03/GDC-Session-Summary-Halo-networking http://udn.epicgames.com/Three/NetworkingOverview.html#Player%20Movement%20and%20Prediction http://halo.bungie.org/misc/gdc2005_recreating_lanparty/ http://www.insomniacgames.com/category/research-development/ http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/ A nice networking library, even if for reference if you're rolling your own: http://code.google.com/p/lidgren-network-gen3/ Unormal fucked around with this message at 01:49 on May 9, 2012 |
|
#
?
May 9, 2012 01:47
|
|
|
OneEightHundred posted:Why are you sending keypresses from the server? Why not just update the position directly? Unormal posted:stuff
|
|
#
?
May 9, 2012 03:37
|
|
|
Lucid Dream posted:If I just sent the position updates and lerped between them it seems like it would be a lot more difficult to determine whether the player should be walking/running/jumping etc. Typically you're sending position AND input/state that is relevant to help the other players' client side prediction.
|
|
#
?
May 9, 2012 03:56
|
|
|
Unormal posted:Typically you're sending position AND input/state that is relevant to help the other players' client side prediction.
|
|
#
?
May 9, 2012 22:04
|
|
|
OneEightHundred posted:This is sort of a balancing act. Other clients will mispredict often because the parameters that control the prediction are constantly changing, so you'll have jerky corrections. Client prediction will amplify any change in client input for as long as the prediction period. Yeah, it's totally game dependent. You just sort of have to try it in your game and see what works best for you, with your input, physics and game-play. :black magic: For instance in totally co-operative games (say, a minecraft clone) you can give much more trust to the client, and get a better real-time experience. However for competitive games, you want to trust the client as little as possible. So it's very situational, and can really drive design. (e: Reasons to build in multi-player from the start, not graft it on later, which rarely works well) Unormal fucked around with this message at 22:26 on May 9, 2012 |
|
#
?
May 9, 2012 22:17
|
|
|
On that topic though, one thing I'm still struggling with is how any modern physics engine interacts with this, especially for things that pretty much have to use the rigid body simulator (i.e. vehicles). Doom 3 went open-source recently, but its physics system is capable of iterating single objects which seems somewhat unusual. Bullet for example only iterates the full scene and has a fixed time step. From what I gather, this is pretty typical, and it looks like it MIGHT be possible to mass disable/enable objects to isolate the simulation, but I have no idea if this is true or not. I guess UE3 just doesn't predict controlled rigid bodies at all, but supposedly the same thing attempted in Source was extremely laggy and unresponsive. 
OneEightHundred fucked around with this message at 23:19 on May 9, 2012 |
|
#
?
May 9, 2012 23:17
|
|
|
Don't snap physics objects to their correct position unless they're 1. misplaced by a significant amount 2. can affect players and 3. aren't visible on the screen. Whose gonna care if the soda can rolling around is one foot to the left? Even bodies which players can potentially use as platforms/bridges can be given some slack since it just looks like other players are lagging and not the physics objects.
|
|
#
?
May 10, 2012 00:30
|
|
|
OneEightHundred posted:On that topic though, one thing I'm still struggling with is how any modern physics engine interacts with this, especially for things that pretty much have to use the rigid body simulator (i.e. vehicles). Doom 3 went open-source recently, but its physics system is capable of iterating single objects which seems somewhat unusual. Bullet for example only iterates the full scene and has a fixed time step. From what I gather, this is pretty typical, and it looks like it MIGHT be possible to mass disable/enable objects to isolate the simulation, but I have no idea if this is true or not. Modern physics engines sort of just don't work multi-player. One of the big networking challenges that hasn't really been solved yet is getting complex physics working that doesn't feel incredibly horrifying to the player. The only workable option I've really seen is to trust each client A LOT when it comes to the world physics, basically making the player a server for any physics object they 'grab' first. This minimizes snapping, at the cost of having to place a lot of trust in the client. This is obviously a pretty big security issue for competitive games, but works just fine for cooperative games. I think you'll see a lot of interesting physics-based cooperative games in our future, but not many competitive ones. I think the endgame (one day in the far flung future) is clients being totally trusted, but totally verified. That is to say, each client is a server for all of the objects someone is interacting with, totally trusted, but the server is running a simulation on it's end and verifying the 100% of the actions are valid, with cheaters flagged and kicked. How you do this 100% of the time?
Unormal fucked around with this message at 01:47 on May 10, 2012 |
|
#
?
May 10, 2012 01:45
|
|
|
|
| # ? May 11, 2024 12:54 |
|
|
Unormal posted:How you do this 100% of the time? You double the computation budget per player. Have the player send key input to the server, and have the server run a local instance of the client. Both run in realtime and you can hash states or do whatever sanity checking floats your boat. It's infeasible today for most games, but eventually it may be fine. (And for simple turn-based games it could still work today.) With unlimited bandwidth and server-side compute capacity you can basically just make the client use a VNC protocol and run everything server-side. edit: I think it's best to think of thick clients as a mechanism for hiding latency from the player, rather than removing it. Internet Janitor fucked around with this message at 02:09 on May 10, 2012 |
|
#
?
May 10, 2012 02:06
|
|