Twin-stick shooter controls

Currently UniBlaster (the main engine of RetroWar) supports four different games / character types. They are similar in many ways, but the controls vary slightly.

  • Droids use the right stick to aim, and automatically shoot a stream of low powered bullets (A)
  • Tanks use the right stick to aim, but require the button to pressed to shoot a single high powered projectile (B)
  • Ships cannot aim, fire straight forward when the button is pressed (C)
  • BombBots have no gun so cannot aim, drop bombs when button is pressed (C)

I've been thinking how to create a more general abstraction of these differences.

Instead of one weapon, each character would have three weapon slots:

  • A fires when right stick is moved, unless button is depressed
  • B fires when right stick is moved and button is depressed
  • C fires when right stick is neutral and button is depressed

This would allow characters to carry multiple weapons and use all three without any switching and only needing one fire button.

Possible uses:

  • The current shooting-type A/B characters could gain a close combat C weapon.
  • Player has a choice between firing a stream of low power bullets, or one high power bullet that will take time to reload. (Also can make reload not begin until player has finished aiming - see CrossCode for example of this.)
  • Player could be given a choice between firing low power bullets, or pressing the button and firing high power bullets but reducing his speed, perhaps to zero. (Need to add speed reduction option to weapons)
  • Player could be given a choice between shooting and dropping bombs, depending on whether he moves right stick.
  • An A type weapon that does no damage, but merely assists in getting the aim right before the B type weapon is fired.
  • A B type weapon that doesn't fire when the button is pressed, but when it is released. Thus holding the button down does nothing, so fire rate entirely depends on how quickly the button is mashed. The amount of time the button is held before release could determine how charged up the weapon is. Why not fully charge every shot? Because charging reduces your movement speed.

Finally, I've been thinking about how RetroWar could be played on actual 8-bit joysticks. Currently 8-way d-pad movement is supported in all games as a virtual stick, (although it puts you at a disadvantage in most of them that aren't grid based.)

But then how to aim when there is no second stick for aiming? You could just fire in whatever direction the sprite is facing when the button is pressed. But that would fire the C type weapon, which is likely to be non-directional bomb anyway, and leave no way to fire the A directional gun. Games like Paradroid handled this by requiring you to move a bit before pressing fire. So the virtual input would create a second stick pointing in the same direction as the real left stick when you press the button with no input from any right stick. Many games also had a locking mechanic, so once you started shooting you held down the button to lock the firing direction while you could move in a different direction. Not sure how that could work in my scheme.

Discord!

Everyone who is anyone seems to be on Discord now, and so are we.

Please join our channel!

Currently listening to GamesQuest podcast by Matt Bauer. Interesting stuff when we are about to enter Early Access.

8-bit vs 16-bit

RetroWar deliberately limits itself to what would be possible to run on an 8-bit computer or console. We believe limitations in visuals produce innovations in gameplay.

Occasionally, after much thought, we break this limits when the benefit offered by modern systems seems worthwhile.

But what exactly is an 8-bit console capable of? Well, in addition to the 8-bit CPU, each system had different chips for graphics and sound, and so capabilities varied greatly, and even overlapped what was possible on 16-bit systems. We have to arbitariliy decide where to draw our lines

Scrolling

Most 8-bit systems could scroll to some degree, but smooth multi-directional scrolling didn't become universal until the 16-bit era. Currently we are not including it, but this is a good candidate to add if we decide to implement more 16-bit type features.

Screen shake

Any 8-bit system that was capable of scrolling was also capable of screen shake, so we include it.

Colour palette

We are using a very simple 16 colour fixed palette. We also try to limit each sprite to 4 colours. Some 8-bit systems had more colours and/or could switch to different palettes. 16-bit systems varied greatly as graphics chips improved. I don't really see the point in doing pixel art with, say, a 4096 colour palette - I think you may as well go right up to 'modern pixelart' in that case and use a 32-bit pallete.

Alpha channel transparency

Makes many nice effects possible, but this was quite advanced even for 16-bit systems. The only transparency 8-bit games had was done by flickering a sprite on and off quickly.

Particles

Surprisingly 8-bit systems could do particles! Just look at Defender. They couldn't do vast numbers of them, they couldn't make them glow with transparency, but they could do them. We break the rules slightly here and provide unlimited particle numbers.

Texture scaling

Probably used most famously on the SNES, 2d textures could be resized dynamically and even drawn as pseudo 3d. You could zoom in the display. You could make a sprite bigger or smaller. We are not including it. (Although Retrowar-common library does include one scale effect.)

Dynamic lighting

If you have a large palette and an alpha channel you can dynamically change the light levels, e.g. have a player carrying a torch. It makes a huge improvement to the look of modern pixelart games, but we won't be including it.

Phones as game controllers

The game I am working on is a local multi-player party game for up to 16 players. However not many people have 16 controllers connected to their PC. So I was thinking about using phones as additional controllers.

I can think of a couple of different ways to do this:

  • Create and publish a native app for Android and iOS. The PC game runs a server, the app scans for servers on the LAN and automatically connects. Touch input is sent in UDP packets. Bonus: server could announce "this is a d-pad game" or "this is a twin stick game" and the app could display appropriate input controls.

  • Write the app in JavaScript. Have the game run a webserver, which serves a page containing the app. Tell players to open the IP address of the server in their mobile browser. The browser runs the JavaScript app and uses Websockets to send the touch input to the server.

This seems such a simple, useful re-usable project that I would expect it has been done before. Does anyone know? If not, is anyone interested in working on it? It might make a nice little project for a student.

RetroWar has a Steam page!

Please check it out on Steam.

There is a new trailer too.