Battle design proposal: A new approach

[MindFlayer]

I really think adding a shake or a flash to the enemies in BattleMode (making it like old style FF games) would add alot to battle mode, and using map sprites for the characters would remove a lot of strain for art for battle mode.

In other words, you are my ally.

Count me in.

[Jetryl]

I'm not sure exactly what you are thinking in terms of how many animations you expect these battle sprites to have, Jetryl. Can you elaborate on this?

The brilliant trick is that this doubles as a full set of map frames, as well. About this many:

[img:393:116]http://www.allacrost.org/staff/user/jetryl/Examples/CT_imp_example.png[/img]



Listen, for now, let's just go with whatever you want to go with for the time being. #3, #4, whatever. I don't care.

I'm getting really sick of this bullshit speculation. You don't have a clue how much time and work this is going to take. I do. I know better than anyone in this discussion, by far, because I'm the only artist speaking here. Our current battle mode is screwed, and I'm not making content for something that's going to look like crap. You can keep trying to make it, in spite of that, but at least half of your current art team has just refused to work on it.

I will work on a design that we can actually get done. I'm going to finish #2, which by your standards, should not regress in any way compared to the existing battle mode, and should look relatively spectacular, because, of course, no one will have made much, if any art for #3/#4 in the interim.

So let's all hug, be friends, and close this discussion.

[ChopperDave]

Wait. These numbers confuse me. What's number 2? The Chrono Trigger approach? If so, I'll help ya Jetryl. We may end up not using it, but we might as well experiment. Sounds like fun.

[Jetryl]

Wait. These numbers confuse me. What's number 2? The Chrono Trigger approach? If so, I'll help ya Jetryl. We may end up not using it, but we might as well experiment. Sounds like fun.

Yep, that's #2. And thank you; I'm prepared to do it myself, but I deeply appreciate any help.

[Roots]

I'm not sure exactly what you are thinking in terms of how many animations you expect these battle sprites to have, Jetryl. Can you elaborate on this?

The brilliant trick is that this doubles as a full set of map frames, as well. About this many:

[img:393:116]http://www.allacrost.org/staff/user/jetryl/Examples/CT_imp_example.png[/img]

Okay, in response to your claim that solution #3/#4 is impossible, I will use this example you posted, some simple assumptions, and mathematics to show lower artwork cost for using separate battle sprites for enemies. To re-iterate, this analysis is for cost of enemy sprites only, not taking into account character sprites, battle backgrounds, etc.

Assumption #1: regardless of what approach we take, the total number of enemies in this game will be n

Assumption #2: battle sprites are always twice the width and twice the height (4x) the size of corresponding map sprites

Assumption #3: the variables x and y correspond to the average width and height of enemy map sprites, respectively.

Assumption #4: for the map sprites only approach, we require a total of 28 frames for each enemy map sprite (same as the CT sprite example above)

Assumption #5: for the separate battle sprites approach, we still require map sprites, but only require the four walking animations (which are 12 frames in the CT example). Furthermore, we only require 1/4th of our battle sprites to have corresponding map sprites, since we don't need to show every single enemy sprite walking around on a map (we only show a single sprite representing a "party" of sprites)

Assumption #6: the total cost of artwork production is directly equivalent to the total number of pixels that must be created (this is of course not entirely true because damage frames and some animation frames are easy to create from a derivative image, but lets keep the analysis simple here)

Map sprite only approach
We require 28 frames for each enemy sprite.

Total # of pixels = (x*y) average size * 28 frames * n enemies = 28xyn

Separate battle sprite approach
We require four damage frames for each 4x size enlarged battle sprite, plus 12 animation frames for 1/4 of the total number of enemies in the game.

Total # of pixels = (2x*2y) average size * 4 frames * n enemies + (x*y) average size * 12 frames * n/4 enemies = 19xyn



Therefore, given these assumptions and this simple analysis, the separate battle sprite approach has a lower artwork cost by 32% (== (28 - 19)/28). Now, I know its easy to tweak these numbers to favor one approach over the other, but I tried to be as unbiased and realistic in my assumptions as was feasibly possible. Note that even if we create walking map animations for every single enemy in addition to the separate battle frames, the cost becomes 28nxy; the same as the map sprite only approach. So as long as we don't create a map sprite for every single enemy that we have battle sprites for, the cost will always be lower than the map-sprite only approach.


I can't believe I just did a mathematical cost analysis for Allacrost artwork. My engineering roots are showing


I hope that you (Jetryl) will provide a compelling argument/explanation for using map sprites only that exploits flaws in my analysis (which I admit is far from perfect, but was the best I could do with the information that I know).

I'm going to finish #2

Alright, if you really feel that strongly about it I have no problem with that. But I think we should keep code development for this in a separate branch so that the map code doesn't become a mess.

:eyebrow: Listen, for now, let's just go with whatever you want to go with for the time being. #3, #4, whatever. I don't care. So let's all hug, be friends, and close this discussion.

We will not go with whatever I want nor will we go with whatever you want. We'll do what we have always done, which is have the whole team vote on this decision and go with the majority rule. And furthermore, closing this discussion would not solve anything, especially as we are just getting started.

[Jetryl]

Assumption #6: the total cost of artwork production is directly equivalent to the total number of pixels that must be created (this is of course not entirely true because damage frames and some animation frames are easy to create from a derivative image, but lets keep the analysis simple here)

I hope that you (Jetryl) will provide a compelling argument/explanation for using map sprites only that exploits flaws in my analysis (which I admit is far from perfect, but was the best I could do with the information that I know).

This is the flawed assumption, and you would know this if you knew how to draw. The difficulty scales with area, and scales exponentially.
This is compounded by the fact that art is produced in a feedback loop. Every change a person makes to something has to be applied to a much larger number of pixels, and any drawing is generally composed of a large series of iterative changes and improvements. Each change that an artist tries as they're working on their piece, takes a longer chunk of time, which exponentially increases the time it takes on top of the intial exponential increase. It's not simply that it takes an increased amount of time to do, but it requires considerably more skill. Larger drawings reveal issues with perspective, and finer points of anatomy that lesser artists are just unable to handle.

The coup de grace comes in that this makes the art far more intimidating to make. For any artist who does not have a robotic emotional makeup, it usually makes it impossible to make - or makes the art produced for it of meagre quality. It also makes it extremely difficult to keep things in the same style - we have all of our map sprites in the same style, but we have a stylistic disjoint between Sylon's battle sprites, and Safir's battle sprites, which is something that people outside of the project have complained about (c.f. that pixeljoint posting). This necessarily limits the pool of people who can provide monster art to a very small number. In the entire 3-year history of this project, we have only had Safir-Kreuz able to do this well (except for his skeleton, sylon's sprites have been rather mediocre). That's not speculation, that's evidence - right there. We have actually gotten several people to do at-or-nearly-at final quality work on map sprites (our walking animations are close to being as difficult as attack animations would be). So by doing this, you're limiting our pool of potential battle mode artists to one guy.




I like to see things well animated, and I would prefer our battle mode to have animated enemies. Yes, I do consider the first few entries in the Final Fantasy series to suck in this manner; the bosses in many side-scrollers or other action games (magic sword, castlevania IV, Contra, Zelda:LttP) looked gorgeous compared to still images that just shook around. I want to make a game that has the level of animation of something like Tactics Ogre, or FF Tactics. Those games look awesome. Given a choice, I would choose to have our sprites at a lower resolution, but have them well-animated - instead of having them at a larger resolution, and having no animation.

I feel that if I do the work to make all the necessary art and code to implement this, that I should have the right to make such a decision. Furthermore, I believe that because I am more willing to work on this than anyone else, that we will rapidly have more "fully animated sprites at a lower resolution" than we do "large unanimated sprites". I feel justified in this, because no one else is working on content your battle mode design. In the past year, the only person who made a single original battle sprite, was me (safir's sprites, IIRC, date from earlier than that).


I'm happy to work on a game that has your story, and your characters, but I'd like to have some authority in the visual sphere. I don't want to work on something I don't even like. That seems like a fair deal, to me. You have no right to expect me, or anyone else for that matter, to spend years making something they actively dislike.


(FYI, I am of course still very enthusiastic about making art for the rest of the game, and will continue to do so.)

[Jetryl]

We will not go with whatever I want nor will we go with whatever you want. We'll do what we have always done, which is have the whole team vote on this decision and go with the majority rule. And furthermore, closing this discussion would not solve anything, especially as we are just getting started.

We will go with whatever gets completed, because that's all we are able to do.

I suspect I will complete my vision of battle mode in less than six months; that is, finish the code, and finish a good set of some 20-30 battle-ready sprites. I suspect the existing vision of battle mode won't be completed for another five years; especially without me helping it.


Voting in favor of an unfeasible solution doesn't make it any more feasible. What part of this don't you understand? I refuse to waste my time on something that will never get finished, and will look bad to boot. You have a choice of cars #1-4, where only car #2 has gas in it. You can go ahead and pick any one of them, but I don't think they'll all get you to your destination.

Alright, if you really feel that strongly about it I have no problem with that. But I think we should keep code development for this in a separate branch so that the map code doesn't become a mess.

I think the exact same thing.

[MoOshiCow]

Well, I'm coming into the discussion from the sidelines, and a bit late..

I guess, it sounds like #2 is going to be the more radical change,
since it changes a lot of stuff in terms of art design and battle system
design.

I'll say #2 sounds like the "better-looking" option, as in visually more appealing. I am a big fan of CT, so I am not against such a change.
Also, since our only Artist, who seems to be in this discussion, is really willing to go forward for these changes, I don't think it's a bad idea at all to try this option out.

But I don't necessarily think #3, #4 will be a horrible option either.
I guess since I'm not an artist, I am not as visually sensitive towards a game...
but I generally think a "good" game isn't all about visual perfection nor is it about the perfection of one particular part.

It's about balancing, mixing all these aspects together to make a "fun" game.
So, no..I don't think early (SNES) Final Fantasies are considered crappy games...
yes, they have some old art styles..with limited animations...
but if you think about old game consoles that don't have all the memory that new gen consoles have...it's a reasonable decision on their part to lower the quality of visuals...
but that doesn't ruin the player's (at least mine) fun...

[zick]

i like jetryl's #2 approach, but i've got some things you should keep in mind:
1) each battle will probably have to be hard coded to the map, now whether or not you participate in the battle is based on various triggers, like did you step on the appropriate tile to trigger the battle ... it'd be neat if a battle took place in a certain area of the map but had several tile triggers like one where you're walking away from the battle, so the enemies will attack from behind (pre-emptive for the enemies)
2) i was just playing ct a month or so ago ... one problem i noticed with the battle is enemies could move anywhere and sometimes would move under the hud and you couldn't see that you were actually attacking them. so i think restricting enemy movements to specific ranges is essential.
3) i'd like to see enemies show some damage though and look like they're being beat up.

i also like the ff style side view but the one thing that i've always hated was the fact that enemies were not animated in any way. i think lunar on ps1 took care of this problem best. if your not animating enemies, you're just wasting your time repeating old-school cliches. if you allow animation of enemies i have no problems with root's proposals. i think some proposed animations should be waiting for a command, waiting for turn to attack, attack (have a couple different attacks like a tentacle monster might bite or hit you with a tentacle), and a death sequence. each of these sets should also allow damage to be shown as the enemy breaks down.

[Jetryl]

Hey, thanks for the comments! Input is very appreciated.

i like jetryl's #2 approach, but i've got some things you should keep in mind:
1) each battle will probably have to be hard coded to the map, now whether or not you participate in the battle is based on various triggers, like did you step on the appropriate tile to trigger the battle ... it'd be neat if a battle took place in a certain area of the map but had several tile triggers like one where you're walking away from the battle, so the enemies will attack from behind (pre-emptive for the enemies)

We will actually want certain encounters to be predefined to always happen a certain way (guard monsters, dialogue scenes, etc), but we'll also want some to work procedurally. Some of "how to do this" could well hinge on map design, and restricting monsters from entering certain areas; if we don't want battles to occur in the "small, single-file tunnel", then we simply disallow monsters from going in there. This certainly won't account for everything, but then, I haven't really sat down and designed this yet. Still a lot of prognosticating to do.

2) i was just playing ct a month or so ago ... one problem i noticed with the battle is enemies could move anywhere and sometimes would move under the hud and you couldn't see that you were actually attacking them. so i think restricting enemy movements to specific ranges is essential.

One major theme with the development of this game is the fact that we're not limited by our hardware in the ways that SNESs were. This is probably one area where we have little to worry about, since we can convey the same or greater amount of information in much smaller (as a percentage of screen space) GUI components (in fact we already do). In chrono trigger, they had to spill the GUI components down onto the battle screen, because they only had so many pixels to work with, and there's a lower limit under which text becomes illegible - a limit they were butting up against. This is also a huge part of why they had the (very irritating, very artificial) 3-character party limit; they couldn't easily fit more characters on the screen (there were other extremely significant reasons, like party balance, but that was a big one). I think, if we simply make sure nothing drops below the top of the bottom info bar, we'll be good to go.

CT also had certain moves where characters would leap into the air, and do a downward strike (or vice-versa). In fact, you just gave me a totally righteous idea; one major way we could improve over CT or FF's model; there is no reason we can't have the camera follow major characters as they jump into the air. That would look totally friggin awesome.

3) i'd like to see enemies show some damage though and look like they're being beat up.

Yeah. As much as I dislike the loss of the "gradual blend" between damage states, I think that it incurred a major problem: creatures could not change pose as they got damaged. In some games, especially with human characters (for which nintendo restricted itself from showing blood and wounds), pose was the only indicator of something's physical condition. I think pose is a very important indication of something's physical state. I think we can use pose to do exactly that, though - tentatively, I think we can have more than one, but should have only have a few different "standing animations" for each monster type.

Generally, as a monster gets increasingly wounded, they'll be less animated (by rote of being significantly less lively) - the "last 10-15%" animation might be a still frame. The "15-50%" animation might be two frames of slouching and labored breathing. The normal standing animation will probably be 3 frames, however, for quite a number of smaller monsters, we can do what CT (et al) did, and just use a walking animation as the "standing" animation. Related to this, I think it would be an interesting idea to have behaviour of the monsters change relative to their health. This would probably be fixed according to creature type, which conveniently means we could pair a very intuitive animation with this state to make it known. Some monsters might modestly change their behaviour - some might just limp out and become, all-around, easier to fight. Some (think turtle-like) might cease attacking altogether, but massively raise their defense (and perhaps regenerate?). Others might go berzerk - if we took this to extremes, they might even attack their friends (like the Myrkridia in Myth II:Soulblighter).


Some principles:
- because they occupy so much screentime, what we convey with a standing animation comes off as the "current condition" of a unit. They're probably the most effective place to do this kind of stuff.
- because all other animations move across the screen, they don't have to look damaged during their execution (especially if the wounded standing animation looks colorwise similar to "all the other animations" - not covered in blood, in other words). This is an old principle of animation, which wesnoth really hammered home for me - it's quite hard for our eyes to notice detail on quickly moving images. This can save an enormous amount of work, and still give us the best of both worlds.
- standing animations are an easy place to do all this stuff, since they're some of the easiest animations to draw.

i also like the ff style side view but the one thing that i've always hated was the fact that enemies were not animated in any way. i think lunar on ps1 took care of this problem best. if your not animating enemies, you're just wasting your time repeating old-school cliches. if you allow animation of enemies i have no problems with root's proposals. i think some proposed animations should be waiting for a command, waiting for turn to attack, attack (have a couple different attacks like a tentacle monster might bite or hit you with a tentacle), and a death sequence. each of these sets should also allow damage to be shown as the enemy breaks down.

To offer the flip-side of things, there were a number of things I didn't like about chrono-trigger's battles. The graphical department was fairly good, but I had a few complaints there:
1] chrono's spin-techniques didn't use enough motion-blur. Especially on chrono's sword-spin techniques, it looked like four obviously separate frames playing in sequence. Curiously, Marathon Rubicon managed to do an excellent job of animating "fan blades spinning" with just four frames; I think it's a trick of where transparency is applied, rather than a simple need for more frames. I think a great deal of inspiration could be taken from the "tornado/twister ability" animation seen in Kirby's Dreamland for the NES, if we are to have spinning animations. This same thing was very true about Robo's techniques as well.
2] the aformentioned business about GUI guzzling up screen space
3] bosses didn't have a lot of animation of their parts
4] animations of electricity were static images being displayed, rather than procedural animations. Procedural lighting just looks so friggin cool.
5] A number of major attacks (Fire 2, Lightning 2, laser spin) were just cheap "static images" being cycled onscreen, rather than actual procedural animations.
6] many fire and water based animations didn't quite look the part. They could have used a lot more particle effects.


In the battle mechanics area, there was a good deal more:
1] no difference between physical damages; all PCs dealt the same damage type, and monsters responded to it in the same way. The classic difference between slash, smash, and pierce was lost, and could have added a lot of flavor. It especially bugged me when lucca got what were basically fire-based guns (plasma), and didn't do fire-based damage. Our elemental system should neatly handle this.
2] not much variation in damage per strike; characters either hit, or didn't hit; there were no parries, no grazing strikes, etc.
3] for bosses, there was something similar to our MAPS, but it would have been awesome to have at least 2 attack points for lesser monsters - especially those that were really 2 creatures, like the "imp riding a roly". MAPS to the rescue.
4] few defensive options - outside of a few high-level shielding spells/items, it was basically a game of "kill them before they kill you".
5] No variability in time consumption for techniques. Simple sword slashes took the same amount of time to recover from as ridiculous hack-everything-techniques.
6] too few PCs and Monsters on the screen at once. Huge brawls are fun, and the lack of them really hurts certain in-game scenes.
7] too many wacky and silly attacks, like frog's "frog stomp", or robo+ayla's "boogie". These are supposed to be easter eggs, not basic attacks accessible in the normal game. Like the "Poyozo Dance", silly attacks should have been very difficult to get.
8] ayla's charm spell really broke the flow of the game, because you needed to use charm against nearly any boss, since tabs (especially the speed variety) are basically priceless. This meant Ayla was tagging along for practically every boss battle after you got her, which really dampened the variety. Not to mention that the attack didn't make any sense - it created items that were not present on the monster's death, it worked on extremely non-male, non-humanoid creatures, and even when it would have made sense, it was just out of character for the enemy to do that. It would have been a lot cooler to have this "plot/character element" as something in the actual plot/events of the game, rather than as a random attack. (E.g. a jailbreak scene, a "weapon of mass distraction" scene, an infiltration scene, etc.)


There are probably other things, I just can't think of them at the moment. I just wanted to give this as a quick example of how, although there were some key things about CT that I did like, there were some equally key things I really didn't like - I most definitely do not want to just "clone" their battle system.

[Jetryl]

Yeah. As much as I dislike the loss of the "gradual blend" between damage states, I think that it incurred a major problem: creatures could not change pose as they got damaged.

It's worth noting that in a 3d game, you -can- get the best of both worlds, because the "gradually changing image" is just a texture that gets applied on a model, and the model can change it's pose without breaking the texture. With models that have actual skeletons, and can interpolate between two "stance animations", they can easily do a gradual shift of stance, too.


BTW, this is in no way a suggestion for us. If we ever use anything 3d, we'd want to only use it late in the game, and probably not for character models (most likely, just for attack projectiles, like falling "huge boulders"). Even that is doubtful. It would be a huge amount of effort, and right now, we should probably just put it out of mind until the basic game is done.

[Roots]

Pardon my dissection of the various posts above.

Some of "how to do this" could well hinge on map design, and restricting monsters from entering certain areas; if we don't want battles to occur in the "small, single-file tunnel", then we simply disallow monsters from going in there. This certainly won't account for everything, but then, I haven't really sat down and designed this yet. Still a lot of prognosticating to do.

This is one of the minor reasons why I'm against having the battles occur on the map instead of on a battle backdrop. We have to have a set of pre-defined areas on a map where we can allow a battle to occur, and we can't allow enemies to roam in certain parts of the map.

CT also had certain moves where characters would leap into the air, and do a downward strike (or vice-versa). In fact, you just gave me a totally righteous idea; one major way we could improve over CT or FF's model; there is no reason we can't have the camera follow major characters as they jump into the air. That would look totally friggin awesome.

Oh yeah, I love this idea Dynamic zooming throughout a battle will really increase the sense of action, since the screen isn't statically fixed in one position the whole time.

3) i'd like to see enemies show some damage though and look like they're being beat up.

I think pose is a very important indication of something's physical state. I think we can use pose to do exactly that, though - tentatively, I think we can have more than one, but should have only have a few different "standing animations" for each monster type.

While having several different poses indicating something's state sounds like a good idea, my opinion would be that it is too much work. Especially if we end up going with a #2 CT battle system, and then you have to do N/S/W/E poses instead of a pose in only a single direction. Not to mention that altering something's pose is a lot more time consuming than simply creating 3 damage frames and blending them together.

I am generally of the mindset that we can have damage frames, or we could have animation. But not both.

if your not animating enemies, you're just wasting your time repeating old-school cliches. if you allow animation of enemies i have no problems with root's proposals.

I disagree that non-animated enemies qualifies as "old-school cliches". The games of the past were limited by hardware and memory size, which restricted their artwork. Conversely, we are restricted by limited artists and a non full-time staff. Personally, I felt that the animation in enemy sprites in CT didn't add much since the animations were for the most part incredibly basic and not smooth. It was more of the fact that enemy sprite positions could be taken into account when selecting area of effect type attacks (which I don't think we should do in Allacrost, since our battle system is already pretty darn complicated).

If we do go with animation, one trick we could use would be to provide multiple color variations of the same sprite. For example, a spider sprite in shades of red, green, black, etc. where each is treated as its own enemy. Personally though, I feel that sort of cheapens the game and I would like to avoid using it unless absolutely necessary.


My personal stance on animation right now is:

- Use map sprites for characters and have several detailed animations for each
- Animate the action effects (ie cure spells, fire attacks, etc)
- Do pseudo-animation for enemies (ie, shaking, jolting forward when attacking or backward when being hit), which will allow us to keep the enemy sprites detailed in battle and allow us to use damage frames
- Provide animation on some battle backgrounds (sprites fighting in the background in a big battle scene, procedural particles blowing around in a sandy desert, etc).



Let me come out and say that I have nothing against a CT style battle system. In fact, way back when Allacrost was first starting we had a meeting where one of the topics we discussed was do we want our battle system to be more like Final Fantasy, or more like CT? We decided on FF-based, came up with all these great ideas and incorporated some of them already, and the player's have seen this system in action. What I am against is a major paradigm shift on an established design point, just because some people don't like the current system. Newsflash: its impossible to make a game that everybody likes. If we change to a CT system, people will complain about things missing that our current battle system has. Just because you prefer one style or another doesn't make that particular style "correct", it just means thats your personal preference.


Sorry, didn't mean to banter about that. But I felt that it is something that needs to be said and recognized by everyone contributing in this thread.

[Roots]

To sort of summarize the major themes in this thread, I think its less a question of "which design do we want to go with?" and more of a question of "how do we want to approach individual design elements?". Those design elements, along with the major solutions proposed for each are:


Character sprites
#1: Use character's map sprites and animations in battle (enlarged 2X in size)

#2: Use separate battle sprites and animations for characters

Enemy sprites
#1: Use map sprites for enemies, and create a small set of basic animations for each

#2: Use separate, detailed battle sprites for enemies along with damage frame blending

Battle environment
#1: Battles occur on the same map background that the player was exploring when the encounter occurred

#2: Battles occur on detailed background images

Sprite orientations
#1: Sprites battle in full 2D movement (requiring N/S/E/W animations)

#2: Sprites battle in pseudo-2D (characters on left, enemies on right)


I think the only one that we've really reached a concensus on is the character sprites. There have been virtually no vouchers of support for separate battle sprites for characters, and I think I was the only major supporter for doing the 3D->2D artwork technique, but Jetryl has since convinced me that going with map sprites for characters in battle would be best.


What we seem to be butting heads with the most right now is the enemy sprites design point. Jetryl is heavily in favor of using the map sprites, while I am heavily in favor of creating separate battle sprites. Battle environment and sprite orientation we haven't fully debated yet; but its been mentioned several times.

[kess]

Hm. I usually follow threads like this in silence enjoying the creative effort of each and all. So in a way I feel sorry to intrude giving voice to my mind.

I just happened to have a “vision” of the battle environment, but I am not sure what plans you already have for it.

#2 Battles are displayed on detailed (composite, barely animated) background images

I treasure all visual aids when entering different playing modes, and entering such a perilious thing as a battle really could need a complete change of background.

What I’m seeing in my mind is that the background images reflect the unique setting of the battle, such as place, time of day, weather, mood et cetera... «A road intersection in a forest, high noon, it’s raining from an otherwise quite clear sky, a small animal runs away, the atmosphere is quite calm. You’re battling someone/something quite easy.»

«A thin cave passage, only a little light, some small movements of something undetermined, the atmosphere is heavy and tensioned. You’re battling someone/something quite nasty/difficult. Perhaps the battle sounds are echoing away in the distant.»

But, really, all that is needed are a couple of detailed backgrounds---the more details, the less boring they become. And as the development progresses...

(BTW, I like how Allacrost is coming along. Hooo! to you all.)

[Jetryl]

Newsflash: its impossible to make a game that everybody likes. If we change to a CT system, people will complain about things missing that our current battle system has.

Every time you say this, you keep making this adamant assumption that we're somehow going to lose features from our battle system. The only potential reason you gave to support this is that the sprites would be smaller, and thus MAPS would be hard to see. I have since said that the sprites (and map tiles) would be doubled in size during battles, leaving them about as big (in terms of final pixel and screen size) as the current ones. This negates that complaint.

If we run through our major battle features:
- elemental damage
- SP use for techniques, SP are scarce and must be either rested in town, or recovered by rare items.
- Multiple Attack Point System
- Battle Wear (really just conditions induced by hitting a certain attack point, such as stumbling up a character by attacking their legs)
- having decently challenging foes appear even when the character is high level
- "Standard ATB with a twist"; mixing up the timing so that certain attacks/defenses take longer to recover from, making characters vulnerable while spell channeling
- character swapping

I can't see how changing the visual aspect, or even making 2d position a factor, could possibly impede any one of those. In fact the way I'm suggesting would probably help you, because a number of these (like spell channeling) would have the monsters actually going through animations to indicate things like spell channeling or battle wear. If we don't lose features, I can't see why someone would suddenly turn from liking to disliking our battle system. Especially since my proposal for battle mode doesn't necessarily have to add any gameplay changes, and thus can't "overcomplicate" gameplay.

If we do go with animation, one trick we could use would be to provide multiple color variations of the same sprite. For example, a spider sprite in shades of red, green, black, etc. where each is treated as its own enemy. Personally though, I feel that sort of cheapens the game and I would like to avoid using it unless absolutely necessary.

Yeah, I'm not a fan of the "cheap and obvious recolors".

I think we can do this sparingly if we do "significantly more than just recoloring",such as deformations to their body - a different variety of spider could have a larger, different-shaped abdomen (and different fangs), with different markings, while sharing the legs with other spiders - the legs on a spider would be the place where animation would get messy, and if we kept those the same, we could save tons of time. This could be an especially effective tactic for creatures that are -supposed- to look similar.

While having several different poses indicating something's state sounds like a good idea, my opinion would be that it is too much work.

Animations like those are easy to make - it's part of why they end up being the first animations made by so many amateur spriters out there. They're really just a single image with minor modifications. Also, it would only be a -few- poses, either 2,3 or even as low as one for very weak monsters. They've definitely been really easy for claudius and laila, and they'd be even easier for most monsters, because the monster's standing pose would generally be its battle-ready pose.

[wayfarer]

As someone who has sprited once too often I would say stick to Jetryl's proposal. The time and amount of work to sprite is not really low and if you want to make it good looking and halfway in a finite fashion of time use use as many synergy effects as possible. Else the artists just work their ass of and nothing gets done.

My 2 cents.

[Roots]

Every time you say this, you keep making this adamant assumption that we're somehow going to lose features from our battle system.

We're losing damage frames if we go with your approach, that's one feature. What really freaked me out was when you mentioned a couple weeks ago about 2D positioning and movement and taking advantage of that to do different area of effect attacks, etc. That set off some red alarm in my head that you're proposing drastic changes to the battle design (other than graphical). But you're right, I am a bit over-reactive in thinking that there are going to be major feature changes.

I can't see how changing the visual aspect, or even making 2d position a factor, could possibly impede any one of those.

You're right there. But remember that we have been discussing other features that may have to be drastically re-thought. (See Battle Design Topics II thread).

I think we can do this sparingly if we do "significantly more than just recoloring",such as deformations to their body - a different variety of spider could have a larger, different-shaped abdomen (and different fangs), with different markings, while sharing the legs with other spiders - the legs on a spider would be the place where animation would get messy, and if we kept those the same, we could save tons of time. This could be an especially effective tactic for creatures that are -supposed- to look similar.

I agree with you here (I was thinking the same thing in fact). Re-use would be acceptable as long as the form changes to a significant degree.

Animations like those are easy to make - it's part of why they end up being the first animations made by so many amateur spriters out there. They're really just a single image with minor modifications. Also, it would only be a -few- poses, either 2,3 or even as low as one for very weak monsters. They've definitely been really easy for claudius and laila, and they'd be even easier for most monsters, because the monster's standing pose would generally be its battle-ready pose.

Even if they are easy, they are time consuming. For characters I would say that's fine, since we'll only have a handful of characters in the game (but we already have portrait damage blending, which partly conveys the same information). For enemies I would say that's too much, especially if we have to do 2-3 poses in all 4 directions.



I think we should all start thinking about which of the two alternatives for each graphical design topic that I listed a few posts ago (sprites, background, etc) we personally feel compelled toward. Of course whatever we decide to is by no means final, and we can always revisit this discussion if we need to change to an alternative.



-----------------------------------------------

(I digress here, feel free to ignore)

I mean no offense here Jetryl, but you seem a little too eager to me about doing all these different sprite animations. The whole purpose of this thread was to figure out how to change the battle design so that the artwork load is reduced. I view a lot of your proposals as reducing only the complexity of the work, but not so much the load (ie, replacing a few detailed, complex animations with numerous animations for simpler sprites). Of course, I say this knowing that I have no concept of how long it takes to do one or the other, but based on what you say on the forums (ie, "Here's animation X, took me about 3-4 hours"), I visualize a lot of time being taken up by all these different poses, etc. Also most artists who join this team are no where near as good as you, so I assume it would take them 1.5-2.5x longer to produce the same animation, and probably in only mediocre quality.

[Roots]

Okay, I think I have developed a compelling argument for having separate battle backgrounds as opposed to having the battles take place on the map. Here is our current battle GUI layout:

[img:1024:768]http://www.allacrost.org/staff/user/roots/mockups/battle_layout_v3.1.jpg[/img]


Keep in mind that we'll also sometimes have a menu along the top for dialog events and other things during battle. And because we've pretty much all agreed that we absolutely do not want our sprites to be able to "hide" behind a GUI menu like they sometimes do in Chrono Trigger, that leaves us about a 1000x600 pixel area for battles to take place. In terms of map tiles, that's roughly 31x19 tile area where the sprites will battle.


Now we can (and probably should) take some liberties with collision detection during battles, but for the most part we want this 31x19 tile area to be open space. We want a sprite in an idle stance at a particular position to "make sense" (e.g., not standing on top of a pit, a tree, a wall, etc). This is where we run into trouble. It means that we are going to require several very large, open areas on our maps to allow for battles to take place in certain locations. This may be okay for some maps (a grassy field) but will be a major burden for others (an indoor environment) Another restriction is the fact that we've been planning for up to 4 characters and many enemies in battles. Chrono Trigger had 3 characters max and I think a max of 3-4 enemies in battle.

We could perhaps mitigate this by enlarging the map by 2x, brining our open area requirement to about 15x10 tiles, but that's still a pretty big requirement. I mean, I don't think we have a single area that open in our existing cave map. Doing the battles on maps will have very large, costly burdens for map designers and programmers. They will be required to:

- Create several large, open areas where its feasible for battles to take place

- Define what battle field to go to when an encounter takes place

- Make sure enemies don't wander too far from a battle zone

- Programmers have to take into account collision detection in battle, which greatly complicates sprite placement and movement

- Figure out how to do a good transition from a map encounter to a battle (ie, move to the battle field, have the enemy sprite "spawn" off several more enemy sprites that will fight, etc)



I feel that the restriction on requiring maps to have battlefields with large open areas alone is a huge drawback. I strongly, strongly feel that we should continue to go with battle background images for the battles to take place on. Yes they are an extra cost for the artwork team, but I feel it is justified due to the cost involved for both map designers. I welcome your comments and criticism about this topic.

[Jetryl]

I mean, I don't think we have a single area that open in our existing cave map.

Actually, we've got perhaps a dozen or more, just in that tiny map. Most of our maps are going to be way, way bigger than that, anyways. I'll show you what I mean in a few hrs, when I have time to prepare a mockup.

- Create several large, open areas where it's feasible for battles to take place

Frankly, those are the only places it makes sense for battle to take place, anyways. Right now, we can have the player wandering through a tiny, "one man wide" tunnel, and start a battle - a battle which mysteriously teleports him to an open cavern where he has a fight with a whole gang of monsters. Really, we're not having that battle in the small tunnel anyways - we're forcing it to happen in a big room, graphically. I can understand a provision for a one-on-one faceoff with a single monster going after the head/tail of a party marching single-file in a small corridor, but if we wanted to properly represent that in the existing battle mode, we'd have to make a special battle screen just for that, and add in logic to simulate the fact that only the front character really has any access to either be hurt by, or do damage to the monster (Area-of-effect or non-line-of-sight techniques notwithstanding). Really, the only thing our current battle mode -does- simulate is "battles in an open space". We can pretend, in our heads, that it's doing something else, but that's really, really stretching the metaphor. Kinda the same way a text-adventure does; and I'd rather directly represent things.


The simple proof of how easy it is to restrict monsters to appropriate areas for battle is the fact that we've already done this, with our current monster zones.

- Define what battle field to go to when an encounter takes place
- Figure out how to do a good transition from a map encounter to a battle (ie, move to the battle field, have the enemy sprite "spawn" off several more enemy sprites that will fight, etc)

1] We're already -in- the battle field, when the fight starts.

2] I would like to, for both the party and the monsters, have a one-to-one isometry between monsters/players in the fight, and monsters/players on the map. What you see is what you get. No suprises, unless there's supposed to be an ambush, and in those cases, you'd see the ambushers jump out of hiding.

When a fight starts, all monsters in that zone (as zones are currently used, size-wise) engage the player in combat.

- Programmers have to take into account collision detection in battle, which greatly complicates sprite placement and movement

We don't have to do this, off the bat, and when we get around to it, it's nothing we haven't already solved the majority of in map mode.

I mean no offense here Jetryl, but you seem a little too eager to me about doing all these different sprite animations. The whole purpose of this thread was to figure out how to change the battle design so that the artwork load is reduced. I view a lot of your proposals as reducing only the complexity of the work, but not so much the load (ie, replacing a few detailed, complex animations with numerous animations for simpler sprites). Of course, I say this knowing that I have no concept of how long it takes to do one or the other, but based on what you say on the forums (ie, "Here's animation X, took me about 3-4 hours"), I visualize a lot of time being taken up by all these different poses, etc. Also most artists who join this team are no where near as good as you, so I assume it would take them 1.5-2.5x longer to produce the same animation, and probably in only mediocre quality.

Complexity IS a huge factor in the load.

"Most new artists" can actually do _something_ for map style sprites. In fact they already have, and around 50% of the time, they've done as good a job as I could.
But they can do absolutely nothing for larger sprites.

[Jetryl]

The promised mockup. Yes, the screen is 1280x960; I'd prefer to switch the entire game to this kind of resolution and zoom factor. I've become convinced, over the last few months, that Rain and Josiah were absolutely right about that:
http://www.allacrost.org/forum/viewtopi ... 0630#20630

But let's ignore that for a second. Here's the picture, and this is what I'm suggesting. As you can see, there's tons of space for different characters; easily enough for the 4 we were slated to have in the current design. This should give you an idea of what I'm gunning for.

[img:1280:960]http://www.allacrost.org/staff/user/jetryl/Misc/battle-mockup.png[/img]