Liqwiid Wars
| Liqwiid Wars | |
| General | |
|---|---|
| Author(s) | steaky1212, silus |
| Type | Arcade game |
| Version | 0.2.6 |
| Links | |
| Download | |
| Website | |
| Source | |
| 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.
--UPDATE-- Pre-release of v0.2.6 available for download. The source is available for download now too. If you do make meaningful contributions to the code then please let me know, and I might add them to the general release.
Controls
In game
 |
Action |
|---|---|
 |
Move Cursor |
 |
Exit to HBC |
Features
- 2-4 Players
- Gradient calculated for each player
- Player can choose army colour
- Options for Attack and Defense Stats
- 2 Maps and a third unique random map generator.
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.
- 18August2009: Background stuff is all complete. Prerelease available for download. Only contains 1 "map" and basic menu. Tested with 2 wii-motes but should scale up to four without any issues.
- 19August2009: Apparently I have been spending too much time on it, as I am issuing another release. This one is fully playable, with 2 maps to choose from as well as Attack/Defense characteristics, and a nicer Menu.
- 25August2009: This will be the final release for a while now. I have not got my head around the graphics libraries and which one is best suited for my needs. Because of this the health colour, and map loading will be difficult. To offset this I have doen the following; players can choose the army colour, and Map3 is a random map generator. Bugs are fixed.
To do for next release
Algorithm - small space for queue optimisation.- Not really noticeable but could mean the drawing is the bottleneck.
Win Condition - Time limit, and if all wiimotes press a particular button then winner has most fighters- Time is measured in game loops not seconds, so this might be a confusing option.
Army Seed Bug - check maps when loaded and move seed position if need to- Armies are now seeded in a random position. However I cant find how to get the system time of the wii (saw it somewhere but lost it) so I am using srand(0); not ideal as now it isnt random at all. But at least the armies seed alright now.
- Fighter - colour change dependant on health. This requires actually sorting out graphics library, as current GX color.h defines Y1CbY2Cr and not RGBa as I first thought. Y1CbY2Cr is more efficient but nowhere near as understandable.
- Maps - add some more maps. This will be done along with the graphics too as my method will be load the map into the graphics buffer and scale it (if needed) to the correct resolution, then read the buffer back pixel by pixel looking for the colour, and store in my map array.
Future Releases
- 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.
- Maps - Load in a PNG and assign particular colour to the wall. (LiquidWar uses dark colour for wall, and light colour for path)
- Special Walls - Invisible walls, Team walls
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, doors, side-scroller
- Maps - Different size maps
- Map Editor - create own map in game, then map saved to sd card
- Network - Add network play (just send cursor positions, plus "random" variable using in direction decision.
Versions Released
v0.2.6
New features include a random map generator and users are able to choose army colour. Fighters wont seed in a wall anymore - but might get trapped inside 4 walls. See Bugs for fix.
v0.2.5
Same as before, except has more options and a win screen. Overall, looks more finished. Also, now has 2 maps.
v0.2
Official public pre-release. This is the first milestone I wanted to reach. Algorithm works fine, fighters move closer to cursors, and will attack each other. Have coded in "holders" for various user options that are to be coded in at a later date. Only 1 map at the moment, but will add many more when proper GUI up and running.
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.
v0.1.2
Same as before but "fighter" will move towards cursor.
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.
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 visible. 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 implementation of same algorithm.No collision detection on fightersPlayer 4 has no army on map1 - tries to seed inside a wall- Army can get trapped inside 4 walls in random. I tried a fix, but it didnt work, so currently Player1 can demolish walls. This could be the start of different game types but watch this space.
Subpages
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 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.