This project is still under development (read: I've almost started.)

So, I have decided to start working on a clone of Tanks! from Wii Play for the CE. If you have not played it before, the goal of Tanks! is to destroy all the enemy tanks in 100 stages. Here's a random YouTuber playing it:

Now, you are probably asking yourselves, "How is he going to get the crosshair to work without motion controls?"
After a thorough investigation of the Wii Remote and the CE's USB hardware, I have come to the completely stunning and absolutely novel conclusion that motion controls are not feasible at this time.
I'll most likely either use two keys to rotate the barrel of the tank, or have a button that, while held, causes the arrow keys to control a crosshair instead of the tank, keeping the tank moving if it is in motion already.

My current plan:

Get level format worked out
Convert levels and sprites into a usable format
Rendering levels
Tanks and player movement
UI stuff
Shells and mines
Collisions
Enemy AI
Tread marks?

Of these, AI will probably be the most difficult part. In the video, you can see that the AIs will

Shoot bullets toward the player, potentially bouncing off walls to get there
Move out of the way of bullets moving towards them (but not if it needs to bounce off a wall to get there)
Move coherently without crashing into walls (but sometimes other tanks)
If it can fire another bullet, move to where it can shoot the player
If not, avoid going into the sight of the player
Lay mines near breakable blocks and in narrow areas
Move away from mines

If anyone has any idea how to implement any of that efficiently please let me know.

The other thing that might be problematic is the tread marks. I would have to store a giant sprite with all of the tread marks and render that between the tilemap and the tanks. Normally I would just leave it out, but it actually has a gameplay function in the last level.

I really don't have anything done besides some data structures at this point, but I decided to go ahead and post a bit early so that people know about the repo:
https://github.com/commandblockguy/Tanks-CE

This was one of my favorite games on my wii. I used to play it all the time with my little sister. Can't wait to see what you can do!

Maybe you could layer the graphics in order of 'floor' graphics (with treads, since the floor doesn't change other than adding treads), the 'important' tiles (like walls, holes, breakable blocks), and then the tanks, bullets, etc. on top layer.

Since only treads should affect the floor, you can just save the floor once and add treads on top, then add the movable/variable stuff on top later. I'm not sure how speed efficient this would be, but maybe it's possible?

Also, if/when you finish the main game, you could add extra levels or a level editor. Those are fun.

Progress update time:
I have converted the first three levels into tilemaps I can render. Here's a recording of the program loading these:

The textures are not final, they are basically just versions of the actual textures I scaled down in a few minutes. If any pixel artist wants to help, the tiles are 12x12.
Due to fancy compression, the file size for the first the levels is 158 bytes.

I have also done some other stuff that isn't visible here. All type definitions should now be reasonably complete. Hopefully I can get tanks and controls working soon, and work on collision physics next. I've also added another commit to the Github repo if you want to see the source.

Now that finals are over, I've had a bit more time to work on the project. I've totally broken anything resembling graphics and I don't really want to work on sprites at this time. Here's a progress update anyway:

As you can see, there is an ugly grid over everything because my sprites are 12x12 but arranged on a size 13 grid. This will be fixed before release, obviously. The number in the top left is the mspt, or the reciprocal of frame rate. I was aiming for 33 mspt / 30 FPS, but that doesn't seem too feasible since I don't even have collision stuff happening yet and I'm already past that point. The black boxes are hitboxes for various things, and the numbers in the top left of the big ones indicate which type of tank it is. The line represents the barrel of the tank and can be rotated with mode and χτθn.

I also worked on more collision stuff, and hopefully I can get those working soon. Mines are also working, though I forgot to demonstrate that in the recording.

I have also decided to leave out tank treads, and I might replace white tanks with the black tanks that usually don't appear till level 50.

This looks great, and I'm glad you're starting to get stuff working! I hope you'll be able to make the game as true to the original as possible. I remember playing this a lot on the Wii a few years back.

Incredibly delayed progress update (over a month!):

I have collision detection working for shells as a proof of concept for reflection. I still need to do a broad phase, as currently every shell is compared against every tank and that is very slow.
I also added levels through 14. These actually take a long time to input not because of the blocks but because of the tanks. I have to count out grid tiles manually for those.
The pre-level screen is functional but still needs sprites for lives and for the background.

I still need to do graphics. Currently the only sprites I have are tiles, and they are all one pixel too small. I hope to eventually use isometric perspective like the original game does, which means that I will need to have some way to rotate tanks.

Additionally, my target speed is 33 mspt (lower is better), and as you can see I am already basically at or beyond that point at all times. That means I have some optimizing to do if I want the game to run smoothly regardless of how many tanks / bullets there are. There could potentially be 30 physics objects in play at one time in the later levels.

Also, AI seems like it will be really hard unless tanks just wander randomly and fire randomly without telegraphing their actions with a cannon swivel. As you can see in the screenshot above, whenever the player rotates their cannon, the tick time increases by a significant amount. This would need to happen continuously if the enemy tanks' barrels were to move smoothly.

EDIT:
I made a pre-release here if you want to try it yourself. It most likely won't crash or reset your RAM as long as you stay inside the play area, but it's still super broken and I am not responsible for damage if you try it on a physical calc.

*bump* how is this coming along?

Decided to work on this a bit more several months later.

I worked on the collision system, as can be seen from this screenshot.


Tile collisions seem to be working perfectly now, but with my luck I'll in about 15 minutes I'll figure out that you can clip through blocks and be forced to rewrite the collision detection function a fifth time.

I also did a quick fix for the tiles, because the grid was annoying me. The grid is still there, though, because I used linear image scaling, which left a slight discoloration on the sides of the blank tiles. I'll fix when I redo the graphics.

As for physics, I still need to get data on the speed of tanks and the amount of time mines take to explode, and implement tank-tank and bullet-bullet collisions, and fix mine explosions.

After that, I need to figure out how I'm going to do enemy AI and isometric rendering.
I still have a few levels to convert, and a bunch of sprites to make.

I've been lurking for a bit and so far it seems great! Hope for no collision bugs!

I saw your screenshot on IRC and this is progressing nicely - glad that you got your collisions working!

nice! The tanks could use some more detailed sprites, imo, but if you decided against that for graphics/memory purposes, it's fine.

edit: 600th post!!

I agree with SM84CE, I saw you said you'll be redoing the graphics so I assume you can do that then.
Great work! I look forward to seeing this progress! (within a month, not 9 months )

The current "sprites" for the tanks are actually not sprites (as those do not exist yet), but a bounding box debug view which shows tank type, direction, and hitbox. Once I finish the physics up, I will start working on graphics and hopefully get an isometric view working. The turret and treads for each tank will ideally be able to rotate independently, true to the original (if the calc can handle it), and different tank types will be color-coded.

Small progress update:
I've finished converting all the levels, though I may have to add height data depending on whether or not I decide to implement isometric graphics.

I did find a collision bug that let me clip through blocks, though it took longer than 15 minutes. Basically, if you were an equal distance from the edge of a block in both X and Y, it just wouldn't pick a direction to spit you out in. Now it prioritizes one (probably X, though I can't be bothered to check right now).
There was also another collision bug, which let you enter into the rightmost row of blocks on the map. I hackfixed this by shrinking the edge of the map by one pixel. Hopefully I'm done dealing with collisions now.

You can now push other tanks around, which is really funny looking.

I've also implemented tank motion. I recommend watching the video at the top of this thread to understand what I mean by this. Basically, this means that the body of the tank has to rotate before it can move in a direction. If the tank needs to change direction by 180 degrees, the body does not rotate, but the treads change direction. If the tank is turning by 90 degrees, it pivots in place. If turning equal to or less than 45 degrees, it can continue moving while turning. I'm very happy about how this turned out, as it simultaneously is almost identical to the original, is intuitive to control, and has a low impact on performance (< 1 ms). It also adds difficulty to the game, as there is a short delay between your input and actual movement if making a sharp turn. I would add a animated screenshot here, but I haven't actually done any of the graphics for this, just the physics, and you can't really see my keypresses.

I found out that my calculations for bullet speed were incorrect. I recalculated the speed as 6 tiles per second, which is quite a bit faster than before. I still need to figure out a speed for the fast bullets.

Compilation time is up to about 15 seconds with debugging active, and file size to 14K uncompressed / 8K compressed with the level pack included.

I'm not sure if I should work on AI or graphics next. It will be simpler to debug AI in a top-down view, but graphics are currently slowing the program down a lot, meaning I can't get a good sense of game difficulty until I optimize it. I might just end up doing the graphics first, then adding a top-down debugging overlay later to make developing AI easier.

EDIT: 300 posts! It's weird, SM84CE and jcgter777 also hit 100-post landmarks within the past few days, too.

I've finished up a few more things, most notably the level start screen and mine physics. I also nabbed a few more values from the original game, though I still need to figure out enemy tank movement speed.

The new start screen:


I've also updated the GitHub repo if you want to check out the code or the game for yourself.

I've also uploaded a release, which can be downloaded here if you don't want to build it yourself.

EDIT: Whoops, the release I uploaded was built with the wrong toolchain branch. Should be fixed now.

That red checkered pattern is amazing!

Thanks! I actually need to rewrite it because I can't math and it doesn't line up exactly with the edge of the screen.

In other news, I've started on the AI for the first kind of tank encountered. It sits there and doesn't move, and only turns its turret around randomly. Somehow it's already taking 180 ms (6x the amount of time per frame) to determine whether or not to shoot, so I feel like I'm going to have to rewrite some things for this game to be playable. I'm pretty sure I can bring that down to a reasonable number if I figure out how to properly raycast on a grid - maybe using Bresenham's line algorithm will work.

Slightly late progress update (can't have my thread falling off the latest post list, now can I?):


This is the debug draw mode for the AI, which is capable of reflecting bullets off walls to hit the player. I basically do this by looping through every line that forms a tile boundary, then reflecting the position of the target across said line, then aiming the turret towards the imaginary tank, then checking if a bullet fired from that position would actually hit the target using the same method as the initial (passive) tank, which I have also optimized. I can give more details if anyone is interested, just let me know. I'll also get around to updating the GitHub eventually.

As for what you are seeing in the image, the teal line is from the raycasting function used to predict whether a bullet will hit a tank. The red line is between the tank with the AI and the center of the imaginary tank. One black line is the line that is being reflected across, and the other marks the intercept of the two lines (because a single point there would be hard to see).

As you can see from the top corner, this is still too slow (target is 33ms), so I'll need to speed things up a bit. I could probably check if the point where the bullet intercepts the line has a tile behind it that it could reflect off of, and if not, don't even try to see if the bullet will hit the tank. My atan2 function is also far more precise than it needs to be, so I could probably improve that too.

I probably should also give the AIs some sort of self-preservation instinct, as currently they will shoot themselves and each other if it means hitting the player. This may not be necessary to handle in the firing code, as tanks will eventually be able to move out of the way of bullets.

Looking neat Have you considered using the forecasted player position based on the current heading rather than the instantaneous player position?