Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 04:03:01 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsStorm Carrier - Vertical 2D shmup with physics
Pages: [1] 2
Print
Author Topic: Storm Carrier - Vertical 2D shmup with physics  (Read 5930 times)
eaxs
Level 0
**


View Profile
« on: November 12, 2014, 05:24:20 PM »

Hello everyone!

I've been working on this game with a friend for a while now and I thought I'd share our progress and thoughts with you from here on out. So here goes...


Setting and story
The game takes place in a not so distant future in which the world is dominated by private military companies. These companies like to anonymously hire outsiders for high-risk missions such as espionage and sabotage.
You and your team on such a mission: Highjack a Battleship prototype called "Storm Carrier" from the Crimson Talons and bring it to the extraction point. Upon capturing the vessel and after short inspection, the crew is unable to bring the main weapon systems online and is forced to improvise. Fortunately, the battleship holds a small attack aircraft and you are tasked to clear the way ahead until you reach the extraction point.


Concept Art - Crimson Talons desert hideout.


Game mechanics
In most shoot'em ups, enemies follow a pre-defined flight pattern or path. And once you shoot them, they explode and nothing else happens. In Storm Carrier you can throw enemies off course to make them crash into each other and eventually create a chain reaction with multiple collisions.


Slow-motion explosion shockwave collisions


Ship destruction
Enemy ships, as well as the player ship do not simply explode upon death. Instead, they go through different stages of destruction. Each ship has a set of armor which must be destroyed first, before you can damage the ship itself.


Crimson Talon "Kite", with and without armor parts.

Once the ship is destroyed, it gets out of control for a short time before it finally falls to the ground and explodes. However, if you deal enough damage, the ship can explode while still flying. The explosion causes a shockwave which pushes adjacent ships aside. The effect occurs for all types and sources of explosions, like rockets for example.


Weapons and upgrades
There are 4 weapon and upgrade categories available and you can equip one of each at a time. So you can have 8 items equipped in total. I am currently revising the weapon systems and there's just one weapon in the game right now, so for now here's a short summary of the categories:

  • Primary weapons - Your primary attack which you'll use most of the time. Mostly consists of Gatling-type weaponry.
  • Support weapons - Automatically used in conjuction with the primary system for that extra pew-pew-power! Consisting mostly of energy based weapons.
  • Secondary weapons - Your second attack. Best used against heavily armored enemies, or enemies in close proximity. Contains weapons that go boom.
  • Automated weapons - For lazy people, these weapons aim and shoot on their own.
  • Shields - Absorbs incoming damage until it runs out of energy.
  • Armor - Absorbs damage until it is destroyed when the shield is down. Armor also alters the top speed of the ship. Heavier armor slows you down!
  • Energy reactors - Provides energy for weapons and shields.
  • Sub-systems - Mostly provides a passive stat bonus. But sometimes can alter game mechanics, weapon functionality.


Game progression
You start the game inside the battleship prototype where you can buy and sell equipment, or have a little chat with your crew members. When you're ready for your flight, you can leave the battleship and initiate the next combat stage of the game. At the end of the stage you return to the battleship and your progress is automatically saved. But if you die during combat, your progress is lost and you have to start all over again (meaning your progress is wiped). However you get to keep special items that you will find during gameplay - see below.


Item drops
Sometimes, enemies leave item crates behind when they are destroyed, which you can then collect open after completing a stage. Each crate contains a piece of equipment that you can either use or sell for cash. Items come in 3 flavors:

  • Bulk - A "normal" item that can be also be bought through the store in the battleship.
  • Modified - Based on a regular item, but is configured differently. For example: higher fire rate, but lower damage. These items can only be found, never bought.
  • Prototype - Items with unique stats and abilities. Like modified weapons, prototypes can only be found in item crates. And on top of that you get to keep them if you die.

I want to point out here that all items will be created manually. There's no random generator rolling the stats and abilities. The only thing that's random (to an extent) is which items come out of the crates.
Each item has an internal "level" value which correlates with the stage in which the crate was picked up. So you can't find high level items in early stages.


There is a lot more to tell and to show, but this should be enough to get this devlog rolling and hopefully pique your interest.

Thanks for reading and commenting  Gentleman
Logged

Howard Day
Level 1
*


Huge fan of spaceships and exposions.


View Profile WWW
« Reply #1 on: November 12, 2014, 07:42:20 PM »

Oh, it looks great! I love the idea of being able to blast the armor off ships, that's very cool. I also love the mid-air/space collision domino effect. I have ever since I saw the original Star Wars. :D So, you've got great ship designs and great gameplay ideas... what's missing is great explosions. Right now your explosions are... anemic at best. You really need to look towards other successful shmups, like Raptor or Dodonpachi - Really overplay the explosions. If you're interested, I have some left over from a previous project, that I never used - or I could point you in the direction of good references!
I can't wait to see more!
« Last Edit: November 12, 2014, 09:20:59 PM by Howard Day » Logged

Main Art guy on Wings of St Nazaire, here's our Devlog, and my Personal Website. SPACESHIP!
Music Vortex
Level 1
*



View Profile WWW
« Reply #2 on: November 12, 2014, 11:19:23 PM »

Already interested in this game. Throwing enemies off course and making them crash into each other is a great idea.
Which platforms are aiming for?
Looking forward to seeing more!
Logged

Jose Mora-Jimenez - Composer
Website | Soundcloud|
Twitter
eaxs
Level 0
**


View Profile
« Reply #3 on: November 13, 2014, 04:58:21 AM »

@Howard Day
Raptor is my favorite shmup and a big inspiration for the overall art style. The explosions aren't so great because...I made them Panda My buddy deals with most of the graphics and so far he focused ship designs and environment. I'll gladly check out your left over images. Maybe they fit right in, or serve as an improved placeholder  Tongue

@Music Vortex
Windows primarily. We're using Game Maker:Studio, so it could be ported to just about any platform.
Logged

eaxs
Level 0
**


View Profile
« Reply #4 on: November 14, 2014, 06:35:40 AM »

Log entry #001

I am currently in the process of cleaning up the code for the weapons. The old code was functional but limited in what you could do and a convoluted mess. All the logic was stuffed into a single weapon object which would cover all the functionalities. I've now dissected the logic and distributed it over multiple game objects. This is how it currently looks on a technical level:

Weapon controller - There is 1 for each weapon category
  • Checks for user input
  • If the player wants to fire, check if the weapons are ready to do so and not on cooldown
  • Check if the reactor has enough power left, then take away the power needed to fire
  • Tell the weapons to fire

Weapons
  • If the autoaim flag is set, find and aim at a target
  • If the weapon is told to fire, relay the signal to the weapon muzzles
  • Repeat the above for x number of bursts or go into cooldown

Muzzles
  • If a signal to fire is received, start the muzzle flash animation
  • Fire x number of bullets at end of animation (default setting. The anim controls when the bullet should appear)

I think that's a clean approach to the overall weapon logic.
Here are some weapon test configurations I made to see if everything works as intended:

Standard full-auto at 600RPM


3x Burst fire


Full Auto with 6 bullets per shot. High spread, low accuracy


3x Burst with 3 bullets per shot.High spread, low accuracy


Auto aiming and firing



There are are some other things I'd like to incorporate, like alternate firing between the 2 weapons, bullet flight stability, heat seeking abilities etc.
Logged

eaxs
Level 0
**


View Profile
« Reply #5 on: November 16, 2014, 09:53:51 AM »

Log entry #002

Got the rockets back in the game - including splash damage, alternate firing, heatseeking and flight stability factors. The trail effect is probably not going to stay like this. But it'll do for now.




Playing around with the flight stability settings of the rockets gives some pretty interesting results. There are basically 3 variables which determine the flight vector of a bullet:
  • Chance to change direction
  • Agility - how many degrees the bullet can turn at a time
  • Limit - Maximum overall deviation from the original flight vector in degrees

Evil
Outraged
Lips Sealed



And finally, alternate firing and heat seeking rockets:

Logged

eaxs
Level 0
**


View Profile
« Reply #6 on: November 23, 2014, 07:13:16 AM »

Log entry #003

The game is in development for a little more than a year now. A lot of that time was spent prototyping features and building the necessary development tools, including our own level editor. Creating our levels with the Game Maker:Studio editor was out of the question right from start for a number of reasons.

The main issue being the size of our levels, ranging from 32x280 (8960 tiles) to 32x392 (12544 tiles) per layer! With no bucket fill, brush size or even auto-tile tools available, it would take a lifetime to create a single level.

So i went out and tried various replacement editors, but none of them had what we needed, or the implementation was too cumbersome. I then started fooling around by making levels through bitmap images, where each colored pixel represented a different background tile or object in the game. While that approach basically worked, it was still too limited. It was impossible to assign waypoints to enemies or to rotate props (try rotating a pixel...).

Ultimately I had no other choice but to create our own. The editor was created entirely with Game Maker and is built right into the game. If I can get myself to polish it up, I'll leave it in there for people to create their own levels. Here is what it can do:


Tools and options

  • Toggle Minimap
  • Save
  • Save & Play from start
  • Save & Play starting at current location
  • Quit
  • Terrain tool
  • Enemies tool
  • Waypoints tool
  • Props tool
  • Toggle tool options


In Action

Placing terrain


Placing enemies

Placing waypoints

Placing props

New Feature - Spawn groups
I keep making adjustments and adding tools as the game evolves, so the editor isn't done just yet. A new feature I added this week was the ability to create "spawn groups", so that a cluster of enemies can spawn at the same time. Without this feature, enemies appear as soon as the top of the screen would "touch" the enemy, which breaks their formation:

Editor
In-game

As you can see, by the time the screen has reached
the upper row of enemies, the bottom row already spawned
and traveled some distance.




With the spawn groups - notice the purple rectangle - the result matches the formation placed in the editor:

Editor
In-game

Let me know if you have any question or comments, thanks!
Logged

The Translocator
Level 2
**


View Profile
« Reply #7 on: November 23, 2014, 12:03:26 PM »

When you said physics, I thought you meant that the ships fall down the screen because of gravity when you kill them and you use that fact to create combos of ships caused by vertically falling ships.

That would make a great puzzle game. This looks more action oriented, but still interesting. The missiles especially look really cool.  Hand Thumbs Up Left
Logged

eaxs
Level 0
**


View Profile
« Reply #8 on: November 24, 2014, 06:42:54 AM »

The ships do "fall", but not down the screen. It's more like sinking to the ground, because of the top-down view.
If this was a side-scroller, then they'd fall down the screen. I hope that makes sense  Smiley
Logged

eaxs
Level 0
**


View Profile
« Reply #9 on: November 25, 2014, 04:22:24 AM »

Log entry #004

Yesterday I've been working on the heightmap generation system. Basically I want the player to get a feel for the depth of the terrain, instead of traversing just a flat surface. Here's what I got so far:



I'm using a grid data structure where each cell/point holds a height value. Flying entities check their current position on the grid and adjust their size based on the value of the cell. The transitions in the gif look a bit choppy, due to skipped frames. In reality, the transition is really smooth using linear interpolation between the previous and the new height.

Maybe I'll go a step further and turn this into a polygon mesh and do something like displacement mapping... Though I have to be careful not to lose the retro-aesthetic in the process. I guess I'll just have to experiment with various techniques to find out what works and looks best.


Besides the heightmap, I've started adding more weapon, projectile and armor assets. They've been collecting dust for a couple of months at least because a lot of the code wasn't ready until now. I'll show some of the more interesting designs soon  Blink
Logged

The Translocator
Level 2
**


View Profile
« Reply #10 on: November 26, 2014, 06:02:35 PM »

The ships do "fall", but not down the screen. It's more like sinking to the ground, because of the top-down view.
If this was a side-scroller, then they'd fall down the screen. I hope that makes sense  Smiley
No, I know why they act the way they do, I just expected another "pseudo-puzzle game with a gimmick" like everyone makes. Instead I found a well-made action game. Keep up the good work.
Logged

eaxs
Level 0
**


View Profile
« Reply #11 on: December 01, 2014, 12:37:32 AM »

Hey thanks  Smiley This is definitely not a puzzle game. Though the domino effect kind of reminds me of games like "Bejeweled"...

I've taken the last 4 days off to celebrate my birthday and I've noticed a certain pressure building up inside of me, like something's telling me that I need to get back to work and update the devlog. It's very unusual for me not to work on anything at all, so it feels good to work again to vent the pressure.
Logged

eaxs
Level 0
**


View Profile
« Reply #12 on: December 02, 2014, 02:08:06 AM »

Log entry #005

I've decided to update to the new 1.4 stable release of Game Maker:Studio....what a mess. At first everything seemed to work alright, but when I tried to make a build of the game, it failed and the compiler kept crashing with an error. Said something about a missing file... Turned out I had to re-evaluate my license key to get it back working. If you have the same issue - try doing that.

More annoyingly is that whenever I add a new resource, the resource tree goes totally out of control and loops through all resources. God knows what's up with that. I just know that it's a hit on my productivity because I have to wait about 2 seconds before it's done doing that. Hopfully that will be fixed soon.



Now back to the actual game. I've added 2 sets of armor, 4 weapon models and a new bullet model. The player ship you've seen so far was without any armor on it (first on the left).


Weapons:


And some quick action with the new bullet:
Logged

eaxs
Level 0
**


View Profile
« Reply #13 on: December 09, 2014, 07:57:21 AM »

Log entry #006

Last week I was trying to solve an issue which bothered me since the beginning: Resolution scaling.
Storm Carrier has a "native" resolution of 1280x720px. Obviously most monitors don't use this resolution or have a different aspect ratio, but the game should look and play great on any display.

The first step is to crop the visible game area to match the aspect ratio of the display. I've decided to keep a fixed height and crop the width accordingly. So for example, if your display resolution is 1024x768 (4:3), the game will look something like this:


(1024 / 768) * 720 = 960px


That was the easy part. The game can now be displayed in a 960x720 window without letter- or pillarboxing, on a 1024x768 display. But what happens if you go into fullscreen?

For this I'll provide another, simpler scenario. Let's assume you have a display of 1920x1080. The game runs natively at 1280x720. Both resolutions have the same aspect ratio, 16:9.



So in theory, I can just scale up the game to run at 1920x1080 without any problems because it's the same aspect ratio, right?
...wrong Sad
To resize the 720p image to 1080p means that every pixel needs to be magnified by a factor of 1.5 (1920/1280 = 1.5 and 1080/720 = 1.5).

This has the effect of pixel doubling and other weird stuff:

Click to see the full image


To solve this, I rounded up the game resolution to the next integer (2 in this case) to get rid of the fraction, and then downscale it again to 1080p with bilinear filtering:

Up from 1280x720 to 2560x1440
Down from 2560x1440 to 1920x1080


A pretty ham fisted approach, but I couldn't find any better solution for it.
For a comparison, you can click on the images below:

1:1 Windowed
Simple upscale from 720 to 1080
Downscale from 1440 to 1080

I know some games simply don't bother with any of this and force a letter- or pillarbox on you, but I personally can't stand it. And changing the projection to match the display resolution isn't really an option because it would lead to all sort of other issues, like what happens if the display resolution exceeds the size of the level?
Perhaps I'm overcomplicating things here, I don't know... If you have any ideas on how to improve this, please let me know  Coffee
Logged

EdFarage
Level 2
**


I can upload avatars


View Profile
« Reply #14 on: December 09, 2014, 08:01:31 AM »

Pixel Art is really tricky when it comes to scaling, i think that the last resort would be to simply ignore "bad pixels" and set a few standard resolutions, just like in old games.
This looks awesome by the way, good job!
Logged
eaxs
Level 0
**


View Profile
« Reply #15 on: December 09, 2014, 08:21:02 AM »

Hey thanks!

I keep believing that there's a magic trick to this and that I'm just doing it wrong  Undecided
But you're right - least I can do is to provide configuration options to the players.
Logged

eaxs
Level 0
**


View Profile
« Reply #16 on: December 23, 2014, 09:47:05 AM »

Log entry #007

Things have slowed down a bit since the last time I've posted due to christmas holidays/preparations. So I've decided it would be a good time to look through the things that are currently in place and do some optimizations and code refactoring.

This is what I like the most about programming, where get to sit down with a cup of coffee and some nice music to polish bits and pieces of code. I find it exciting and relaxing and the same time, because the end result often feels "solid" and coherent, rather than cobbled together.


One thing I've looked at was the general code architecture. Until recently, I had about 1200 script files for the entire game which became increasingly difficult to manage. This was because every game object event handler would call a script, rather than execute code directly in the event handler. I did this to avoid code framentation - some loose code in the objects, and other in scripts. In pseudo-code this could look like this:

Code:
class obj_player_ship
{
function event_create()
{
PlayerShipEventCreate();
}
}

Calling event_create() would then call script PlayerShipEventCreate(), which creates an unnecessary overhead. So I removed those scripts and transfered the code to run directly in the handler, like this:

Code:
class obj_player_ship
{
function event_create()
{
$hull_hitpoints = 100;
$shield_hitpoints = 100;
$energy = 100;
...
}
}


Micro-optimizations, d'uh! Is what you might think. Which is true in part. On the other hand, it helped reduce the number of script files I will have to maintain in the future, which was the main reason for switching to the new architecture. Also, it is possible that this approach is more efficient to compile in some cases. I have not done any isolated benchmarks and there is 0 documentation on how to optimize code for the YoYo compiler. But I did notice the performance increase for events that run constantly.


Which brings me to the next optimization. I've done away with code running in the main game loop, specifically the step events. The problem with those events is that they can't be stopped or taken out of the loop. For example if I wanted to pause parts of the game, I couldn't. So I've replicated the step events using alarms. Alarms are basically timed script calls. There are 12 alarm handlers built into every object, and I use them like this:

  • alarm 1  - Step begin replacement
  • alarm 10 - Step main replacement
  • alarm 11 - Step end replacement

This approach allows me to pause, stop or "slow down" parts of the game, by saying something like "Alarm 10 should be triggered every 2nd loop". So this also make it somewhat possible to separate the code logic from the renderer. Most of the code logic now runs at 30FPS or fewer, while the renderer still produces 60 images per second. Obviously, this resulted in a huge performance boost.


Right now - and for the rest of the year - I'm looking to get rid of most global variables. Specifically the ones that hold a lot of data.
When the game starts, it loads things like item information into global variables to make them available at any given time. A lot of this data is only needed in certain areas of the game though, so I'm trying to create self-contained data objects which load and unload data when necessary.


That's all for this year. Have a great christmas holiday and until next year!  Wizard
Logged

eaxs
Level 0
**


View Profile
« Reply #17 on: January 13, 2015, 02:03:11 AM »

Log entry #008

Holidays are over and we're back to work. Here's to a productive year 2015!  Beer!
A couple of things have happened since the last update. Most notably, the first level of the game is now in a playable state, Yay! I've also started adding sounds back into the game, though most of them are placeholders that will need to be updated later down the road.

My buddy is working on adding more terrain tilesets and updating the contrast/colors. Here's a mockup of how it will end up looking (reminds me of a detergent ad):


Logged

eaxs
Level 0
**


View Profile
« Reply #18 on: January 20, 2015, 06:31:01 AM »

Log entry #009

All the tile sets have been adjusted and are in the game. It was definitely a visual upgrade from the previously washed out colors.

While I was designing the first level, I noticed that it was much to wide. I initially thought that having more room to navigate would be a good design decision, because all shoot em ups confine the player to stay within the boundaries of the view space.  It always made me feel uncomfortable, like sitting next to a smelly person in an airplane with no chance to escape.

So while I was setting up the enemies and their movements, I noticed that it was nearly impossible to cover so much ground to force the player into a tight spot. That's when I realized that this wasn't a technical limitation of the old days, but rather a concious design decision. It seems so obvious now, but when you're in the middle of it, it can be hard to see.

So I've narrowed down the level quite a bit, from 1792px to 1472px wide. Considering that the view is 1280px wide, there is still a little bit of room you can navigate to the left and right, but not much. Maybe I come back to tweak it some more later.

Another thing I worked on is the localization system - being able to play the game in different languages.
I've set up a mysql table for each language, holding key/value pairs. So the result is something like this:

KeyValue
NEW_GAMENew Game

I can then export the data to JSON, and from there into my own binary file format, readable by the game.
I could have left the data in JSON format, but Game Maker is super slow at reading it, so yeah...

Now I have to sift through the UI code and replace the hard coded strings  Huh?
Logged

eaxs
Level 0
**


View Profile
« Reply #19 on: February 02, 2015, 08:07:12 AM »

Log entry #010

Code development has nearly come to a halt as I've had an unfortunate accident with my right hand. My middle finger got caught in a closing car door. I couldn't use my hand for a week because of internal bleeding. But it's getting better now, to a point where I can write again (without using the middle finger). It's not exactly efficient, but I can't stand sitting around any longer. So I will resume work now as best as I can. I think this is the worst thing that's going to happen to me this year. Glad I got it out of the way so early.

In other news, I'm happy to announce that Joseph Elliott will be doing the music for the game. Maybe he'll share some of his thoughts and work in progress later on.

That's all for this time. And remember, watch where you put your mitts  Bro Fist Left Bro Fist Right
Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic