Liqwiid Wars

Liqwiid Wars
General
Author(s)	steaky1212, silus
Type	Arcade game
Version	0.13
Links
Download
Peripherals

About

Using the Liquid Wars 5 algorithm as a basis for a Wii rewrite - a port would probably take the same amount of time as the code is messy and bloated.

I know the name is groan-worthy, but I figured if you can fit wii in the title somewhere why wouldn't you.

This has a planned first playable version release of 31st August 2009.

Controls

In game

	Action
	Move Cursor
	Exit to HBC

Progress

I figured people might want to know how far along I am, but you have to bear in mind I have a full time job, and 2 young kids so it wont be the quickest development.

• 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" optimization 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 isn't 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.

• 05July2009: Now up to a team of three, as I asked a friend to help with the core programming, and Guy has agreed to do the music. Fighters are now implemented as a separate class. Also decided to use GRRLIB for the GUI stuff, as probably make the graphics a lot easier to code. Current release has one fighter try and get to the cursor - haven't done any error capture yet, so if your cursor is on the left border when the fighter gets to the cursor it will catch...oops.

• 08July2009: Algorithm changed. Most urgent bugs fixed. Fighter collision outstanding.

• 12August2009: Bulked up the algorithm and movement stuff to make more resilient. Nearing first proper beta release - Will have a simple GUI, no music, 1 map but all that will build onto this release.

Still to Do

• Maps - Load in a PNG and assign particular colour to the wall. (LiquidWar uses dark colour for wall, and light colour for path)

• Algorithm - needs redoing (Might keep current one just for testing - as works on empty maps)

• Army population - already cycle thru all fighters, so can add up teams

• Music - Leaning towards including work by my good friend Guy John, whose work includes a Go sequencer, and a DS sequencer. This would involve loading an mp3 file and playing it.

• Menu - Simple menu structure in place,just coding looks now.

• Fighter - Collision, health transfer, Initialisation.

v2 Ideas

• Mesh optimisation - Speeds up the calculation of the gradient

• Clever AI - Comp player will attempt to circle the enemy forces

• Special Walls - One way walls, Invisible walls, Team walls

• Maps - Different size maps

Versions Released

v0.1.1

Supports 4 wiimotes.

Paints red squares where the wiimotes pointing at.

Gradient is calculated for each wiimote. The value for C1's gradient can be see by "looking" with C2.

v0.1.2

Same as before but "fighter" will move towards cursor.

v0.1.3

Algorithm now based around a queue based flood fill. This means fighters can go round walls. Other than that it is the same as before.

Known Bugs

• No error checking on gradient check, so will get array underflow and overflow. Fix in pipelines.
• Gradient not calculated for AI players, despite cursor being visable. Seems to think cursor in [0,0] position.
• New algorithm based on flood fill causes stack overflow. Might be able to overcome with mesh or different implimentation of same algorithm.
• No collision detection on fighters

Thanks to

• Christian Mauduit - Liquid Wars 6 programmer.
• The people behind the Homebrew Channel.
• The people behind DevkitPro.
• All the people who contribute to wiibrew, both the wiki and the forums.
• Team Twiizers and Waninkoko - I know you've got your differences, but both sides have made vital contributions.

External Links

Liquid Wars 5 documentation

Liquid Wars on the DS The DS port puts this into perspective, as it was done by a group of CS students for a final year thesis.