Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Nov 2011
Offline Last Active Dec 02 2012 05:19 PM

#5006353 Camera, Player, and GameObject Architecture

Posted by on 02 December 2012 - 01:41 PM

If you are using component-entity architecture (not sure if you are since you didn't specify), you could just create a CameraComponent and attach it to any entity with a Transform (x, y, scale) component. This allows you to attach the camera to any entity.

#4928826 Structure of a game framework?

Posted by on 06 April 2012 - 11:03 AM


I wanted to ask if there are any good ressources on how to structure a basic game framework.

I am not completely new to game programming, but all my games tend to have the same "ugly" structure, i.e:

-Player Class (which holds the attributes for the player, i.e. health, movementspeed, position,...)
-Enemy Class (almost the same as player, only with some sort of an AI)
-Game Class (extended from a jpanel, has an instance of player and a collection of enemies, handles input, drawing, looping, etc.)

My problem here is, that the "Game" class becomes bloated rather fast and with that it gets more and more difficult to add things to it.

So, are there any ressources you can recommend to look at, for a decent game framework structure?
Or can you give me some hints and tips on how to structure my games better? How to separate Input from Drawing and everything else?

PS: I doesn't need to be specifically for Java, I would appreciate it though.

First of all you should use inheritance. Your Enemy and Player classes should extend from a common [abstract] class, seeing as how they are so similar. You could call this "Entity" or "Object". You could create interfaces to support the AI which individual extensions of the class (ie, WolfEnemy) could inherit and edit to their liking.

As for keeping the input/logic and display seperate, you're going to want to use threads and java's concurrency packages. You could use a CyclicBarrier to signal the display thread to start rendering, and then reset it when you're done rendering so the input/logic thread can Sleep and then run a new iteration. Display and Logic/Input are generally handled on seperate threads in bigger games, *however* if you are doing something simple like Pong, or something that doesn't have very intensive math calculations, you could just stick Display and Logic/input on the same thread to simplify things (do *not* do this in a team setting) while you get the hang of things.

A few things for you to look at:

#4928737 [C++/GameProgramming] - Need help to get started?

Posted by on 06 April 2012 - 05:22 AM

Hi. I'm 15 and very interested in building games. I've been doing basic programming since I was 9, although back then it was just html and css. Now that I've moved on to fit closer to my interests I would like someone who could help me at times I get stuck, I'm going to be mainly working with C++, Lua, java, and python.. But the real big one is C++ because after the research I did that seems like the one most fitted for my needs. But I'm really just look for someone who can really help me when I'm stuck. I've got quite a bit of ambitions and really want to move forward.

OT: At your age I learnt Lua, I attempted C++ and just found it too difficult. I learnt Java and read a bit about pointers in C++ and it finally made sense, and then I was able to learn C++ with no issue. Just a tip ;)