Captain Spectre, a vertical shmup

[rfeese]

I'm posting here to get feedback and hopefully a little motivation to finish this hobby project I've been working on for years now. I never imagined it would take this long but I hope that the journey has been worth while.

Captain Spectre: Wingman Ops is a vertical scrolling shooter based on the Captain Spectre comic by my friend Tom Floyd (http://captainspectre.com). It is planned to consist of four main levels with a few secret levels and an alternate ending. It has "options" in the form of wingmen that are earned by collecting coins. The wingmen fire when the player fires, and they have two states: attached and detached. In detached state, they stay in their current location relative to the screen. When in attached mode, they fly towards the player until they reach formation on either side of the player. Player and wingman weapons can be upgraded a few times by picking up power-ups dropped by certain enemies.



Over the years I have been refining the game engine, learning and adding features. Now I hope to really focus on the final mechanics and level design. Right now I have a loose set of short levels designed that cover most enemy types and features. I need to make another working pass over them to make them longer and more detailed. I am going to try to work on the first few levels and post a demo, then work on the remainder of the levels. I still need to work out the mechanics of when powerups appear (I imagine they will be dropped by certain types of enemies or objects) and when coins appear (Dropped by all enemies or certain types of enemies). Also, I have a lifebar right now...I know not everyone likes that.

So far I have done allmost all of the graphics myself and I am slightly colorblind so I'll need feedback on anything that looks strange...

[Laurel_McFang]

Loos cool take your time

[laxa88]

The screenshots look appealing -- I would give it a try for sure. Any playable demo?

[rfeese]

Thanks for the encouragement. I am trying to focus on developing the enemy patterns for the first two levels, then I will post a demo. For those interested, this is developed in C using SDL and OpenGL. I store pretty much all configuration data in external text files. I have some rudimentary editing tools I have developed for modifying enemy movement and firing patterns, etc. Let me know if anyone has questions about that stuff. I've kind of made my way through all this stuff with the help of reading various articles on the Internet. I have the project compiling using GNU make on Linux (where I develop) and it also builds for win32 using MXE (http://mxe.cc/).

[Laurel_McFang]

Thanks for the encouragement. I am trying to focus on developing the enemy patterns for the first two levels, then I will post a demo. For those interested, this is developed in C using SDL and OpenGL. I store pretty much all configuration data in external text files. I have some rudimentary editing tools I have developed for modifying enemy movement and firing patterns, etc. Let me know if anyone has questions about that stuff. I've kind of made my way through all this stuff with the help of reading various articles on the Internet. I have the project compiling using GNU make on Linux (where I develop) and it also builds for win32 using MXE (http://mxe.cc/).

Awesome. Will you let Linux users compile their own build or will you provide binaries? Regardless that's really impressive you made an open Gl based game.

[rfeese]

Awesome. Will you let Linux users compile their own build or will you provide binaries? Regardless that's really impressive you made an open Gl based game.

Most likely I will do both. I had always kind of planned on making the source code available. I am not using autotools though and I want to clean up the project structure a little bit more to make building a little more straightforward. The source code is kind of a mess but some parts may be helpful to others to see how (or how not to) do things. Just curious, but what is your interest in compiling from source?

OpenGL is not really that difficult. It provided a great performance boost for doing 2d graphics. I started out using 1.0 and then I updated to 2.0 for GLES compatibility, although I am not really focused on that now.

[rfeese]

Sorry no demo yet...just a devlog style post and update.

Game Assets

As I believe I mentioned previously, I have game configuration in external files. I am using zziplib to load these game assets from a single zip file. This library is neat because it can read from either a directory or a zip file which means I can have all my assets in a directory for development and then package them in all in a single zip file for distribution.Managing all these asset files became a much larger task than I originally imagined. Right now there are over a thousand files in my assets directory (all assets are in a single directory). I have a few file naming conventions to help keep things organized. The main convention is on using 3-letter filename extensions. I am using .bmp files for graphics and .wav files for sound effects (No music yet, but my game has basic support and I plan to use XM modules). Most other assets are custom text files: .obj for game objects (maybe not the best choice), .pth for paths, .lvl for levels, .cin for cinematics, etc. These text files may reference other files, which creates complex inter-dependencies. When the game engine loads assets it remembers file names corresponding to assets in memory and is thus able to avoid loading files it has already loaded.

Asset Management

I use source code management for this project, with separate Subversion repositories for the source code and game assets. In order to do a release such as a demo or even a full release version of the game, I want to have a way to identify the assets I need and only package the necessary assets into a zip file. I have a fairly simple Perl script that roughly interprets the text configuration files and is just able to pick out file names within the data files and recursively process them, giving me a complete list of dependencies. My asset dependencies are mostly descended from a main game configuration file which lists the levels in the game. (The level files then reference objects and paths which may reference graphics and other objects, etc.) I can create different main configuration files for different release versions/demos. I created a Makefile that can then use this information to build the resources zip file. The Makefile can contain targets for different release versions as I wish.

Level Editing

I have a level editor that allows me to do basic adding/removing/editing of my game "events" which occur on a fixed timeline. I often need to drop out to a text editor (a handy thing about using text files for configuration) or other edit tools to modify things not handled in the level editor. You can see in the screenshot the timeline along the right side. Most events are tied to the spawning of enemies along paths. Within the editor I can scroll through game time and invoke a "play from here" function to test things while I edit.



Progress Update

So right now I am in the process of trying to use the editor to revise the first couple of levels in the game so that I can release a demo. Along the way I will be finding and fixing bugs in the editor and possibly adding features to the game engine (though hopefully I will be able to limit this). I also will be using other editing tools for honing the objects and paths, which I may detail more in the future.

So that is enough for now...I think by describing all this it may help me focus on the next steps of getting a short demo ready.

[mystran]

As I believe I mentioned previously, I have game configuration in external files. I am using zziplib to load these game assets from a single zip file. This library is neat because it can read from either a directory or a zip file which means I can have all my assets in a directory for development and then package them in all in a single zip file for distribution.

Yeah, this approach makes everything much easier, I do it as well, except I use miniz as a library (single c-source, license public domain or equivalent where PD doesn't apply; doesn't search raw directories, but not hard to do that manually). Anyway, another trick that might be useful is to have the game binary search more locations (eg. data dir and multiple archives) in priority order. This way you can keep the working version in directory, then package them easily for distribution, and then if you need to update just a few files for a patch, you can package just those into another archive (for smaller updates; the new archive only needs changed data) and have your new binary look for the files in the updated archive at higher priority than the original.

[rfeese]

Thanks @mystran for the reference to miniz as I was not aware of that. I think I'm committed to what I'm using now, but it could be handy in the future.

Work continues...

I am fairly satisfied with the first level now and I think it is about ready to go. I think I will plan to build out the first two levels and then release a demo. The other option I have been considering is releasing a "technology" demo which would just be a really simple level that would allow me to get an idea for how well the game runs for people, including the menus, settings etc. I am leaning towards this in order to get something out there soon because even though I think the first level is fairly complete, there is more work, which brings me to my second topic...


Secret Levels/Stages

I have three, and maybe four secret levels planned, which I realize now is basically one per every standard level. I am wondering how people feel about this. I am not planning on having this game be purely about scoring although there will be a hiscore table and a decent scoring system. I wanted to do secret levels because I think it makes it more interesting for the player and could produce more playability for the average player. For someone who is serious about score, they would of course want to seek out and be aware of all the secret levels as that will provide more opportunities to score points. I imagine that people who are interested in getting the highest score will read spoilers or whatever they need to do to figure out all the secrets. Let me know if anyone has thoughts on this.


Distribution

I have put a little more thought into how I want to distribute the game. I am pretty sure I want to make the engine open source. Not because it is a great engine, but rather so that if people want to port/optimize/learn from/fix it, they could. I am considering licensing the content separately, perhaps using the old "shareware" model. There could be the "demo" or shareware content which would be released with some kind of free license and then, if I think I could sell the full content version, maybe I would offer it under a non-free license. I am not looking to make a huge profit here...it would be a few bucks perhaps. I'm curious if anyone has any experience doing this in the PC market using any of the distribution channels out there now like Steam/Desure/etc. Honestly if it looks like this is going to be too complex I might just set up a paypal account for donations and release it all free.

[rfeese]

Optimization

I decided to put together a demonstration level to "stress test" my game engine with a large number of objects on screen. When I did that I noticed I was getting some pretty low frame rates once there were around 600 objects on the screen. Using the Valgrind profiler, I was able to determine that the collision detection routines were using most of the CPU time. My method for doing collision detection was not really optimized -- I was checking every object against every other object. So, I decided to implement a spacial partitioning grid to reduce the number of checks needed for each object. After several hours of development and debugging, I have it working and now the frame rates seem more stable. I will have to do some more testing to see what the limits are now and see if I can do any more optimization to the grid.

[rfeese]

Just for fun, a screenshot that visually demonstrates spatial partitioning for collision detection. While I was debugging I added a visual display of the grid. The grid represents separate portions of the playfield in which objects are tracked. You only need to check for collisions between objects that occupy the same grid cell. Doing collision detection this way helps reduce the average number of checks you need to perform even though there is some bookkeeping work to maintain the grid.


Rank and Difficulty

You may also notice some "rank" numbers in the screenshot above...This game has had a player weapon power up feature for a long time. The power ups increase the number of bullets the player fires with each shot. The wingmen that the player earns also contribute to overall firepower. I have known for some time that these power ups dramatically change the balance of the game and as I have started to deveote more attention to level design, I have found it difficult to find the right balance. So, I decided to implement a rank system. The rank is based on the number of wingman options and power ups the player has. The rank will affect enemy hit points and for bosses it will affect their offensive capabilities.

Spoiler

Bosses will spawn with different guns/turrets based on the current rank. In most cases this means the bosses will have a different appearance based on rank.

I also am thinking about implementing difficulty levels. Difficulty levels would primarily affect:

1. Player hitpoints (maximum difficulty the player would have 1 hitpoint -- no lifebar).
2. Inital rank level and maximum rank.
3. Spawning of enemies -- Some enemy spawns will be designated as only occuring under certain difficulty levels.

[CoderGamesIsBack]

I think your grid is too big. Too many leafs, if you're using a tree, to maintain the grid.

[rfeese]

I think your grid is too big. Too many leafs, if you're using a tree, to maintain the grid.

It might be. The grid is actually an array of linked lists. The size of the grid is currently defined by height and width constants which I can easily modify to experiment with different values. In my experiments so far, this size seems good. There are some other optimizations I think I could make if it turns out to be a problem. Right now I am able to get 60 fps pretty consistently with 2000 objects on screen. That number of objects seems like a lot at this point, but we'll see... I'm developing on modest hardware that is a few years old and a low-end (Radeon Cedar) video card. I'm planning to work on a stress-test demonstration so people can test things out and try the various settings.

[CoderGamesIsBack]

You're a beginner. Arrays are slow for collision checks and for building the collision grid, even if the arrays are just pointers toward link lists. Binary tree is the way to go, minimal number of checks. And, your game is so basic that it should run smoothly on old integrated video card.

[rfeese]

You're a beginner.

You're abrasive, and not necessarily correct. But, thanks for the feedback.

[CoderGamesIsBack]

Ah, sorry about that, was not my intention. I meant to say, an obvious beginner in the collision area. I was too, many years ago, even though I programmed for years before that. Since one needs to update the collision grid each loop, it's very expensive to use arrays.

[rfeese]

Hiscores and gameplay recordings



I've been spending some time trying to get gameplay recordings working across multiple levels and it finally seems to be working fairly well. I also have integrated automatic gameplay recordings which are saved along with the hiscore table. This is a configurable option, but it means that for all the entries in the hiscore screen, you can click on them to see a replay.

[rfeese]

Shadows, more scoring mechanics

For some reason I wanted to add shadows so I worked on that for a while. I implemented them using a stencil buffer.



I also became more interested in having some more scoring mechanics. I added a level-summary screen which adds bonuses based on the player's performance in the level. Right now I am tracking percentage of enemies killed, end rank, and maximum kill chain length.

Kill chaining is still a bit of a work-in-progress. Right now, any enemy kill counts towards the chain, and I will need to see how the level design will work with the "timeout" value for the chain. I am also still working out how to visually indicate the chain and its effect on scoring. It will be a score multiplier of some sort, but I haven't decided exactly what it will be.

I also added a bonus for destroying an enemy piece-by-piece. That is, destroying all sub-parts of an enemy first, grants a bonus. Now I just need to create some more mulit-part enemies...

[BPzeBanshee]

I'm glad to see you're still working on this in some capacity, rfeese. The high scores board is looking very nice!

Out of curiosity, are you doing anything special in regards to maintaining multiple parts on enemies? I'm currently getting a bit more into this side of things with my project at the moment, and while I'm not going as low-level I'm curious to know if there's more than one way to skin a cat aside from just a parent enemy maintaining child parts (or an array of multiple parts if its large).

[rfeese]

I'm glad to see you're still working on this in some capacity, rfeese. The high scores board is looking very nice!

Oh yeah, I'm just slow...Working on this is a lot of fun for me but I'm not always motivated after work and all that. Thanks for the feedback on the hiscore table...I've invented my own crude UI library for this game. The hiscore screen will have another widget for switching between hiscore tables of different game modes...

Out of curiosity, are you doing anything special in regards to maintaining multiple parts on enemies? I'm currently getting a bit more into this side of things with my project at the moment, and while I'm not going as low-level I'm curious to know if there's more than one way to skin a cat aside from just a parent enemy maintaining child parts (or an array of multiple parts if its large).

I don't know that I'm doing anything special, it has evolved over time though...

So right now I have a large linked list in which all objects exist, including child objects. Then, parent objects (well, any object) have an array of sub-object pointers, and child objects point to their parents. (I would think about making this a linked list, but I am referencing indexes in some cases) I think I've worked out most of the kinks. Things get a little complicated when you are iterating over the linked list of objects and then doing operations that may update (for instance: destroy a parent and sub-objects) objects that may appear in other locations in the list.

Sub-objects can also have paths relative to the parent object and can be detached or attached. This would allow you to do things like have a bomb bay that opens or the wings open up to reveal a robot head or other fun things like that. Also, a sub-object can be replaced by a different sub-object like in the case of a wing or gun that gets destroyed it could be replaced by a burning stub or something.

[rfeese]

More score bonuses

I added the ability for level configuration to have special score bonuses for certain scenarios that may occur in a level. This includes things like destroying certain objects, destroying a certain number of objects within a given amount of time, or when certain objects spawn, (which can be triggered by various other conditions). I'm thinking of things like "Destroyed at a time" and "Defended the house" bonuses in Raiden Fighters among other things.


Lightning Attack

I have come up with a secondary attack mechanism that I think is fitting for the character in the game. Shooting enemies charges your "tesla coil" which charges a meter. This can then be unleashed on enemies within range, lasting as long as you hold down the button or you run out of power. Lightning can chain to nearby enemies, which damages them all, but drains your power more rapidly. The field that discharges around the front of your ship also cancels bullets. I am thinking about adding "coil charge-up" power-ups that could drop at certain times. I still have a few other details to work out, but this feels fun and should add some depth to the game.

[rfeese]

Co-op!

I have always enjoyed co-op games and it bothered me that this game did not have any co-op. So, I decided to add 2-player co-op. This also gave me an excuse to revisit the input code and various other places where I think I improved the logic. I've been working (slowly) on this feature for over a month and it has been interesting. With more than one player I found that I needed to track more information so that points could be assigned to the player that earned them. Hopefully I did not introduce too many new bugs.

I have not ironed out all of the details, but basic 2-player capability is working. I still need to design another ship for the second player -- right now my plan is to always have player one be Captain Spectre and player two will be a sidekick, with a ship with different look but equal capabilities. Two-player will have dedicated game modes with similar levels derived from the single player levels but customized specifically for two players. I also have yet to decide how hiscore in two-player mode will work. Right now I am thinking about summing the scores from the two players at the end and having a combined/shared hiscore.

Playtesting 2-player mode will be an interesting challenge...

[rfeese]

Game Replays and Consistency

I've been implementing some additional scoring mechanisms lately and eventually started noticing some inconsistencies. The only way I would have noticed this is due to having a high-score table and game replays. In playing back some example runs, I could tell that scoring was occasionally off. I was able to add additional scoring debug output and observe the differences when the replay was played back several times. This was crucial in helping me track down the scoring bugs (which were related to an uninitialized variable). Doing long replays and verifying the score is making me feel more confident about the overall consistency of the game engine as well. So I guess what I'm trying to say is that what was once just an extra feature suddenly seems like a valuable development tool.

[ciox]

Yeah it's definitely a good thing, many devs have noted this when trying to implement replays or multiplayer.
It's really important for all the logic in a game to be either fixed or variable timestep (preferably fixed for shmups) otherwise parts of the game will run at different speeds when performance changes which is beyond silly, implementing replays and/or multiplayer will force you to face these bugs.
I remember for a very long time my game had the player's shots running at variable timestep because it was the first thing implemented and I had never looked at it since, I only fixed it like one and a half years later because it kept desyncing replays.

[rfeese]

Rank

I've been working on how the rank system affects game play and scoring. Watching game recordings playback is allowing me to more
easily see how scoring is affected and should allow me to refine that more easily. Game difficulty scaling is more difficult to a
djust because as soon as you make an adjustment it can easily break a gameplay recording.

Rank is fairly course and only goes from 0-4 currently. This allows me to more easily set up differences in game play. Hopefully
the rank changes won't be too jarring. Rank is calculated based on the following factors:

• 1. Weapon powerup level
  2. Number of subobjects
  3. Secondary weapon charge level
  4. Time alive

On normal mode there is a cap that keeps rank from reaching the maximum. On difficult mode, rank starts out higher and goes to max. Rank can affect the following things in-game:

• 1. Whether certain enemies spawn.
  2. Whether bullets in enemy firing patterns spawn.
  3. What rank enemies spawn as.

An enemy's rank affects the following:

• 1. Hitpoints.
  2. Points awarded for destroying.
  3. Sub-objects spawned (typically this would be extra guns on the enemy).

I've started to go through the enemies and design them with scalable firing patterns and think about how rank will affect them on screen. There's more to refine but at least now I am getting deeper into the level design and seeing how these things all fit together.

[rfeese]

Initial Demo


Life is getting more complicated all of a sudden and I want to finally get something out there, so here it is. This is a preliminary demo that includes initial versions of the first two levels and some additional stuff if you can find it. I am still very early in the level design process, so bear that in mind. Also, there are missing sound effects and no music yet.

There is a win32 build and a linux amd64 build. The windows build should run out of the folder, but may require some missing DLLs. The linux build is dynamically linked on Debian wheezy amd64 and I have not included required libs. In the future, I plan to release the source code as GPL and distribute it with the game.

Windows
captain-spectre-0.5-w32-demo1.zip
MD5: 5cfa169992f54db082e0e351dab63912

Linux
captain-spectre-0.5-linux-demo1.tgz
MD5: 19689139c16d73a25d8c23eec067f65c

[rfeese]

I am still working on this...

In the past year I actually ended up with more time to spend on this "hobby project". However, even though it was on my mind a lot, it wasn't always possible to stay motivated and productive. I did pursue some new ideas for improving the general polish of the game.


Making use of extra screen space

I had developed a "wallpaper" system some time ago, but that still just seemed like wasted space. I eventually decided that it would be nice to move status information off of the playfield area if there was extra screen space available. This seems like a logical thing to do and actually an older version of the game had this.



If the screen is in TATE mode, then that space should be utilized as well.



Additional status information

Over the past year I watched a lot of gameplay footage and periodically lurked on the forums. I was intrigued by the Garegga rev.2016 release. The screenshots and early footage showed additional details in the unused screen space. This inspired me to try adding some similar features. You can see some extra information displayed in the above screenshots.


Rank Revisions

Battle Garegga rev.2016's rank graph was interesting because I had been thinking that I still needed to adjust rank mechanics in my game. By having a rank graph I realized I could more easily see how rank changed during gameplay. This should help greatly in level design. Right away, I discovered that my rank graph was "boring". It basically just looked like a stair steps. This lead to making changes so that rank changed more continuously during gameplay. I am still working on this, but I think it will lead to more interesting gameplay.

After I felt a little better about rank calculations, I decided to build something to show information about scoring. This also proved to be helpful in that I could more easily analyze scoring mechanics. Perhaps this takes away some of the fun for players who would want to figure out these mechanics for themselves, so I may leave it as an option that can be turned off.

I added a few other types of informational displays and came up with ways to have them work in different screen orientations and in 2-player mode.


Housekeeping

I finally decided to attempt to make my code less spaghetti-like. This is something I had been putting off for a long time and somehow I got motivated to work on it. I broke up some large files and functions and hopefully made the code a little more manageable and maintainable. It meant revisiting some problem areas and long debugging sessions, but I think I reached a point where it did have some benefit. I would say that the primary benefit is that the code should be a little easier for me to work on.


SDL 1.2 to SDL 2

I decided to finally upgrade to SDL2. Moving to SDL2 was part of the inspiration for code clean-up. I think that SDL2 will provide some improvement in display compatibility and I am also interested in the new input API in SDL2. I do have a few notes on what it took to go from SDL1.2 to SDL2 if anyone is interested.


What's next

Right now I have a fairly complete input mapping scheme, but I would like to be able to have some default gamepad/controller configurations that should be possible in SDL2.


A Few notes on distribution

I've been using mxe to build a Windows exe for several years but I have had few opportunities to test the port. I will need to ask for help testing the Windows port.

I've also been researching more about how to distribute on Linux. Steam on Linux seems like a viable option and I may pursue porting to the steam runtime. I think that the Steam runtime is an interesting development in PC gaming.