OO / Design Pattern Question
Monkey Forums/Monkey Programming/OO / Design Pattern Question
| ||
Should I make a manager class, containing a list for "renderables" and a list for "updatables," and every tick have it render or update everything on the list, instead of going through all lists manually, eg.renderables.renderall() instead of particles.render(); guiobjects.render(); map.render(); What other dividends could be experienced from doing it the decoupled way? |
| ||
| I think it depends on the scale of your project. It would have to be pretty large and complex before it made much of a difference in most cases, I think. |
| ||
| I'm going to warn you from experience that doing it the first way leads to massive over complexity in small and medium sized projects. In large projects it would probably relieve something, I'm sure, but not in the others. |
| ||
| Like Gerry said, it depends. I'll throw in my two cents as well and note that there's no need to overengineer something until it gets complicated. Experience will teach you how much to engineer something ahead of time. This often involves a lot of refactoring, but I've learned the hard way that it's unavoidable -- if you try to out-think your future self, you'll just end up having to redesign it anyway, removing unneeded complexity and stuff when streamlining the next iteration. There's kinda no getting around it. Eventually you'll have enough boilerplate code down where this isn't so big of a concern anymore and you'll know what to do, but I feel like there's no skipping that learning stage. |
| ||
| Nobuyuki, by definition you follow the YAGNI principle. Which should probably be noted here as it encapsulates the topic of discussion quite well. |
| ||
| @Goodlookingguy I guess I just preached it, huh? But I totally don't practice what I preach 100%. For my framework I've designed several things in advance of when I've needed them even though I should "know better", just because my memory of good ideas isn't photographic. But even still, I'd forget things that were in there even when leaving comments for myself as to design decisions and all that, and some code ended up having to be redesigned, anyway. As a general rule, it just seems like if you're not going to use something you're coding right away, spending much time on it doesn't always pay off. The iterations needed to get to the usefulness of that particular design chunk have to be a clear and explicit path in your head, basically. A lot of that gets thrown out the window when writing library code, but again it seems better for commercial projects to polish off an nth iteration of working/practical code than to engineer a brand new radical design that hasn't been tested, lest you run into some extremely fun (ie: terrible) unforseen issues once it's entrenched. I've made this mistake before, too... :( |
| ||
| So did the Netscape team. However, without such experience you can't expect to know about the problems with doing that. I certainly know in my younger days I'd done this sort of thing. |
| ||
| Should I make a manager class, containing a list for "renderables" and a list for "updatables," and every tick have it render or update everything on the list, instead of going through all lists manually, minib3d uses the manager class, "TRender", executed by RenderWorld(). though, the api also offers ways to render things individually. Animation and physics is done through UpdateWorld(). now, one place where you *could* have problems is through layers. if you need one layer to render on top of everything else (HUD, GUI). then you would want that control of rendering something after all others. but this could be controlled using extra function calls or interfaces to the manager class. |
| ||
| Something like minib3d is a good case for using a manager if it simplifies the library interface for users, I think. But if you're writing a typical small to medium game in your own code, then particles.render(); guiobjects.render(); map.render(); ...is probably actually easier to comprehend. Not to mention easier to write in the first place, and to change, if you decide the particles should probably be on top. |
| ||
| Thanks gents. I've been programming for a long time but primarily in C and C-with-classes so a lot of the possibilities of OO are only lately becoming clear to me after a few years of using OO languages, primarily Mark's languages and Python. One other thing I'm working on is a runtime tweaker that adds boxed variables to a list of tweakables, with a menu in the console to allow adjustment of gameplay variables. The possibilities are really mindbending as you move toward runtime manipulation of functions as data... |
| ||
| These days I'd just go for the second approach. Having tried many times to write generic game frameworks / managers / whatever you want to call them, in various languages, I've found that the only way for me to write an actual game is to forget frameworks and just write the game. Frameworks just result in me spending all my time writing and tinkering with the framework and never getting to the actual game :-) |
   |