ALPHA Mythical Wings - HTML5 browser game and STG 2D engine

[MythicalWings]

Hello,

I worked on a FREE and open source browser based STG 2D game engine (HTML5) and it can also be considered to some extent to be a shmup maker.

You can get the source and examples here: https://github.com/christopheroussy/stg-game-engine

Here are two things you can do:
* play the 'pre-alpha' arcade game (by clicking on one of the links) and give some feedback.
* read about the engine in this post and give some feedback (ideas, questions, ...)

PLAY IT ONLINE IN YOUR BROWSER, controls are specified in the page (ESDF, J shoot and K switch weapon, P to pause):
THIS IS PRE-ALPHA, DO NOT EXPECT A FINISHED PRODUCT
PLAY easy
PLAY normal
PLAY hard
PLAY harder

NOTE: There is NO boss and no level ending in this level, serves as a demo to get some feedback from the community.
NOTE: Here is what the level text looks like.

I recommend:
* you close other tabs and stop downloads/streaming as those may slow down the game.
* use a recent Firefox or Chrome browser

Here are some of my goals:

• [DONE] Cross platform / portable (achieved through using modern browsers)
  [DONE] Ability to run OFFLINE
  [DONE] Only 2D for now (The engine I used underneath is specialized in it)
  [DONE] Only vertical STG
  [DONE] Arcade style movement and game play (you could do something else, but I provide 'arcade' code)
  [DONE] Playing using keyboard
  [DONE] Support for xbox compatible controllers
  [TODO] Support for joysticks
  [DONE] Levels can be edited via text files
  [DONE] Levels can also be generated by code instead of read from file (roguelike stuff)
  [DONE] Allow user to preview level section by placing player using 'p' character anywhere in the text
  [DONE] Optional: Warn user if level has anomalies (unknown text characters, missing characters...)
  [DONE] Variable difficulty (through a difficulty factor between 0 and 1, faster, more bullets, more enemies, other enemies...)
  [DONE] Allow to set background graphics (ground), parallax scroll layer on top (clouds)
  [DONE] Graphics are simple png files which you can edit with paint like software
  [DONE] Provide code for standard weapons (straight, side, aimed, laser, missile shot, bombs)
  [DONE] Provide code for standard enemies (turrets, left right movement, mines, ...)
  [DONE] Boss enemy (Did one boss which shoots patterns and spawns enemies)
  [DONE] Allow enemies to spawn other enemies
  [DONE] Event on death (explode, spawn stuff, suicide bullets, give bonus)
  [DONE] Collectibles (bonus items, coins, ...)
  [DONE] Allow randomness via level text annotations
  [DONE] Allow enemy presence depending on difficulty factor via level text annotations
  [DONE] Allow variable level speed via level text annotations
  [DONE] Allow to stop level until all on screen enemies are killed (good for mini bosses)
  [DONE] Allow destructible environment tile blocks
  [TODO] Music and sound effects are ogg/mp3
  [TODO] Level end and transition
  [TODO] Two players (locally)
  [TODO] Pixel perfect collisions
  [TODO] Advanced collisions using various shapes
  [TODO] Open source code once sufficiently mature (otherwise it will be hard to update it)
  [WILL NOT DO] Multiplayer online

The engine itself is some STG specific code tools on top of the excellent http://phaser.io/ engine (recently renamed to Lazer ?!).

The game engine itself will be open source, but the game I make using it (specific code, levels, assets like graphics and music) are not, but I will give one set of level tiles and enemies. The game is what mario is to mario maker, or unreal to unreal tournament.
The music will be mostly arcade style (Mostly FM synths like YM-2612, YM-2151 and some other synths).
The resolution is QVGA 240 height, 320 height (16px tiles) and usually limited color palette pixel art, but you could probably change that for your games.



My game will feature a mix of static and some generated levels (procedural/random/roguelike) and variable difficulty.
The game feels like oldschool games (Raiden and such), but has some modern elements (sometimes bullet hell, suicide bullets, combos, random levels).
The game serves as a demo for the engine.

The engine is low level, scripts, do not expect a fancy drag and drop GUI and all kinds of nice interfaces.
What makes it friendly is that it is specific to vertical STG so you will not have to work on that part
The levels are text based and are loaded from bottom to top (vertical scrolling), this allows anyone with a text editor to change level, generate levels using a script, copy and paste levels... games are quite safe as they run in the browser sandbox.
Anyone can share his levels/game online (host them somewhere) and anyone else can play them, no installation required.
Games made using it can run OFFLINE in some browsers.

The code itself is pure JavaScript and some JSON files for the config, both can be edited using some text editor.
You do not need to compile the JavaScript, so editing text files and refreshing the browser page will suffice.
So all you need for basic games is modify text files and make some graphics with a paint like software or whatever.

For advanced stuff like custom enemy movement, custom weapons, you must be able to script.
For the moment the engine is not online but it runs around 60 FPS no problem, maybe a bit less for extreme bullet hell situations.
Gamepad control (XBOX compatible) can be supported.
Multi-player not yet supported.

Let me know if you are interested in this project and if you would back it to support the development.
Are you interested in an STG game with playable pseudo random levels and variable difficulty (Steam or other) ?
Any other feedback ?

[MythicalWings]

I am probably on the wrong forum, any players who want to develop games here ?
Has anyone played the game using the links ?

[Ixmucane2]

There are serious problems with appearance and level design.

• Quick and "nervous" movement, but plenty of fixed obstacles (which are usually rare, obvious and preannounced in a vertically scrolling shooter).
• What is an obstacle, and its shape, is completely unclear.
• You place score items next to obstacles, leading to excessive and gratuitous difficulty.
• Score items look and explode like bombs.
• Nasty close-range shooting, often with the cover of score items.

[MythicalWings]

There are serious problems with appearance and level design.

First of all thank you for testing and writing something critical.
The problem is I have trouble to see some of the obvious problems because I got used to the game by playing it during development. This is exactly why I posted it here.

• Quick and "nervous" movement, but plenty of fixed obstacles (which are usually rare, obvious and preannounced in a vertically scrolling shooter).

• What is an obstacle, and its shape, is completely unclear.

  Yes this is a real problem I will have to fix, I do want obstacles but I am not sure how to make them stand out more. Maybe I should include some warning graphics for the first walls and towers in the level.
  Also note that obstacles do not kill you in easy mode, they only block you, maybe I should use the same for normal difficulty.

• You place score items next to obstacles, leading to excessive and gratuitous difficulty.

  I may have tested this game too much, I find it pretty easy to get them now
  I do think getting score items should include some kind of risky move, maybe not in the first level though.

• Score items look and explode like bombs.

  I did try using other colors for the score items, but when green they look like the grass and trees, purple is like enemy shots, when red they still look like the shots, maybe I should try 'player shot blue' AND use a non-round shape like a star (looks less like bullets). FIXED THIS
  Explode like bombs: I will definitely fix this once I have done a specific animation for them (or use another for combos)

• Nasty close-range shooting, often with the cover of score items.

  
  
  Hmmm a bit too nasty for a first level. You got to switch weapon and use the side shot to 'safely' kill those towers.

There are serious problems with appearance and level design.

There is no serious level design to this date, this is some level to showcase a few things you could do with the engine.
To this date most of the work went into the engine (level loading, performance, ...) so you can expect something much smoother later on.
'Ixmucane' is something I remember from Tyrian or is it the mayan thing you refer to ?

[Ixmucane2]

Also note that obstacles do not kill you in easy mode, they only block you, maybe I should use the same for normal difficulty.

I only tried normal difficulty, but obstacles should behave in the same way at any difficulty level. Make them always harmless.

I do think getting score items should include some kind of risky move, maybe not in the first level though.

Important items deserve serious risks, not ordinary and plentiful ones. Score items are usually awarded only after killing enemies; offering free ones doesn't suggest they are a big deal. You could use breadcrumb trails of items to lead the player towards a more dangerous part of the level, but it must be a choice, not an ambush.

I did try using other colors for the score items

Stars, spinning coins, medals, and rectangular or non-round shapes in general (e.g. bees) are traditional choices for items that don't look like bullets. Color is not enough to differentiate good and bad rounded things, and on the other hand reserving colors limits your options for bullet appearance.

Nasty close-range shooting, often with the cover of score items.

Hmmm a bit too nasty for a first level. You got to switch weapon and use the side shot to 'safely' kill those towers.

What towers? I'm talking about the first few formations of flying enemies, which cannot be killed with the front cannon before they reach close range and shoot and cannot be killed with the lateral cannon because it would mean missing the score items. Thinking of it, maybe firepower is inadequate; killing these enemies shouldn't require more than two hits.

There is no serious level design to this date, this is some level to showcase a few things you could do with the engine.
To this date most of the work went into the engine (level loading, performance, ...) so you can expect something much smoother later on.

The engine side seems good; I suggest focusing on collision detection quality (testing complex and pixel-perfect collision shapes).

[MythicalWings]

Concerning wall death, would it be ok if you die when crushed between a wall and the screen limit ?

Will definitely lower hitpoints of those early enemies, I have a tendency to give them too much HP.

Concerning collision detection, for the moment I use a simple box.
In any case I always first check a bounding box for performance before doing advanced collision checks.
I know this will not work for enemies with a complex shape.

I suppose real pixel perfect collision is too expensive in a browser game.
I may use it for really complex enemies.
For round enemies I could approximate using a circle/ellipse.
It would also be possible to automatically generate several collision shapes from the png graphics.

[Ixmucane2]

Concerning wall death, would it be ok if you die when crushed between a wall and the screen limit ?

It's a traditional pattern, but it is usually applied at a larger time and space scale: getting out of a major dead end before it becomes a deathtrap, either as soon as it is recognized as such (in a maze) or after completing a deliberate dangerous detour (the dead end usually contains items or "bonus" enemies as a reward for the unnecessary risk).
Given the fast scrolling, your small dead ends would be a less fun case of pure dexterity (delay the entry and you miss the item, delay the exit and you are dead).

There can be softer penalties for getting stuck, for example stopping scrolling when obstacles crush the player against the bottom of the screen and ruining score by means like simply letting enemies get away, decreasing a time-based end of level bonus, ending or cooling down timeout-based chains and multipliers, changing rank, etc.

Concerning collision detection, for the moment I use a simple box.

Assuming walls are aligned with the vertical and horizontal tile edges, the player ship needs both an axis-aligned large box exceeding the size of the ship for walls (telling where it stops safely) and a small ellipse or box contained inside the hull for bullets. Enemies can be the same, with a generously large bullet hitbox. Bullets can be circles or possibly capsules.

In any case I always first check a bounding box for performance before doing advanced collision checks.
I know this will not work for enemies with a complex shape.
I suppose real pixel perfect collision is too expensive in a browser game.
I may use it for really complex enemies.

Enemies with a complex shape can have separate hitboxes for different parts and different states. For example, a TIE fighter seen from above can have a circle for the hull and two separate thin capsules for the side panels, while a wide boss with turrets on the wings can have one circle for each turret and a very fat capsule for the fuselage, and after each turret is destroyed a capsule (the leading edge of the wing section around that turret) can become active to allow damage to the wing.

For round enemies I could approximate using a circle/ellipse.
It would also be possible to automatically generate several collision shapes from the png graphics.

I suggested pixel-perfect collision detection as a nice feature, but almost everything can be managed with axis-aligned boxes, ellipses and capsules and possibly arbitrary convex polygons. Matching collision shapes to opaque parts of a sprite is usually wrong, as the pseudo-hitbox for avoiding obstacles must be bigger than the ship's hull while the hitbox for catching bullets should be significantly smaller (a grazing miss is OK, a hit without actual contact is sloppy and unfair).

[BareKnuckleRoo]

The graphics for the background are very pretty, and I didn't have as much of an issue discerning the obstacles as the brick walls were at least a different colour than the rest of the city/islands. I think it's visually a bit disconcerting though because the walls that block you appear to be the same height as the houses are, and you're already flying so high up that it feels odd that you can't simply fly over these. Perhaps double the height of the walls so they're more discernible?

I don't understand the point of the weapon switch. Why not simply have one button fire straight, the other fire sideways? That way, even when using the sideways weapon, you can choose to charge up when you like. More freedom that way.

[MythicalWings]

The graphics for the background are very pretty, and I didn't have as much of an issue discerning the obstacles as the brick walls were at least a different colour than the rest of the city/islands. I think it's visually a bit disconcerting though because the walls that block you appear to be the same height as the houses are, and you're already flying so high up that it feels odd that you can't simply fly over these. Perhaps double the height of the walls so they're more discernible?

Thank you for taking some time to test.
Good to know they please someone, I do think pixel art is nice for a 2D shmup.
It probably works well in this case because it looks very distant and does not interfer much with the onscreen action.

I plan to make the wall and tower tiles more tileable in order to have more freedom to make castles with variable wall and tower height.
Doubling wall height would be a good compromise... it is indeed a bit odd that you can fly over the houses and not the walls
I could also make every building destructible but that would change the gameplay quite a lot, hmmm...

I don't understand the point of the weapon switch. Why not simply have one button fire straight, the other fire sideways? That way, even when using the sideways weapon, you can choose to charge up when you like. More freedom that way.

I had initially planned to have more tha 2 weapons, for a moment I also had a laser. Not sure about one button for each weapon, what happens when you press both at the same time, will both shoot, the last one pressed only ?
I do not want both to shoot at the same time otherwise the players will always press both buttons.
Maybe two buttons are ok if you have only 2 weapons, perhaps you can change ship or equip other weapons before the level starts.

[BareKnuckleRoo]

Not sure about one button for each weapon, what happens when you press both at the same time, will both shoot, the last one pressed only?

Have you ever played a game that uses a shot/laser system? I would recommend playing something like Dodonpachi. Or, better yet, the 6 button version of Daioh.

Crisis Force is another game worth looking at - the ship visually changes when you cycle weapons through the shot types, with each ship having two different weapons (depending on the colour of weapon you currently have) and a unique bomb.

It's pretty common for shmups to have two different weapons, one that has priority over the other when you hold both buttons (also usually tied to movement speed). In some cases like Dodonpachi DFK BL, two buttons are used to control three weapons (shot, laser, shot+laser).

[MythicalWings]

As few people are interested in this kind of engine and I have little time to work on it I just uploaded the source and stopped working on it. You can learn a few things in the source code and make some games with it if you know how to code.

You can get the source and examples here: https://github.com/christopheroussy/stg-game-engine

Note that I have the copyright on the pixel art graphics, so you cannot use them for commercial applications.