Jump to content
  • Advertisement

humpolec

Member
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

122 Neutral

About humpolec

  • Rank
    Newbie
  1. Looks OK, but remember you'll need garbage collection done somehow.
  2. I see OpenGL has a very convenient set of matrix operations, which allows programmer to render an arbitrary object in whatever position/rotation/scale they want... but what if I want to actually know the coordinates in some common reference system? For example, I render a complex 3D model at a given position and rotated by a given angle, and want to know world coordinates of its points (for example, to perform collision detection). Is there a way I can use OpenGL for that, or do I have to do all the math again myself? And if I have to do it myself, what is the most common way to do it in C++? Write my own set of functions, or is there some simple library for that?
  3. Quote:Original post by Zahlman(I really can't think of a sane game design that requires a Monster to know what Level it's on, except perhaps as a level *number*, i.e. depth in the dungeon.) Using your example, a monster may want to lit a lamp, or cast an area-effect spell that illuminates area around the monster, which in turn would trigger Level::illuminate(). Of course, all monster actions could be handled by Level, but I still don't understand how that should be better, if the monster abilities, skills, inventory, AI strategy etc. are stored in the monster object. Quote:Also, assuming C++, please use references where you can, and pointers only where you really need to. Actually I want to try out D (which encourages references everywhere, much like Java), but I don't think that makes a big difference in design. :)
  4. Quote:Generally, a monster shouldn't care what square it's it. The method that might belongs in square and acts on a monster (or is a free function/functor that acts on a square and a monster). I think actions such as walking or dropping items (and monster actions in general) should be handled by a monster. Quote:Original post by Spoonbender In any case, are we talking about enough squares to actually make this become a problem? A 1000x1000 grid would require a million extra pointers. At 4 bytes each, that's 4MB. Hardly a big problem on today's computers, is it? Of course, if you have 100 levels of this size, and you need to keep them all in memory at the same time, it starts getting more expensive. So work out approximately how many pointers we'd be talking about, and you can easily determine whether it'd be a problem. No, I don't think the data size would be a problem. It just seems a waste. Looks like this would be the simplest way, though... Quote:Error-prone? How so? When you work with a monster, you tell it which level/square it should act on. That seems pretty fool-proof to me. It looks dangerous to me because it'd be possible to pass a wrong square object to the monster, which can happen for example in a function handling interaction between monsters, or movement.
  5. Consider a RPG/roguelike game in which we have a number of levels (let's assume I want to simulate all of them at once), level consists of a grid of squares, a square can contain a monster, and a monster owns a number of items. When I model this as Level, Square, Monster and Item classes, I find that Square's methods may want to know which Level it's on, a Monster may want to refer to its Square and Level, and Item has to know its owner, etc. How to model this relationship? 1. The obvious solution that comes to mind (and what looks most OO-ish to me) is to make a reference to the owner in each class - that is, Square has a Level pointer member, etc. This looks nice, but creates a LOT of unnecessary pointers - we already know that Monster A is on Square B which is on Level C, because Level has an array of Squares, which has a pointer to the Monster. 2. I can make all the methods require the context as arguments, and just pass the pointers around when calling them - that is, Monster methods receive Level and Square pointers. This avoids creation of tons of unnecessary pointers, but is awfully verbose and error-prone. 3. I can also make these classes temporary wrapper classes - for example, I store all the Square info in a simple struct, then create and pass around a temporary Square object (with a pointer to square info, pointer to level, and all the methods) when necessary. This also looks a bit ugly, though. 4. ???? Do you have any suggestions? This looks like a frequent OO design problem...
  6. humpolec

    Public dream diaries

    forum.ld4all.com is a great site about lucid dreaming (if you don't know what lucid dreaming is, ask Wikipedia, it's very cool). There is a dream diary area where members post their DD's, you have to register though. I often had dreams about games I played before. Also I heard that there's a connection between playing Tetris before sleep and good dream recall. [duh, the website is down. it should be working again soon, though.]
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!