Saturday, December 11, 2010
BWAPI Beta 3.4 has been released
BWAPI Beta 3.4 has been released. This release adds a new mode to the Local PC network module that uses pipes to enable communication between multiple instances of Starcraft: Broodwar, adds a number of functions to Game, Player, Unit, and UnitCommand, adds macro unit types, and also fixes a number of bugs. Here is the full list of changes.
Friday, November 19, 2010
BWAPI Beta 3.3 has been released
BWAPI Beta 3.3 has been released. This release adds a Local PC network module which enables games between multiple instances of Starcraft: Broodwar, native Windowed-mode, support for Heroes, Beacons, and Standard Powerups, new functions for upgraded unit type stats, and also fixes several bugs. Here is the full list of changes.
Thursday, October 21, 2010
BWAPI Beta 3.2 has been released
BWAPI Beta 3.2 has been released. This release adds several menu automation options to bwapi.ini, adds the ability to disable the Starcraft GUI/graphics system for increased speed, and also fixes several bugs. Here is the full list of changes.
Friday, October 15, 2010
BWAPI Beta 3.1 has been released
BWAPI Beta 3.1 has been released. This release fixes a number of bugs, adds the ability to disable latency compensation, adds the ability to associate arbitrary information with each unit, and more. Here is the full list of changes.
Wednesday, August 11, 2010
Testing Framework is Complete
The testing framework now tests map information functions and as well as events/callbacks. These were the last two groups of test cases that I planned to add to the initial testing framework, bringing it to completion. That said, most functions in BWAPI use information obtained from Starcraft's memory, and like any RTS game, Starcraft has a very, very large state space, so of course the testing framework is no where near exhaustive. However, for now its safe to say that the framework tests unit commands, unit, player, and map information functions, and verifies that events/callbacks are generated when and only when they should be. However, if any bugs pop up in the future, I can add test cases to the framework to ensure that the bugs stay fixed.
I've also run the testing framework on the BWAPI client and it runs without error, so it looks like the client is nearing completion as well.
I've also run the testing framework on the BWAPI client and it runs without error, so it looks like the client is nearing completion as well.
Friday, July 23, 2010
BWAPI Beta 3.0 has been released
BWAPI Beta 3.0 has been released. This release fixes a number of bugs, improves the performance and functionality of the client-server architecture, adds several new functions, merges several Orders together, and more. Here is the full list of changes.
Saturday, July 17, 2010
Unit Command Test Cases Complete
After pulling an all-nighter, I'm happy to say that I've completed test cases for every unit command and they all pass on the server and client without a single failed assert. Perhaps the hardest test cases of the 43 unit commands were cancelTrain(slot), cancelMorph, and cancelConstruction, as different attributes of the unit had to be latency-compensated for different lengths of time, making them rather tricky puzzle pieces.
An off-by-one mistake in the latency compensation code would over-compensate or under-compensate the unit or player attributes (i.e. giving the player the appearance of having more or less resources than he actually has), leading to a failed assert that would only pop up for one or two frames at a time and then vanish in a game that's being run at 180 frames per second. Nonetheless, I have determined the shape of these puzzle pieces and now the latency compensation code is a perfect match for even these three unit commands, allowing for a seamless transition from latency-compensated values to actual values read from Starcraft memory.
As explained in my last post, my next main goal is to make test cases for events and callbacks, and more importantly start making the internal adjustments in GameImpl.cpp that will be necessary to make those new test cases run successfully on the client.
An off-by-one mistake in the latency compensation code would over-compensate or under-compensate the unit or player attributes (i.e. giving the player the appearance of having more or less resources than he actually has), leading to a failed assert that would only pop up for one or two frames at a time and then vanish in a game that's being run at 180 frames per second. Nonetheless, I have determined the shape of these puzzle pieces and now the latency compensation code is a perfect match for even these three unit commands, allowing for a seamless transition from latency-compensated values to actual values read from Starcraft memory.
As explained in my last post, my next main goal is to make test cases for events and callbacks, and more importantly start making the internal adjustments in GameImpl.cpp that will be necessary to make those new test cases run successfully on the client.
Subscribe to:
Posts (Atom)