Battle Code: Doing It Right

For discussion of the code running behind the game

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Fri May 27, 2011 6:12 pm

Bertram wrote:I wondered whether you thought about the possibility of letting the game continue while the player is selecting the next action.


Not only have we thought about it, we were planning on implementing it. My only concern with this change is that it puts pressure on the player to make fast decisions.


Bertram wrote:- The player could also wait for two or more playable characters and later maybe do combo damage, union skill use, or both possibilities?


We considered this a long long time ago when the project was in its first few weeks. We decided against having any sort of "combo attack" feature because of the complexity involved. I think there's more than enough features to our battle system.
Image
User avatar
gorzuate
Developer
Posts: 2575
Joined: Thu Jun 17, 2004 3:03 am
Location: Hermosa Beach, CA
Contact:

Re: Battle Code: Doing It Right

Postby gorzuate » Fri May 27, 2011 11:05 pm

Roots wrote:
Bertram wrote:I wondered whether you thought about the possibility of letting the game continue while the player is selecting the next action.


Not only have we thought about it, we were planning on implementing it. My only concern with this change is that it puts pressure on the player to make fast decisions.


It used to do that a long time ago. Then someone suggested we pause the action while the user selects what to do, so we implemented it. I personally like it, I don't like being having to rush things (if the action is paused, one can read all the background info about the different skills which I believe was just or is soon to be added; if the action is not paused, no one's going to be reading anything).

But if there's so much back and forth on it, I'd suggest making it a user setting in the options menu, and letting the user choose. In fact, I thought it's already in there? Can't remember...
Image
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Fri May 27, 2011 11:17 pm

Really? I don't remember us ever having a battle system that didn't wait for the player to enter commands. :huh: I guess I just forgot.


Yes, I did add the ability to view detailed information about skills and items from the battle menu about a month ago. Its one of my bigger concerns with making the battle environment continuous, because people will rarely use that feature if there's an implicit penalty associated with it. Maybe what we could do is keep the action rolling but pause it if the player requests to open up the information about a selected skill or item. :shrug:


Many RPGs do allow the user to choose between the "wait" and "active" battle modes. Its certainly worth considering. For now though, I think we should just focus on getting battles to play out well with one of the two types and not create more work for ourselves than is necessary right now. Later on when we don't have more important things to work on, we can always implement the other way and see if we want to offer both choices to the player.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Mon May 30, 2011 1:39 pm

Hi,

Just suggestions, of course. :)

I remember some rpg proposing it as an option, too. Can't remember which one :eyespin:

best regards.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Tue May 31, 2011 8:54 am

Hi again,

You'll want to burn me alive with my suggestions but eh, I can't help :9 (Plus, I try to find the easiest yet good enough way to improve the things I see.)

During the battles, the stamina bar (or the bar which is displaying monsters and heroes portraits slowly going up for the next action)
is displaying the monsters then the heroes. This means the heroes portrait are often covered by the monsters portraits.

I first thought that heroes should cover the monsters but I then thought about something that may be better:

Why not display the hero portrait on the left side of the stamina bar, and the monsters on the right side of it?

This way no images would cover another one, except monsters with monsters and heroes with heroes (but eh, that would be less disturbing.)

Another thought was that the one with the better stamina should be displayed first; this means that IMHO the portrait that are higher than the others should be displayed first, with the exception that when the hero portrait is waiting at the yellow bar for the next action, it should be displayed always first.

Now you can start the fireburner :)

Best regards.
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Tue May 31, 2011 9:09 am

Bertram wrote:Why not display the hero portrait on the left side of the stamina bar, and the monsters on the right side of it?


Great minds think alike. :)
viewtopic.php?p=31063#p31063

I'll be implementing this sometime in the next two days I hope (I leave for vacation on the 2nd and won't be working for five days). If not then I'll do it sometime after I get back. It shouldn't be too hard to make this change, and if for some reason we don't like the way it looks we can always change it back.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Tue May 31, 2011 1:51 pm

Hi,

:approve: I'm glad we agree (along with rujasu) on that point.

Have nice holidays! :)
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Thu Jun 16, 2011 11:10 pm

Hi again,

This time, I've been trying to get productive.

Remember that you were insanely attacking your enemies and the last alive died, the next attacker was slashing in the air before running.
This patch should fix that point, maybe not in the best way but I'm open for suggestion about it. :)
actor-attacking-after-battle-ending-fix.patch.txt
(540 Bytes) Downloaded 150 times


Best regards.
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Fri Jun 17, 2011 4:01 am

Thanks! Your patch is committed as of revision #1972. I was going to see about getting you SVN access, but it looks like you already have it. :) Feel free to directly commit any future patches/changes from now on. :approve:
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Fri Jun 17, 2011 12:36 pm

Hi Roots,

I'm glad that the patch suited you :)

I must say I didn't dare committing directly without any review since I'm still quite new regarding the code base. :heh:

I might ask for review for patches I'm not sure of if you don't mind ;)

Best regards.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Fri Jul 01, 2011 9:39 pm

Hi all :)

@Roots:
When I said the heroes don't deal anymore damages. It's noticed it was this:
Gorzuate wrote:So you can attack, huh? Interesting.

Do you ever see a message printed out from Lua (either a warning or an error, I can't remember at the moment) about ChangeSpriteAnimation being a nil value so Lua can't call it? It looks like that function is used a lot in attack.lua, so that might be my problem.


Roots wrote:Yeah, the ChangeSpriteAnimation is a method on the BattleCharacter class. It *should* be bound in defs_modes.cpp and thus accessible to Lua. The attack fails because once Lua sees that it can't complete the function call successfully, it just aborts.

This is a semi-wild guess, but what might be happening is that Lua is trying to call that function on a pointer to a BattleActor class (IIRC, actor pointers are passed in to the script for both the user and the target). It might be a difference in implementation in Lua or Luabind that is causing the problem. In your case, Lua isn't recognizing that the BattleActor pointer is actually pointing to a BattleCharacter class and thus can look up the function call there. In my case, Lua is recognizing that the pointer is a BattleCharacter and not just a BattleActor (BattleActor is an abstract class anyway) and thus the function look-up for ChangeSpriteAnimation is successful. If I'm right about this, I don't know why it works on one system and not another. May have something to do with different Lua/Luabind versions.

Here's a fix to try. Add the ChangeSpriteAnimation function (with the same signature) to the BattleActor class. Make it virtual and leave the implementation of the function empty ({}). Then add it in defs_modes.cpp to the BattleActor class binding code. Then see if that works. I have confidence that it will.


Hmm, that kind of bug is starting to irritate me. And when it's becoming irritating, I'm just feeling like correcting it. :heh:
Along with the fix Roots proposed to test, should we enforce some luabind version? As there is a luabind source provided within the game one, shouldn't I look to enforce that one on the configure process?
Or is this a bug that should be fixed anyway?

Thanks in advance for the feedback :)

Best regards.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Mon Jul 04, 2011 3:22 pm

Hi again,

I think nobody dared answering this post, so I searched myself.

Here is the fix Roots proposed earlier:
luabind-fix.diff.txt
(1.35 KiB) Downloaded 151 times


At least, it doesn't break a previously working build, but I still have to test it out on a system that is concerned with the bug. Something that I'll do asap. Stay tuned :)

EDIT: I've updated the patch to be a bit better formatted, and I tested on my affected system. It's working!! :approve:
I'm now awaiting the approval of a grand master to push it.

Best regards,
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Mon Jul 04, 2011 8:17 pm

FYI: Bertram and I discussed this on IRC and I gave him the go-ahead to commit it, after adding a comment and making a minor formatting change. It is now in as SVN revision #1994.
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Wed Jul 13, 2011 4:04 pm

Hi again :)

I made a small patch fixing the fact that the wounds from battles didn't make it back to the game characters, here you are:
fixed-hp-sp-update.diff.txt
(3.1 KiB) Downloaded 140 times

Yet, I don't know either it's the best way to do it, or even whether there already was a way to do it, so feel free to comment! :heh:

Also, I noticed that one of my previous "fix" didn't really fixed what should be done IMHO.
I earlier proposed a fix to reset the characters animation to 'idle' once the battle is over. Yet, I just realize we never see the last attack in fact, making the victory screen pop-up maybe a bit abruptly.
Hence, I wonder whether it would be better to wait for the last action to finish before saying "Yes, you win!".
What do you think everyone? :shrug:

Best regards,
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Battle Code: Doing It Right

Postby rujasu » Wed Jul 13, 2011 7:49 pm

Bertram wrote:Hence, I wonder whether it would be better to wait for the last action to finish before saying "Yes, you win!".


Ideally, yes, it would be better.

Also, shouldn't we have some sort of animation/effect for enemies dying? That should be the last thing to happen, not just the attack/action animation.
User avatar
Roots
Dictator
Posts: 8666
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Battle Code: Doing It Right

Postby Roots » Thu Jul 14, 2011 3:37 am

Yes, the various battle sequences still have some work to be done. Its somewhere on the middle of my very long list of stuff I need to/want to/must do. I'm also itching to create a new header/source file pair called battle_sequence.h/.cpp to store the sequencing code that I currently have in battle.h/.cpp. I didn't create a separate file pair when I first wrote this code a couple months ago because the class heavily uses the BattleMode class (since it has to basically implement custom update/draw functions using the members of that class) so it just made sense at the time.


I'll add in your patch for setting HP, but SP I'm going to leave on auto-regenerate to full for now. The reason being that we don't have any means right now to replenish SP in the game. I'll be adding gradual SP regeneration to battles at some point in the future though.


Yes, we'll have some sort of animation/effect when enemies die. Yet another thing I haven't gotten around to. But I don't know what we can do right now, because I don't think there's a way to gradually cause an enemy to go into grayscale mode. But then again I don't like having dead enemies in grayscale to begin with...
Image
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Thu Jul 14, 2011 7:47 am

Hi,

rujasu wrote:
Bertram wrote:Hence, I wonder whether it would be better to wait for the last action to finish before saying "Yes, you win!".

Ideally, yes, it would be better.
Also, shouldn't we have some sort of animation/effect for enemies dying? That should be the last thing to happen, not just the attack/action animation.

Roots wrote:Yes, we'll have some sort of animation/effect when enemies die. Yet another thing I haven't gotten around to. But I don't know what we can do right now, because I don't think there's a way to gradually cause an enemy to go into grayscale mode. But then again I don't like having dead enemies in grayscale to begin with...

IMHO, the worse the better for now, so having just the last attack action finished before that the victory window pops-up is fine to me, and can be kept that way as long as necessary.
Also, thanks for considering my patch :)

Best regards,
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Thu Jul 14, 2011 1:32 pm

Message moved here, where it belonged more:
viewtopic.php?p=31743#p31743
Last edited by Bertram on Sun Jul 17, 2011 11:42 pm, edited 3 times in total.
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Fri Jul 15, 2011 7:53 am

Bump, anyone?
User avatar
Bertram
Senior Member
Posts: 127
Joined: Fri Feb 26, 2010 10:08 am

Re: Battle Code: Doing It Right

Postby Bertram » Fri Jul 15, 2011 5:11 pm

Hi,

As said earlier, I'm now attempting to implement dynamic enemy formation placement, and I must say I've done some progress on the question :)

Here are the specifications I made so far:
(If you're against something, please flame now!!)

User-side:
* The enemies shall have predefined battle position preference. Like warriors will go to the front, mages and archers to the back, boss usually in the middle, whatever order the enemies are added in the roaming party.

* The enemies can have different predefined formation placement:
- Square like (or simple line if not enough enemies.)
- Cross like
- Quincunx like
- Offensive arc (just as this '<')
- Defensive arc (just as this '>')

* if necessary, enemies sprites below others should be partially displayed over them to gain space but also to render the perspective.

* The formation type, and order should be overridable, especially for boss battles.

Technical:
* The enemies are sprites drawn in a specific portion of the battle screen which so far seems to be :
600 pixel wide and 300 pixels high, beginning at the position: 314, 168.

* Speaking of that (and this is a note for others: The origin X=0;y=0 is bottom left of the screen, above the action bar, at least in battles. I had the surprise myself :) )

* There is a curve (seen on heroes) attempting to render the scene perspective of y=3x. I'll have to apply on monsters, too

* Each predefined formation can be set randomly, or later using a parameter but will only accept a maximum surface (yes, width*height) of actors, falling back to the square formation.
The square formation will draw (first statically) the sprite partially on each other based on the space needed, with a minimal of 4/5th of the sprite, for every formation. The 4/5 will be applied for the sprite height but also the width as the current images margin is taking some space atm.

* Enemies with a front preference will be drawn the most left possible, the middle ones after that, and the back ones, after the middle ones.

I've made a patch implementing this:
- Front placement
- square formation
- static 4/5 of the image drawn over the one above.
- Accept any number of enemies but draw them too far to the right, when there is too much of them.
dynamic_enemies_formation.diff.txt
(6.59 KiB) Downloaded 151 times

Note that the patch isn't meant to be pushed!!

Here are two screenshots of what is done so far (Excuse the jpg format but I had a file size problem otherwise):
example 1.jpg
example 1.jpg (160.83 KiB) Viewed 6318 times

example 2.jpg
example 2.jpg (142.67 KiB) Viewed 6318 times

What do you think of it?

Best regards,

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 5 guests