[XP] Advance Wars Engine

[KK20]

Yeah, I was busy for a long while, not to mention my hard drive died during the time I was really into it (don't worry, all my stuff is saved). I'll get back into the groove of things in the coming days. I had a lot of script requests in between that took my attention away from this. I was also working on some of the boring, more technical stuff as well (lots of experimenting coupled with trial and error).

I could implement a basic AI, but I would need to do quite a bit of programming first. Plus, I don't think there are script calls you can use via an event to manipulate certain functions.

lol I had a ReadMe file in there. First line says to install the font.

But thanks for the comment. I know I haven't updated in a long while, but that's because I never finished anything I had started in motion.

[Gears]

Okay then, here we go.

I've been looking into this engine, and trying to add CO's. so far, I've had some marginal success, and am trying to push the engine's (CO) limits a bit and see what happens.  However, I've encountered a few roadblocks which i would like to see if you've got a solution for.

To start off, i've been tinkering with unit ranges. For instance, i've made a CO who simply adds +1 range to every unit, which instantly turned all my units into indirect units!  I guess the engine handles the difference between indirect and direct attack units simply with the unit ranges, with the maximum for direct attack units being 1. Is there a way to circumvent this using CO properties? I haven't been able to find exactly where in your code the difference between indirect and direct attack units was made, but it should probably be modifiable.

Another thing i encountered was the cost multiplier. Most normal advance wars CO's use an overall cost multiplier which affects all units cost. but what if i want to make, say, only infantry cheaper? Or only tanks? or make infantry more expensive while making tanks cheaper?

I've also been tinkering with the damage calculations code. It hit me that by modifying the code, it should be possible to make a CO who would be able to ignore the attack reduction normal units get when their health drops.  i did this by changing, for example:

if @ammo == 0 or target.damage_chart[0][@unit_type] == -1
damage = target.damage_chart[1][@unit_type].to_f * (unit_hp/10.0)
@weapon_use = 2

into:

	if @ammo == 0 or target.damage_chart[0][@unit_type] == -1
        if @officer == CO_Test
        damage = target.damage_chart[1][@unit_type].to_f 
        else
				damage = target.damage_chart[1][@unit_type].to_f * (unit_hp/10.0)
        end
      
  ###########################################################################  
        @weapon_use = 2
        

While this code gives no errors, it doesn't seem to be affecting the game. I think i got the part where i try to define the CO all wrong. I gather it should be possible to make exceptions on certain things according to which CO you have, but i don't know the exact "if" statement to use for it. Would you know one?

[KK20]

Range: ShowHide

Did you look at how I did it with other COs that modify range? I mean, you should have obviously looked at Grit and saw how I did it.

def range_bonus(unit)
  return 0 if unit.max_range(false) == 1
  if @scop
    return 3
  elsif @cop
    return 2
  else
    return 0 #<== normally a 1 in the original games, but that's OP as hell
  end
end

You are correct about the max range for Direct combat. A direct combat unit is defined as having a max range of 1, so you have to check if the range of the unit is not 1 for indirects.

Cost: ShowHide

You will need to add another method of some sort that can handle individual costs. Something like this for the CO class

def unique_cost_mult(unit)
  return 1
end

For your custom CO class

def unique_cost_mult(unit)
  if INFANTRY.include?(unit.unit_type)
    return 0.9
  elsif unit.unit_type == TNK
    return 1.2
  else
    return 1
  end
end

And this modified cost method for the Unit class

def cost(no_cost_mult = false)
  return @cost if no_cost_mult
  return (@cost * @army.officer.cost_multiplier * @army.officer.unique_cost_mult(self)).to_i
end

Attack: ShowHide

You should try using

@officer.class == CO_Test

Without the class method, you're asking if the INSTANCE of @officer is equal to the constant CO_Test, which doesn't make any sense and evaluates as false.

[Gears]

Yeah, i used grit's code, i was just a little surprised to see all the direct units suddenly acting like indirect units, since i at first thought that difference would be defined by unit rather then range itself.

[KK20]

I can see your reasoning behind that. I probably just didn't want to create another variable since it's pretty obvious that a direct unit should only have a max range of 1. Also wouldn't make sense giving an indirect unit a max range of 1 either.

[Gears]

I found several minor errors in the game itself. mostly concerning aircraft.

First of all, sometimes, once an aircraft dies due to fuel loss, an error seems to occur. It seems to have to do with the daily fuel equation, specifically, the part where it cycles trough units to determine which ones should die. It tries to check the daily fuel amoutn of the unit, and i suspect it does so again after it's killed the unit. Another weird thing is that airbases don't resupply aircraft, (and other buildings don't have their supply or repair mechanic working either sometimes), which is potentially annoying on aircraft maps. Lastly, stealth fighters cannot attack pipe seams. their unit script doesn't seem to be able to recognize the pipes in question.

Apart from that, there's some new new questions regarding CO's I've got to ask.

One is somewhat related to the move_bonus boon. i wanted to add move penalties, which would lower unit movement rates. Unfortunately, simply adding a minus before the usual bonus movement resulted in a strange error where ruby would not allow me to subtract anything, saying that nil cannot be coerced into a fixed number. some googling allowed me to find out that this (usually) means you cannot subtract zero from anything, yet i haven't been able to find a workaround. adding an a extra definition into the calculation (move_penalty) didn't work out either. have you got any workarounds?

Another thing is Player-specific variables. I was hoping i could introduce some sort of day counter that only works for certain CO's, and is player specific, meaning that even if two players play the same CO, the variables remain separate. Have you got any idea how to do that?

[KK20]

I think the problem I had before was that I was just deleting the unit objects while evaluating the array of units at the same time (which is generally a very bad programming practice). I think I fixed that now.
I'm sure airbases can resupply and repair (as can all the buildings that should). Again, this is probably tied up with the bug aforementioned.
And yeah, the thing about pipe seams was brought to my attention a while back. Has something to do with the Unit#can_attack method being modified in certain unit classes. I also might not have inputted a damage value for when a Stealth attacks a pipe seam either.

But I think I have addressed those by now. I'll run a playtest in my current build and see where I'm at.

I'd have to see what you are actually doing for the negative move bonus. Nothing is screaming out to me at a glance.

Every CO is a separate instance, even if they are the same CO. It's just a matter of putting a "dud" in the base CO class and the actual value assignment/whatever you want to do with it in the character CO class.

[Gears]

Well, for the move penalty, i'm either using:

Spoiler: ShowHide

  def move_bonus(unit)
  if VEHICLE.include?(unit.unit_type)
			return -2
    end
  end

or trying to make it trough:

Spoiler: ShowHide

  def move_penalty(unit)
  if VEHICLE.include?(unit.unit_type)
			return -2
    end
  end

with in the CO class

Spoiler: ShowHide

	def move_penalty(unit)
		return 0
	end
  

and in the unit script:

Spoiler: ShowHide

return @move + @army.officer.move_bonus(self) + @army.officer.move_penalty(self)

For the Player specific variables, i tried putting them in like that, using:

Spoiler: ShowHide

  def Chronocounter
     if @phase_preturn or @cop
      return @Chronocounter+=1
    end
    if @Chronocounter ==5
    $game_map.set_weather('snow', 1) 
    return 0
    end
end

in the CO code of a test CO, and using

Spoiler: ShowHide

  def Chronocounter
    return 0
  end
  

in the general CO class code. The idea is that every start of the player's turn, a counter will slowly rise towards 5, at which point it will reset and summon snow. Using your COP also adds to the timer. It doesn't seem to work yet. I'm guessing i got the "start of turn" condition wrong. For that matter, how does the game define the start and end of a turn outside the Scene_Map script?

[KK20]

Well now that nil into fixed number error makes sense. You're missing a return value for when the unit is not a vehicle.

  def move_bonus(unit)
    if VEHICLE.include?(unit.unit_type)
      return -2
    else
      return 0
    end
  end

Without the 'return 0', the method would return nil. In Ruby, nil is not the same as zero; it is its own class. Doing any arithmetic with nil in the equation will throw that error.

As of now, the only way to get the current turn phase is through $scene.phase, but that won't do you a lick of good for what you're trying to accomplish. Your chronocounter method needs to be called by the running process--it's not running in parallel to the game. You'll have to call the method in Scene_Map under phase 0 (Pre-turn).

elsif @preturn == 5
  @player_turn.officer.Chronocounter
  cursor.move_speed = 5
  @phase = 1
  @preturn = 1
end

[Gears]

Well, i managed to implement the Feature using the following code, but for some reason the += command refused to work, so i had to use this:

Spoiler: ShowHide

def Chronocounter
    if @Chronocounter == nil
      @Chronocounter = 1
    elsif @Chronocounter == 1
      @Chronocounter =2

      elsif @Chronocounter == 2
      @Chronocounter =3

      elsif @Chronocounter == 3
      @Chronocounter =4

      elsif @Chronocounter == 4
      $game_map.set_weather('snow', 1) 
      @Chronocounter = 0
       elsif @Chronocounter == 0
      @Chronocounter =1
    end
end

it works for this specific CO, but it's kind of messy and ineffective if i intend to implement a larger counter number or something.

[KK20]

+= should work. It's probably because you never initialized @Chronocounter to zero and was essentially doing nil = nil + 1.
There are two ways around it.

def Chronocounter
    # If counter is nil, initialize it to zero, otherwise does nothing
    @Chronocounter ||= 0
    @Chronocounter += 1
    if @Chronocounter == 4
      $game_map.set_weather('snow', 1) 
      @Chronocounter = 0
    end
end

or, under the CO#initalize method, insert @Chronocounter = 0 somewhere.

Oh yeah, also wanted to add that the aircraft errors you pointed out have been fixed already.

[KK20]

So it's been a while since I've last updated the progress of this project. It has really been an off-and-on process. March 2013 was when my interest took a shot (it was also the time I had to halt doing anything since my HDD burnt out). I went months not doing a single thing. But I have steadily continued to make small changes here and there and I guess I'd like to share them.

First off, I recently (like 10 minutes ago as of typing this) did a comparison of how much faster I can draw move/attack ranges. I used a fighter with wide-open spaces as my test case due to its movement of 9 spaces (that's like 200+ tiles to evaluate and draw for). The first image is the current release version, the bottom my most current.

Spoiler: ShowHide

I rewrote the entire move range calculation method from GubiD's TBS. I'll probably explain my method to get some feedback and possibly inspire a working game designer to create his own. I also decided to draw the sprites for the ranges only once and reference/make changes to them rather than doing the dispose and create process every time--which pretty much cuts out a TON of time.

3- and 4-player maps are now possible, although I have only tested 3-player. The CO Power bars (the stars you see next to your officer) have been aesthetically updated. They now bounce up and down and change colors. I also recently implemented a sliding effect of the officer tag and gray information window when the cursor moves to the other half of the screen. Lastly, the tilemap rewrite I created for Custom Resolution works perfectly fine. I'm still debating whether to continue to use it for implementing modified autotiles (sea-side cliffs, rivers, and shoal tileset graphics will benefit greatly from this).

All bugs reported from v.1b have been fixed to my knowledge. Some damage chart and CO changes here and there. Still a lot of sprite ripping to be done. I made one animation for activating a Super CO Power where it creates these sparks over your unit. I also think I'm using FMod as my new "sound player" script.

Now that everything is working, it's just a matter of cleaning up some of the code from my novice RGSS scripting days before pressing forward. I've got methods in here that don't make any sense for existing I have also been writing a ton of notes on AI, and I think I have a solid plan for attacking it. I just hope Ruby can handle the sheer amount of calculations.

[Zexion]

3- and 4-player maps are now possible, although I have only tested 3-player. The CO Power bars (the stars you see next to your officer) have been aesthetically updated. They now bounce up and down and change colors. I also recently implemented a sliding effect of the officer tag and gray information window when the cursor moves to the other half of the screen.

Gettin graphical, lahve it!

Now that everything is working, it's just a matter of cleaning up some of the code from my novice RGSS scripting days before pressing forward. I've got methods in here that don't make any sense for existing Tongue I have also been writing a ton of notes on AI, and I think I have a solid plan for attacking it. I just hope Ruby can handle the sheer amount of calculations.

Sweet, AI is always tough, but I'm sure you can make it good lol.

Glad to see you've found interest in your project again. It's all too common in the rpgmaker community to loose interest due to life, and time, but it's awesome that you are still going for it. This also reminded me that I need to get back to work on your sprite-o's lol.

[KK20]

Thanks. It sure took me a while to find the passion for it again--maybe because all the script requests have died down a lot recently. Anywho, last school semester reminded how much I missed working on this. I really do hope I can have another demo to release during summer.

The AI process has been pretty rough, especially being a strategy AI. You can't really just move units in any which way and expect to be a challenge. After reading from this blog I found, I know I can write something up pretty similar. Probably the hardest thing will be testing my influence maps and picking values that work best. If I had a bunch of testers, that'd be great.

And lol, you forgot about the sprites again :3

[Gears]

Ohohooo!

I'm looking forward to messing with THAT!

I wonder though. Does RPG maker allow you to (easily) create save files ingame and load them? Obviously this project is a long way from multiplayer just yet, but i'm wondering if it's possible to create a stopgap measure by having it save to a dump file every time it ends a turn. that way, you could theoretically bounce this file around to fight each other.

[PhoenixFire]

Well, for multiplayer, I'm sure you could adapt rmx-os for that purpose. You would need to implement some sort of rudimentary token ring system to decide who's turn it is and such, but I think a script should be able to accomplish that =p

[KK20]

Yeah, I'll be moving forward with RMX-OS no doubt. While I could write some kind of passable file, that's both tedious and impractical. I don't exactly have the means to keep a dedicated server up 24/7, so if people want to play with friends, they'll have to go through the entire RMX-OS process themselves.

In the meantime, if anyone has TeamViewer, I'll gladly slaughter you in a game.

[Gears]

Teamviewer? That could indeed work as a way to play it. you'd still be able to see all your enemy's actions and stealthed units though. Or not?

On that subject. Is it possible to enable fog of war during an SCO? and then restore it to it's normal, map-based status?

[KK20]

Yeah, that's the only downside. It's not that much of a problem though. FOW is out of the question though.

As of this moment, there is no way to alternate between FOW and normal vision. FOW is still highly experimental and probably won't be done for a while.

[Gears]

Poor Sonja.