Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 31 Oct 2009
Offline Last Active Mar 20 2012 11:39 PM

Posts I've Made

In Topic: Implementing Objects with specifications

18 March 2012 - 04:15 AM

I would go for the first method, but with the modified class bollu suggested.

Are you planning to store the stats of the weapons in a text file? or a database? or an xml file? Seems the first method would work nicely with any of those.

In Topic: recommended ways of storing game entities and state game structure

18 March 2012 - 03:08 AM

@YogurtEmperor Not only did I find that useful, I read it when I found it on google from an old post you made! Thanks!

@Postie Yep, sometimes I feel as if I just need a confirmation from others that what I'm doing is within reason. Thanks as well!

In Topic: recommended ways of storing game entities and state game structure

17 March 2012 - 08:19 AM

Thanks for the replies!

I've already change my design slightly (still feels a bit off, but it's slowly getting better). I'll definitely just keep working on it to help discover more design flaws that I can work into fixing in the next iteration of the engine. It's been a great learning experience already.

Did you guys have any comments specific to storing textures? How would your draw functions in your various game entity classes access the textures? Should each class be storing a reference to it's own texture for binding and rendering? Should they be centralized in any specific way? Is it a bad idea to have a single class with static variables and functions to hold the texture files and control binding?

In Topic: recommended ways of storing game entities and state game structure

15 March 2012 - 05:19 AM

I'm not sure why many of your classes would need a reference to the Key or Mouse handlers. To my mind, there should be a single part of your code concerned with handling mouse or keyboard input (somewhere in your user interface layer), which then sets gamestates or something similar to act on that input. It'll be easier to maintain if all your input is centralised somewhere.

Oh, I should have probably been more specific about this but the keyHandler and mouseHandler classes just hold a hashmap of which keys were pressed (for the keyHandler) and which location on the screen was clicked (for the mouseHandler). They don't handle the events (the JPanel uses key bindings and a mouse listener to do this), more so just store what event was triggered. Every game state would need access to these since I have to be able to processEvents in each game state. Same with each component of the screen (inventory, etc).

In Topic: recommended ways of storing game entities and state game structure

15 March 2012 - 05:09 AM

Thanks for the replies everyone. It really does help get me thinking.

The resource manager initially also had the player class in it (which I moved to the entity manager), but at the moment I have the world class, the game engine and mouse/keyboard handlers. I'll have a think how I want to redesign things to hopefully make more sense. I really don't like the way I've done things (which is why I decided to ask here), but for the time-being that was the simplest way I could think of doing it. So at the moment it does kind of include both system resources and game resources.

Does this mean in general when writing a game people pass references of what each class needs as they create the class? It gets pretty messy since I feel as if so many different classes need access to so many different other classes (but that's probably a huge design flaw I currently have).

Are there classes that you guys (when writing a game, simple or complex) generally have shared with the whole system?

What about with texture handling? At the moment I have a texture manager which basically just holds a public static reference to the sprites atlas for binding and getting the correct texture coordinates in the sprite atlas.