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