[gameprogrammer] Re: Getting Started...


On Feb 27, 2007, at 3:34 AM, Chris Nystrom wrote:


On 2/27/07, Scott Harper <lareon@xxxxxxxxxxx> wrote:


Anyway, I hope for this project to become a nice game, but also I
would like to open my framework up for community modification when I
get closer to having things ironed out and they aren't in such a
constant state of flux.  I think there are at least a few classes I
have, for instance, which have redundant/unnecessary data in them.


If you are planning on opening up your sources, you might consider
opening them up earlier rather than later.
I would be all for this, actually, as it would allow me the opportunity to get things more "right" from the get-go. ^_^ Um... any suggestions on how? I've never started an opensource project before... ^^:;; I guess sourceforge.net is the way to go? Is it all pretty straightforward from there?
I'll check it out on my own as well, though. Any suggestions for a decent name? I was thinking something like "Open-Abstractiong Framework" or "OAF", as it's not an engine, but an extensible framework for someone who wants to write a game but not have to write all the small details in between over and over again. 

Here's my basic hierarchy setup of objects calling each other:

Game
-Scene
--Layer -> View
---Entity
----Form
Game : sets basic information about the game, and switches scenes, etc... Only one Scene is on at any time. Scene : Middle-management object which is called each refresh, and send commands down to process and draw each layer. Layer : Contains a View and Entities, and is much like a sub-scene. As far as I can tell, this needs to be placed in to the scene in order-of-drawing, meaning if you have a background 3D layer, it needs to go in before the 2D overlay. View : Contains information on how to set up the rendering environment, such as 2D/3D projection. A Camera Entity object in the View would likely have a reference to a View object to tell it how to react and change as the game is played. Entity : The logic behind game objects. Contains a Form (see below). Entities are the process objects, they specify information like size, rotation, position, etc... for the in-game objects. User input is handled at this level for each object affected by making "InputRegister" objects with a static "InputManager" class. Form : Simply information on how to draw something. This can be anything from a hard-coded colored square, to having an initializer method which loads 3D models and animations (not yet implemented... ^_^).
Entities in the game also communicate with each other. I have a simple messaging system set up whereby any entity can call it's Layer (okay, the layer is a newer idea that I have to work in this afternoon after class, but it'll be there!) to check for collisions against any Entities registerd as "collidable" with the layer. If one is found, it can then send that object a message. Entites can then examine the message and choose to react, etc... 

Let me know what y'all think! ^_^

-- Scott

---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html

Other related posts: