79
edits
Changes
Jump to navigation
Jump to search
Line 37:
Line 37: − + + − 26June2009: Got 2 dots painted on the screen where my 2 wiimotes point to. Added a basic timer so that I can track how many cycles my while(1) loop has done. Can now perform algorithm every X cycles. I am considering writing it all from scratch now, as modifying the algorithm would seem too much like a bodge - like the rest of my code. + − − − − − − + − + − + − + − + − + − +
no edit summary
24June2009: Started design. Got core algorithm - not tested it yet. Tracking IR position of 2 wiimotes (would be 4 but I only own 2, the code supports 4 - If anyone wants to donate a wiimote then feel free).
*24June2009: Started design. Got core algorithm - not tested it yet. Tracking IR position of 2 wiimotes (would be 4 but I only own 2, the code supports 4 - If anyone wants to donate a wiimote then feel free).
*26June2009: Got 2 dots painted on the screen where my 2 wiimotes point to. Added a basic timer so that I can track how many cycles my while(1) loop has done. Can now perform algorithm every X cycles. I am considering writing it all from scratch now, as modifying the algorithm would seem too much like a bodge - like the rest of my code.
*29June2009: Been speaking with Christian Mauduit, the guy responsible for the latest version of LiquidWars. Helped clear a few things up. Currently, LiqwiidWars takes the 4 IR positions and -using 2 for loops- will create a "potential" for the armies. It basically comes down to (pseudo) grid[player,x,y] = abs(wiimote(player).ir.x - x) + abs(wiimote(player).ir.y - y). This ignores the "mesh" optimisation that might go in at a later date. All the "fighters" need to to is move to an area of equal or lower potential if they can. This algorithm is not affected by number of players or size of army - just size of map.
29June2009: Been speaking with Christian Mauduit, the guy responsible for the latest version of LiquidWars. Helped clear a few things up. Currently, LiqwiidWars takes the 4 IR positions and -using 2 for loops- will create a "potential" for the armies.
It basically comes down to (pseudo) grid[player,x,y] = abs(wiimote(player).ir.x - x) + abs(wiimote(player).ir.y - y).
This ignores the "mesh" optimisation that might go in at a later date. All the "fighters" need to to is move to an area of equal or lower potential if they can. This algorithm is not affected by number of players or size of army - just size of map.
*02July2009: After discussion on forum.wiibrew, maybe the way I'm currently implementing liqwiidwars isnt the best way. Also, my potential gradient is not the same as the one in Liquid War. I think I will start working on the GUI stuff while trying to figure out how to actually implement this.
== Still to Do ==
== Still to Do ==
Maps - Load in a PNG and assign particular colour to the wall outline?
*Maps - Load in a PNG and assign particular colour to the wall. (LiquidWar uses dark colour for wall, and light colour for path)
Algorithm - nearly done
*Algorithm - needs redoing (Might keep current one just for testing - as works on empty maps)
Mesh - for v2
*Mesh - for v2
Army population - just add up fighters?
*Army population - just add up fighters?
Music - maybe play mp3's that are held in certain directory? Though leaning towards including work by my good friend [http://www.notesandvolts.com/ Guy John], whose work includes a Go sequencer, and a DS sequencer.
*Music - maybe play mp3's that are held in certain directory? Though leaning towards including work by my good friend [http://www.notesandvolts.com/ Guy John], whose work includes a Go sequencer, and a DS sequencer.
Menu - not even thought about yet
*Menu - not even thought about yet - although as other work put on hold, I can now do menu and "advance settings"
== Versions Released ==
== Versions Released ==