Keywords: design
In the first of a series of articles tackling common developer issues in Anime style RPGs, we will look at the classic problem of enhancing and managing how players use skills.

If you'll excuse the obvious, skills are actions that a player can learn and perform. The game I am involved in making, Naruto Universe, makes extensive use of skills in a number of forms. Firstly you have attack skills, called Jutsus. These are part of the core mechanics of how a player does battle. There is also training skills, used to beef up your character. Both have something in common, which is that a player performs them. In BYOND, quick player-driven actions are pretty easy to write. Just make some verbs for the player's character (some kind of mob) to use, like so:

src << "You've performed a skill!"

Ta-da, you've written a skill, it appears over in their commands. The player clicks the skill, and it does its thing. Pretty straight-forward and easy for the player to use. Unfortunately this gives rise to a few problems. Players get into a habit of just hammering away at skills, or perhaps feel it isn't terribly fun. I would agree; obviously there is some player skill in choosing the right skill at the right time, but actually using them is a pretty passive affair. Over the next few paragraphs, I'll talk you through one of a number of other approaches, in particular the one the team for Naruto Universe went with.

Our approach is somewhat datum-driven. In particular, we felt it would be more interactive to use a system of combos to perform skills, a bit like those old NES cheat-codes. So firstly we'll need something to represent combos:


Now, combos are not too neat on their own, unless you can perform them and activate a skill:



if (src.directions[1] == dir) // They hit the right direction.
// Reduce the list, perform other cool things.
// If we're out of directions, we can trigger the action.
return 1
return 0

Now, we fleshed out this system a bit, but the basic idea is there. Players have a list (or something similar) of actions they can perform. Your interface can filter requests to start actions (perhaps you have something as simple as some verbs wrapped around this), then grab a /Combo and attach it to the player. Once the player hits the appropriate directions in order, the /Action does its thing.

The benefit of the datum-driven method comes from the separation of concerns. Combos hold the information on where a player is in a /Combo, while an /Action describes the general process and features of a player skill. In Naruto Universe, this system brings some real improvements on performing skills. For-instance, in Naruto the character performs skills, Jutsus, by performing a series of hand gestures, Seals. Combos are our programming version of those seals, so when a player hits the correct direction, we can change their icon to reflect the new hand gesture. It's no longer a case of click and go; the player is now actually performing the seals, just like in Naruto.

One final comment is that with having the actions as datums, it is very easy for us to add new actions without changing a single line of existing code. Similarly, it is easy for us to arrange them into things like skill trees, another favourite of RPG style games. If the interface has been done correctly, a datum-driven approach (perhaps like this, maybe different) saves you a lot of work and makes it very easy for you to add those cool new skills players ask for later on.


Naruto Universe is a project aimed at providing BYOND with an immersive and innovative Naruto gameplay experience. The core of the game focuses on linking the player and their actions to that of their character, with character actions reflecting what the player does in more detail than ever. Naruto Universe is being developed by Mista Dougie, AmonR, Kalzar, T3h B4tman, Disturbed Puppy and the author of this article, Stephen001.

Stephen is a programmer for Naruto Universe, having come from a background of 6 years of programming experience and 3 years of formal education in software engineering. Stephen also assists in BYOND community management, acting as a moderator for both Dream Makers and BYOND Anime.
Nice article Stephen. Hopefully these articles will show people that not every Anime game needs to have the typical pbag/log training and that the game can actually be fun and entertaining instead.
I've been thinking of modeling a combat system after this method for a while (I read about it in a Propaganda post somewhere along the lines). It will be interesting to see whether this actually makes it into a non-rip Naruto game, though.
Nice article Stephen. Hope this helps out alot of anime games.
That's a pretty cool way of preforming Techniques. I remember seeing a screenshot of this not too long ago and it looked great. Not to mention that's some great modular programming right there :).

I was planning to reprogram WOTS with a more /datum approach(Like I have with my other project), but I never got the chance to since it's officially dead.
Yeah, I'm with Bakasensei, here. It sounds like almost an advertisement..
I suspect that is just because of the tag-line, which is kind of of an advertisement style in the sense it covers "About the project/author". Aside from that, most references to the project are aimed at explaining the consequences of a design decision on the project, part of the aim of DevTalk. It's very much more a real-life case study of design, demonstrating a line of thought readers might not ordinarily take, a new way of approaching a problem.

While I am expecting differing tones and writing styles from Alathon and Tiberath, the reference to their respective games and the consequences of the problem they choose to discuss (like this article has) is something that will probably feature just as heavily. I suppose the crux is, the author's case study game and the solution they chose will get reflected in a positive light (like an advert), because they think it is good. If they didn't think their decision was good, they wouldn't be writing about it. =P
Part of the idea behind the articles is to allow people to follow the development of several games as it occurs. That becomes a bit too abstract without any information on who the writer is and the game they're working on. You'll see a similar blurb in my first article at the bottom, and likewise with Tiberath's first.
Jogem e divirtão-se