Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

Posts I've Made

In Topic: Rpg Stats - Temporary Changes, Harder Than I Realised!?

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.

In Topic: RPG Style Game. Every Position Needed!

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!

In Topic: Suggested patterns for declaring and detecting event triggers?

26 June 2016 - 01:46 PM

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.

In Topic: Linux c++ debugging

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.

In Topic: Why are artists less likely to work on free/hobby projects than others?

10 September 2015 - 07:45 PM


If you want artists to work on your games, how about bringing them in as equal partners from day 1?



I've realized this from day 1 with my own project. No one wants to work on someone else's dream game. If you're asking them to work for free, the least you could do is ensure them a seat at the table for determining the game's general design (not just art design). Here's the exact words I put in my most recent help wanted ad seeking artists:



This project has six active team members at the moment. We want to continue building a team of dedicated, passionate individuals who share the vision of what Allacrost is to become and want to be a part of making it happen. 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 pretty 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. While we are seeking core team members, we're also happy to welcome contributors who prefer to help out here and there with adding a new feature or creating new art or music, but aren't as invested in this project.


And this is further reinforced on our new contributors page, which is the very first thing someone that is new or interested in joining the project would see. I think it's a good set of policies that our team has, and have helped this free project survived where others have failed. Despite all this, it doesn't seem to be enough to interest artists any more than your average "come make art for my awesome game" type post.




Earlier in this thread someone mentioned that because art can be instantly evaluated without needing it in a game, artists aren't that interested in contributing to a free project because they can build their "portfolio" without needing any game project at all. This is true and a very good point. But then shouldn't the same hold true for composers? I can listen to a piece of music and feel how talented the composer is. They don't need to contribute to game projects, yet I get so many interested that I have to turn some away (we really can't have more than 2-3 composers realistically).