[gameprogrammer] Re: Getting Started...
- From: Scott Harper <lareon@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Tue, 27 Feb 2007 10:26:25 -0700
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:
