Pre-alpha engine feedback

[beermat]

I'm slowly making a shmup in my spare time (actually it's little more than an incomplete engine written in c++ atm). It's at a very early stage, and I want some pointers to make the foundation more solid. There's an issue I'm working on about time-progression (it's done time-since-previous-frame not frame-by-frame, which means no slowdown but also means different runs will not be pixel identical {things will spawn at ever-so-slightly different times on different runs}). Will convert to frame-by-frame and enable VSync, possibility of slowdown but sound like a better idea?

What there is so far:

• Memory is pre-allocated
• Anything that goes offscreen is destroyed (with a threshold beyond a sprite length to avoid sprites disappearing onscreen)
• Score is accomplished with chip points, base point value, grazing enemies with your bullets, getting grazed by enemy bullets
• Paths for enemies are defined as chained line segments relative to an initial absolute position, which enemies traverse at their own speed. If they get to the end of the path and they're still onscreen, disappear
• Paths for bullets are defined as a current position, direction and speed. In this way curved trajectories should be easy to implement. Keep going until offscreen
• There's no bullet-pattern logic. Enemies (and you) have turrets, which spawn certain bullet types in certain directions at certain rates.
• Shitty procedural background or repeating image
• Vertical orientation
• Resolution is the same as game logic, at present 960x960 but only because it's convenient for testing
• Keyboard input: up down left right z/y

Planned in near future:

• Turret types other than fixed direction to accomplish things like: lock-on, sine wave bullet patterns etc
• Currently it's like enemies are always holding z, implement enemy fire patterns (or maybe do direct bullet patterns)
• Curved bullet trajectories

Anything you'd do differently (or remove) and why? Lots of things aren't implemented, like I say it's pre-alpha, suggestions for other features are welcome.

[Pteriforever]

Not sure how well the whole turrets system will work. Wouldn't doing it a more traditional way with bullet-pattern logic be both neater and give more flexibility as to what kinds of patterns you can have?

[beermat]

Not sure how well the whole turrets system will work. Wouldn't doing it a more traditional way with bullet-pattern logic be both neater and give more flexibility as to what kinds of patterns you can have?

It might be better to do bullet-pattern logic for more difficult enemies and bosses, and in tightly scripted areas. I have a vague idea about a mechanic where the player can customise their fire by altering the turrets location/type/direction. It might turn out that popcorn is easier to do with bullet-patterns (they only use turrets now because that's the only bullet mechanic implemented), but turrets are probably here to stay for the player.

Thank you for the feedback.

[ciox]

I think using a fixed timestep (frame-by-frame) is recommended, there aren't really cons because slow down is both unlikely and something players are used to if it does show up. The typical timestep is 1/60 so you have 60fps max.
The big con for sticking with variable timestep is that when the game is slowing down because there's too many bullets, the last thing you want is for them to skip and move in jumps towards the player.

[beermat]

Update: Now converted to fixed-timestep, which yielded slow framerates because of poor design decisions, which was previously hidden by variable-timestep. Much refactoring later and now we have 60 FPS constantly, until we get to many hundreds of enemies at once (orders of magnitude more than is sensible in a proper game), combined with many hundreds of player bullets at once (which understandably grinds collision detection to a halt). Scoring system can be customised at compile-time with defines.

It's now at a point where I can show something, albeit everything is a placeholder as there's no game yet. Highlights/lowlights:

• 8 different (placeholder) popcorn enemies, all with their own gun firing patterns (hardcoded in turret style)
• Player weapons are turrets
• Single bullet type
• Player, enemies and bullets can be animated
• Enemies and player are tyrian sprites, maybe with palette swap
• Background is a very basic procedural river

Miscellaneous things you might have an opinion on:

• Internally there are fixed size pools for spawns, enemies, enemy bullets and player bullets, all things which can be 'alive'. If a pool is full (full means full of live objects), trying to put another object in it does nothing. Each object doesn't take up much room so the pools can be relatively large, they should be large enough to never get full.
• Current enemy fire routine is: fire a bullet from a turret every n frames. Technically everything describing the bullet is a bullet-pattern with a single bullet. The way to implementing bullet-patterns could be to have turrets fire bullet-patterns instead of bullets. This would make game logic go from:
  spawn->enemies->turrets->bullets
  to
  spawn->enemies->turrets->bullet_patterns->bullets

[Ixmucane2]

Run stress tests with at least 2000 bullets, 100 ships and all types of special effects for several minutes (monitoring memory leaks). Run them again with moving turrets, huge bosses, and any other performance-sensitive feature.

[beermat]

Run stress tests with at least 2000 bullets, 100 ships and all types of special effects for several minutes (monitoring memory leaks). Run them again with moving turrets, huge bosses, and any other performance-sensitive feature.

I have done stress-testing to a limited degree. There's no memory leaks which is nice, pre-allocating made that simple. There's very few special effects or features yet, but when they're in there will definitely be kitchen-sink testing.

The most performance-sensitive feature so far is collision detection. It runs smoothly with 2000 player bullets and 100 enemy ships with a naive collision detection implementation on a single core of an i5-2500k (just, btw this is with VSync which is forced on in my crappy intel linux driver). Yesterday I sped up collision detection 3x just by optimising the core detection code. Not sure if a fancy multi-tiered collision algorithm will work well here as the core code is simple, will investigate. If it can be made 2x quicker or better from this point great, but it should already be quick enough (unless making a bullet-hell-for-the-enemies targeting older computers, meh).

To get you fully up to date there's been a few bullet features implemented including:

• Bias: Bullets can start going one direction and alter course towards another
• Acceleration: Increase bullet speed over time
• Wobble: aka sine wave
• Split: Bullets can split into new bullets over time

Wobble is used in the example for the blue discs (the bullets follow a sine wave path, the turret is static). Split is used for the green stars. Bias and acceleration is used for the pink missiles, to simulate the missiles detaching then engaging. Will try split as a cheap (implementation) way to do bombing, although it's probably expensive collision-wise and would look like crap.

[beermat]

Here's a link to a small win32 tech demo: http://www.sendspace.com/file/cb8pgl

Controls:
Movement: UDLR
Fire: Z/Y
Upgrade bullets: A
Upgrade missiles: S
Upgrade discs: D
Reset: Q
Toggle rain: W

Let me know what you think, if it lags on your setup and when (and what you have), if it crashes and when, if it says missing dlls etc. To stress it turn enemies on, power weapons to full, move to bottom centre and hold fire. It'll probably lag at least a little, I average 58 FPS (native linux 64 bit) or 52 FPS (binary in download through wine) on an i5-2500k with VSync enabled.

Known problems:

• On windows it may crash on exit, a known problem with the old version of the library I'm using
• You need a 1080p resolution desktop. It tries to open a 1600x900 window and the library wont do it if the screen resolution is too small
• Sometimes bullets come down the left hand side from an offscreen source

An actual game is still a long way off. Hopefully in a few months there'll be a proper demo of some sort.

edit: The above binary is no longer suitable for stress testing as it's out of date.

[beermat]

New tech demo: http://www.sendspace.com/file/3npsp8

This one is much quicker than the previous version, maxes the framerate on everything I have that's hardware accelerated. Resolution is lower so it'll probably run on most other setups. Screenshot shows all three player weapon types at their max setting. ATM the idea is that there'll be a choice of red or blue for the main weapon, green for the alternate (aka business as usual):

edit: Almost forgot, in the demo you can see some good quality enemy death animations.

[beermat]

Added a death timer to bullets, so they can die after n frames. This is to implement melee attacks. ATM the idea is for the alternate weapon to be unreliable missiles (in the sense that they fire within a certain range), or melee:

Starting to think about the first demo/game to make. Left to implement for a barebones game:

• Bullet pattern format
• Bullet pattern designer
• Level format
• Level designer
• Level(s)
• Bosses
• Rank
• Basic graphics that aren't stolen or garbage
• Basic sounds that aren't stolen or garbage

Things that don't need to be implemented for a first game:

• Bombs
• Items
• Lives
• High score list
• Replays
• Particle effects, or rather effects in general
• Anything that hasn't been specifically mentioned

Demo/game idea:

• One level looping forever
• 2 main weapons (red, blue), 2 alternate weapons (missiles, melee)
• Rank
• Boss with multiple destroyable parts
• Multiplier that increases when you destroy enemies, decays over time
• Buy weapon upgrades using score
• No lives or health. One hit and you're dead
• Rudimentary difficulty levels (just set the starting rank accordingly)

Let me know if you think I'm doing something badly, and how you would do it better.

[beermat]

Trying out an alpha version of single player co-op. Failed runs through a level act as backup on subsequent attempts:
http://youtu.be/yQMgW2uH_to

A proper game can be built on this mechanic (once it's evolved into something usable). Should solve a lot of problems down the line, like designing levels that are fun for both average and expert players simultaneously. Average players die until there is enough backup to progress, or they figure out a successful path from analysing their failed paths. Expert players are rewarded with better score for using less backup. Some simple strategies for overcoming obstacles (like decoys) may also be able to mix play up a bit, in ways not possible otherwise.

Super time force uses a similar mechanic, but are there any shmup examples? It would be nice to feel what others have done.