Jump to content

Laurens

Members
  • Posts

    564
  • Joined

  • Last visited

Everything posted by Laurens

  1. 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
  2. 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.
  3. This is what callbacks achieve without hardcoding a specific method that all entities must then implement.
  4. Do you mean from a user interface perspective or from a programming perspective (as in the domain model)?
  5. Laurens

    LuaGui

    I don't think Aggror is still around, I'm not sure if this would even run anymore.
  6. 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.
  7. I sometimes have to cry compiling open source libraries. True story.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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. I indeed can't and don't want to. But that still does not warrant a move to Unity, 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.
  13. 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.
  14. 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.
  15. 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!
  16. 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.
  17. 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. That's a very specific implementation and most certainly not a must. It depends on your requirements. Furthermore I highly agree with:
  18. 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". 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"?
  19. I did not mean to offend anyone. 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. 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? 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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?
  24. 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
×
×
  • Create New...