2D Shmup development log

[shponglefan]

Following from the posts in the Game Ideas thread, I decided to start up a separate thread to chronicle development of my first attempt at a real C#/Monogame video game.  It's going to be a basic space-themed 2D shmup.  Nothing ground breaking, but I'm hoping it will serve as a good learning experience for game programming.

My initial goals are as follows:

1) Create at least a single 2D shmup level with 3-4 enemy types and an end boss;
2) Support different screen resolutions and controller inputs (keyboard and gamepad);
3) Design the game in a way that will utilize scripting for enemies, levels and so on;

If I can do the latter correctly, I'm hoping I can then build a multi-level game from it.

To start this, I've started completely writing a new code base somewhat based on the prior prototype.  The difference is I'm trying to modularize the code to allow for easier construction as the game engine grows.

First, I completely rewrote the background graphics code into a new Background class.  The prior code was a spaghetti mess; now the Background class handles everything and it's very easy to add multiple layers of background graphics will different scrolling speeds and directions.

Second, I reworked the class for the Player.  Previously everything was crammed into the Player class.  Now there is a separate Ship class which handles everything associated with the ship sprite and behavior.  In addition, I added a Thruster class to add some thruster animations.  The Ship class contains one or more instances of the Thruster class.  In the below example video, there are 6 instances of the Thruster class all based on the same animation (scaled in size).  They simply activate or deactivate depending on the player pressing Up or Down.  The result is the illusion of a ship powering up or down it's thrusters relative to its movement.

Next up is to do the same with a Weapon class.

[keilmillerjr]

Looks good so far!

Since your using mono, will it be cross platform?

[shponglefan]

Thanks keilmillerjr!

No plans for cross-platform yet.  My main focus is going to be building for various configurations of Windows.  If I can do that reasonably well, then I'll look at expanding beyond Windows.

[eds1275]

Looks great. If it does indeed end up with a few levels, consider putting in a coin/credit system so it sits nicely with a mame cabinet!

[keilmillerjr]

Looks great. If it does indeed end up with a few levels, consider putting in a coin/credit system so it sits nicely with a mame cabinet!

+1 for want of free credits, the arcade was lost.

[Malenko]

I'm a visual guy so I'll just say I think the big flames out the back is too much, backwards should be the default exhaust flame, what you have as normal should be the forward. Maybe some sort of repulser  from the front when you're going backwards?

[thomas_surles]

What language is the game being made in? Also what engine ( if any) are you using?
Sorry if you already answered this elsewhere ( I didn't look hard)

[eds1275]

I believe c# monogame.

[shponglefan]

Looks great. If it does indeed end up with a few levels, consider putting in a coin/credit system so it sits nicely with a mame cabinet!

I'll keep that in mind.

I'm a visual guy so I'll just say I think the big flames out the back is too much, backwards should be the default exhaust flame, what you have as normal should be the forward. Maybe some sort of repulser  from the front when you're going backwards?

Reverse thrusters is something I want to add, I just need to add code to modify the relative angle of the thruster graphics.

As for the existing thruster size, right now the graphics are all for test and not necessarily going to be the way it looks in the end.  It will more than likely be changed.

What language is the game being made in? Also what engine ( if any) are you using?

I'm writing it in C#.  The engine is technically my own, but using the MonoGame API/framework to write it.

[shponglefan]

I added in the code for weapons/projectiles.  The projectile code itself is taken straight from my prototype.  But I added a Weapon class, which right now serves as a Projectile emitter of sorts.  The Ship class can have multiple Weapon instances, allowing me to create however many particle-based streams I want.  And each Weapon particle emitter can have its own attributes (angle, speed, sprite graphic).

The Weapons can also be grouped, with different weapon group selected at any given time.  In the below video, there are four different groups.  The last one is garish, but just there to test mixing of speeds, angles and particle sprites.



And here's a test video with animated projectiles:



Ultimately, I want to have four different weapon types:

1) Projectiles (as coded)
2) Homing missiles
3) Bombs
4) Solid Beams

The first three I think could be done with the existing projectile code, except changes to the basic behavior.  The last one is going to take more work.

[lordnacho]

Looks good. 

Is this sprite based?  Fixed resolution? 

[shponglefan]

Looks good. 

Is this sprite based?  Fixed resolution?

Thank you!  Yup, it's a 2D sprite based game.  I do want to be able to scale the resolution.  Right now I'm targeting 1080 vertical as a base, with plans to scale up or down depending on actual resolution.  For horizontal, I'm hoping to be able to take into account relative aspect ratios of a user's screen.

[shponglefan]

Continued to work on a few things this week.

First, rewrote a chunk of the animation code.  The original code was based on this MonoGame animation tutorial.  However, I didn't like that it relied on passing the frame width/height, so I rewrote it to auto-detect that instead.  Then I extended it further by adding support for rotating animations.

Next, reworked the Thruster class into a more generic ShipPart class.  Now the thrusters and other ship animations are based on that class instead.  The below video demonstrates these animated elements (i.e. thrusters, pulsing glow), rotated animated elements (the reverse thrusters), and using rotation for animation (rotating gun turret).

I still have to add a lot of behavioral/state stuff to the ShipPart class.  Ideally I want to be able to define each ShipPart as contingent on whatever the ship is doing.  For example, moving, not moving, different directional movement, firing a weapon, selecting different weapons, etc.  The idea is to effectively "script" all of these parts to make a more dynamic ship both for the player and enemies.



Another video with more obvious demonstration of the rotating animated elements:



Also started working on the overall Level class.  All the background objects are now instances in that class, rather than the main game class.   Next up will be to start adding ability to script timed events to the Level class.  This will form the basis for the overall level scripting.

[shponglefan]

Couple things in this update.

First, I wrote the Ship status code to use enumerators (enum).  This allows me to use a single variable where each bit represents a different state.  For example:

Code: [Select]

        [Flags]
        public enum ShipStatus
        {
            None = 0,
            IsNotMoving = 1 << 0,
            IsMoving = 1 << 1,
            IsMovingUp = 1 << 2,
            IsMovingRight = 1 << 3,
            IsMovingDown = 1 << 4,
            IsMovingLeft = 1 << 5,
            IsFiring = 1 << 6,
            SelectedWeaponGroupOne = 1 << 7,
            SelectedWeaponGroupTwo = 1 << 8,
            SelectedWeaponGroupThree = 1 << 9,
            SelectedWeaponGroupFour = 1 << 10,
            SelectedWeaponGroupFive = 1 << 11,
            IsFullHealth = 1 << 12,
            IsHealthThreeQuarters = 1 << 13,
            IsHealthHalf = 1 << 14,
            IsHealthOneQuarter = 1 << 15,
            IsHitByProjectile = 1 << 16
        }
All I have to do is make sure I'm updating each state correctly in the Ship class and I can create any ShipPart, Weapon, etc, instance to activate or deactivate on whatever state I want.  It seems like an elegant solution to easily add whatever particular state I want to the Ship class.  For example, I could have boss ships that start showing damage animations as their health meter drops.  Or show different animations depending on which weapon is selected.

Second, added some basic enemies to test out multiple instances of ships and all the associated behaviors.  Initially, I discovered a ton of bugs, particularly around the way I was calculating (or in some cases not calculating) positional and angular information for each instance of the Ship, ShipPart and Weapon classes.  I fixed a lot of it, but it's made me realize my code is clumsy and things aren't encapsulated as well as they could be.  I'll need to go through it and start mapping out the logic of how all the instances of classes should pass data around.  The code needs a lot of streamlining and I'll need to tackle that before moving on to more complicated items like scripted enemy spawns, movement patterns and AI.

[shponglefan]

Started working on basic scripting for enemy movements.  Right now I've only implemented a couple patterns (straight down and a sine wave based one).  I'm going to start investing bezier curves to see if it's worth implementing more varied arcs, but for now things are quite simple.

Also added some collision detection; collision detection against the player works, but the player is invincible.  Enemies on the other hand, are not.

It's starting to look a bit more like a real video game:

[shponglefan]

After spending a good chunk of the day trying to get audio and music to work in MonoGame, I said "screw it" and migrated everything over to XNA 4.0.  In trying to develop under MonoGame I have run into a number of headaches, but this was one too many.  I may move back to MonoGame if I can figure out how to get audio and music to work properly, but in the meantime I will continue with XNA 4.0.

This video demonstrates music and sound effects, plus two different enemies.  The sound effects are a bit buggy, with multiple instances of the laser blast being triggered.  I've got to work on determining the best approach to handling audio code.  But at least it works reasonably well, which is more than I say for MonoGame.

[eds1275]

That art is great. The ships and stuff. Did you draw them? If so, can you give more deets on how you went about it?

[shponglefan]

That art is great. The ships and stuff. Did you draw them? If so, can you give more deets on how you went about it?

As much as I've love to take credit, I'm afraid most of the art used isn't mine. 

The sprite art was obtained from OpenGameArt.org.  It's a site for providing open-license artwork for use in games.

Space ship, thruster effects, and lasers: http://opengameart.org/content/space-ship-construction-kit
Explosion animation: http://opengameart.org/content/explosion-animations

The background drawing I got from some wallpaper site I can't remember.

I have done some art and modifications to the sprites myself.  For example, the pink laser blasts the player shoots are recolored thruster animations.   The transparent cloud and star layers I created myself; ditto with the glowing light animation on the back of the player ship.  All my modifications were done using Photoshop.

[eds1275]

So what's happened with this?

[shponglefan]

So what's happened with this?

I took a break from coding for a few weeks, but I'm back to chipping away at it.

Where I am at right now is trying to fix a bunch of poor design decisions.  When I initially started coding this, I wasn't too concerned with making it scriptable and ended up hardcoding a lot of things I shouldn't have.  So I have to pull apart a bunch of code and re-do a bunch of stuff (mainly to do with content management and entity management).

It's tedious which is also why I'm a bit less motivated at this stage.  But once I get over this hurdle, it will be back to the fun stuff.

[Howard_Casto]

It's very impressive man. 

I've got a question... how much overhead do you think adding some translucency would take?  I saw this photoshop tutorial and it was talking about how if you want an object to really look like it's inside an image (in this case the background) a good way to cheat is to make it just the tiniest bit translucent... I'm talking like 2 or 3 percent.  I tried it on something I was working on and I'll be damned if it didn't immediately look integrated into the background. 

[Slippyblade]

Refactoring code sucks.  Badly.  I feel your pain man, good luck.

[shponglefan]

It's very impressive man. 

I've got a question... how much overhead do you think adding some translucency would take?  I saw this photoshop tutorial and it was talking about how if you want an object to really look like it's inside an image (in this case the background) a good way to cheat is to make it just the tiniest bit translucent... I'm talking like 2 or 3 percent.  I tried it on something I was working on and I'll be damned if it didn't immediately look integrated into the background.

Thanks Howard!

Translucency is already built-in.  For example, the clouds that move by in the background are transparent sprites and are rendered accordingly in the game.

It's also possible to apply transparency to sprites that are not normally transparent.  So you could fade things in and out, or as you suggest, apply a little bit of translucency to an otherwise opaque sprite.

[shponglefan]

Refactoring code sucks.  Badly.  I feel your pain man, good luck.

Thanks Slippy!  I keep telling myself it's part of the learning process.