Established RPG project (non-MMO) seeks pixel artists

As promised, here's some more detail on our implementation. Below you'll see a mock-up image for how the battle screens will be laid out (this is not a final version, but we've been refining this for a few weeks now and I think we're pretty close to freezing the layout design).

For those interested in the battle sprite artist position, you can also see some of our early battle sprites in this draft as well and get an idea of the style we're going for.



General
This is a 1024x768 pixel mock-up of our battle layout (that's our default game resolution). The gridlines are used to make easy reference to positions in this draft. Each square is 64x64 pixels and there are a total of 12 rows and 16 columns on the map.

Background
We are planning to animate the top 4 rows of the battle background to make the scene a little nicer to look at. This will include simple things such as leaves falling in a forest, or showing fire and chaos during a large-scale battle between armies.

Character Sprite
All chracter sprites are 64x128 pixels (1x2 'tiles'). There is a maximum of 4 characters that may be present in a battle. Character sprites will be fully animated. The way we do this is to group skills into similar categories (near-attack, far-attack, magic spell, defensive action, etc.). The sprite will use the skill-category action for the majority of the move, and the final effect (the spell cast, sword striking the enemy, etc.) will be a unique animation on a per-skill basis.

Basically what this boils down to is that characters won't just be taking a couple steps forward and swinging down their weapon as you see in most older RPGs. They will run up to the enemy and get in their face to attack. However, weapons won't have a unique appearance as a result of this, because it is too complicated and costly for us to do with full-animation, and not worth the effort.

Enemy sprites
Unlike character sprites, enemy sprites are not animated (there's just too many enemies it would be futile to try and animate them all). Instead, we use a technique that I guess you could call "progressive damage sprite blending". Basically the way it works is each enemy sprite has 3 frames created for it: a 0% damage frame, a 50% damage frame, and a 100% damage frame. Depending on the enemy's health, we blend two of these frames together so the enemy looks like its progressively getting more and more damaged. (We can't do dramatic things like change the stance of the enemy or severe limbs, however, because that wouldn't look good with this blending technique).

Here's a sample video of the technique in action (if I see our site bandwidth getting raped, I'll have to disable this link later):
Progressive Sprite Damage Demo

Enemy sprites come in all shapes and sizes, with the minimum size being 64x64 pixels (1x1 tile), and all sprite image sizes must be in a dimension of 64 pixels, so they consume entire tiles.

Status bars
Directly to the left of every character sprite are their status bars and menus. We have a hit point bar, a skill point bar, and a wait time bar. (I'll talk more about skill points in another post). There is also a place for status icons to be placed (both beneficial and detrimental effects). Because of the limited space, if there are more status icons present than there is width of the left menu bar, only a limited number of icons are displayed and they are periodically rotated so the player can see all active status icons.

We'll also have an option for switching between numerical values and bars in-battle.

Portrait
The actively selected character gets their portrait displayed in the upper left hand corner. The little number 1 represents the number of character swaps that the player has available (I'll discuss more about character swaps in a later post).

Action Type Selector
We are thinking of going with a Lufia-style action selector rather than just putting together a text list of the different command options. A list of the options:

- top: Aggresive Skill
- left: Defensive Skill
- middle: No Action (but sometimes may have a special command)
- right: Support Skill
- bottom: Use Item

To run, the player holds down the left select and right select buttons (think the L/R shoulder buttons on the SNES controller). I'll discuss skill types in my next post.

Most Rection Actions
To the right of the action type selector menu, the 3 most recently used options by the character are listed, so that the player has easy access to their previously used commands.

Action Selection List
Finally, we have a list of actions depending on the action type that was selected by the player. Notice that the same action can be found in both the recent actions menu and this menu (Whirlwind Slicer). Oh, and of course I made up all these names on a whim, don't take them seriously. [smile]


Except when a character is ready to execute a command, the top menu remains hidden. When a character is ready to take an action, the following events occur:

1) The character's portrait gets displayed in the upper left.
2) The action type selector menu shifts in from the left.
3) (After #2 completes) The most recent action menu shifts in from the left.
4) If the player selects an action type, the action selection list shifts in from the left.



And that's all I have to say about the layout of the battle screen. This was put together out of a lot of trial and error and several heated debates about what would be "the best" way to organize all this information on the screen. This will hopefully give any potential battle code designers an idea of what they are up against, at least graphically. If you have comments or questions you are more than welcome to post them.



Sometime tomorrow, I will make a post discussing some of the major features of our battle system, so stay tuned. [grin]

I will not present some details into our battle system, so potential designers (and players) will know a little bit of what to expect from Allacrost. Before I dive in however, I want to state the three design criteria we keep in mind while developing this game. They are primarily to keep our game from becoming "just another RPG" and also

Remove tedious tasks
Ever try talking to everyone in town just to see if they have something new to say? How about continually mashing the "A" button while walking around, hoping to randomly stumble upon some treasure? These are the types of things I'm talking about, and we absolutely don't want to see any of this in the game.

Design battles to be less of a chore and require more strategy
Select Fight. Wait. Select Fight. Wait. Select Fight. Wait. Getting bored yet? In my opinion, most RPGs seriously lack a battle system that is fun. We borrow some concepts from other games, including some original ideas of our own to create what we will believe a fun and engaging battle system.

Additionally, we all are tired of random encounters that just aren't really...well...random. There's usually a handful of enemy parties that you encounter in an area, and so you repeatedly fight the same battles over and over and over. We mix it up by not having pre-set enemy parties and also by not giving an enemy the same stats every time. We also are taking measure to ensure that battles are never an easy victory. This is especially important when returning to previously explored areas in the game, where usually foes become such push-overs that they are nothing but an annoyance impeeding your progress.

Focus on gameplay and story, not graphics and...graphics
One of the reasons that I started this project in the first place was because I'm dissastisfied with the majority of today's games. Graphics graphics graphics is all the big name game designers seem to care about, and the amount of fun and story depth have seen a rapid decline from the early 90s. We want to bring those things back in our game and set it as a high priority item.



That will hopefully give you some insight into why we have some of the features I'm about to explain. Now, on to the battle design.



Magic Points? "Fight" command? Don't need 'em.
There is no MP. In fact, there is no standard "Fight" or "Attack" command either. Instead, players have a series of skills. There are three categories of skills: Attack Skills, Defense Skills, and Support Skills. Each skill consumes a certain number of Skill Points (SP). Generally the more powerful the attack or effective the skill, the more SP is consumed. Some of the weaker/less effective skills are innate (they require no SP to use). Each character has their own unique variety of skill sets.


Skill Points, in-depth
Our goal with the use of skills and skill points was so that the user didn't constantly "grind" (select the same action over and over again). To accomplish this, we formulated these rules regarding skill points:

- A character's max SP grows with experience levels
- SP can be recovered in an inn, gradually by walking across a map, and gradually in battle.
- There will be items, spells, or other easy way to quickly recover SP -or- these methods will be extremely rare and hard to find. This prevents the player from doing the classic: cast level 10 meteor - enemy party wipped out, + character MP depleted - use ether outside of battle to restore MP - repeat.
- SP is retained between battles. That is, SP is not automatically set to some amount at the beginning of a battle. (In this way, you can feel the effect that previous battles have had on you)


MAPS: Multiple Attack Point System
Now here's something that personally I've never seen before. The basic concept behind MAPS is that each entity on the battle field can be attacked in multiple places (called "attack points"), and each AP has different properties. For example, the standard character sprite has 4 APs (head, torso, arms, and legs). An attack to the head has a lower chance of hitting than, the torso, but it deals more damage. Furthermore, successful hits in some APs may give the victim a temporary handicap. A powerful blow to the legs would reduce a character's speed, while attacking the arms would temporarily reduce the character's attack stength. This will (hopefully) make battles many many times more strategic than the typical RPG battle.


Active Time Battle (with a twist)
To keep things from getting too complicated, we decided to go with a standard ATB timing system. The only difference is, a character may execute an action even though their wait bar is not at 100%. If you're in a desperate situation but know that your opponent is close to falling, you may choose to pre-emptively attack them and hope to knock off the last of their health. Or, if you notice that an enemy is preparing for a powerful attack, you may want to quickly try to defend yourself. However, pre-emptively execution an action is less effective than waiting for the 100% mark, so a smart player wouldn't use pre-emptive actions all the time.


Character Swapping
Similar to FFX, characters may be swapped in and out of battle. The only difference is, the amount of swapping that the player can do is limited. There is a swap counter that actively reports how many swaps the player is allowed (and this counter will increment as the battle progresses). The reason we limit swapping like this is to prevent the player from abusing this feature (I know I abused it in FFX a lot). Additionally, characters who are greviously injured may not be swapped out until they have their health partially restored.


Switchin' it up, Gaussian style
One thing I hate about many RPGs is predicatibility in battles. You encounter the same wolf you've battled 20 times already. You know it has exactly 80 health points. You know what actions it takes. You know how to take it down with minimal effort. Its boring and its not fun when you're always in the know.

The way we ameliorate this problem is by making just about everything a random value, using a standard Gaussian random number generator (consult your math teacher/professor, I'm not going into statistics here). Basically what happens when a battle begins, is first the median experience level of the characters in the party is found. This number serves as the mean for the GRV (Gaussian Random Variable). For each enemy in the party, a GRV is calculated to determine its experience level. Then, the enemy is run through a level-up simulator, where we simulate the enemy leveling up from level 1. Each statistic in each level up has a chance of gaining a certain number of points (note I said a chance, not a definite amount). Thus, you'll always get random foes, and additionally these foes will typically be around your strength level, although some may be much weaker or stronger, depending on all the random variables.

Yes, this is sort of like how Final Fantasy VIII worked, but I feel at least that its a more thorough approach and it will keep the player on his or her toes.


****************************************************************


So that finishes up the main points of our battle system. If you have any comments, questions, or criticisms about the features I explained above, I'd love to hear them. I'm looking forward to it!

[Edited by - Roots on August 22, 2005 12:31:43 PM]

We're still seeking applicants for both positions.


I'm a little surprised that no one has commented on the design concepts I explained above. Maybe I was just too verbose and no one bothered to read it? [sad] I really would like to discuss the benefits and drawbacks that others see in these concepts, so if you have an opinion please share it! [smile]

Your battle system sounds interesting and fairly well thought out, I like the idea of always having (at least slightly) different enemies. Will you be putting something into place to ensure that they also take different actions, and that those actions are appropriate to the situation at hand and the skills of the creature in question? A lot of games follow very simple attack scripts, which are quite predictable and often result in creatures taking actions that don't make much sense.

Yeah, AI is definitely something we're thinking about. I don't like simple battlescripts either (like where an enemy just chooses a random action). As I've already professed, I despise predictability in a game. [wink] I think that the enemy party should try to find and exploit weaknesses in the player's party. If one of the character's in the party is weakened, the enemy party should target that character more to try to finish him or her off (and this is where defensive skills would come in handy). On the contrary, if the player is obviously using one weakened character as "bait" for the enemy and constantly executing high-level defensive skills on that character, then the AI should adjust and not be so gullible. Enemies should actively search out and exploit weaknesses in the characters party and since there are multiple attack points, there can be quite a few weaknesses. I do want Allacrost to be a little more difficult (but not too difficult) than most other games in its class and requiring a higher-order level of thinking from the player.



Also one important feature about this game that I failed to mention was our modular release model. Basically, instead of trying to just create this game all in one go and then release it, we are completing and releasing sections of the game at a time. In that aspect, its somewhat analogous to watching a new episode of your favorite TV show, ending on a cliffhanger, and then having that anticipation for the next episode to air. [grin] Of course the first module takes the longest to release by far, because we have to design the code pretty much from scratch. But after that not nearly as much coding will need to be done and we can focus our efforts on art, music, level design, and story. [smile] As far as I know, this type of development model hasn't been attempted by any other game (there's a good chance I'm wrong though). It also helps us to stay motivated and focused because we set our sights on completing the game one module at a time, rather than trying to concentrate on the (enormous) grand design.

Quote:

Original post by Roots Yeah, AI is definitely something we're thinking about. I don't like simple battlescripts either (like where an enemy just chooses a random action). As I've already professed, I despise predictability in a game. [wink] I think that the enemy party should try to find and exploit weaknesses in the player's party.

Indeed, although I would certainly also hate to see either completely random or 'perfect' AI either. In my opinion allowances should be made for the fact that mistakes may be made in battle sometimes, as well as for the fact that some tactics are just plain better than others, and should crop up repeatedly unless the situation calls for something else. There would of course still be the odd crazy and/or unskilled enemy that doesn't do anything even remotely similar to an optimal tactic, although I expect such an enemy would probably be fairly rare. I don't like predictability either, but you have to also be careful not to be random just for the sake of randomness.

Quote:

Also one important feature about this game that I failed to mention was our modular release model. Basically, instead of trying to just create this game all in one go and then release it, we are completing and releasing sections of the game at a time. In that aspect, its somewhat analogous to watching a new episode of your favorite TV show, ending on a cliffhanger, and then having that anticipation for the next episode to air. [grin]

The idea comes up reasonably often, but I can't think of any games that have successfully implemented it off the top of my head. Do you plan to have a set number of modules (or episodes), or are you just planning to make them as long as you can keep a team interested?

Also, any thought on having different major story arcs? I guess to use the TV comparison this would be equivalent to having a different series, where there might be a few different characters and a different challenge to face.

I'll be interested to see if you can make the modular delivery succesful.

Quote:

Original post by Kazgoroth Indeed, although I would certainly also hate to see either completely random or 'perfect' AI either. In my opinion allowances should be made for the fact that mistakes may be made in battle sometimes, as well as for the fact that some tactics are just plain better than others, and should crop up repeatedly unless the situation calls for something else. There would of course still be the odd crazy and/or unskilled enemy that doesn't do anything even remotely similar to an optimal tactic, although I expect such an enemy would probably be fairly rare. I don't like predictability either, but you have to also be careful not to be random just for the sake of randomness.

True. There will be a lot of balancing that will need to take place, and we have to find a good balance between a "perfect" AI and a stupid/random AI. We want the AI to appear human, and humans make errors. We're also definitely committed to assigning enemies to different AI intelligence levels. Boss-type characters will usually be much smarter and more difficult to exploit weaknesses in than a slime.

Quote:

Original post by Kazgoroth The idea comes up reasonably often, but I can't think of any games that have successfully implemented it off the top of my head. Do you plan to have a set number of modules (or episodes), or are you just planning to make them as long as you can keep a team interested? Also, any thought on having different major story arcs? I guess to use the TV comparison this would be equivalent to having a different series, where there might be a few different characters and a different challenge to face. I'll be interested to see if you can make the modular delivery succesful.

No, there's no plan for us to release a set number of modules. Actually to quote our FAQ the game will be "as long as it needs to be to tell our story", so however many modules it takes us to do that, that's what it takes. [smile] Interesting concept on the story arcs. I don't know if we'd be able to implement it in our current design model, but its an option worth pondering about.

The modular release definitely won't be a trivial thing to accomplish, but I feel its do-able and its worth the effort required to make it a success.

Free bump, as this thread was just unstuck after a week as the Help Wanted Spotlight Project.

This is a promising looking project, I'd encourage anyone interested to enquire.

Thanks for the encouragement Kazgoroth. And we are still actively looking for applicants for both of these positions! Send an e-mail to jobs@ (followed by) allacrost.org if you are interested. [smile]


>>>EDIT<<<

Actually while I'm on the subject, our latest design draft of the battle mode places the top menu down at the bottom (and it still auto-hides as before), and we staggered the tile grid in the actual battle field area so the screen has a little more depth to it. Both of these actions have decreased the amount of area we have to place sprites though (chopped off two rows and two columns). Quick poll: do you all like this design layout better than the first posted above? Thanks.

*bump*

Still looking to fill both positions. Here's a couple of unreleased music tracks that are still in production to hopefully pique your interests. [wink]

Boss Battle Theme

Intermission Theme

Hi! I'm feeling very tempted to respond to the request for a C++ programmer, but unfortunately due to time constraints I'm almost sure that won't be possible. Anyways, your project looks like it's going somewhere, so you should wait patiently for someone to contact you about those positions. I'll keep an eye open for your game in the future!

Just a couple of comments that came to mind while reading this. Since you mentioned animating some tiles, it would be nice to see some old school effects like leaves blown by the wind (lots and lots of particles), reflecting the characters on the water when crossing a bridge, etc. Don't forget to implement these as they're very simple but look sweet! Regarding the battle AI, if you go with a simple finite state machine supported by the usual set of rules (hard-coded counters to the tactics you just mentioned), it would be cool if each rule is tied to a value that can be compared to the monster's intelligence attribute, which is a simple way to convey varied enemy AI. You could also tie different rule sets to different enemy types.

Thanks for the vote of confidence Jotaf. Actually a few months ago our current video programmer said the same thing (wanted to help but didn't have the time). Then later he saw that we were looking for a new video programmer and now he's been doing an awesome job for us. So yeah, keep us in mind for the future. [wink]


> Old school effects
We're already planning on implementing these sorts of things. [grin] The only issue will be finding a balance, because we want the game to be able to run well on older machines (we're allowing users to turn off more advanced visuals to increase performance).

> Battle AI
I was also thinking about tying an enemy's intelligence rating with better/worse AI. I think it would be pretty cool. You could have some bosses that are ridiculously powerful but stupid, and others that are not that strong but very tactical. It could make things very interesting. [smile]

We have filled our battle programmer position. Thank you to all who applied; it was a very competitive process and all applicants had great skill sets and experience. We are still looking for pixel artists to help us out though. In addition to the battle sprite artist, we are now seeking an artist to create map tiles and objects. I have edited the top post (and included some snazy example artwork) to reflect this change.


Also any artists interested in either applying or freely contributing may wish to view the contents of this thread in our forums, which contains some frequently asked questions regarding our artwork design. Thanks!

Its been a while and we haven't filled either of our art positions yet ([sad]) so I'm giving this thread a little *bump*. I hope to have more eye-candy content to share with you all next time I post. [wink]

The screenies you're posted here so far look pretty nice. I like the staggered effect, myself. ^_^

Thanks. [smile] We're planning on releasing a new (and much improved) set of screenshots soon as the code to support it in-game is almost complete, but we still lack depth in the art department to get them done as soon as we want them. Hence, the primary motivation behind us looking for more artists. [wink]

Amazing and detailed. I may be able to throw some graphics your way.. hmm. I am not sure at the time, but my hat is off to you my friend.