Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

296 Neutral

About Ariste

  • Rank
  1. Ariste

    Some Newbie Questions

    Quote:Original post by return0 That is totally untrue. Getters and setters are considered bad form in pure OOP. Ok, you're probably right. More like, most introductory books will tell you everything should have a getter/setter. But the important point is this: Quote:Original Post by oler1s If something is private, the idea is that it is an implementation detail that the public should not care about. To then provide a public interface to private data prevents abstraction. Now the public knows about this implementation detail. Getters/setters contribute to an interface and an abstraction. The question to ask is: are you building the right abstraction? Quote:When you mark something as private syntactically, but then provide a public getter and setter, what behavior have you modeled? You just reinvented the notion of a variable This isn't necessarily true. One of the benefits of getters/setters is that they abstract the notion of access to a property. If you want, for example, to change a value so that it's computed instead of cached, getters/setters allow you to do this without modifying external code. Of course, whether you need this kind of abstraction depends on the situation and your preferences.
  2. Ariste

    A question about learning C++

    You should be able to start on a library after finishing your first book. As long as you understand the basics, the best way to learn any language is to use it. You'll learn more making a Pong clone than you will reading a whole slew of beginner books. Having said that, it's probably a good idea to work on some smaller, console-based projects before you jump into 2D graphics. You can do this as you read, if you like. It'll help you better understand the language fundamentals, so you don't get caught up in them when you should be learning how to use Allegro or SDL.
  3. Ariste

    Help creating an interface

    Do you have a question?
  4. Check here for some info on wrapping Win32 window functionality.
  5. Ariste

    Some Newbie Questions

    Quote:Original post by milan_b Does this kind of thing come with experience, or is there a guide to stuff like this? Mostly I think it comes with experience. Try to design classes such that they handle a single problem, and fully abstract this problem so that client code doesn't have to deal with it. The single responsibility principle is a good guide. Quote: After I'm out of college in 3 years, I will be looking for a game programming related job, but until then I'm just practicing and (eventually) going to build up a portfolio of games. Most professional games are written in C++, so it's a good idea to become proficient in it. Having said that, it's always good to know multiple languages. And once you learn one, it'll become much easier to learn others.
  6. Ariste

    Some Newbie Questions

    Quote:Original post by milan_b My questions are: How do you structure a program so that it's easier to read and organize? For example: should I be making getters and setters or just set the properties to be public? OOP purists will tell you that everything should have a getter/setter. In reality, they aren't always necessary. I try to mostly use accessors, except in the case of straight up data structs, in which case I use public properties. If you're worried about efficiency, you can always use inline. The important thing is that you try to minimize access to member data at all. If you're giving outside access to a class's property, first make sure that you can't eliminate the need for such access by modifying or sharpening your class's abstraction. Do outside entities really need access to this variable? Can this class handle everything itself? Quote: Should I switch to Python to focus more on game logic rather than dealing with C++'s complexity? I plan on learning both languages anyway eventually. My next project is going to be a 2D side-scroller and I'm doing 2D projects for a while, so speed isn't too important. That's really up to you. Why are you learning game development? Do you want a job, or is it just for fun? What are your goals?
  7. Ariste

    Why is this null

    I'm not sure what your problem is, but my God those are some long type names =P
  8. Ariste

    Scripting with Lua

    Quote:Original post by rasher_b2 Quote:Original post by Ashaman73 Well, this is not an issue with including a script language into your game. Using trigger, ticks , updates etc. could be all solved completly in c++ or in lua. The question is, where to make the cut :-) Yep, could be done in either but just need to decide where to separate things. I did have an Entity with tick, etc. functions in C++. However, after some thinking and prototyping, I have decided to split things a bit lower down so entities only exist on the Lua side of things. This means I just handle things like rendering, physics, etc. on the C++ side. What I'm doing now is creating a Lua state when my game starts. I keep this state around until the game exits. Lua can use the C++ API to create game states (a game state is something like the menu, game world, pause menu). As the game loop runs, it calls a tick function in Lua that runs the active state's logic. Input events are also propagated to the Lua code. I'm not sure how much sense that made. I've left out many details but it's been working well for me so far. I'll elaborate if anyone wants to continue the discussion. I do something similar. Basically, the engine exposes as much functionality as possible and allows Lua to control it from the outside.
  9. Ariste

    Rendering Design

    Quote:Original post by aqez Because I've never tried that before.. who knows. So anyway the point of the post.. I have a few questions: How expensive will the virtual calls be because of the IRenderable interface and dynamic binding of the objects in the vector/stack? Will allocating new stacks and adding them to the vector be a costly operation? I've not worked too much with the STL I've usually rolled my own data structures but now I've become a bit more wise in not re-inventing the wheel - thats for the masochists out there, although I am glad I've done it at least for the experience and knowledge of how they work. My guess it that the overhead will be pretty negligible compared to the cost of actually rendering the objects and other operations, like physics or AI. Of course, there's really only one way to find out :) In general, aim first to get it working, then to get it right. You can always optimize if you find it's too slow. Someone famous once said that premature optimization is the root of all evil, and I think that's pretty good advice.
  10. Ariste

    Class Relationships

    To answer your last question: If the dependency must exist, then it's not a problem. In fact, passing around pointers/references is probably the cleanest way to deal with these kinds of dependencies. It's not "unclean" that one class depends on another class; such dependency is a product of the natural relationship between the two objects you're trying to encapsulate. In your design, a Renderable does depend on a Renderer. The best way to represent this in code is to require that Renderable be passed a reference to a Renderer. Having said that, you can eliminate the dependency between Renderer and Renderable by making Renderable more like a container for geometry and material data which is read and interpreted by the renderer. In your design, what is the distinction between mesh and model? Why do you need a hierarchy of renderable objects? And why must Renderables know how to render themselves? If, instead, you eliminate the hierarchy and turn Renderable into a geometry container to be interpreted by Renderer, you eliminate the need for the dependency between them. Renderable then need only be supplied with raw geometry and material data, not a reference to a Renderer.
  11. Ariste

    Component-Based Entity Help

    Quote:Original post by crancran Some claim it is acceptable for a component to ask the owning entity to return a reference to another owned component should the two components need to operate on one another. But in my eyes, this again puts a strong link on the two components, does it not. That's exactly how I do it. The thing is, certain dependencies just exist, whether you want them to or not. If your UI widget needs to know about the player's health, then there is a dependency. You can try to mask it with message passing, but all this does is obfuscate the dependency and your solution to it. It's better to acknowledge that the dependency exists and provide an appropriate interface for dealing with it.
  12. Ariste

    Component-Based Entity Help

    A lot of this, I think, is personal preference. I use your second method of component creation. I got the idea from here. I seem to be linking to that thread more and more lately :) If you follow the design suggested in the link, then the answer to your last couple of questions is that the data should be stored in the components. Ideally, data won't need to be shared or replicated, but this isn't really practical, so you'll need to allow components to access and talk to each other. The best way I've come up with to think about this design is that entities are acted upon by their components. They don't act themselves. Entities are simply a means of keeping track of which components go together, and they "change" whenever one of their components changes.
  13. Ariste

    Book about game design

    Quote:Original post by Nanoha Quote:Original post by dabo Perhaps architecture is a better word? Strongly reccomend Game Coding Compelte (favourable reviews on this site also). I've learned a great deal from it from general game architecture to tiny but fantastic little things. Also has a whole game developed later int he book (but I've never read that bit). Full source is availible online. ++this. Game Coding Complete is one of the best books I've read on general game design. It's also enormous, so it'll give you lots of time out on that hammock ;)
  14. What you're really talking about here is the difference between a hierarchy and a component system. The general advice is to prefer composition (i.e. your option B) over inheritance. It's more flexible and, to me, makes more sense conceptually. Look up "component entity systems" for some more info. This is a good start.
  15. What, exactly, do you find confusing about them? It's difficult to help you if you don't ask specific questions.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!