1943: The Battle of Midway

Nineteen43.hex

Finished Game: https://community.arduboy.com/t/1943-the-battle-of-midway-horizontal-v1-0-3/

I am currently working on a remake of 1943: The Battle of Midway

It is still in development but slowly getting there. I have implemented the roll, the power up that gives you 3-way shooting and so forth. Watch to the end of the video to see what happens when you run out of fuel.

I created the video using SIMAVR so unfortunately you will not be able to hear the cool music that goes with it.

The speed on the simulator is not quite right and the graphics on the Arduboy are a lot smoother.

This would lend itself to an Arduboy with a vertical screen (like the Tetris Microcard).

10 Likes

If anyone is interested in the game so far, a ‘pre-release’ is available at https://github.com/filmote/Nineteen43/releases

2 Likes

Awesome! I played a lot that game when I was 8 or so with my Atari

I am missing the initial loop/flip the plane did when starting, I am pretty sure that is easy to add :joy::rofl:

1 Like

Assuming there’s any memory left.

A.W.E.S.O.M.E. well done @filmote Are you using the latest version of the emulator? If yes and the speed is not satisfying then you can recompile it after changing
#define USE_THREADS 0
to
#define USE_THREADS 1
in sim_arduboy.c

I’m thinking that I better prioritise releasing binary builds…

1 Like

I noticed you released one yesterday which I have not got otherwise I am current - 1. I will update it soon and try these settings! Thanks.

1 Like

As @Pharap has pointed out, memory is becoming an issue but these little touches make the game. I will see what I can do!

1 Like

I didn’t think the existing video without sound really did the game justice, so I made one with sound and gameplay of the first level.

My video is pretty bad because I made it with a really old camera that films in 1440x1080, it’s night here, our bulbs give off a silly orange glow, I’m bad at filming and I crushed the quality from a 77MB .mov to a 4.5MB .webm

But at least the music is glorious!

3 Likes

Hi there! loving it! I’m also a huge fan of the original!

Interestingly enough, my last processing minigame was a remake of this with my own graphics and a more “futurist” theme. If you are interested by straying away from the original, I’m sure I can port my graphics to be Arduboy friendly! (including the cute little pin-up girl). See attached screenshots:

4 Likes

I love the idea idea but it would be an interesting challenge to get this to run in the memory constraints of the Arduboy. As it is, my program is taking up nearly all of the memory and I have spent a fair bit of time (with @Pharap’s guidance and help) to minimise the overheads of the code.

To give you an idea, the enemy planes are 16 x 16 pixels and take 34 bytes of data each. I have 8 images facing north, north east and so forth, so 8 * 34 = 272 bytes. Each has a mask of equivalent size so 544 bytes. I have two different enemy types so 1,088 bytes. I also have boats, the actual player’s image (with various images of it crashing into the sea), explosions and a bunch of matching masks. It is easy to consume 3 or 4K on basic sprites and we haven’t even got to splash screens, mission end and game over screens.

Did I mention music and sound effects? More memory … and the machine only has 28K of progmem and about 1.5K of useable RAM.

I make it sound limited but in my mind this is the joy of developing in this environment, Just what can you squeeze out of it?

I have been building some routines to rotate images 90 / 180 / 270 degrees and to render sprites from RAM and / or Progmem. This will allow me to reduce the number of images significantly but will I will need some staging memory in the already limited RAM. See how we go.

1 Like

@filmote I will show my ignorance, surely! (and my age also :))

  • for the sprites, if you go full top down, can’t you just rotate the sprites? Can you overlap two sprites… some enemies could be a combination of 2 overlapped sprites, as a way to save storage space while bringing diversity? why do you need to have the 8 directions? (or is it because you want to stick to the original art style that included some sort of perspective? - or maybe rotating sprites isn’t an option in Arduboy?)

  • What are the masks for?

  • The crash: can it be done through “fake” particles? (when I did my processing one, the explosion where the plane looks like it’s dismantling is actually not a sprite but “fake” particles (meaning instantiated pixels that fly off on collision)

  • About the sound: been using trackers for a big part of my life: was playing with FastTracker when I was younger, and from what I’ve seen with Team ARG, it seems that the way music is composed with Arduboy is somewhat very reminiscent of the tracker scene… if that’s the case, I may be able to help there as well, I’m still into music and still compose with trackers (using https://www.renoise.com/ now, which is a very very modern version of Fastracker)

  • That’s precisely why I’m worried about learning C++: it seems that a lot of the conveniences I’m used with Processing or Unity, like sprites rotation, are a ‘luxury’ with the small memory footprint of Arduboy.

Please, don’t consider any of my questions as a challenge: I’m just trying to understand the production pipeline as an artist for this device, not trying to imply anything or sound that “I know what’s up” - I have no slightest clue on what it takes to make GFXs for this device yet :slight_smile:

to make more sense about the overlaping of sprites: for example, in your game, you have enemies with colored wings, and enemies with outlined wings: could the colored wings be its own spritesheet that overlaps over the outlined planes while not including the rest of the plane shape? that would save a few bytes (or KB) in the spritesheet? Again, just spit-balling here to try to understand better the memory constraints as far as GFXs go!

Mmmm… I am 46.

Actors could easily be made from multiple parts. I have 8 positions because there is no native rotation of images in Arduboy - hence the routines that I are working on.

Spritres in the Arduboy library are an array of black / white pixels. If your sprite is non-rectangular, you may want to provide a mask which defines the ‘shape’ of the sprite itself - The sprite and the mask are logically combined to work out what to apply to the screen itself. If you have time, look in the previous copy of the Arduboy magazine for my article or run the following sample code > https://github.com/filmote/Pipes_Article1_SpritesDemo

You could do this … its a trade off between the amount of code required to achieve this versus the amount of images you need.

1 Like

Well, I’m possibly barely a year younger than you :slight_smile:
Thanks for your answers - it does indeed show me that I need to dive deeper in Arduino’s IDE…no native sprite rotation is a bummer :(… oh well, if you need help with anything while being ok providing direction, I’ll be happy to oblige

FYI I’m working on a library for rendering frames on the fly. I do not have anything to show for the time being and it’s just an experiment of mine but the upside is that there is no frame buffer and you gain 1024 bytes of RAM, the downside is that without vsync signal there will be some tearing.

1 Like

I have included a .hex distributable here https://github.com/filmote/Nineteen43/tree/master/distributable if anyone wants to have a look at it running.

@Odie1

4 Likes

Thanks, will give it a try

Obviously @bateske didn’t see this comment … I figure if enough people ask for a vertical screen it may hapen one day!

1 Like

WOW I finally get some time to catch up on Arduboy to find this sitting here, this is amazing stuff @filmote .
I too would love to see a programmable Microcard as the Arduboy doesn’t really shine in Tate mode.

1 Like

Thanks @Keyboard_Camper … really appreciate the feedback. How do you find the game play?

1 Like