Hiatus time a-go-go

Okay, I know I promised an update with the battle engine. Well, all I can say is that it'll have to wait.

I have the battle animations and everything done. It's just that integrating that separate program is going to present some problems that I can't easily resolve with program more than it already is. Essentially, I need to move the code rewrite up first before I can believe I can continue. The primary problem I see is the grid system I have right now, which is really bad.

So, this is what's going to happen. I'm going to go over the code with KnD and get clean everything up.
It might not be much to look at, I would wager that you'll probably find something around Christmas. Maybe some sort of present? =)

Road map to version 0.3.0-0.5.0

Okay, work on the battle generator is going well. I had to do some editing (my sprite sheet didn't have any of the infantry units!), but I finally have a good sheet for the unit animations in battle.

So, tonight, I figured I just write a brief entry on the next few releases of War Machine, which hopefully will run from now until mid-November, hopefully before Thanksgiving (and once that happens, my work schedule will get a lot more hectic, so I will make limited headway until the new year).

Version 0.2.x - Battle Code
Version 0.3.x - Code Rewrite and Optimization
Version 0.4.x - Net Code

I have a new member to the team. He goes by the handle of Knife and Dagger. From what I've seen, he knows his stuff about coding, so he will be immensely helpful in the rewrite. (He took a look at the code earlier, and he was shocked by its unruliness....oh man.)

I want to get Net Code done by Thanksgiving because what that allows is for people to start testing en masse (or at least on a bigger scale than the three people playing it now!). And that will give me time to hear about the bugs and such during my limited time during the Holiday shopping season.

I should be able to have the new version out by this weekend. Stay tuned!

Battle Simulator (v. 0.2.0)

Version 0.2.0
Well, I think I have successfully created a battle calculator which mimics Advance Wars' engine very nicely.
I got the damage calculator code and the initial damage chart from Mr. Samuel Wilder on GameFAQs...cheers.

Screen (sim vs. original):


The game is behaving correctly...
Famicom Wars and Advance Wars have different values for unit attack and defense. Advance Wars also gives the attacking unit an advantage of extra defense; on the GBA, blue would have 7, as my engine calculated, but red would have 9 units.
So consider the current system a hybrid of the two: the Advance Wars' initial damage with the Famicom Wars' no-advantage combat. (It'll probably get changed)

Now, as I move into animation, and then integration of the calculator into main game, we can deal with balance issues. If some unit is essentially unstoppable, I'm open to discussion about altering some of the units offensive and defensive power. I also think that the attacking unit should have an additional edge in combat, but I want to hear your feedback before I change anything.

Status update (ver. 0.2.x)

Hello loyal reader(s),

Well, it's been a week since my last update; I got a little burnt out programming the path movement of 0.1.x (which still needs a little improvement, I know).
However, today I have begun work on the Battle Simulator! I've decided to make it a separate application that I will later integrate into the main program. This is for two reasons: first, I won't dick anything up in the already stable program, and second, I can test specific units with specific HPs and specific terrain bonuses.

So, you're not going to see many screens until much later in the 0.2.x series. I might try to leave it as a surprise!!

Well, it's back to work for me, until real work. =(

Version 0.1.10

Mr. Larry Laffer found a few problems with version 0.1.9. I have corrected these:

[Bug] Units and menus are drawn on different(and wrong) layers: Menus should be on top.

[Bug] Menus are click-through in certain conditions(possibly because of the above layers issue). If you order the blue unit in that screenshot to move, you'll probably click over one of the factories. As such it'll bring up the build menu instead of moving the unit.

[Bug] Very possible memory leak. While idle, the game was using between 50 and 75% of my 2.4GHz Celeron and had an average memory allocation increase of 600 kb/s. I've left it running for around an hour, came back to find it unresponsive and with well over 450 megs of memory in use.

Windows

Mac

Linux (coming soon...)

Version 0.1.9 ready for testing!

Essentially, in this build, I think I finally nailed down the movement problem that had been causing me so many headaches.

I also changed the game flow a bit.
READ THIS:
To end your turn, you must right click. This will give you a pop-up menu near your cursor that you can choose to end the turn or quit game (see the example below). While right-click is typically the cancel button, left clicking when this menu is open will cancel this menu in this instance.

Also, clicking on your general's avatar no longer has the option for ending the turn; only to surrender.

Surrendering returns you to the main menu, instead of quitting the program as before.

Now let me say this: the game functions correctly. However, the game is not perfect, so you will probably find errors.

So please, let me know what you find!
Windows

Mac

Linux

Ultimatum on ver. 0.1.9

Okay, here's the scoop folks. I still have work to go before the 0.1.9 release, but I wanted to fill you in.

For the last week or so, I've been pounding my head on the keyboard trying to develop a working movement path algorithm. Everything works until I try to take mountains into effect. Some units cannot go through mountains, which affects their movement paths. However, the current engine does not take this into consideration

I have tried to find some way to find a work around. Right now, I have something that does the trick about 50% of the time.

I think I have figured out a solution. The design of the map is kinda like a W (see this):

☐■☐☐☐■☐
☐■☐■☐■☐
☐■☐■☐■☐
☐☐☐■☐☐☐

So, what I'm going to do is have four relay points.

For those of you who are curious what exactly I'm doing, you should first be familiar with the "A* Search Algorithm." Wikipedia has an article, but I found this one to be a little more relevant (and helpful).

Essentially, with my modified form, my game finds the "Delta X and Delta Y" (or together, the f value) for each point in a certain radius of the unit's start point. For each grid movement up-down or left-right takes one point. Thus, anything with an f-value from zero to the unit's max speed becomes a movable square.
I really have tried to make an algorithm that can steer around obstacles such as mountains, but alas, I have not been successful. So, the f-value for a grid is unaffected by mountains.

However, in my current workaround, the game detects where the unit is, and based on whether the unit is east or west of the mountains, adds to the f-value of squares to the left or the right of the mountains. This works fairly well, but it's not perfect.

I've been testing with the Cav Scout unit. This unit has a speed of 6. Most other units do not cause the problems that the Cav Scouts do when it comes to movement. However, if the Cav Scouts work, the other units will fall in line.

So, to compensate for the mountains, I will have four relay points. After I calculate the f-value and assign it to a relay point, the game will then use that point and calculate a new movement path. However, the radius will be f-value subtracted from the unit speed.

So, this will be what I do tomorrow (or, in a few hours rather). I will also add a couple last-minute convenience features, then the porting begins, which should take no time, now that I got Windows and Linux set up.

But, come hell or high water, whether this thing works or not, you will have some sort of demo tomorrow. I can't wait around on this forever!!
>=D