I work on a RPG built using a custom engine in C++ and Lua.
Total of 942 files
300 files are C++
82 files are Lua (used for data retention, scripting)
Our project is open source and has a page over on OpenHub that tracks the project's activity, analyzes code to determine its content/quality/worth, etc. Kind of interesting to see.

I posted to that forum about a week ago and never saw my post there, nor any rejection notice. If you take a glance at this forum right now, the most recently created thread there is over a week old. So I'm wondering what the situation is here. Is there only one mod in charge of that forum and they are on vacation or something?

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.

IIRC Luabind only needs boost in order to compile. If you have a pre-built library, you don't need to worry about boost. There are of course other Lua binding solutions (use google to find them, I can't remember them all). I think most (all?) of them are less capable in their binding than Luabind is, but the last time we compared Lua/C++ binding solutions was many years ago, so I don't know what's available now.

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.

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.

About
Hero of Allacrost is a single player 2D role-playing game inspired by classic console RPGs. In Hero of Allacrost, the player will explore rich environments, solve challenging dungeon puzzles, and fight strategic battles in an active-time based system. The game is free to play and built with open-source software. It is currently available across several platforms including Windows, OS X, Linux, and FreeBSD. The three major design goals we are seeking to meet with this title are:
Prioritize efforts on developing engaging gameplay and a compelling narrative
Eliminate tedious and micromanagement mechanics that are commonly found in RPGs.
Make battles interesting, challenging, and requiring of a high level of strategy from the player
The About page on our website describes several of the game's core features and how they enable us to meet these goals. See some screenshots here and videos here.
Talent Needed
At the moment the team consists mostly of just myself. There are two other programmers working as well, but they have very limited availability to do any work at the moment. Becoming a member of this team means more than simply getting told what to create. We strongly encourage people to participate in design discussions and offer their own ideas to improve the game and the project itself. Although the core design of Allacrost is well-defined at this point, there's still a lot of unanswered design questions and features we have not yet implemented. There's still plenty of room for you to influence this title should you be interested in doing so. You can read more about what it's like on the Allacrost team and our philosophies by reading about our team policies on our wiki.
Listed below are the specific needs that we are seeking to fill at the moment and what people who fill those roles can expect to be working on for the next couple of months. If you're interested in the project but don't really want to work in these roles, you are still welcome to join us. Very soon we'll also be needing a writer, game/map/level designer, traditional 2D artist, and perhaps a composer.
Pixel Artist
The most immediate needs for pixel art include: various demon sprites, townspeople sprites, and some needed improvements and additions to our desert castle-town tilesets. See the (2) and (3) links for some examples of our current pixel artwork so you can get an idea of our style. If you feel this above your skill level, please don't be intimidated. Even programmers create some of the art occasionally (myself included), and they are certainly not this talented.
Links:
(1) - Information on rights to an artist's work and how to get started
(2) - Lists the types of artwork found in Allacrost. The Maps, Sprites, and Icons sections cover pixel art
(3) - Explanation of our artistic styles, influences, and design
C++ Developer
Allacrost uses a custom engine, which is in a completed state, and the core aspects of the game operation and gameplay are all functional. We still have several advanced features to add and technical challenges to overcome on the development front. At the present moment, the major work we need help on are: save points and the save/load game system, enemy AI, and the implementation of scripting in battles. While our developers mostly focus on C++, there will be some Lua development involved as well.
Links:
(1) - Qualifications to become a programmer and steps on how to get started
(2) - Our primary documentation home, covering the engine, game logic, and more.
(3) - Our code and content repository, free for anyone to look at and study
Activity
Our most recent release was in June 2015. This was a development release, which is essentially a snapshot of our work in progress. Below is a link to download it as well as a walkthrough video of this release with commentary.
Release Files: http://www.allacrost.org/download
Release Video:
The next milestone we're working toward is another development release that continues where our previous release left off, which will finish out the current "chapter" of the game. The major requirements for this release include map design, scripting, and creation of some additional artwork (a few map tiles and around a dozen sprites). We're also introducing fundamental changes in the design to make our battle system more interesting and fun. The anticipated date of this next release is sometime within the next month or two.
By the end of this year, we will be making an official release. This will be a fully designed, balanced, and polished product. It will be an iterative improvement of the next development release with some amount of additional content and improved event scripting, dialogue, and several improvements in the UI and other areas of the code. This is the team's current long-term goal. More information about our upcoming releases can be found on the Roadmap page on our wiki. This includes a list of all the major tasks that must be done along with their current status.
Compensation
Allacrost is created and distributed for free. Because of this we cannot offer financial compensation to those who work on the project. Our team members are quite content with putting forth their efforts into what we believe will be a great game to share. We learn a lot from each other on the Allacrost team and you will absolutely learn new techniques and skills from those whom you work aside with. Having this experience will also make you a much more attractive candidate if you are seeking to enter into the gaming industry. Some of our team members have been solicited by recruiters for well-known game development companies. Your full name will appear in the game credits.
Joining
Follow this link for information on how to join our team and what you can expect from working on this project. If you have questions or wish to give feedback, feel free to either post a reply in this thread or message me directly if you wish to inquire in private.

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.

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.
http://blackshellmedia.com/2015/03/why-your-brilliant-game-idea-is-absolutely-worthless/
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.

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.

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!

I think that's a great suggestion, and I like how simple it is. However I'm wondering if it would be better to have it build a queue of events that occurred (button pushes, sprite movement, etc) when the map is doing its update operation. Then when the map script does it's own update, it looks at all of the events and their properties and decides if something needs to be done. That way we aren't making a function call from C++ into Lua on every single move/collision/whatever. Still thinking about it though.

Hi everyone. I've got a 2D RPG written in C++ and Lua with a custom game engine. I've been designing some more complicated environments in the game, and in the process I discovered a big technical limitation in the way we detect when important things happen that make us want to process a change. I'll call these triggers. When a condition is triggered, we want to fire off an event (that may in turn fire other events). My issues are not with the event system or processing, but rather checking when those triggers happen and firing the appropriate event.
How it works right now
It's pretty basic right now. Every map has an Update() function written in Lua. In the update function, we execute a series of conditional statements (the triggers) and if they are true, fire off the correct event. At this time, this is pretty much limited to checking if a sprite is located within a zone (we define zones simply as a section of the map). If it is, we fire the event. If there's something that we only want to occur once (say, a section of a cave collapses), then we register a string/value pair in a global event manager that keeps track of the fact that this event already happened.
Here's what it looks like in practice.
if (GlobalEvents:DoesEventExist("passage_collapsed") == false) then
if (zones["collapse"]:IsPlayerSpriteEntering() == true) then
GlobalEvents:AddNewEvent("passage_collapsed", 1);
EventManager:StartEvent(event_chains["passage_collapse"]);
end
end
Limitations
There are other things that I want to be able to trigger events in addition to just checking the position of objects on a map. For example, when the player presses the action button and was facing a certain interactable object. Or when the player collides into a locked door, to play sound. This one is particularly hard right now as collision dection and resolution is done completely in the backend of our map code and the results are not available to the map script at all. It seems kind of silly and inelegant to just have a big list of if statements listed in a function that we check on every update loop of the game.
I've been doing some reading on my own to see if I can get some ideas for a pattern or design that would work better in terms of flexibility. Right now I'm considering the Observer pattern. I'm hoping to hear some opinions on what sort of system you all may have tried to solve similar problems, or point me at what articles I should read or other designs I should consider. Thanks

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.