|
roomforthetuna posted:How would you do it instead? Have the manager have separate lists of objects-that-can-collide-and-don't-render, objects-that-can't-collide-and-don't-render, objects-that-can't-collide-and-do-render and objects-that-can-collide-and-do-render (and double the lists again for every other trait that can lead to an unnecessary function call)?
|
#
?
Nov 12, 2010 19:35
|
|
|
|
| # ? May 12, 2024 22:31 |
|
|
What do you think of this proposal? There's Renderable objects and Physics objects, but they are completely independent. Renderable objects have a Texture, a Transformation, and a GameBehavior (determines lifetime, etc). Physics objects have a Transformation, and a GameBehavior. The classic 'Entity' would be represented by a Renderable object and a Physics object that both happen to point to the same Transformation and the same GameBehavior. If something in the GameBehavior (possibly driven by scripting) causes the object to be destroyed, or causes the Transformation to be altered, the Renderable and Physics objects both react identically. To the end user, this appears to be one cohesive 'entity' even though the two are linked merely by sharing behavior. With this proposal it's entirely possible to create Renderable elements that don't have collision detection, and Physics objects (invisible boundaries?) that don't have graphics.
|
|
#
?
Nov 12, 2010 19:43
|
|
|
Orzo posted:I don't know how I would do it. That's part of the reason I asked. If you didn't know you'd do it, it seems strange to make a statement like "game programmers are bad at OO." When it comes to game programming, performance tends to trump elegance, and that's especially true when it comes to OOP, and especially true in the age of multicore processors. The most natural organization of data from the programmers perspective is rarely the optimal organization for concurrent algorithms. That being said if you're browsing gamedev.net's forums you're most likely looking at posts made by people who are as or even more inexperienced than yourself (regardless of your level of experience) so it's not really a great resource unless you know exactly who is talking. Anyway, to contribute: I've been working on an experimental multithreaded game engine for a little while. The way I organize game data is to have several different modules which are all completely independent. They don't share any data but instead synchronize via message passing using lockless queues. So, for example, there's an Entity class and a EntityManager which tracks the logical entity and its gameplay-related statistics. For rendering the equivalent is Actor and SceneManager, for collision/physics it's Body and PhysicsManager, etc. Unique IDs are used to identify objects in messages. Each of the sub-engines (the Manager classes) works by first processing all pending messages to update its objects to the most recent state. For example the physics engine will receive any message from the game engine about position changes for bodies which are not physics-driven. Then it'll run its own simulation, and post messages to the game engine for any collisions or position changes for physics-driven bodies (using the entity ID codes to signify which entity it's talking about.) Loose coupling is a huge advantage and means each system can be completely replaced without any effect on the others so long as the interface remains the same. No data sharing, which resulting in some additional memory usage, means that multicore processors can be exploited much more efficiently. Personally I find tight coupling of the various components (rendering, physics, logic) to be a huge code smell.
|
|
#
?
Nov 12, 2010 20:00
|
|
|
Paniolo posted:If you didn't know you'd do it, it seems strange to make a statement like "game programmers are bad at OO." Also, I think it's completely valid to be able to detect a problem with a design and not necessarily have a solution ready. Saying 'I don't know' and 'I don't know so I'll stop thinking about it and implement this horrible solution' are two very different things. When I posted that I wasn't really sure, and after giving it some thought I think I have a good solution which avoids the design smells.
|
|
#
?
Nov 12, 2010 20:12
|
|
|
Zerf posted:I think his concerns are legitimate, you don't want to execute function calls if they just nop. Why not? Orzo posted:What do you think of this proposal? I guess the best way to describe an "Entity" is as a way of tracking/coupling different systems together. So your game has Physics objects, and Renderable objects, and GameLogic objects. Your World manager would have a list of weak pointers for all physical objects, renderables, and GameLogic (although usually GameLogic will be rolled into the entity itself, and just refer to the other two). Your Entity class would have a smart pointer to a PhysicsData and RenderData. As I mentioned though, Entities usually refer to GameLogic objects, so there's not much need to have an entity that has physics and rendering but no logic, or whatnot. Usually those are entirely different systems altogether. It only becomes "Bad OO" if you fall into one of the most common OO traps -- trying to over-generalize your objects. e: And if a design doesn't smell at least a little, it's not working hard enough.
|
|
#
?
Nov 12, 2010 22:15
|
|
|
Hubis posted:Why not? Hubis posted:I guess the best way to describe an "Entity" is as a way of tracking/coupling different systems together. What does 'overgeneralizing' mean? And I don't agree with your last statement about code smells.
|
|
#
?
Nov 12, 2010 22:50
|
|
|
Overgeneralizing means rolling too much functionality into one construct and making it the only way to deal with that functionality. Like if you want a player to be holding a weapon, and your entity model is "entity = independently moving networked renderable object" then now you're stuck dealing with the "independently-moving" cruft when it's bolted on to an existing object. Old Quake mods used to run into this problem too when trying to create particle effects since the only way to create renderables was to create them on the server as networked objects. It's okay to have functionality piped through individual classes for the sake of convenience, but the parts should be separable.
|
|
#
?
Nov 13, 2010 00:17
|
|
|
Woke up with a burning idea for a game this morning, so decided I should probably finally invest some serious time and money in learning to code. I think I will go with C++. I've been reading this thread for a few months so I have picked up a few pointers, but if any of you want to mention tutorials or books that you've had experience learning with, that would be cool. There seems to be a lot of love for an array of languages in here. I'm a complete neophyte so for now one language seems pretty much like another. I think all my games will be 2D isometric or Windows-GUI based. I don't really have any interest in 3D. That would lead me towards Python but I'm not sure if I'll have to end up learning C++ anyway. Anyway, I have a specific question about coding with other people. Is it a problem coding alongside other people in terms of work sharing (at the hobbyist level)? I have a friend who got a kick out of my ideas and we intend to work together, but trying to get my head around how we would (eventually) share code seems daunting. Harmonica fucked around with this message at 00:44 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 00:41
|
|
|
Orzo posted:Can you give me an example of when a no-op implementation is good? Allowing a few no-op calls can be good if if greatly simplifies your overall design. With a pure Entity model you have only one base class and a handful of Behavior interfaces. Some no-op calls will happen, but with a decent interface design they should be semi-rare and are pretty cheap to execute when they do occur. The problem that can arise with a pure OO design is that you either have to design a million derived classes for every possible special case or you have to push functionality up the inheritance hierarchy toward the base class to make a smaller set of more general objects. If you make a million derived classes you have a complicated code structure. If you make a few general classes then objects that could be simple in principle end up having a lot of extra functionality that takes extra CPU time, possibly much more than if they had just been allowed to make the occasional no-op call. e: Two good write-ups on the subject: Scott Bilas' GDC presentation and Cowboy Programming. PDP-1 fucked around with this message at 01:30 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 01:23
|
|
|
PDP-1 posted:The problem that can arise with a pure OO design is that you either have to design a million derived classes for every possible special case or you have to push functionality up the inheritance hierarchy toward the base class to make a smaller set of more general objects.
|
|
#
?
Nov 13, 2010 01:39
|
|
|
Harmonica posted:Woke up with a burning idea for a game this morning, so decided I should probably finally invest some serious time and money in learning to code. I think I will go with C++. I've been reading this thread for a few months so I have picked up a few pointers, but if any of you want to mention tutorials or books that you've had experience learning with, that would be cool. I can't speak about code sharing, but can I do anything to dissuade you from using C++. Speaking from experience, you're going to spend more time fighting with the language if you've never played before then you will actually making games. I've put in my love of flashpunk many times here (you can get playable prototypes out in a matter of hours), or at least something like gamemaker or construct. edit: hours, not minutes, but still very quickly. ambushsabre fucked around with this message at 04:01 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 01:55
|
|
|
Got something I want to prototype quickly, so opened up Flash, quickly reminded that I can't draw anything in Flash without it looking like a jar of arses. Is it even possible to draw something decent in Flash itself, or will you have to import? if you want the end result to be pretty? Obviously there's lots of nice looking Flash games out there, and I always assumed assets were created elsewhere and imported, but I guess I don't know for sure. Anyway, going to try and have a rough as assholes prototype by the end of the weekend, would like to get feedback on a few things before I proceed (probably throwing everything away and starting a larger project in C#)
|
|
#
?
Nov 13, 2010 02:22
|
|
|
ambushsabre posted:I can't speak about code sharing, but can I do anything to dissuade you from using C++. Speaking from experience, you're going to spend more time fighting with the language if you've never played before then you will actually making games. I've put in my love of flashpunk many times here (you can get playable prototypes out in a matter of minutes), or at least something like gamemaker or construct. Yeah, I can totally be dissuaded from using C++. I chose it mostly out of it being what it is and just for the sake of picking one and getting started. It's pretty confusing picking a language considering there's pros and cons of all of them and I really have no grasp of why one might be better than another. Portability, speed, eloquence and so on don't really have any short term relevance. If the language is intuitive I guess that's a plus but the main thing is that, if I spent a year becoming versed in a language I wouldn't regret it at the end because I run into a whole load of limitations. Flashpunk looks very neat from a look at the site and tools, but is it merely for getting A GAME running? I suppose I should give it a go anyway. Harmonica fucked around with this message at 04:04 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 03:58
|
|
|
Harmonica posted:but is it merely for getting A GAME running? I'm not sure I totally understand the question here, but if you mean is it only for making games, then yes. It's just a library built on top of actionscript 3, which literally isn't good for anything but flash stuff. I just suggested it because I thought you wanted to learn to program for the purpose of game dev, and that (for me) is one of the best ways to program AND be able to easily create games. However, if you get proficient enough in one language, you should easily be able to switch to another. But that's years down the line, not really months.
|
|
#
?
Nov 13, 2010 04:05
|
|
|
Harmonica posted:Yeah, I can totally be dissuaded from using C++. I chose it mostly out of it being what it is and just for the sake of picking one and getting started. It's pretty confusing picking a language considering there's pros and cons of all of them and I really have no grasp of why one might be better than another. Portability, speed, eloquence and so on don't really have any short term relevance. XNA may also be a good choice if you want to go down that road. It uses C#, and can be run on Xbox, Windows, and the Windows Phone. I picked it up a while ago and basically taught myself C# and created a space invaders game in only a day, so it's not too hard (I may be a bit bias though since I know many other languages, so a new one is always really a combination of two other ones I've used  ).Still, C# was pretty fun to use since it's intuitive, unlike c++, which to this day I'm still struggling with (the only reason I'm trying to completely learn it is because it's what most non-indie game dev's use) 
|
|
#
?
Nov 13, 2010 04:11
|
|
|
Harmonica posted:Anyway, I have a specific question about coding with other people. Is it a problem coding alongside other people in terms of work sharing (at the hobbyist level)? I have a friend who got a kick out of my ideas and we intend to work together, but trying to get my head around how we would (eventually) share code seems daunting. Do you mean actually using the same code between two computers in two locations, or are you talking about delegating tasks and working together? You can use a server for a code repository (or something free like github/sourceforge) so that you guys are using the same code. Plus you have other tools like ideone and codepad.
|
|
#
?
Nov 13, 2010 04:17
|
|
|
Bob Morales posted:Do you mean actually using the same code between two computers in two locations, or are you talking about delegating tasks and working together? Both. They seem rather confusing. ambushsabre posted:I'm not sure I totally understand the question here, but if you mean is it only for making games, then yes. It's just a library built on top of actionscript 3, which literally isn't good for anything but flash stuff. I just suggested it because I thought you wanted to learn to program for the purpose of game dev, and that (for me) is one of the best ways to program AND be able to easily create games. However, if you get proficient enough in one language, you should easily be able to switch to another. But that's years down the line, not really months. Sorry, what I meant was, is it merely for prototyping as it says? I'm not in a vast rush to jump to making the game I have in mind, it's probably too complex right now. I'm looking to do the whole hello world - asteroids - poker - parallax scroll - shindig until I know how a language works. The eventual type of game I had in mind was zelda-style RPG gameplay (though in a futurist setting) alongside simulation and management elements. And roguelike-ish. This is why I'm not going to be able to make it for a good while. Tw1tchy posted:Still, C# was pretty fun to use since it's intuitive, unlike c++, which to this day I'm still struggling with (the only reason I'm trying to completely learn it is because it's what most non-indie game dev's use) If C# is that much more intuitive than C++ I guess that rules the latter out, then. I do have a 360 and the idea of dropping games onto more than one platform is interesting. Seems like kind of a far-off goal right now though. Harmonica fucked around with this message at 04:26 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 04:18
|
|
|
Harmonica posted:Sorry, what I meant was, is it merely for prototyping as it says? I guess you could say that because flash games tend to be polished prototypes (and not even that in a lot of cases). If you want to be able to move on past the fun little distraction zone (which it sounds like you do), then yeah, go with C# or some other solution. If making little games with simple mechanics in a short amount of time sounds appealing, go for flashpunk/flixel. I fall into the latter category since all of my game ideas take like a day to prototype and I love being able to play them really quickly. fakeedit: Of course there's going to be exceptions to the above, but in your case I would recommend c#. It's a nice language and it has xna, so that's probably your best bet. Everything I said above was under the assumption your ideas where a lot smaller, so sorry for giving a lot of advice that doesn't really pertain to you. Good luck!
|
|
#
?
Nov 13, 2010 04:37
|
|
|
ambushsabre posted:fakeedit: Of course there's going to be exceptions to the above, but in your case I would recommend c#. It's a nice language and it has xna, so that's probably your best bet. Everything I said above was under the assumption your ideas where a lot smaller, so sorry for giving a lot of advice that doesn't really pertain to you. Good luck! No apology needed, I should have been clearer, and it's all good advice! Making fun smaller games is probably going to be a good thing to do even if it's just on the side of learning a language.
|
|
#
?
Nov 13, 2010 04:43
|
|
|
Harmonica posted:Both. They seem rather confusing. If you're a student at a uni or a school somewhere you can get a free XNA creators club trial, which lasts 12 years and lets you develop games for the xbox without cost, the only limitations being that you can't sell them, which costs $99 to do that (better than apple's $99 a year though for iPhone, +$20 per game on the store). Although, you can also develop a complete game on the pc, and then change the control code from keyboard to gamepad and instantly you're ready to sell it for xbox, since they work exactly the same. Either way, xna provides you with almost everything. To draw a sprite on the screen, starting from a blank template file they provide you with, you have to add 3 lines of code: One for initializing the surface. One for loading the image. One for drawing the image. That's it. Compared to c++ and whatnot, it's so much easier and a lot more intuitive! Either way, I'd just give it a shot. It can also create 3D games if you ever want to go that far.
|
|
#
?
Nov 13, 2010 05:10
|
|
|
Orzo posted:I don't understand what you're saying here at all. First of all, there's no such thing as 'pure' OO design. There's good OO design, which is what I'm striving for here, and my suggestion was the polar opposite of making 'a million derived classes'. In fact, it has a completely flat hierarchy. Work spent towards making design "good" often doesn't actually make a game. I think your "proposal" earlier is probably close to what a lot of games do. I also think that a lot of the architecture of games is very purpose-built and only comes out of a crucible of whatever it's taken to ship.
|
|
#
?
Nov 13, 2010 09:42
|
|
|
Senso posted:Because I'm a Linux sysadmin? Producers decided we were going to make Unity games without checking if the gameservers ran on Linux, so we suddenly have to port our maintenance code and all that to Windows, it was quite unexpected. You guys have an interesting architecture if deciding on a specific engine for your game clients forces you to switch platforms for the servers... though I'm not sure what "maintenance code" means.
|
|
#
?
Nov 13, 2010 15:01
|
|
|
Orzo posted:I don't understand what you're saying here at all. First of all, there's no such thing as 'pure' OO design. There's good OO design, which is what I'm striving for here, and my suggestion was the polar opposite of making 'a million derived classes'. In fact, it has a completely flat hierarchy. I wasn't commenting on your proposal in that post, just pointing out that eating a few no-op calls could be 'good' in the sense that it may be cheaper to have a few no-op functions in a simple Entity class than to have a complicated general base class that does a ton of work for every object in the game. I'm working on my own Entity model and running into the same issues that you are. I can either make everything in the game out of a super general base Entity or I can split things up into a small set of types like having a SmartEntity group for things that move and collide and a DumbEntity group for things that just exist. Going with the general Entity method makes everything super flexible but introduces a lot of no-op function calls for objects that don't do much. Splitting things up into a few groups removes the no-op calls but requires a few extra manager classes and some type checking when things interact. I decided to go with the general base Entity model for now - my game is just a simple 2D thingy that is nowhere near CPU limited so I chose simplicity and flexibility over efficiency. Having everything be the same kind of Entity can result in some odd situations where plugging the wrong behavior into the wrong object can make the player's inventory bar attackable (or aggressive!) but I'm also making an Entity factory that will hopefully only allow 'legal' objects to be introduced into the game.
|
|
#
?
Nov 13, 2010 15:55
|
|
|
This probably doesn't need to be said but i've found the more time I spend trying to work out the perfect architecture for a project, the less likely it is that I actually finish said project. If you just generally stick to very basic concepts like keeping components separated and then add in something simple like an event system/message pump, you can deal with issues with that approach as they occur as opposed to planning for every eventuality, of which the vast majority will never occur (and the ones you didn't think of, will). It's way too easy to get into the trap of trying to make your game engine the most generic and extensible thing in existence and waste so much time you could've wrote a purpose built engine for 3 different games. I mean it's great to be aware of all the various design approaches and there's no harm in discussion or anything, it's just that I know far too many programmers who spend their entire lives writing perfectly templated, serialisable, extensible, support everything under the sun engines that never produce anything that doesn't require a "Hey so this doesn't look much but underneath it all it's the sistine chapel!" disclaimer.
|
|
#
?
Nov 13, 2010 17:19
|
|
|
PDP-1 posted:I wasn't commenting on your proposal in that post, just pointing out that eating a few no-op calls could be 'good' in the sense that it may be cheaper to have a few no-op functions in a simple Entity class than to have a complicated general base class that does a ton of work for every object in the game. Last night I wrote down exactly what the two options (A) and (B) were, and I came up with this: (A) There's a Renderable class (responsible for providing drawing information), and there's a PhysicsModel class (responsible for collision detection, etc), but neither has a reference to eachother. However, both would OFTEN have a reference to the same Transformation object, since both drawing and collision detection rely on positin, rotation, etc. So, a monster, for example, would be represented by an instance of Renderable and an instance of PhysicsModel, but neither of those things 'know' about eachother. After all, why would they? However, because 'moving' the monster affects both, they share a pointer to the transformation object. This model supports renderable objects without physics models without any no-ops at all--simple don't create the physics object. It also supports physics constructs that don't need to be drawn, although I'm not sure what this would be. (B) There's an Entity class that holds potentially null references to Renderable behavior, Physics behavior, Transformation behavior, etc. Most likely a bit easier to manage since there's only one list of entities, but makes you wonder why you need this thing that holds N components when you're only using 1 or 2 of the N components available. Hopefully this makes sense. In the end, I'm probably going to go with B just because it's much easier to manage in an editor as well as easier to serialize properly. But I think it's a good thing for me to think through (A).
|
|
#
?
Nov 13, 2010 20:03
|
|
|
brian posted:This probably doesn't need to be said but i've found the more time I spend trying to work out the perfect architecture for a project, the less likely it is that I actually finish said project. If you just generally stick to very basic concepts like keeping components separated and then add in something simple like an event system/message pump, you can deal with issues with that approach as they occur as opposed to planning for every eventuality, of which the vast majority will never occur (and the ones you didn't think of, will). It's way too easy to get into the trap of trying to make your game engine the most generic and extensible thing in existence and waste so much time you could've wrote a purpose built engine for 3 different games.
|
|
#
?
Nov 13, 2010 20:05
|
|
|
Why do you think (A) would be hard to serialize? Don't do (B) 
|
|
#
?
Nov 13, 2010 20:34
|
|
|
Not so much 'hard' to serialize, but the relationships are a bit more complex. In proposal (A), a transformation node, for example, is an independent entity that lives by itself, meaning it has its own ID for lookup. The physics model AND the render model both point to the transformation node, which, to the player, make the collider and the picture look like one cohesive 'entity', even though it isn't. The reason it's slightly harder to serialize is that models like this start to look more and more like a relational database, which to me seems a bit more difficult to persist than, say, what proposal (B) posits. In addition, (A) seems like it might run into problems once the game logic kicks in. Let's say there's a GameBehavior object that the Physics and Renderable both point to. It's likely that this GameBehavior object will need to alter both the Physics aspect AND the Renderable aspect in different ways. If this is the case, the entire separation is destroyed anyway, since I'd have to make assumptions about the nature of what references the GameBehavior. For example let's say there's a GameBehavior object that represents the player. When the player is hit by something, the script says to flash the player red and temporarily turn off collisions with other enemies. How can this be done without assuming that there's a Physics object and a Render object that point to this GameBehavior? Although it does enable some interesting things such as linking multiple renderable objects to one GameBehavior, it seems like it's a bit more difficult to manage. Sorry, this is kind of hard to explain without a code diagram of some sort, hopefully this makes sense. edit: sent you a message on AIM, you there? Orzo fucked around with this message at 21:48 on Nov 13, 2010 |
|
#
?
Nov 13, 2010 21:03
|
|
|
To me it looks like (unless you have tens of thousands of objects active at one time) the very small efficiency loss of calling a virtual function that just returns immediately for objects that don't render or don't do physics is well worth it for the sake of simplicity versus the tangle you end up with if you have three or more distinct sorts of objects all cross-referencing each other. With the "single object, null interfaces for things it doesn't do" model you don't have to worry about reference counting on the transformation objects (or however else you were planning on dealing with cleaning up an object that's referenced from two or more places at the appropriate time), and it's not like the null function overhead is pure cost - it's partially offset against the management costs of dealing with the multi-referenced stuff, that you don't do. But mostly it's the simplicity that seems like the big benefit. vvvv I can't think of any way you could manage a tangle of mixed types cross-referencing each other more cleanly and simply than you could manage a single set of objects with the same available functionality some of which is just blanked for objects that don't care about it. Though I could see maybe an argument for the objects having some sort of more C-like behaviour, wherein some of the functionality might be set per-object rather than per-class so that you can have any combination of physics A or B and rendering X or Y without having to do any multiple inheritance malarkey. roomforthetuna fucked around with this message at 00:22 on Nov 14, 2010 |
|
#
?
Nov 13, 2010 22:47
|
|
|
Yeah, I'm not concerned with efficiency of virtual functions since on this scale it's not likely to make a difference. This is about code cleanliness and extensibility, not speed optimization.
|
|
#
?
Nov 13, 2010 23:08
|
|
|
Orzo posted:Agreed, this is why I'm going with a design I find less than optimal. I do think it's definitely worth the time to take a few days at the beginning to slow things down and really think about what you're doing rather than just jumping in, though. Unless you have plenty of previous experience with real-world game engines, no, it's not worth any time at all to think about these things. Anything you do at this point, you'll change later on. Spending time you could have spent actually implementing, on thinking up highly engineered designs that cover all sorts of future hypothetical situations and relationships, is almost always a waste of time when you start out. Don't make an engine, make a game. Choose the absolute simplest path you can for putting something playable on screen, and iterate from there. Just make sure to be diligent about refactoring whenever there's any need, and the engine will take care of itself.
|
|
#
?
Nov 14, 2010 01:04
|
|
|
Vinterstum posted:Don't make an engine, make a game.
|
|
#
?
Nov 14, 2010 01:16
|
|
|
Orzo posted:I appreciate the advice, but I'm actually pretty interested in the engine design. This is a side project, not my job, and I'm just as interested as great engine design as I am great game design. The point is that unless you have experience with a couple of game projects already (your own, or in a team, whatever), thinking up base engine designs is about as useful as working out a football strategy without ever having watched an actual football game. It's starting out in completely the wrong end of things, and you'll probably end up with something which just isn't going to be a good fit for an actual project and will need to be redone anyway.
|
|
#
?
Nov 14, 2010 01:33
|
|
|
Vinterstum posted:The point is that unless you have experience with a couple of game projects already (your own, or in a team, whatever), thinking up base engine designs is about as useful as working out a football strategy without ever having watched an actual football game. It's starting out in completely the wrong end of things, and you'll probably end up with something which just isn't going to be a good fit for an actual project and will need to be redone anyway.
|
|
#
?
Nov 14, 2010 01:36
|
|
|
Vinterstum posted:The point is that unless you have experience with a couple of game projects already (your own, or in a team, whatever), thinking up base engine designs is about as useful as working out a football strategy without ever having watched an actual football game. It's starting out in completely the wrong end of things, and you'll probably end up with something which just isn't going to be a good fit for an actual project and will need to be redone anyway.  I posted it on SA once and a bunch of people had some fun with it, I should dig up a working copy. Years later I searched for it and found some random people had put up youtube videos on how to beat some of the levels. http://www.youtube.com/results?search_query=crystalex+game&aq=f
|
|
#
?
Nov 14, 2010 02:05
|
|
|
Orzo posted:I have completed a game before Great! Time for another one then .
|
|
#
?
Nov 14, 2010 02:17
|
|
|
For a project of large scale with dozens developers and thousands or millions of users, it's important to think of a good architecture that will support the needs of its development distribution and use. For a project of small scale with one developer and less than a thousand users, who gives a gently caress? Just code it the way that's easiest. Don't waste time thinking about the foundation when you're building a teepee.
|
|
#
?
Nov 14, 2010 06:10
|
|
|
Edit: Yeah, I was just being a dick here. Move along.
Pfhreak fucked around with this message at 06:33 on Nov 14, 2010 |
|
#
?
Nov 14, 2010 06:22
|
|
|
Orzo posted:However, both would OFTEN have a reference to the same Transformation object, since both drawing and collision detection rely on positin, rotation, etc. So, a monster, for example, would be represented by an instance of Renderable and an instance of PhysicsModel, but neither of those things 'know' about eachother. After all, why would they? However, because 'moving' the monster affects both, they share a pointer to the transformation object. In general though, the physics model should expose attachment points, the renderable (if you support attached objects) should expose them as well, and you should define some mechanism which makes it one-way. Easiest way to do this is make renderables bindable to physics attachment points and armatures, but not the other way around.
|
|
#
?
Nov 14, 2010 06:24
|
|
|
|
| # ? May 12, 2024 22:31 |
|
|
OneEightHundred posted:This is a pretty tough thing to answer because it varies heavily depending on the level of object interaction. Independent objects, attached objects, and controlled armatures (i.e. skeletal animation or multi-part vehicles that submit to the physics model) all require separate approaches.
|
|
#
?
Nov 14, 2010 08:13
|
|