Liqwiid Wars

Liqwiid Wars
General
Author(s)	steaky1212, silus
Type	Arcade game
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.

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" 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.

• 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 - havent 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.

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)

• Mesh - for v2

• Army population - just add up fighters?

• 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 a midi file and playing it.

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

Versions Released

v0.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.12

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

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 vasible. Seems to think cursor in [0,0] position.

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.