Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Aug 2004
Offline Last Active Yesterday, 09:57 PM

#5300445 RPG Style Game. Every Position Needed!

Posted by Roots 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 Roots 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 Roots 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 Roots 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 Roots 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 Roots 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 Roots 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 Roots 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 Roots 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.

#5229767 How To Do RPG Interiors

Posted by Roots on 18 May 2015 - 11:24 PM

The problem of basements and second floors will be a tough one though, I'll hit it head-on and be back when I find an obstacle!


I made a video of our map editor earlier this year where I explain how we do something like that. Here's a link to where I being discussing that (5:55 mark). I talk about it until around 6:45 or so.




Essentially the way we handle interiors, basements, etc. is the following:

  • Each map contains a number of "contexts". For a town the base/default context is typically the exterior of the town.
  • We create a separate context for each unique "view" of the map. In the video, I have two more contexts: one representing the inside of the house, and one representing the basement
  • In the map script, I specify areas of the map called transition zones, which when the sprite pointed to by the camera walks over, the view switches from one context to another
  • In the video, the transition zones would be at the front door (switching from exterior <-> interior) and the stairs (switching from interior <-> basement)


So when I go in the door, I switch the tiles representing the outside of the house to those of the inside. When I walk on the stairs, those tiles are changed a second time to show the basement area. It's pretty nice. You can specify how any tile on the map changes in one context or another. So if I want to show portions of the "outside" context that are close to the windows of a house when inside, I'm able to do that.



Hope that gives you some ideas. All the code for my game and editor are open source too, by the way (C++ is the primary language). If you're interested in taking a look, I can point you in the right direction to where this functionality happens. Just let me know.

#5229516 How To Do RPG Interiors

Posted by Roots on 17 May 2015 - 07:18 PM

In my opinion SiCrane is right. If it is an small area with a few floors, I would prefer the transparency. It is annoying (for me) to get into another zone, just to get one item or talk to an unimportant person. Additionally you could leave and enter the area easily and if you are in the wrong house you just walk out there. With transitions this is just annoying.
But if there is an unique looking house with lots of floors (like an hotel or labyrinth) you should use another zone.


Agreed. Players want to explore the map, not sit through the same transition effect over and over as you walk from one room to the next. I would only do a transition between maps/levels (eg, from a town to a forest).



There's one thing you have to consider though. If you do the transparent roof option, you're going to need to make your houses much bigger than they otherwise could be. Consider a game like FFVI where you had nice looking towns with very small houses:




Once you walk in those doors, the interiors are much larger because they are essentially their own map. You can't make a 3x3 tile house work if you go the transparent roof option. Its something I never really thought about until I started working on my own game that did this, and realized that medium-sized houses pretty much take up an entire screen worth of space.

#5228970 I'm having trouble attracting contributors to my project as it gets older

Posted by Roots on 14 May 2015 - 08:55 AM

Oh, I would love it if I could find someone that would do that. I'd actually prefer to give Mercurial a try over git though, as they both offer pretty much the same thing, but Mercurial is a little more user friendly. I've worked on projects on github and was tearing my hair out sometimes with trying to resolve conflicts during branch merging, etc. A lot of our developers come from backgrounds that don't use git, and I don't want their initial experience to be a frustrating one as they try to learn how to use this tool.

#5228875 I'm having trouble attracting contributors to my project as it gets older

Posted by Roots on 13 May 2015 - 06:24 PM

So after taking in everyone's feedback and looking at where things stand, here's the course I've decided on.


Rebuilding a Team

  1. Continue working solo for now. Get a development release out that people can play. Upload a playthrough video showing it in action so people don't even have to install it to see it in action.
  2. Update the website to better explain the product, its major features, and design goals. Sell it to the audience to get them interested and excited about playing it.
  3. Once the previous steps are complete, try recruiting once more. Include latest gameplay videos and a link to the section on the site explaining the product in more detail. Explain that we're seeking people passionate about this type of game that want to contribute their ideas and talents to building it.


Project Status

  1. Depending on the size of the team and ability to complete work in a timely manner, cut extra features as necessary and where it makes sense to. We can't keep having such ambitious goals for a project if we don't have the resources to complete them in a matter of months.
  2. Set a finishing point for the project that is much closer than originally planned (a few hours of game content as opposed to 40+ hours). Make that the current "long-term goal" and don't worry about anything beyond that.
  3. After reaching the end goal, re-evaluate the project status, team status, and desire to continue. At that point figure out whether the project should continue or if it should be marked as complete.

Other Ideas

  1. Consider a "soft reboot" of the project. Bring in a new team of enthusiastic people and explain to them what assets, technology, and story currently exists. Start from scratch, making a game that this new team is interested in while reusing as much of the old work as we can.
  2. I forgot to mention it earlier, but there's a fork of our project called Valyria Tear. I've been a contributor to that project throughout the couple of years it has existed. Maybe if things don't work out with this project, I could just continue my work over there instead. They've seen a lot of great progress (and a full release) in the last few months.



Thanks again for your input, everyone. I feel much better (and perhaps more realistic) about the next steps to take moving forward.

#5228873 I'm having trouble attracting contributors to my project as it gets older

Posted by Roots on 13 May 2015 - 06:05 PM

Thanks for your comments, everyone. I've read them all, agree with most, and have done some thinking. I've got a lot to respond to, so I'm going to give succinct responses.



If you want to create a game by a team  you need to be really fast at finishing it, until time will disintegrate the team.

A lesson I've surely learned now, and wish I knew sooner. The biggest mistake that our initial team made was diving head first into a large and complex project with zero prior experience. Hence why the first couple of years were really a learning experience.



From the point of view of an artist, they want their work to be enjoyed by a lot of players. They want recognition.

I fully agree, and this is something we learned a few years back. Artists are generally not inclined to checkout the code and compile/build the game themselves to see their work in action. We started producing more internal screenshots and releases so that non-technical people on our team could see the progress, but it was too little too late I"m afraid. Right now, the project is in the best position that it's ever been for artists to see their work enjoyed by others.



From my perspective it kinda sounds like what you want is not contributors, but friends to work on the project with you in your collective off-time.

Exactly. I want people who love this type of game (a 2D JRPG with an interesting story and solid gameplay) and are passionate about beinga member of the creative process to build one. I tried to get people who joined to take ownership of the project and have them share their ideas, rather than being the one who always dictated what we should build and what we should do. It worked with some people, others preferred to remain more aloof and just get assigned things to do. Maybe I should use that sort of language in my recruitment posts.



I took a look at your project's forum and it's the very definition of dead.

Yup. I wish there were people active there because I like to post a lot and share my ideas and plans with others as a kind of sounding board. There are some people that still drop by our IRC channel occasionally and chat, but that's about it. I was hoping that posting more to the forum myself would entice others to do so, but there's really no one to read/respond to new posts.



Are you sure this isn't just an excuse to "have a life" and "watch the occasional TV show"?

I wasn't meaning to use "I'm busy" as an excuse. I've been much, much busier in my life and still made more time for this project then than I do now. I was pretty miserable during my workaholic years, and I don't want to fall back into that lifestyle. Ever. If I'm not having fun working on this project, there's no point in me continuing to work on it. I want to enjoy this process, even if it means it will take a long time.



But, how much of the original idea is left?

Actually, quite a lot. We've remained pretty darn true to the original design discussions we had with our initial team. And we've continued to follow our core design philosophies as we've worked out the details and built the game. Although the game has had a lot of features added on that increased development time, asset requirements, etc. I think one failure of this project (and myself as a team leader) was allowing this kind of bloat continue to pile on for things that we really did not need. (Example: we used to do random encounter battles, which are really easy, but now we have enemy sprites roam around the map and chase after the player character, who can use a stamina meter to try and outrun them).



It looks as if the project needs a reboot.

I was thinking something along the lines of this. What I was imagining was forming an entirely new team and starting somewhat fresh. We'd still use the same code and assets and story, but we'd brainstorm about what kind of game we want to build with it. I thought of this because its hard to be enthusiastic about joining a project that pretty much has most of the core mechanics and gameplay nailed down that were decided by a group of people years ago who have long since parted ways with this project. So I've been wondering if I could roll with that sort of mindset, attract a new team of enthusiastic people and share what we have to work with, and see where we want to go from there.



Try a kick starter, get donations, etc.

This isn't a for-profit project. We're not trying to make any money from it, even donations. It's just a hobbyist project to use our talents to build a game for people to play. It's as simple as that. Hence one reason why this is such a long endeavor. If I could make this my full-time job, I would have. But its never been our intention to charge people for this. And I wouldn't feel comfortable starting to ask for money seeing as how many people have worked so hard on this project for nothing for so many years. Its not fair to them if someone makes money off of their work.



Let it go. Maybe have a final release as a goodbye and do something fresh. It could be another RPG or even a smaller minigame. The world's your oyster.

Definitely thought about this many times as well. I wouldn't let it go without having some form of final release. Probably a much shorter version of what the full game was intended to be (maybe a few hours of content). I have a clear stopping point in my mind of where the game could potentially end if it were to end pre-maturely. So once I get to that point, I'll re-evaluate whether it makes sense to continue going forward or to call it done.



The front page of the site tells me nothing about the project.

Yes! I realized this myself a couple months ago. Our website does not explain nor "sell" the idea of the product well at all. I want to improve this, but kept telling myself "if you're going to work on this project, work on the product". But I think this is important enough that I should spend some serious time working on our about page to explain what this game is and what makes it special.

#5228284 I'm having trouble attracting contributors to my project as it gets older

Posted by Roots on 10 May 2015 - 05:25 PM

I've been working on an open source RPG for a number of years [link]. In the first 3-4 years, finding help was never a problem for us. However, as our project has gotten older it has been more and more difficult to find people to help out. I made a post on our website recently explaining that this project has essentially become a 'one-man army' now because despite my efforts, I've failed utterly at recruiting others to join the project. I've tried recruiting from multiple different sites (including here, where the majority of our contributors have come from historically). I've tried making the on-boarding process as simple as possible. I've documented and organized all the information that someone new would need to know to get started. I've been sharing screenshots and videos of the latest progress I've been making.


I'm really running out of ideas here on what I can do to attract help. My next attempt is to publish a new development release, but it takes a long time when I have to do the work all by myself.



What would you suggest I do to attract contributors to this project again?

Keep in mind I'm working solo right now and don't have a lot of time to spare. So suggestions like "completely overhaul your website" just aren't going to happen. Some people have suggested that because we're not using the new popular services like GitHub, we're not going to attract help. While I'm not against migrating to a new hosting service or revisioning system, it seems odd to me that that would be the lone reason why I can't get any help. Plus I don't really consider doing things like this a priority right now when I'm working alone. I'd rather invest what little time I have in making progress on the title, not the services we use surrounding it.



Are people generally ageist against joining older projects?

I can totally understand why an older project might not be as attractive as a new one. Much of the vision in gameplay, artwork, and music has been more or less defined now. It's harder to put forth your ideas and have them considered if it requires a major redesign to implement them. And there's perhaps not as much excitement as there is for a newly birthed project. I just hope people realize that an established project has its own set of benefits. I find it ironic how so many people were willing to jump on my train when we were starting out. I was so ignorant and naive in those early days, but perhaps we all were then.