What to include in my "level" code
So far this is what I have. I use lua but it doesnt really matter. (this is not in any specific order)
Bunch of requires (includes) of all game objects used in this level.
load them into memory. (for now, game isnt really complicated/big enough to load when needed)
---Define collision groups
---Placement of any initial objects into scene. (Buttons, HUD, starting guy)
---Load game rules ( functions to be used to handle game interaction)
---Handlers for events/leverage game rule functions. this includes input.
---function for releasing/deleting all game objects in this level.
There is a lot here, and I know that some of this will exist seperatly from a level. but the game level needs to include and define all of this and associate the relationships between these things.
comments?
[Edited by - AverageJoeSSU on April 19, 2010 6:23:21 PM]
Quote:Original post by theOcelot
You mean what to include in your Lua script?
kind of.... that is what i intend to include above... and more so how to organize such things in a level file. game logic only exists at the lua scripting level, everything else exists at the engine's native level (physics, rendered objects). a game object in lua has a reference to a rendered object (which would be loaded by referring to the level file and include (aka require) ).
In that case, I can only tell you what I would do in your place. I'm only just beginning with Lua myself. [grin]
How are your game objects defined? Can they be defined both in and out of a level?
How are your game objects defined? Can they be defined both in and out of a level?
absolutely, i intend to provide a script that implements each object... with functions (at least in the context of this thread) for each game object.
for example.....
Cube.lua will have code to create/load a cube.
the level file would do something like
Then functions like this would be provided
then placing an object in the scene goes something like so
So that is how i see it happening.
that is just loading and creating objects in the level, let alone plugging in the game rules (i have an event system so the game rules will most likely be heavily event driven).
1 way of doing it (and this is just general practice using a random example) is when a collision event fires with 2 objects, i have a function that checks the types of the collided things and calls various game logic (just functions) based on what they are. So if object1 is a bullet and object2 is a player, then something like object2:TakeDamage(object1) or something.
for example.....
Cube.lua will have code to create/load a cube.
the level file would do something like
local Cube = require "Game.Objects.Cube"
Then functions like this would be provided
Level = {}Level.Assets["cube"] = Cube.Load()
then placing an object in the scene goes something like so
Player1 = Level.Assets.cube["create"](x,y,z) --Would return a cube game object at x,y,z.
So that is how i see it happening.
that is just loading and creating objects in the level, let alone plugging in the game rules (i have an event system so the game rules will most likely be heavily event driven).
1 way of doing it (and this is just general practice using a random example) is when a collision event fires with 2 objects, i have a function that checks the types of the collided things and calls various game logic (just functions) based on what they are. So if object1 is a bullet and object2 is a player, then something like object2:TakeDamage(object1) or something.
Do you mean:
Or does Cube.Load() really return the actual creation function?
I think the loading code looks too complicated. I'd rather see something like:
But what I'm really interested in is what Cube.lua looks like, and how your events get wired up. Everything kind of depends on how the game objects expect information to be passed to them, and how they process it.
Level = {}Level.Assets["cube"] = Cube.Load
Or does Cube.Load() really return the actual creation function?
I think the loading code looks too complicated. I'd rather see something like:
require("Cube") --or whatever it's calledmycube = Cube.Create(x, y, z)--creates a cube--and automatically puts it in the scene--no messing with Level.Assets required :)
But what I'm really interested in is what Cube.lua looks like, and how your events get wired up. Everything kind of depends on how the game objects expect information to be passed to them, and how they process it.
Ah... so an important thing to realize is that when mycube is declared as a global, garbage collection becomes/can become an issue. this is a huge discussion in and of itself. But the bottom line is that keeping my objects in a table keeps them from being global, and leaving them tied to the lua registry.
a reference thread for this can be found here...
http://www.gamedev.net/community/forums/topic.asp?topic_id=543652
and the thread the guy is talking about can be found around the same timestamp as that thread. phew
Anyways.... what gets returned in that initial Load() function call is a number that is used by the engine to refer of a cube type.
basically...
--pass a bunch of data to engine describing object (Load)... engine returns number that is id to this object description.
--when you want an object with that description, pass the id along with object creation stuff, and the engine will create that object using the id to refer to its description.
My cube.lua script is all in one right now (hence me trying to design/implement a level abstraction)... but you can see the functions in action... and a cube actually being created.
On a different note though... level code.. haha.
I do see your point with that... and in fact... i tried to do that, but my lua mojo is not vast so i struggled a bit with loading the assets (mesh texture etc) with the require call.
anyways... There is a lot here... and really what i have left besides organization is the game rules.... for example a damage table and interaction of different objects. I have the straight-forward way of just having different functions that handle different object types and events. but i was curious if anyone had any other ideas.
a reference thread for this can be found here...
http://www.gamedev.net/community/forums/topic.asp?topic_id=543652
and the thread the guy is talking about can be found around the same timestamp as that thread. phew
Anyways.... what gets returned in that initial Load() function call is a number that is used by the engine to refer of a cube type.
basically...
--pass a bunch of data to engine describing object (Load)... engine returns number that is id to this object description.
--when you want an object with that description, pass the id along with object creation stuff, and the engine will create that object using the id to refer to its description.
My cube.lua script is all in one right now (hence me trying to design/implement a level abstraction)... but you can see the functions in action... and a cube actually being created.
function createCube() Cube = {} function ForDeath() EngineManager:Release(self.ID) end function ForCubeCreation(x,y,z) local Object1 = {} print("Lua::CreatingCube") Object1.defaults = Cube.properties Object1.hp = Object1.defaults.MaxHP Object1.ID = EngineManager:CreateObject(Object1.defaults.Type, x,y,z) RegisterEvents(Object1) return Object1 end function RegisterEvents(Obj) EM:Subscribe(Obj,"LMouseDown") EM:Subscribe(Obj,"W") EM:Subscribe(Obj, "Collision") function Obj:W() print( "Object1 W key Pressed" ) end function Obj:Collision( CEvent ) t = CEvent:getObj2ID() d = CEvent:getObj1ID() print( t .. "," .. d .. ":and my ID:" .. self.ID ) end function Obj:RMouseDown() print( "Object1 got Right Mouse Down" ) end end Cube.properties = { mesh = "..\\Content\\Models\\asym.obj", --JA: Want to move the following def's to our own format possibly, so we can just import one file. texture = "..\\Content\\Models\\235.bmp", normalMap = "..\\Content\\Models\\235-normal.bmp", terrain = false; collisionGroup = 1; Type = 0, --0 means no type from asset manager = bad Mass = 100, Scene = 0, MaxSpeed = 25, MaxAcceleration = 5, MaxHP = 1000, --Lua Only Properties for Game Logic Armor = 1, Events = { OnCreation = ForCubeCreation, OnDeath = ForDeath } }end createCube() Cube.properties.Type = EngineManager:LoadAsset(Cube.properties)Cube.properties.Events["OnCreation"](0 , 3 , 0)
On a different note though... level code.. haha.
Quote:
I think the loading code looks too complicated. I'd rather see something like:
require("Cube") --or whatever it's called
mycube = Cube.Create(x, y, z)
--creates a cube
--and automatically puts it in the scene
--no messing with Level.Assets required :)
I do see your point with that... and in fact... i tried to do that, but my lua mojo is not vast so i struggled a bit with loading the assets (mesh texture etc) with the require call.
anyways... There is a lot here... and really what i have left besides organization is the game rules.... for example a damage table and interaction of different objects. I have the straight-forward way of just having different functions that handle different object types and events. but i was curious if anyone had any other ideas.
I'm still confused. So Load() loads all the assets for the Cube object type, and then returns a creation function that has all these assets already marshalled? Where does the ID come in? Whatever Load returns, you seem to be accessing members from it.
The way I currently handle asset loading is that a single string serves as a handle to a glob of information containing the image filename and its animation sequences. All this is handled and loaded on demand by the engine. The way I guessed Cube.Create(...) would work is that it would request a basic game object from the engine, giving it just the information required to load assets on its own. Internally, they would be loaded on demand and cached.
The way I currently handle asset loading is that a single string serves as a handle to a glob of information containing the image filename and its animation sequences. All this is handled and loaded on demand by the engine. The way I guessed Cube.Create(...) would work is that it would request a basic game object from the engine, giving it just the information required to load assets on its own. Internally, they would be loaded on demand and cached.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement