Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Aug 2004
Offline Last Active Yesterday, 09:49 AM

#5306660 Triggering Events with Lua- and C++-Objects

Posted by on 18 August 2016 - 09:39 PM

Yes, representing C++ objects in Lua is much more common than the other way around. Typically, all your engine and core functionality you want to be built in a faster and more structured language like C++ and have those entities available to be used anywhere. It's not dangerous as long as you are careful about which side "owns" the object and makes sure to destroy it when they're finished. We haven't had any problems with Lua referencing dead C++ objects, because Lua is the one that creates those objects and they are only destroyed when that map/battle/whatever is finished.



I don't quite follow your last paragraph. Our triggering checking is done entirely in Lua. If a trigger condition is met, we write Lua code to enact the change, whether its starting a sequence of events or changing something about the map state. It's pretty straightforward.

#5306280 Triggering Events with Lua- and C++-Objects

Posted by on 16 August 2016 - 09:31 PM

Yes, Luabind can handle the passing around of pointers to class instances as function arguments or return values. If you only want Lua to run when there is a trigger, you have two options. 1) Do your checking of whether you need to call the event handler on the C++ side (for example, if you're looking for a mouse click event, figure out if any sprites were clicked, and if so then you call their event handler). 2) Don't register any event handler until its ready to be called, and remove the event handler when you've determined that you don't need to call it anymore.. The advantage of (1) is that its easier to share trigger checking code among classes, but at the cost of flexibility. If you did your trigger checking in Lua, you could easily customize different sprite objects to handle things in different ways.


You shouldn't worry too much about calling into Lua every update loop though. I mean, eventually you're probably going to be doing so anyway. For our maps we are always guaranteed to call into Lua functions at least twice per game loop: one to update the map state, and the other to handle any custom drawing code. Function calls into Lua (and vice versa) are not that much more expensive than just a standard call to a C++ function.


Yes, Lua code can totally listen to events happening from C++. We handle this in our Update() functions to tell if something has happened such as a sprite entered a zone that triggers an event sequence. You're thinking incorrectly about this incorrectly with your question "how would the Lua object know which C++ object to use?". There is only one object, and it exists both in C++ and Lua (unless you explicitly make two different objects representing the same thing, which I wouldn't know why you would do that). For example, all sprite objects in my game are constructed in Lua. We store all sprite objects we create in a table in Lua called "sprites" and use a unique string identifier as the table key for each sprite (ex: "npc_villager02"). At the same time we create the object in Lua, we also make a call to a C++ function with a pointer to the sprite object so that the C++ code can know which sprites exist on the map, and do update/draw calls to them as needed. So the same sprite object is created in memory, and two pointers to it exist: one in C++ and one in Lua.



I strongly suggest you read through the Luabind documentation so you can get a better understanding of how this is all possible, and how this library can be used to make your data and functions available in Lua. I personally really like the library, although it no longer is actively maintained. It is well documented and solid as a rock, and we've had very few issues with it after setting it all up in our build process.

#5305991 Triggering Events with Lua- and C++-Objects

Posted by on 15 August 2016 - 10:25 AM

What library are you using to write your C++/Lua binding code, or are you rolling your own solution? It's hard to give good answers when we don't know what your binding code is capable of (can it bind classes, and can it recognize class inheritance?).


In my project we use Luabind, which is pretty damn powerful. If I were trying to register event handlers, I'd likely take one of two approaches.

1) Every event handler is a Lua function. The sprite object has as a member a pointer to the Lua function (possible in Luabind). The sprite class I'd write a "RegisterEventHandler(std::string function_name)" class, that takes the name of a function and sets the handler pointer. I'd call RegisterEventHandler() when my script is running its load/setup code, and if I wanted to change handlers mid-execution, just call the same function again with a different name.


2) Create a small class called "ScriptFunctionHandler" that is bound to Lua. The Lua script can create and initialize objects of this class, then pass them to the sprite objects, which keep a pointer to the handler object.




I haven't found a need to register handlers in my own game yet, but I do handle events and triggers on maps in a different way. We create several event classes in C++ which share a common base class: PathMoveSpriteEvent, PlaySoundEvent, ChangePropertySpriteEvent, and so on. All events have a Start() and Update() function. The former is run only once when the event begins. The latter is run every iteration of the game loop until it returns a true value, indicating that it has finished and the event should be terminated. Events can be linked to one another, meaning that I can start event A, and after it finishes it starts events B and C, and event C starts event D 500ms after it start. This way we can chain events together into an event sequence to create scenes, like where the camera follows a sprite walking to a door, playing a knocking sound, then having another sprite appear on the screen behind the door. It is a super flexible system and pretty easy to use. I have a little documentation written about it here, although its pretty basic and I plan to write a more detailed explanation about this system. Our code is open source and online so if you're interested in taking a look, I can link you to it.

#5304240 Ide For Linux

Posted by on 05 August 2016 - 12:56 PM

I use KDevelop and I love it. I've tried Eclipse but always found it too cumbersome and slow compared to other editors. KDevelop works great, and I'm super impressed at how much it can "figure out" about my code without even having a project file (i can hover over a class method name and it looks up the signature and doxygen comments for that and displays it in a popup). I've used it for the past decade and haven't ever found the desire to look at any alternative.

#5303205 Need Help With Art And Coding

Posted by on 30 July 2016 - 11:19 AM

Sorry, but you're not going to get anyone interested if all you bring to the table are "good ideas". Every game developer, hobbyist or professional, has their own ideas they'd like to implement. Unless you are offering serious payment, you won't find anyone interested in implementing your game ideas while you just sit back and tell them what to create for you. Also, ideas are inherently worthless. Even something that sounds good in theory may not work out well in practice (I'm speaking from personal experience). And furthermore, implementing the ideas and creating the game content is over 99% of the work in game development.


Here's an article re-iterating what I just said, if that lends more credibility to you. Also search google for "game ideas are worthless" and you'll find source after source stating the same.





Here's what I suggest to you if you really want to see these ideas become a real product.

1) Take out a loan, do a kickstarter, or find some other way to come up with money you can pay people to complete your game for you

2) Learn an actual useful skill other than just "idea guy". if you're doing the work too, it's a lot easier to get others onboard and suggest a revenue sharing option

3) Describe your ideas in more detail. The only thing you've described is a pretty generic sounding side-scroller. What are these great ideas of yours that are going to make it awesome? Why would someone want to work on your game instead of another?



If you're worried about people "stealing" your ideas, you shouldn't be. It's very likely your ideas have already been thought up by another, and like I said the overwhelming majority of the work comes in implementation and execution, not just thinking up ideas.

#5302527 Rpg Stats - Temporary Changes, Harder Than I Realised!?

Posted by on 25 July 2016 - 02:01 PM

3. Represent the stats as a stack of operations.
e.g. a stack for your speed stat might contain:
*Slow: Subtract 10
*Base: Set 50

When you evaluate that from the bottom up, you get (50-10) = 40.


A similar approach, and the one we took, was to have two classes for characters (or enemies, but lets focus on characters). One is called GlobalCharacter, and this is the permanent class object that maintains all of the character's stats. When we enter a battle, we create a BattleCharacter class which contains a copy of all the GlobalCharacter stats. We don't touch the global character stats in battle, so we always have the original values. When the battle ends, we set the stats on the GlobalCharacter to those of the BattleCharacter to reflect changes like HP or mana.


This also has the convenience of allowing us to restore the conditions when a battle began, which is something we take advantage of as we allow the player to restart a battle a number of times if they are defeated.

#5300445 RPG Style Game. Every Position Needed!

Posted by on 12 July 2016 - 03:47 PM

This is a really ambitious project that has no guarantees. This game is all about creating an amazing experience for the next generation. I want to give them the same amazing experience that I had with games that I grew up with.



Hi. I was hoping to offer some advice, as many years ago I came to these forums announcing a RPG project of my own (that I continue working on). It sounds like you are new to game development (apologies if I'm mistaken), so I wanted to give you some recommendations based on my own experience.



1) Start Small and Expand

Even simple 2D RPGs take A LOT of time and effort to build. I know this better than most anyone. Our team originally had planned to develop the first chapter of the game and release in an episodic model. Well, even what we wanted to do in that first chapter turned out to be too complicated. Instead, what we ended up doing was to first make a "tech demo" demonstrating basic gameplay. From there, we produced a few different "mini RPGs" that had a playtime of 20-30 minutes. Only after we had been able to get this far did we have most of the necessary technology and content to really begin producing our final product.


2) Don't Create from Scratch

Specifically, I'm speaking about building your engine from scratch. We decided to do that (or rather, we were so damn ignorant we didn't even realize that using an existing engine was a viable option) and we spent our first two years mostly doing engine development as a result, instead of working on the game itself. Building your own engine will give you a better learning experience, but that's about the only real benefit for a small part-time team. I'd also recommend using freely available assets (legally) from sources like opengameart.org starting out. Trying to create all your artwork from scratch, especially if you are relying entirely on unpaid work, is very, very difficult even if your project is popular. You can always replace shared/placeholder art with custom made art later.


3) Don't Over-design Upfront

In my project's beginning, we spent the first few weeks nailing down every minor detail of features we wanted to see in the game before we really got started. This was somewhat of a mistake for a couple reasons. First, we were nowhere near ready to implement most of the features we desired to have. Second, by the time we were ready to implement the features, those early team members had all been replaced by new ones, who weren't completely sold on the ideas of the past team. As a result, we questioned whether a lot of those old ideas made sense, and ended up throwing out or replacing several of them.


It's good to have a general "loose" design starting up so that you are all on the same page though. I'd hash out the major features you want the game to have first with your team, and worry about the details later once you have a playable demo up and running.



Hope that helps you out. Good luck!

#5252278 Linux c++ debugging

Posted by on 14 September 2015 - 08:16 PM

I've never been a fan of DDD because I don't like it's user interface, even though it's a very powerful tool. Haven't used it in a few years though, so who knows. I use KDB myself, which I find a lot easier and more intuitive to use.

#5250478 HP displays on enemies or visual indicators?

Posted by on 03 September 2015 - 03:56 PM

That's a solid suggestion. We did something similar to that in the past (the numbers sat in the middle of the bar and were drawn over the top half of it). We recently changed to this scheme because we added a new feature to our battle system which included some additional information to the bars (the darker section you see in the above screenshot), and this information was obscured by having the numbers drawn over the bars. So in this case doing that wouldn't work well for us, but should work well for most other games.

#5250473 HP displays on enemies or visual indicators?

Posted by on 03 September 2015 - 03:22 PM

why not both?


Health bars give a good quick indication of how much health is left while damage as a visual cue just adds to immersion, they work great together as a pair imho...


I strongly prefer both myself. Showing your current health point amount and not just a bar is crucial. Usually you see enemies dealing a certain range of damage to your characters, and you use that information to gauge about how many more hits they could take before the character is knocked out. But you also want an idea of how much health you are missing because you want to know if your health restoration abilities are going to recover enough. Some games just use raw current / max numbers, like "HP: 1362 / 2058". I don't like this because it's more difficult to read and figure out (okay, I have roughly 60% health right now). Plus if you have all your character's HP amounts next to each other in a little menu, it's even more difficult to read.


We recently wrapped up some work to improve the health information interface in our battle system (for a JRPG). This is the result of a lot of back and forth.



#5250471 Alternatives to Hit Points.

Posted by on 03 September 2015 - 03:14 PM

Our team is working on a JRPG and we recently came up with a new mechanic (at least, one I've never seen/heard of before) for dealing with health and mana. Our goals at the start of the design discussion were the following:


  • Remove the tediousness of requiring players to go to the party menu and heal/restore health and mana after battle
  • Allow characters to use their full set of skills in any given battle (ie: don't follow the case where a player just uses basic attacks for normal enemies until they get to a boss, and then go all out with their most powerful abilities).
  • Require the player to have a strategy so they are penalized if they frequently use their most powerful attacks or take too much damage (ie, make dungeons have a sense of danger)
  • Determine a way for mana to restore naturally so that the player feels more comfortable and using high-cost skills regularly in battle


The system my team came up with is something we call battle fatigue. Here's how it works:

  • All characters are restored to full health and mana at the beginning of every battle (so no need to heal outside of battle)
  • If a character takes damage, they accumulate health fatigue. This fatigue reduces the max health until the player can visit an inn
  • When a character uses a skill, they accumulate mana fatigue. This fatigue reduces their max mana in the same manner.
  • Characters have two attributes that determine fatigue accumulation: stamina for health fatigue, and resilience for mana fatigue.
  • Formula: health fatigue accumulated = damage received - stamina. So a stamina value of 20 would cause no fatigue accumulation unless the damage dealt to the character is > 20.
  • Formula: mana fatigue accumulated = mana consumed - resilience. So skills that have low mana requirements do not produce any fatigue
  • Mana regenerates a small amount every turn. Health does not regenerate (must use items/abilities to restore health).


I think it's a pretty awesome mechanic. What this means is that when a player is in a dungeon, if they are constantly using their most powerful abilities to end a battle quickly, toward the end of the dungeon they'll find that their max mana is very low and they will struggle a little more against tougher enemies and bosses. At the same time, if the player is too conservative with their skill usage and takes too much damage from drawn-out battles, their health fatigue climbs greatly and they have a lower max health when they face tougher enemies deeper into a dungeon. The player needs to carefully manage both types of fatigue to be successful.



I'm really excited for this personally. Of course like all ideas, even if it sounds good in theory the implementation is what matters more than anything. I feel confident that we'll be able to balance it out nicely though. I implemented the feature last month and we are currently play testing with it. We have a release coming out sometime this month which will be the first time we show it off to the public.

#5250468 C++ engine hosting LUA scripts

Posted by on 03 September 2015 - 02:37 PM

I'm unclear about what you are wanting to do here. Do you want to read a Lua script and then modify the data in state and then execute it (without modifying the existing script)? Or do you want to read a Lua file, overwrite that file, and then read it again and run it? I'm not sure about how to do the former off-hand. The latter I've done, but we only do this sort of thing for writing a save game file, user preferences, or other sort of long-term storage. We don't overwrite our existing scripts in real-time (which seems like a bad idea both for performance and maintainability).



I wrote an API a few years back that can construct a Lua file piece by piece. You can tell it to write single data, tables, containers of data (vectors), and even comments. It doesn't build actual functions/code though, but we could easily add that functionality if we had a need for it. Follow the link below to check it out. You want to look at the "script_write.h" and .cpp functions to see how this is done. It's rather simple really, and is just a matter of text processing.



#5240369 Game entity system: Interactions between Lua and C++

Posted by on 14 July 2015 - 06:35 PM

I think you're confusing lua states with our usage of the metatable to provide a shared space. Something like the following is at the top of most of our Lua scripts:

local ns = {};
setmetatable(ns, {__index = _G});
harrvah_underground_river_cave = ns;
setfenv(1, ns);

What this does is similar to how a namespace works in C++. Any variables declared within this "namespace" (which in this case we name harrvah_underground_river_cave) are protected within this metatable so that a variable with the same name in another script doesn't collide and overwrite these values.


For example, say we have two Lua files, each which represent a map. Let's call them a_map and b_map. Our engine starts a single Lua state for running the game. This state is shared among all Lua files we load into it. We want to have the same variable names in a_map and b_map (ex: a table called "sprites", a number called "tileset_count", and so on). Without these metatable namespace guards at the top of the file, we could only ever have one map loaded into the Lua state at any time. Otherwise a_map and b_map would be sharing the same variables, and running code on a_map could overwrite the stored data for those matching name variables on b_map.



That's why we do that. We do not use seperate Lua states. We use metatables to essentially wrap the file in a namespace to avoid collisions with the same variable names in other Lua files that we may load into our single Lua state. (Disclaimer: this was added to our Lua standards long ago and I wasn't involved, so I don't know how or why this little trick works. All I know is that it does work).

#5235625 Game entity system: Interactions between Lua and C++

Posted by on 19 June 2015 - 12:44 AM

The RPG I'm working on uses a custom C++ engine and Lua for scripting. It's open source, well commented, and has a decent amount of documentation, so maybe you could snoop around what we've done there and get some ideas.


I've been thinking about putting a video together on our youtube channel to explain how the map exploration code in the game works and how you build a script with it, but unfortunately won't get around to that until next month at the earliest. Here's some general designs that we've implemented.



First, we use Luabind to connect our C++ and Lua code. Luabind allows us to specify which classes and functions we want to be available within our Lua files. Most of the code that processes what happens on a map happens on the C++ side (or Lua calling into the C++ functions). For example, path-finding, animations, and drawing all happen in C++. The things that happen in Lua for a map are some large functions that populate the map with sprites, objects (like treasures), zones (defined areas of the map used for different purposes), and events (things that happen on a map). Lua will also have a number of small custom functions to do specialized things that we need, for example shaking the screen during an earthquake scene, moving the camera to a different location, or telling a sprite to move to a specific destination.


Most of the class objects we create in Lua we send a call to the corresponding manager class in C++ to handle that object. So every sprite we create is sent to a sprite manager, for instance, so that the sprite manager can figure out which sprites need to be updated, drawn to the screen, and handle collision detection between sprites. When we do this, we also tell C++ "I created this object in memory. I'm now giving it to you with the responsibility of destroying it when you are done". This isn't something you have to do, but it helps us to keep all object destruction contained in a single place rather than rely on Lua's garbage collector. (We use special arguments in our Luabind binding code to make this happen).


Now one thing I want to describe in detail is our event management system. Our maps all have an event manager, which holds event objects of various types. You may have an event that moves a sprite to a destination, an event to display a dialogue between characters, an event that causes a battle to occur, an event that plays an audio file, and so on. We also have custom events that contain pointers to Lua functions to run. Events can be chained together so that after one event finishes, another will begin automatically. This is useful for sequences where we want to have several things happen one right after another. You can specify how long to wait after an event finishes before the next one to begin, or you can start another event at the same time that the current event begins. Every event has two functions: a "Start" function that runs when the event begins, and an "Update" function that updates the event as necessary, and returns true when the event is finished. So a sprite move event would specify the desired location for the sprite in "Start" and the "Update" function wouldn't return true until the sprite reaches that destination. This is a simple system that offers great flexibility, which is what you need to build maps that are interesting.


The image below hopefully helps illustrate this idea of event chaining. We use Lua code to setup an event chain and to check for the conditions when an event chain should begin (for example, when a sprite walks into a certain area of the map). Lua tells the event manager to start the first event in the chain, and from there the C++ code handles the rest, processing each event until the sequence is complete (or processing it infinitely if there's a loop in the event chain).





I know that's a lot of ideas and words I'm throwing around, but hopefully some of what I said makes sense and helps you get a better idea of how C++ and Lua can co-exist. This was one of the most difficult problems for me to figure out myself, so my best advice to you is to experiment and figure out what works best for your situation. Maybe it's something like we've done, or maybe it's something entirely different. There's really not a right or wrong answer to how to mix Lua and C++ together.

#5229934 A whole lot of constants.... good or terrible? :/ (c++)

Posted by on 19 May 2015 - 06:08 PM

Magic numbers... You mean numbers that change a lot?


No. Magic numbers mean random values that appear in the code without any apparent meaning. For example:

for (int i = 0; i < 67; ++i) {
    // do something...

What is 67 (the "magic number") supposed to represent? It's not obvious and makes for code of poorer quality (and more bugs potentially). Instead you should be doing something like this:

// Line below done from another file or class
const int MAX_FRAME_RATE = 67;

for (int i = 0; i < MAX_FRAME_RATE; ++i) {
     // do something...

You might think it's just a minor improvement, but it's a pretty big fucking deal. Especially when you're dealing with a code base with hundreds of thousands of lines and magic numbers popping up everywhere.