Laurens
-
Posts
564 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Laurens
-
-
In its most basic form I would simply start running a counter the second the player's altitude is less than 0 (this may ofcourse not always mean the player is submerged, you probably need some more complicated algorithm to determine whether or not the player is under water). Whenever that counter hits 30, start decreasing the health of the player each update.
Game Coding Complete (Third Edition) defines a useful Process/ProcessManager for these sort of long running processes (i.e. spanning more than one Update call). I can highly recommend the book.
As far as the user interface is concerned you could simply make some health bar in Paint and do DrawImage (or whatever it is called) with varying width to represent the player's current health.
-
For example we would have two methods , one for the Initialisatio nof the entiity , the other called each engine frameUpdate for the entity :
This is what callbacks achieve without hardcoding a specific method that all entities must then implement.
-
Do you mean from a user interface perspective or from a programming perspective (as in the domain model)?
-
-
Wow, that C4 code made me cry even worse. It's a prime example of why I think Leadwerk's has a giant edge over the competition. Josh does not enforce some paradigm on us like C4 does.
-
I sometimes have to cry compiling open source libraries. True story.
-
As Metatron suggested, you need to write two class scripts, one on the wolf and one on the bird. Then, initialize its properties from the editor. Open up the atmosphere script as an example. Then there is also no need to maintain a separate table for entities, you can simply find any entity by doing FindChild on the scene.
As far as your common methods go, Leadwerks defines several callbacks you can use to run update logic. Take a look here: http://leadwerks.com/wiki/index.php?title=Entities#Callback_Functions Then you don't need to go about defining your own methods. I am not sure they are implemented in Lua though. You can most certainly use them in C/C++.
Before you start re-inventing the wheel, I would suggest you write some small (think Pong, Asteroids, Gorillas) clones to get a feel of what Leadwerks can and can't do. It will save you time later.
-
@Laurens :
You should open your mind a little more : Minecraft , Terraria, Limbo uses simplest possible **** graphics ... and well they are big big sucess no ? And there is a PS3 interesting title using vast sand landscape with the simplest graphics you could find also, and im' sure it will be a success.
I was not saying that. I was saying that **** art will look **** on any platform. Something that looks inconsistent on a PC will look inconsistent on a mobile platform as well.
-
I'd also like to argue that **** and inconsistent art will still look **** and inconsistent on a mobile platform, not negating the need to have both programming and art disciplines on your team unless you are some kind of prodigy.
-
I have spend the last two evenings trying to get CEGUI to compile, even without replacing the Lua implementations but slew of dependencies is hellish and I think I am going to give up on this one. I vaguely remember you having similar problems when you were trying to create a single DLL that contained all the dependencies for Leadwerks. In the spirit of moving forward I think am I going to hardcode the event handlers, which allows me to still define layouts in XML, just not the interactions.
-
You ask total control , that's your way of seeing game programming like lot of other people
I do not want total control, if I wanted total control I would be programming Assembly. I want a certain degree of control. And Leadwerks' offers me that control.
But you can't prevent other people to gain some Lua framework or some Lua more 3D artist oriented capability "like" Unity 3D .
I indeed can't and don't want to. But that still does not warrant a move to Unity,
Isn't it efficient and prooven to work even for 3D artists ? So why not LE3 with Lua going this way ?
Because this is a programmer-centric engine and the main reason why a lot of programmers got this engine instead of Unity.
But there is obviously no right or wrong. There is vanilla and strawberry. I do think, without trying to offend you, you bought the wrong engine and you should get Unity. It appearantly is everything you want. There is a free version you know.
-
Interaction between "players" and "characters" is such a specific feature I would find it highly undesirable to be forced into Josh' paradigm as far as the implementation would go (I'm starting to feel like and old record player). You keep iterating you want everything to be "simple". Let's take that to the extreme so I can illustrate my point. In the most simple possible case whe have a button that creates a game for you. Slightly more complicated you can define a genre. Even slightly more complicated you can specify additional parameters such as number of units or available weapons. You can see where this is going.
Then there is Unity. Allows you a fair amount of control. More complex is Leadwerks. Allows even more control. And that is why I bought Leadwerks and not Unity. Because it allows me control to the degree I want.
-
Hi Rick,
CEGUI can indeed call Lua functions but it does so in its own state. It has Lua 5.0.1 compiled into it and passing Leadwerks' Lua state as a parameter to the construction of the scripting module fails. Communication between CEGUI and Leadwerks is therefore not possible (so you can't call engine methods from the CEGUI state and vice versa) so next order of business is trying to recompile CEGUI and roll in LuaJIT as a replacement to "vanilla" Lua.
-
So I finally figured this thing out. I used the code I found here: http://cc.byexamples.com/2008/11/19/lua-stack-dump-for-c/ to debug the Lua stack at various points in the application. This is my final main loop:
Script* s = new Script(reinterpret_cast<lua_State*> (GetLuaState()), "Scripts/Game/game.lua"); while (!AppTerminate()) { UpdateFramework(); s->Run(); // calls luaL_dofile RenderFramework(); glPixelStoref(0x806E, 0); glPixelStoref(GL_PACK_ROW_LENGTH, 0); glPixelStoref(GL_UNPACK_ROW_LENGTH, 0); CEGUI::System::getSingleton().renderGUI(); Flip(); } delete s;It turns out only the first call to to s->Run() failed, and all others were fine. Appearantly simply calling CreateFramework() does not complete the initialization. Upon calling RenderFramework() the engine loads more resources and all subsequent calls to s->Run() work fine. Perhaps the Lua state is not initialized up until the first call to RenderFramework()? Anyhow, it is working perfectly fine now.
Thanks for the help!
-
Well, don't I feel silly. After getting some help on the LuaHub forums I managed to get MinGW to compile the import library but it turns out the compiler is fine with linking against a DLL so I didn't need it. The root cause of the problem was incorrectly including the header:
#include "lauxlib.h"
should be
extern "C" { #include "lauxlib.h" }I was unaware of the fact you needed to include C code like that. Anyway, it is compiling and running now, sort of. At the point where I run the file, I get a
PANIC: unprotected error in call to Lua API (attempt to call a string value)
though, but at least I got it running using Leadwerks' Lua state.
-
Actually , you have to load the entties by name and depending on the name : place a light or place X or Y entitie.
This is incorrect. I don't know who informed you or you may have misinterpreted the information given to you.
LoadScene loads all the entities within that scene and runs their Lua scripts. That includes models, lights, the universe and everything
No further code required.Than have some big table containing all dynamic NPC and manage their interaction.
That's a very specific implementation and most certainly not a must. It depends on your requirements.
Furthermore I highly agree with:
I think game engines are meant for programmers, and tools are meant for artists to produce art in a suitable format for the engine to use
-
If with LE3 i will be able to only have to script my game behaviour and have all entities, game tweaks, lights automatically loaded, so have to only "attach" code to entities, i 'll buy it.
This is already the case for the current version. Scripts are attached to classes and you can specify properties on individual instances. LoadScene loads all of these "automatically".
And LE3 have already the "open side" for 3D artists with new scripting and plugin systems, so both worlds : programming , 3D artists should be happy
!The current version does indeed not allow for plug-ins in the sense that you can't use them straight from the editor but I still don't see how Leadwerks is not "open". What would you define as an engine being "open"?
-
I did not mean to offend anyone.
Both Unity (and others such as C4 for that matter) do force you to follow the engine developer's paradigm.
Sorry, but anyone do any kind of game with unity.
I wasn't saying that. I was saying that you are forced to follow the engine developer's paradigm. For instance, in C4, your main application is required to extend a C4 class and compile your project as a DLL.
It is that hard to follow the simple rule of putting code in the method named "FrameUpdate()" ?? And sorry but lof ot simple commands are as simple as in LE to program, it's fluid also.
I find it highly undesirable to put all my code in one method. What advantage is gained by locking developers into this? What is keeping you from defining your own update method?
And its not Unity, they have not exactly same features and sorry but the price is totally different also
Where is the problem to open up the engine and let some people making plugins or templates to help 3D artists ?
The engine is completely open the way it is now, locking people into a paradigm forced on us by Josh would be closing it down. Mind you, that is not to say I am opposed to a plugin-model for the editor, I am impartial to that, but they are completely different things.
-
The problem with providing a framework for non-coders is that you're potentially locking coders in a specific structure that may not suit their game. I would even go as far as saying that it is impossible to create a generic framework that perfectly suits all genres and matters of play. Even if you were to create "templates" for specific genres you would just be reinventing the wheel and you would be off better buying FPS Creator or Realm Crafter. While those tools do have more released titles, they all look and feel the same which is a major turnoff for me.
This does not mean that I don't think Leadwerks needs better documentation, a more intuitive user interface and a more streamlined art pipeline because it does, but Leadwerks 3 seems to address all those issues.
A second point I would like to raise again is that one of Leadwerks' major unique selling points is that it is not Unity in my opinion and nor should we move in that direction (to far). I bought this engine because the API is complete bliss and does not force me to follow a specific convention Josh dreamed up. Both Unity (and others such as C4 for that matter) do force you to follow the engine developer's paradigm.
-
I guess I can give that a try. I wish Josh would have just exposed the LuaJIT methods to LE though, this is extremely painful.
Thanks for all the help! I'll let you know how it turns out tonight.
-
Hi Rick,
I'm flustered, no matter how I compile or reference LuaJIT in my project, it is not compiling any .lib. All I end up with is "lua51.dll" and "luajit.exe". There is nothing to link to. I have to assume that when you build your project, there has to be some kind of .lib to link to, even though VS copies it to the appropriate directories for you. Is there anything in your project's directory that slightly resembles the lib?
The function is in fact present in the source distribution, in "lauxlib.h" to be precise so that shouldn't be the problem.
-
So I have been trying to get this working for the past few hours. I have gotten to the point where I can build the application without compilation errors but I am getting one upon linking:
build/Debug/MinGW-Windows/_ext/1186093/Script.o:/src/Script.cpp:6: undefined reference to `luaL_loadfile(lua_State*, char const*)'
I am obviously missing some DLL. Did you have to compile LuaJIT and reference the resulting "lua51.dll" in your project?
-
The last I heard was fall 2011. I'm not sure if this this holds true but I am not counting on it. I guess it's done when it's done. Seems to serve Blizzard well anyway
-
This engine is pretty programmer-centric and anybody would have been able to tell you that. It suits me much better than Unity which definately caters to designers and I can fully understand how some people feel better in such an environment. What do you mean by 3D artist coding though?
As far as the upgrade costs, I believe no figures have been dropped because there is no working product yet.
No further code required.
lifes and health
in Programming
Posted
Getting hit by a bullet could easily be solved with a raycast. Whenever someone hits the trigger button, do a raycast and see if it hits the player. If so, kill him off.
http://www.leadwerks.com/wiki/index.php?title=Raycasting#LinePick