Davaris

Dynamic Game Object Component System for Mutable Behavior Characters http://www.josericardojunior.com/docs/DGOCSMBC_SBG08_1.pdf EDIT: This has links to his source code. http://sertao3d.blogspot.com/2008/01/data-driven-game-development.html His forum discussions. http://www.jmonkeyengine.com/forum/index.php?topic=6980.0 http://www.jmonkeyengine.com/forum/index.php?topic=6980.15 Unfortunately the engine is in Java, but you might get some good ideas.

Thanks for this.

This article discusses and solves the communication problem nicely using Java generics. I don't know if you can apply it to C++ or not. http://t-machine.org/index.php/2010/05/09/entity-system-1-javaandroid/ He reduces it down to the following. e.getAs( Position.class ).x = 5; e.getAs( Damage.class ).hitpoints = 145; e.getAs( Renderable.class ).foregroundColour = Color.red; If you could call functions using that system and from scripts, it would be a dream to use. int retVal = e.getAs( Position.class ).SomeFunctionCall(param1, param2, param3); e.getAs( Position.class ).FunctionCall(ref param1, ref param2, ref param3); EDIT: Looking at that again, I'm thinking if you need to do the above, you may as well link the components together.

Continuing from what we were discussing last night, the other reason I think the Properties Pattern might be useful for rapid development, is while it uses inheritance, it is not static inheritance (I hope I am using the term correctly), where related classes must be stacked on top of each other. Instead, unrelated objects can be dynamically linked together in a vertical structure, so everything can be accessed and overridden, from an update script situated at the bottom. It will be an ugly ball of code at the base, but if it is all in scripts written by your users, it may not matter so much. With the Object Components method, you have a flat structure where each object must look left and right for components it needs to access and control, so you have the problem of components sending messages and getting data from each other, while preserving the all important loose coupling. I haven't seen if you have solved this problem yet, but the solution needs to be simple, it must not create extra work and it must be available to script programmers. EDIT One other thing I'd want for an Object Component system is the ability to call functions in other components that calculate and return a response. I assume that is easy to do with your event class. Anyway I haven't made up my mind yet. I'm still weighing the pros and cons of each system. These are the relevant articles for anyone who wants to join the discussion: Properties Pattern http://steve-yegge.blogspot.com/2008/10/universal-design-pattern.html Object Component Pattern http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://gameprogrammingpatterns.com/component.html

Oh wow. About time as well. If their products can be successfully used in games, that would be awesome.

From what I understand they are remaking the Blender interface. I haven't seen it, but I read a comment where someone said it is similar to Cinema 4D. Check out the 2.5 alpha here: http://www.blender.org/download/get-25-alpha/

I was using abstract as well. Depending on which directory I started it in (the one with engine.exe or GUI scripts home directory) it would say it couldn't find the paths for all 5 dds files or it would not be able to find paths for the first 4 files and then for the 5th it found the path but couldn't load the dds.

Would that affect its ability to find texture files?

I can't get this to work at all. I've tried running guitest.lua and guitestnew.lua in their Scripts/GUI directory and it says it can't load the textures because the path to the .dds files are not found.

Thanks Niosop!

I love this community! Thanks Chris.

I just tried changing the compatibility of the exe I am generating, but it made no difference to the fire pit. EDIT Might be Win7 64 bit!

I think this is it: void LuaTools::SetScriptObject( const std::string& name, BP o ) { int size = GetStackSize(); PushObject( o ); SetGlobal( name ); SetStackSize( size ); }

In GameLib this function is called: void TGame::Initialize(int sx0, int sy0, int fullscreen) { scene.Initialize(sx0,sy0,fullscreen); scene.game=this; gamelib_callback=this; luat.Create(); // create the LuaTools object luat.SetScriptObject("fw",scene.framewerk); // set the Lua variable fw

I think it is initialized in GameLib. BTW I just deleted that post because it was freezing my browser. Sorry about that.

It works perfectly in the editor for some reason.

Just tried it and the Windmill still doesn't spin and the fire barrel behavior is unchanged: there is light and sound, but no visible particles for the fire or smoke. I don't know if Josh has updated those scripts though.

I haven't been able to get the burning barrel to show fire or smoke, or the windmill to spin, so I'll have try them out with a compatibility change as well.

I just fixed it. I altered the compatibility mode to WinXP SP3 and now it works! The SDK was in the Program Files (x86) directory, so I don't know why it did not properly.

Win 7 Pro 64 bit AMD Phenom II X3 720 2.8GHz GeForce 9800 GTX/9800 GTX+ 4 GB RAM

On mine it isn't showing the transparent red rectangle. In the example just before it uses: function FlipHook() SetBlend(1) SetColor(Vec4(1,0,0,0.25)) DrawRect(100,100,GraphicsWidth()-200,GraphicsHeight()-200) SetColor(Vec4(1,1,1,1)) SetBlend(0) end and it works in that the red rectangle is visible. On the one I posted above, it doesn't work, even when I copied it to my SDK directory which is updated. So if it works for you guys it might be a bug.

I'm going through the Getting_Started_With_Lua.pdf and I just got up to the AddHook part and I can't get the DrawOverlay hook to work. Can anyone see what I am dong wrong? require("scripts/constants/keycodes") require("scripts/hooks") --Register abstract path RegisterAbstractPath("") --Set graphics mode if Graphics(1024,768)==0 then Notify("Failed to set graphics mode.",1) return end world=CreateWorld() if world==nil then Notify("Failed to initialize engine.",1) return end gbuffer=CreateBuffer(GraphicsWidth(),GraphicsHeight(),1+2+4+8) camera=CreateCamera() camera:SetPosition(Vec3(0,0,-2)) light=CreateSpotLight(10) light:SetRotation(Vec3(45,55,0)) light:SetPosition(Vec3(5,5,-5)) material=LoadMaterial("abstract::cobblestones.mat") mesh=CreateCube() mesh:Paint(material) ground=CreateCube() ground:SetScale(Vec3(10.0,1.0,10.0)) ground:SetPosition(Vec3(0.0,-2.0,0.0)) ground:Paint(material) light=CreateDirectionalLight() light:SetRotation(Vec3(45,45,45)) function DrawOverlay() DrawText("DrawOverlay",0,50) SetBlend(1) SetColor(Vec4(1,0,0,0.25)) DrawRect(100,100,GraphicsWidth()-200,GraphicsHeight()-200) SetColor(Vec4(1,1,1,1)) SetBlend(0) end AddHook("Flip",DrawOverlay) while AppTerminate()==0 do if KeyHit(KEY_ESCAPE)==1 then break end mesh:Turn(Vec3(AppSpeed()*0.5,AppSpeed()*0.5,AppSpeed()*0.5)) UpdateAppTime() world:Update(AppSpeed()) SetBuffer(gbuffer) world:Render() SetBuffer(BackBuffer()) world:RenderLights(gbuffer) DrawText(UPS(),0,0) Flip(0) end

To be honest I think it is much easier getting started with GameLib, than going through all the tutes and trying to build something from scratch. Once you get a world loaded and you can run around in it, it will do wonders for your confidence. Perhaps we need a GameLib LUA version? Or perhaps one already exists?

I was going through the LUA Tute and saw it has a debugger, which tells you when you have an error which is great. The only problem is it doesn't tell you what line number the error is on. So my request is can we have line numbers included in the error report? Once a script starts to become large and complicated, no line numbers on the error messages, will make them very difficult to find. --Register abstract path RegisterAbstractPath("") --Set graphics mode if Graphics(1024,768)==0 then Notify("Failed to set graphics mode.",1) return end world=CreateWorld() if world==nil then Notify("Failed to initialize engine.",1) return end mesh=CreateMesh() mesh:Point(nil)

I chose Leadwerks over Unity and Unreal, because I preferred the look of the Leadwerks renders. Also I didn't like the cost of Unreal (25% of all earnings over $5000?). With Free Unity, apart from what people have said about shadows, it has no C++ and no C++ was a deal breaker for me, because I have tons of old code I want to reuse. Also there are lots of great open source C++ libraries that I wouldn't be able to use with Free Unity.