|
Morpheus posted:You're right, but what I think would be better would be for the user to 'shape' the map according to functionality...so to speak. Not just changing some numbers around. Hmmm... Tree structure whose nodes represent building types. Where some room types are composite structures containing other rooms. Each room contains a generate method describing how to set up that room. A cell might insert a bed and a toilet. A prison may insert a random number of cells (which, in turn, generate their own details.) You just work your way up from there, a bedroom contains some furniture, a home contains some bedrooms, some bathrooms, a kitchen. A block contains some homes, a suburb contains some blocks, etc. Seems like a textbook case for the composite pattern. Once the tree is constructed, layout the nodes on your grid, and do some sanity checking. Interesting problem, and absolutely solvable.
|
#
?
Mar 7, 2009 01:15
|
|
|
|
| # ? May 9, 2024 22:44 |
|
|
Clock Explosion posted:However, wouldn't that just call foo.t or foo.f if any button is found to be pressed? How do you differentiate between buttons? Just use the index for something like this: code:
|
|
#
?
Mar 7, 2009 01:39
|
|
|
Pfhreak posted:Seems like a textbook case for the composite pattern. Once the tree is constructed, layout the nodes on your grid, and do some sanity checking. Interesting problem, and absolutely solvable. Yeah! also, during the second pass is when you'd add in essential game objects like entrances/exits, stairs, NPCs, quest-related objects etc. That's my guess. You may be able to accomplish that in the initial generation... Good solution though! terminatusx fucked around with this message at 02:34 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 02:31
|
|
Indie Game Dev and
|
Seat Safety Switch posted:In that code sample, you are looping through the available button indices and asking for each button in order (for index in range...) and then if the button is pressed, you are invoking foo.t(). If any button is not pressed, it invokes foo.f(). Okay. I was hoping that would work, but wanted to make sure it did - I have a lot of buttons that I'm going to be dealing with.
|
|
#
?
Mar 7, 2009 02:46
|
|
|
terminatusx posted:Yeah! also, during the second pass is when you'd add in essential game objects like entrances/exits, stairs, NPCs, quest-related objects etc. That's my guess. You may be able to accomplish that in the initial generation... Good solution though! I'm such a junkie for design patterns that I'd probably build a visitor for doing those sorts of things (and even doing the initial layout.) That way, I could use the same data structure to represent the dungeon in a game agnostic way.
|
|
#
?
Mar 7, 2009 03:15
|
|
|
Pfhreak posted:I'm such a junkie for design patterns that I'd probably build a visitor for doing those sorts of things (and even doing the initial layout.) That way, I could use the same data structure to represent the dungeon in a game agnostic way.  what's a visitor? free computer science lesson pls!
|
|
#
?
Mar 7, 2009 07:32
|
|
|
terminatusx posted:
Wikipedia has a rather nice summary of it with code and all: http://en.wikipedia.org/wiki/Visitor_pattern
|
|
#
?
Mar 7, 2009 07:40
|
|
|
thx wikipedia 
|
|
#
?
Mar 7, 2009 07:50
|
|
|
A more distilled version would be to say this: The visitor pattern delegates the responsibility of acting on a data structure. Rather than have your binary tree object responsible for printing itself (or, in this case laying itself out on a grid) you create an object that peers into the data structure and does work with the data there. In a binary tree example, the visitor would be able to do a pre-, post-, or in-order traversal of the structure and print some specific piece of data to the screen. In our hypothetical game example, the visitor would traverse our tree and extract the data necessary to populate our grid with our rooms. It's a wonderful way to increase encapsulation in your programs. I'm a huge proponent of more encapsulation. Data objects (in general) are not graphics objects, or sound objects, or physics objects. They are the parameters necessary to create those objects. A 2d room isn't a list of sprites, sounds, and other heavy weight, platform dependent objects, it is a list of abstract qualities that the visitor is responsible for interpreting. Rather than have your data be responsible for presenting itself, you remove the presenting to other objects. A room shouldn't know how to draw itself, it should know what it contains. It's up to the visitor to know how to draw the room. With this, you might build a 2d graphics visitor, and a 3d graphics visitor -- one might traverse your tree to draw the minimap, another to draw the world. It also lets you basically hot swap systems in and out to render your world. It appears to add complexity to a novice coder, until you realize that without it, every node in the tree has to know how to render itself in your game engine -- essentially coupling every node to every subsystem of your game. Edit: Don't know if that was really more distilled... Edit 2: If you haven't already, buy the Gang of Four Design Patterns book. "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides. Don't ask why, just buy it. It is the most important book on my shelf. Now, if I could only get out of this current job writing business apps for power (ie, electricity) engineers, and into a game programming job. Pfhreak fucked around with this message at 08:26 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 08:23
|
|
|
Pfhreak posted:Edit 2: If you haven't already, buy the Gang of Four Design Patterns book. "Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides. Don't ask why, just buy it. It is the most important book on my shelf. Now, if I could only get out of this current job writing business apps for power (ie, electricity) engineers, and into a game programming job. No don't buy this book, there's really no point. Some of the various design patterns pop up in code (others are just dumb), but you don't actually need to be aware of them to use them; usually, when a design pattern is appropriate, it's the obvious solution anyway. People who start coding by thinking about design patterns generally attempt to shoehorn them into code where they don't belong (a good example of this is the "room" example posted above*). The visitor pattern is really just a hackish attempt at providing runtime dual-dispatch, anyway. Besides that, a lot of the design patterns result from an unhealthy obsession with object-oriented programming, as though it's the "one true way" of designing an application (it's not). EDIT: tl;dr, design patterns are glorified hacks designed to work around missing language features. * EDITx2: the problem is that you barely have an idea of what you want and you're already talking about using a design pattern. It should be the other way around: specific, detailed goals first (writing actual code is a good way to nail these goals down), design patterns second (if at all). Avenging Dentist fucked around with this message at 10:35 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 10:17
|
|
|
Avenging Dentist posted:No don't buy this book, there's really no point. Some of the various design patterns pop up in code (others are just dumb), but you don't actually need to be aware of them to use them; usually, when a design pattern is appropriate, it's the obvious solution anyway. People who start coding by thinking about design patterns generally attempt to shoehorn them into code where they don't belong (a good example of this is the "room" example posted above*). The visitor pattern is really just a hackish attempt at providing runtime dual-dispatch, anyway. Exactly this. People get so tied up about doing things in a generic, reusable way that they never finish solving the problems for their specific instance. Or when they do the solutions are over-engineered, under-tested, half-assed, and slow. Oh so slow.
|
|
#
?
Mar 7, 2009 10:59
|
|
|
But would you say you're better off never learning design patterns? Perhaps it's worthwhile to know of them as long as you can avoid overusing them. This is pretty self-pertinent because I actually know of very few design patterns. Classes I took in programming never got to that depth (Digital Media B.A. woopwoop  ). But one day I discovered a Singleton pattern in some code at work, and after looking it up on wiki, found it to be a pretty useful device for actionscript at least, where it's a convenient way for creating a "controller" that helps all the components communicate w/ eachother. So that kinda makes me want to learn the others, and consider getting a book like this. terminatusx fucked around with this message at 18:39 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 16:46
|
|
|
Pfhreak posted:A more distilled version would be to say this: Actually that made a lot of sense, thanks for the summary. I could see this being useful at times as well...
|
|
#
?
Mar 7, 2009 17:15
|
|
|
Did you really need a design pattern to tell you that it is sometimes helpful to have a single, global object that takes care of things?
|
|
#
?
Mar 7, 2009 18:10
|
|
|
not a dinosaur posted:Did you really need a design pattern to tell you that it is sometimes helpful to have a single, global object that takes care of things? No, not at all. anyway that wasn't really the point.. for lack of a better expression, I feel like design patterns help to avoid "reinventing the wheel" terminatusx fucked around with this message at 18:41 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 18:38
|
|
|
terminatusx posted:But would you say you're better off never learning design patterns? Perhaps it's worthwhile to know of them as long as you can avoid overusing them. This is pretty self-pertinent because I actually know of very few design patterns. Classes I took in programming never got to that depth (Digital Media B.A. woopwoop Now, I won't get behind the singleton pattern. That's one I generally disagree with. It has a very specific niche usage and it is far too often overused. Dentist, I was more attempting to illustrate the usage of the pattern, or where it might be appropriate to use a pattern. Yes, you should always have done your spec work before your design work. But as an intellectual exercise in design, where the spec is, "Create a graph/tree based memory structure responsible for generating a dynamic dungeon where the rooms have meaning and context with one another." I really do think that the patterns here were appropriate usages. Yes that spec sucks, and absolutely you should build some prototypes. I didn't mean to suggest that any of those things aren't true. I think you are selling patterns short to call them all 'hacks'. When was the last time you wrote a real piece of software that didn't use the factory pattern? What network or gui program doesn't use a variant of the chain of responsibility pattern? Ehnus, the idea that over-engineered, under-tested, half-assed applications are somehow the result of the patterns themselves is wrong. That's a problem with the people, not the concepts. Yes, programmers are lazy fucks. That's what we do for a living, write code to make our lives easier and more automated. That design patterns are slow is potentially true in some cases, there's no disputing that. The visitor has many more method calls than just implementing the logic in the data structure, sure. But that inefficiency isn't going to be noticed unless you are writing a AAA big budget game. (Or the rest of your code sucks.) Hell, it's practically mandated that every GUI app these days uses model-view-controller, even though it may not be the most efficient code. Maintainability nearly always trumps efficiency, and good OO design principles are one way to establish clean, maintainable code. Before you flip out, yes there are programmers who over use and under understand the concepts. They construct altars to the GoF in their work places (I work with a guy who literally mumbles "Design patterns... Design patterns... Design patterns" under his breath for hours at a time. I poo poo you not.) Don't look at the book as a Way Things Are, but rather another tool in your repertoire. Just like anything else in software, you have to understand their place. Even globals and gotos have their (admittedly small) use. It's important to know when and where to use them. Edit: I'll admit I probably come from a different sector of the software industry. I write code that regulates and maintains the power grid worldwide. There is a huge emphasis for infallibility and maintainability in our code. If our apps crash, hundreds of thousands of people lose power, and millions of dollars of equipment could be damaged. Because we have a large number of software projects, and we are growing almost 20% a year for the last 10 years, we are constantly bringing new engineers into our projects. It's important that our code base be as clear as possible, because it will need to be maintained for decades. Pfhreak fucked around with this message at 19:22 on Mar 7, 2009 |
|
#
?
Mar 7, 2009 19:16
|
|
|
Pfhreak posted:I think you are selling patterns short to call them all 'hacks'. When was the last time you wrote a real piece of software that didn't use the factory pattern? I think I've used the factory pattern once, ever. And even then it was a heavily modified version. Also, design patterns are hacks because they exist to work around missing language features (e.g. multiple dispatch, globals, extension methods). In many dynamic languages, these design patterns are so trivial that they're not worth mentioning. It's only when attempting to use heavy OO in languages like Java and C++ that you run into this. Pfhreak posted:What network or gui program doesn't use a variant of the chain of responsibility pattern? Some of the design patterns are useful, (I'd be a bad C++ programmer if I hated iterators), but you don't need to know about design patterns to know that these are good ideas. The only thing design patterns really bring to the table is that it removes the necessity of thought from schlub programmers, somewhat reducing the number of things they can screw up. In business software, this is especially important because the talented programmers are off doing better things, so you have to deal with hiring the leftovers.
|
|
#
?
Mar 7, 2009 20:53
|
|
|
The GOF book is bad for making the 'schlubs' think that any given pattern needs to be implemented some some predetermined manner, or that they are bound to some kind of language feature or lack thereof. Every language has patterns, and every programmer/workplace/project has patterns. Most people just don't spend the time to formalize and document them. Ultimately, design patterns are just a naming convention for common scenarios, but the word has simply become too tainted by too much head up the assery.
|
|
#
?
Mar 7, 2009 21:11
|
|
|
Pfhreak posted:Ehnus, the idea that over-engineered, under-tested, half-assed applications are somehow the result of the patterns themselves is wrong. That's a problem with the people, not the concepts. Yes, programmers are lazy fucks. That's what we do for a living, write code to make our lives easier and more automated. Yes, it's the people that decide to look at the GoF book as some sort of magic recipe repository for all their programming needs that are a problem. Patterns ideally are supposed to arise naturally from code as it develops and common mechanisms are factored out for maintainability, they're not supposed to be the starting point of software design. The problem with patterns in video games, and I suspect other domains as well, is that games are largely a problem of data movement but patterns specify behavior. When putting pixels on screen or sound out the speakers you need to think about your source data format (meshes, textures, animation data, etc.), the destination data format (vertex buffers, compressed textures, etc.) and how you can load and transform one to the other in the least amount of work. Data based design allows you the flexibility of more easily operating in heterogeneous execution environments (PPU/SPU or CPU/GPGPU or brain/abacus or whatever) which object+behavior based design inhibits or outright forbids. Performance is a problem in video games of all shapes and sizes, not just AAA blockbusters. I'd even say that the AAA titles are probably better equipped to deal with performance problems because they're likely to have people on the team who enforce cycle/memory budgets and people with the experience to fix problem areas when they arise. Sort of unrelated but the post-mortem for Weapon of Choice does mention that they spent a lot of time chasing down issues relating to their overuse of garbage and it's about as far from a AAA commercial title that you can get.
|
|
#
?
Mar 7, 2009 21:28
|
|
|
krysmopompas posted:The GOF book is bad for making the 'schlubs' think that any given pattern needs to be implemented some some predetermined manner, or that they are bound to some kind of language feature or lack thereof. Every language has patterns, and every programmer/workplace/project has patterns. Most people just don't spend the time to formalize and document them. If people just wrote code, looked back, and said "hey this looks like an instance of MyGayPattern" and documented it as such, the (programming) world would be a better place.
|
|
#
?
Mar 7, 2009 21:31
|
|
|
So, not to distract from this engaging discussion of design patterns but I have a question about networking. If I have an object on a server that needs to be updated on a client (or a set of objects requiring different updates), what's a good way to go about this? I'm pretty sensitive to the amount of data sent because I'm targeting cellphones as a potential client platform. I was thinking I'd write a packet that includes all the object updates for the tick. Each object update would have a header that indicated what kind of update it is (i.e. position, velocity, activity), the ID of the object it is for and then some data for the actual change. Is this a good design? Are there other approaches in common use? I want to write the object update structure such that it would read/write each value as a series of bytes regardless of type so that I could save bytes on each update by avoiding word alignment and at the same time end-around endianness problems, but I'm not sure if there are other gotchas with this approach that I'm unaware of.
|
|
#
?
Mar 8, 2009 20:31
|
|
|
If you can make you game engine fully deterministic, and the game isn't too fast-paced, you only need to send player inputs; there was an article on Gamasutra in 2001 explaining how this was done in Age of Empires. http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php Otherwise, if you're sending the state of each object each tick, you'll want to consider interpolating between the current and latest received position for an object, and extrapolating from the last received into the future, so that a dropped packet doesn't cause objects to jump. And if this works well enough, you don't need to send an update for objects every frame; you could do it every few frames instead... When it comes to resolving collisions that affect gameplay, there are two approaches I've read about; in an FPS you would tend to do it all on the client so that when the player thinks they got a headshot, they score it; this is vulnerable to exploitation in various ways. The other approach is to handle the collision on the server, which introduces lag between a player's actions and a visible result and might look strange on the client. Will your game have a dedicated server? What sort of bandwidth is available and how many objects will need to be updated each frame?
|
|
#
?
Mar 10, 2009 17:20
|
|
|
Fib posted:If you can make you game engine fully deterministic, and the game isn't too fast-paced, you only need to send player inputs; there was an article on Gamasutra in 2001 explaining how this was done in Age of Empires. http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php The current plan is for the game to be semi-turn-based--clients get one action every second (or so), so all they need to send is their command. I'll be duplicating any physics code on the client that's on the server, so I'll only need to send an object update when the expected position/velocity/acceleration is invalidated. Collisions will be modeled on both the client and the server, except where it would be too complex for the client to model (I expect smartphones to be fairly slow at things like this). The whole thing is kind of a pipe dream, but the ultimate plan is to run the server on a home built computing cluster. As far as bandwidth goes--I have no idea, which is why I'm looking at optimizing it early. The number of objects I need to update could be quite large, but the number I need to send to clients would be limited by the client's potentially visible set.
|
|
#
?
Mar 10, 2009 18:26
|
|
|
Fib posted:If you can make you game engine fully deterministic, and the game isn't too fast-paced, you only need to send player inputs quote:When it comes to resolving collisions that affect gameplay, there are two approaches I've read about; in an FPS you would tend to do it all on the client so that when the player thinks they got a headshot, they score it; this is vulnerable to exploitation in various ways. The other approach is to handle the collision on the server, which introduces lag between a player's actions and a visible result and might look strange on the client. Personally I'm considering different approaches, conceding that perfect aim in net play is a lovely thing to depend on, and possibly look towards adding auto-aim (oh poo poo FPS taboo!) with damage falloff instead of accuracy falloff. OneEightHundred fucked around with this message at 22:37 on Mar 10, 2009 |
|
#
?
Mar 10, 2009 22:27
|
|
|
OneEightHundred posted:You also need to be extremely careful to make sure that floating point precision doesn't gently caress you. SSE and x87 use different precision, for example, and D3D by default will change your floating point precision too. From experience, AMD and Intel chips also like to deal with floating point slightly differently from each other in some cases, for added fun.
|
|
#
?
Mar 11, 2009 02:17
|
|
|
I'm almost sure the Ascii Dungeon tutorial has been posted here before ( http://cgempire.com/forum/tutorials-101/terror-ascii-dungeon-c-tutorial-codephobes-part-1-a-379.html ) but I liked it. I built a bit more from that framework (if you can call it that), but right now I'm in horribly over my head. There's so many things that probably are really basic - like attacking a monster, how the hell do I specify that it is the specific monster standing next to the player I want to attack - and so on. I wish he would write a new part or something 
|
|
#
?
Mar 14, 2009 00:50
|
|
|
Konec Hry posted:I'm almost sure the Ascii Dungeon tutorial has been posted here before ( http://cgempire.com/forum/tutorials-101/terror-ascii-dungeon-c-tutorial-codephobes-part-1-a-379.html ) but I liked it. I built a bit more from that framework (if you can call it that), but right now I'm in horribly over my head. There's so many things that probably are really basic - like attacking a monster, how the hell do I specify that it is the specific monster standing next to the player I want to attack - and so on. Weighing in as one out-of-his-depth poster to another, you surely have some collection that contains all the active monsters (otherwise your question would have been about implementing monsters at all). Go through all monsters on the level or in the area or whatever and see which one is at the location you're trying to attack.
|
|
#
?
Mar 14, 2009 09:11
|
|
|
The way a simple roguelike would implement the feature is to add on top of the movement something likecode:If your world were instead, for example, a 2d array of lists, you would instantly know how many and which things exist in the point you're looking at, because you would look up the point in the array and then iterate over the list inside that point. The tradeoff is that then it's harder to say "this is how many monsters are in the world" without iterating over the entire world(slow) or maintaining an additional list for monsters(additional state to maintain, potential source of complexity/bugs), and it's also harder to do movement because you're shuffling your monster around from one list to another instead of just incrementing coordinates. Once you get beyond a few kinds of things in the world it helps if you shift to a composition-oriented system, where actors are collections of component objects that each implement a little slice of functionality(collision, visualization, ai, etc.) as it lets you reuse more and specialize only where it's necessary.
|
|
#
?
Mar 14, 2009 10:21
|
|
|
I'll have to look into the 2d array of lists. Now that you mention it, my biggest breakthrough in modifying the code was having the room.draw or whatever fill a 2d-array with the ASCII-tile of a wall/floor/corner and then having a different function actually print that out to the screen. So yeah, what you (t_rf and Blue Footed Bobby) say makes a lot of sense, and it does sound like something I could get semi-working some day. Thanks 
|
|
#
?
Mar 14, 2009 11:07
|
|
|
I've just had a run through those tutorials - is Part 4 the last one, or am I missing something?
|
|
#
?
Mar 14, 2009 12:41
|
|
|
Staggy posted:I've just had a run through those tutorials - is Part 4 the last one, or am I missing something? Yeah it is
|
|
#
?
Mar 14, 2009 15:12
|
|
|
Konec Hry posted:Yeah it is That sucks. They're really good, and after only an hour or so you really feel as though you've made something. It's a pity that I had the usual problem, and my code descended into a clusterfuck of "#include"s and warnings. Speaking of which, does anyone know of any good sites/tutorials explaining how to lay out file/class includes? Specifically around the sort of stuff you find in games - so objects, object managers, worlds, etc.
|
|
#
?
Mar 15, 2009 00:14
|
|
|
I'm working on a turn based game, and am considering adding online multiplayer sometime soon (something I've never done before). Looking over UDP vs. TCP it seems to me that in a turn based setting, the performance gains of UDP aren't worth it compared to the success/failure feedback that TCP gives you. Is that a correct conclusion? From a simplicity of implementation standpoint, my assumption is that TCP is easier than UDP.
|
|
#
?
Mar 16, 2009 05:22
|
|
|
For turn based you should just use TCP, correct.
|
|
#
?
Mar 16, 2009 06:06
|
|
|
TCP all the way when milliseconds don't matter. Will save you a lot of trouble.
|
|
#
?
Mar 16, 2009 09:46
|
|
|
Staggy posted:Speaking of which, does anyone know of any good sites/tutorials explaining how to lay out file/class includes? Specifically around the sort of stuff you find in games - so objects, object managers, worlds, etc. As far as actually managing the files in C++, remember that you can use class/struct prototypes (right word?) for declarations, the definitions (which you need to include the header files for) are only necessary when you actually use perform operations on values of that type, or use it as a non-reference property or variable. i.e. if class A includes a reference to an object of class B, it's fine to just do: code:If you're dealing with inline code with interdependent classes (i.e. matrix/vector libraries), you should declare the class first, include dependencies for the code, THEN write the actual inline functions in the header. OneEightHundred fucked around with this message at 09:47 on Mar 17, 2009 |
|
#
?
Mar 17, 2009 09:44
|
|
|
Thanks for the reply - I understood maybe 70% of the words, but I got the gist of it. Just let me clear a few things up - would the following be valid? code:
|
|
#
?
Mar 17, 2009 17:34
|
|
|
Staggy posted:Thanks for the reply - I understood maybe 70% of the words, but I got the gist of it. Yes.
|
|
#
?
Mar 17, 2009 20:09
|
|
|
Does anyone have any experience with PhysX here? I'm using the character API and I noticed in the documentation that characters don't fire trigger actors. Does anyone know of a workaround for this? It would be handy for creating some entities in my engine instead of implementing a separate collision detection system.
|
|
#
?
Mar 19, 2009 15:20
|
|
|
|
| # ? May 9, 2024 22:44 |
|
|
I want to get into game development (as a hobby for now) but I'm not quite sure where to start. I've been taking programming classes at school for a few years now and have always done well, but I haven't really done any serious programing outside of class. My classes have been taught primarily in Java and C++, with a bit of C thrown in and even less Perl. I also learned some assembly in a CE class and have taken linear algebra. For my first game I'm thinking about making a Tetris Attack clone. It doesn't seem like this would be too much harder than starting with something a bit more basic, like Tetris, but I don't really know. Is this a reasonable goal for my first game? For those familiar with Tetris Attack, my broad plan is to start by only implementing 1 player's side (scrolling, clearing, combos), then get it working for 2 human players (sending blocks to your opponent) and finally add either internet support or computer opponents. What language (and libraries) would be good for this and how are my language choices limited if I eventually want to be able to play the game in a web browser? I see Python recommended a lot for people beginning game programming. Is it still a good idea to go this route if I already have experience in C++ and Java? What are some good websites and/or book resources that would help me get started with this game? I'm going to need the most help with the graphics portion of the programming as I haven't written anything besides command line programs besides some basic GUI stuff in Java. Hope this is the right thread for this...thanks!
|
|
#
?
Mar 27, 2009 06:45
|
|