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!
26 October 2009
23 October 2009
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.
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.
20 October 2009
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. =(
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. =(
13 October 2009
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...)
[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
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
12 October 2009
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
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
07 October 2009
Version 0.1.2 - 0.1.4; Roadmap to Version 0.2.0
Version 0.1.4
This version adds a couple critical features to the game engine: money and unit deployment and movement.
First, the money. The game now operates off of an economy. Right now, both armies begin with $15,000. At the beginning of each turn, for the HQ, barracks/seaports/airports, and for each captured city, the army will earn $1000 each. However, since Red Army goes first, the Blue Army gets the first "tax collection" to make up for the advantage given to the Red Army. However, I might eliminate this. We'll see.
This money also allows or disallows you to build certain units. For instance, you cannot buy a Main Battle Tank company the first round as the Red Army; it costs $16,000 and all you have is $15,000. Thus, the game will not build that unit for you, and in fact, it tells you that.
Second, unit deployment and movement. In the last build, I was able to deploy units to the map. I also created a class, and using that, if your mouse is over the unit, it moves to show that you're over it. Using a VERY, VERY simplistic algorithm, if you click on a unit, it can show you where it can go.
However, I must stress that this algorithm is only for beta testing purposes only. It is accurate enough, in that it displays the proper "radius" of motion per unit, but it does not take mountains and forests into effect. I have done testing to incorporate that, but with limited success.
After the unit is moved, it cannot be moved until the next turn.
Screens:
In this shot, the mouse is over the Main Battle Tanks. Since I do not have enough funds (as you can see under Gen. Worm's avatar), I cannot buy the $16,000 unit.
In this shot, the Red Army has deployed a Light Tank and deployed it on the road. the Blue Army is getting ready to move a Heavy Artillery battery, anywhere with the zone with the blue hashes.
Roadmap to Version 0.2.0
I'm actually fairly close to releasing a new beta. Version 0.1.5 should be fairly easy to code, however, I'm going to take a serious look at the movement code to correct its flaws. Stayed tuned...you probably see something this weekend!
0.1.5 - Capture cities; prohibit wheeled vehicles from entering mountains
0.1.6 (and 0.1.7, if needed) - Stabilize movement
0.1.8 - Quality control and cosmetic upgrades: animate units on build screen, etc.
0.1.9 - Cross-system testing
0.2.0 - Ready for the Combat/Support phase!
This version adds a couple critical features to the game engine: money and unit deployment and movement.
First, the money. The game now operates off of an economy. Right now, both armies begin with $15,000. At the beginning of each turn, for the HQ, barracks/seaports/airports, and for each captured city, the army will earn $1000 each. However, since Red Army goes first, the Blue Army gets the first "tax collection" to make up for the advantage given to the Red Army. However, I might eliminate this. We'll see.
This money also allows or disallows you to build certain units. For instance, you cannot buy a Main Battle Tank company the first round as the Red Army; it costs $16,000 and all you have is $15,000. Thus, the game will not build that unit for you, and in fact, it tells you that.
Second, unit deployment and movement. In the last build, I was able to deploy units to the map. I also created a class, and using that, if your mouse is over the unit, it moves to show that you're over it. Using a VERY, VERY simplistic algorithm, if you click on a unit, it can show you where it can go.
However, I must stress that this algorithm is only for beta testing purposes only. It is accurate enough, in that it displays the proper "radius" of motion per unit, but it does not take mountains and forests into effect. I have done testing to incorporate that, but with limited success.
After the unit is moved, it cannot be moved until the next turn.
Screens:
In this shot, the mouse is over the Main Battle Tanks. Since I do not have enough funds (as you can see under Gen. Worm's avatar), I cannot buy the $16,000 unit.
In this shot, the Red Army has deployed a Light Tank and deployed it on the road. the Blue Army is getting ready to move a Heavy Artillery battery, anywhere with the zone with the blue hashes.
Roadmap to Version 0.2.0
I'm actually fairly close to releasing a new beta. Version 0.1.5 should be fairly easy to code, however, I'm going to take a serious look at the movement code to correct its flaws. Stayed tuned...you probably see something this weekend!
0.1.5 - Capture cities; prohibit wheeled vehicles from entering mountains
0.1.6 (and 0.1.7, if needed) - Stabilize movement
0.1.8 - Quality control and cosmetic upgrades: animate units on build screen, etc.
0.1.9 - Cross-system testing
0.2.0 - Ready for the Combat/Support phase!
02 October 2009
Version 0.0.9b for Mac
Sigh...
I'm getting my car repaired today...nothing major, but it means that I can go to my mom's house and test the game on her Mac.
It was having serious problems.
Here is the temporary fix.
You'll also need the Vorbis and Ogg libraries. They need to go in your /Library/Frameworks folder (the Library in Macintosh HD).
The problem is that the game is linking to frameworks in two spots: the SDL libs, contained in the package, and the Ogg Vorbis libraries in your /Library/Framework. This should be only linking to the frameworks within the package. I believe I have fixed this, but we'll see with the next version.
Also, here is the Linux version.
I'm getting my car repaired today...nothing major, but it means that I can go to my mom's house and test the game on her Mac.
It was having serious problems.
Here is the temporary fix.
You'll also need the Vorbis and Ogg libraries. They need to go in your /Library/Frameworks folder (the Library in Macintosh HD).
The problem is that the game is linking to frameworks in two spots: the SDL libs, contained in the package, and the Ogg Vorbis libraries in your /Library/Framework. This should be only linking to the frameworks within the package. I believe I have fixed this, but we'll see with the next version.
Also, here is the Linux version.
01 October 2009
Status update
Well, I'm currently mired in ver. 0.1.2. It's going alright. Nothing to release today that can't wait another day of two.
Essentially, right now, I have the build menu (or "Deploy Units") so that the Red Army can build units on its HQ. The units then appear on screen. They are still until the cursor is over them, then they move (only three frames, but it's movement!).
But, I've had to do a lot of debugging today (stupid brackets), so I don't think I'm going to work anymore on the code tonight.
Unfortunately, I'll be missing a large chunk of my day tomorrow taking my car to be repaired. I'll have the evening, though, so that should be okay.
TO DO for 0.1.4 (or 0.1.5):
- Allow Blue Army to build units
- Tie the building of units to available funding
- Finalize movement logic (I'll need to do some research...)
- Flag units that were recently created or completed an action
- Reset this flag at the end of a turn
Essentially, right now, I have the build menu (or "Deploy Units") so that the Red Army can build units on its HQ. The units then appear on screen. They are still until the cursor is over them, then they move (only three frames, but it's movement!).
But, I've had to do a lot of debugging today (stupid brackets), so I don't think I'm going to work anymore on the code tonight.
Unfortunately, I'll be missing a large chunk of my day tomorrow taking my car to be repaired. I'll have the evening, though, so that should be okay.
TO DO for 0.1.4 (or 0.1.5):
- Allow Blue Army to build units
- Tie the building of units to available funding
- Finalize movement logic (I'll need to do some research...)
- Flag units that were recently created or completed an action
- Reset this flag at the end of a turn
Subscribe to:
Posts (Atom)
