21 MAY 2022:

- In most shmups, the enemies spawn from the top or sides of the screen. While that will also be the case in Scrapship, I'm working on a mechanic where enemies can sometimes spawn from the background. So far it's working as planned. This will ultimately allow more variation in the AI.

- The shield fighters now have a new animation when they spawn.

Quote of the Week:

"You didn't come this far to only come this far."

Thanks for reading and have a great rest of your week!

28 MAY 2022:

- Shield fighters can spawn from the background now. There is also an animation of the shield forming.

- Enemies deactivate if the player scrolls too far in certain directions.

- The Threat bar increases when the player is firing their weapon, but cools down when the player is not firing. The idea is that if the player wants a little more challenge, they can become more of a threat by simply firing their weapon. If the player finds the game too hard, they can cease fire so the enemy will view them as less of a threat.

- I put in a fps counter. It starts to lag when it gets down to 40-50 frames per second. This is mostly when larger enemies are on screen, so I'll be working on a way to make the graphics more efficient so the frame rate remains steady.

Quote of the Week:

"Obstacles are those frightful things you see when you take your eyes off your goals." -- Henry Ford

Thanks for reading and have a great rest of your week!

4 JUN 2022:

This week was mostly about balance.

If you think about it, making a game is very similar to someone making a sword. You could have a blade that is extremely sharp, but if it's not balanced properly, the wielder is going to tire out fast. That is why balance is so important in game design as well as in sword-making. We've all played those games that go like this:

Level 1 -- Easy

Level 2 -- A little bit harder

Level 3 -- Suddenly very hard!

That's a sign of a very unbalanced game and I often find myself giving up on games that do that.

At the moment, there are parts of Scrapship that feel very unbalanced. To fix this, I've started rethinking the relationships between different objects in the game.

For example, the Carrier enemy is in the same "class" as the battleship, but has 3x more hit points and takes up twice as much of the screen. It is also over 3 times the file size (500k vs 130k).

To fix these inconsistencies, I've been plotting out in Excel how all the different game assets and objects relate to each other. If the screen size is X by Y, what should be the max size of a planet graphic in the background? If the max planet size is X by Y, what should be the max size of the final boss enemy? And so forth all the way down to the smallest enemy and even projectiles.

When I'm done mapping all this out, the result will be much greater balance and consistency across the board, resulting in a better play experience. It will also affect things like frame rate, because larger enemies take longer to load than smaller ones. A giant planet background may look cool, but can also bring the game to a crawl. And as I'm learning the hard way, it doesn't make much sense to have a 1940x1940 planet background that is only going to be on-screen for about 10 seconds before being scaled down or moved off-screen.

Much of this week was more about number-crunching than actual programming. How slow should a shield fighter move? How fast should a shield fighter move? At either of those speeds, how quickly should the player be able to destroy them? How much more powerful should weapon A be against weapon B? 

A lot of this sounds like it should have been thought about early on -- and you'd be right. But as I'm finding out, the problem with game design is that sometimes you don't know what you need to do until you see that your initial plans aren't working.

I still feel like Scrapship is on the right track and I'm not too worried about Scope Creep. The game is only going to have 5 levels and 5 main enemies. The challenging part is getting it all to mesh together in a way that makes sense and is fun.

Quote of the Week:

"If you want the rainbow, you have to tolerate the rain."

Thanks for reading and have a great rest of your week!

this cool devlog! i like this retro screenshots. And idea to make a game. latter- make it good looking. This is a thing to think for myself.

11 JUN 2022:

This week was mostly experiments and tests, but I got a lot out of it.

- To be consistent, I've decided to make all my image sizes a multiple of 8. Ideally, you want to have numbers that are nicely divisible (less math for the computer to do). You could work with an image size like 97x13, but it would be mathematically sloppy.

- Next up, the Battleship. Truth be told, I've never been completely satisfied with how the Battleship enemy has turned out. Below I'll do a quick review of its iterations:

This first one viewed from a top-down angle just looked plain ugly. Even now it's kinda hard to tell what it is.

The next version was bigger and the slightly angled view made it more obvious what it was. Guns not shown because they're a separate layer.

The final version I toyed around with this week will look something like this. Enemies in shmups shouldn't always have to be viewed from a top-down angle and I think this view makes it much more imposing and threatening -- like a Battleship should.

Whereas the previous version only had the 3 guns that could be targeted, the newer version will allow you to attack 4 segments. One for each of the guns, plus the Bridge. I've already tested this version in-game and it looks . . . AWESOME!

Quote of the Week:

"Don't set yourself on fire to keep others warm." -- Gamedev Unlocked             (<---- click here for video link)

It was a little shocking this week to hear that Gamedev Unlocked was going to stop doing Youtube videos. He's that rare indie game developer success story.

But burnout is a very real thing in any creative endeavor. 

As indie developers, we shouldn't be allowing this happen. For me at least, part of the whole allure of being an indie gamedev is being able to call the shots. Feel like working 10 hours in one sitting? Go for it. Only feel like doing 10 minutes? Do that too. Or even take the day off.

I'm blessed to say that I don't feel "burned out" with Scrapship. Sure, it's taking much much longer to finish than I expected, but I'm still having fun with it. I used to really pay attention to follower counts, downloads and other metrics, but I've recently stopped counting those things. If you want your performance to be measured, let me tell you, there are lots of 9-5 jobs that will gladly do that.

We're indie devs, and I hope that means to you what it means to me: We do our own thing and we do it because it's fun!

Thanks for reading and have a great rest of your week!

18 JUN 2022:

- This week I created a damaged satellite that you will encounter in Level 1. It's basically the tutorial "enemy" to allow the player to try different weapons and introduce them to the concept of collecting scrap.

- I started scripting out Level 1. A huge part of this is determining when and how the earth and moon appear. Those are definitely images  I do not want to be drawing at full scale when the screen is cluttered with enemies -- creates too much lag. In my tests so far, the game has been running over 60fps, which is what it should be.

- I'm satisfied with the new enemy sizes and tested all of them. Below is a little montage I put together in Powerpoint to give an idea of relative scale:


- Made some adjustments and bug fixes to the threat bar.


QUOTE OF THE WEEK:

"You are what you do, not what you say you'll do." -- Carl Jung

Thanks for reading and have a great rest of your week!

25 JUN 2022:

BEFORE

AFTER

Before I get knee-deep in coding again, I want to make sure that I'm absolutely happy with how the enemies look. The last one to need improvement was the Carrier. As you can see in the "BEFORE" picture, the original design has a lot of bright, highlighted sections that look cool, but don't make it obvious what their purpose is. Are the bright squares sections you can target? Where do the enemy fighters spawn from?

I started by seeing if I could get away with just making some slight modifications, but it quickly became apparent that would not be possible. I found that there were LOTS of vertices floating in space, disconnected planes and other chaotic geometry. To fix this, I deleted the "hull" section entirely and made heavy use of extrusion and insetting to get the new shape.

Colorwise, I felt it should be incredibly obvious where the enemy spaceships launch from. In the original version, I kinda arbitrarily picked a blue square and tried that out. As you can see now, the only highlighted sections are the hangar (glowing green) and the engines (glowing blue). All other colors have been toned down.

It felt really good to play around with Blender this week and I even learned some new techniques like push/pull. 

QUOTE OF THE WEEK:

"The wise man does at once what the fool does finally." -- Machiavelli

Thanks for reading and have a great rest of your week!

2 JULY 2020:

- This week I spent more time refining the AI. It is now set up so that there will be about 19 different attack orientations. I think that provides enough variety.

Shield fighters attack from 1 direction.

Bombers attack from 4 directions (originally only 2)

Cruisers also attack from 4 directions (originally only 1)

Battleships and Carriers each attack from 5 directions  (originally only 2)

- Experimenting with a new shield fighter design, in particular the shield itself. It's not quite where I'd like it to be just yet, but it is getting closer. 

ORIGINAL
EXPERIMENTAL

- I was invited to take part in the 3rd QBasic Game Jam but refused because, let's face it, I really need to finish Scrapship (this year hopefully) and that's not going to happen if I get sidetracked with other projects.

- I have all of next week off so I'm looking forward to getting a lot done!

QUOTE OF THE WEEK:

"Don't compare your Chapter One to someone else's Chapter Twenty."

Thanks for reading and have a great rest of your week!

9 JULY 2022:

- This week was all about graphics and animation!

- Has it ever happened to you where you play an old version of your game and think, "Hey! That feature was really cool! Why did I get rid of that?" That's basically  what happened with the Shield Fighter. In an earlier version, the shield would move back as it got hit. So I took to Blender and made some adjustments, resulting in the animation you see below.

Next, I turned to Embergen and experimented with some exhaust effects. There was only one problem -- Embergen can't render a transparent background.

A little frustrated by this, I next tried Aseprite because it does have support for rendering transparent backgrounds. But graphics in Aseprite are by their nature very pixelated, which I didn't really want for my game.

Finally, I turned to trusty ol' Blender and found a great (but dated) Youtube tutorial on how to make engine exhaust. But even here, I found that rendering against a transparent background was (seemingly) not possible. Thankfully I found a compositing node tree online that fixed the issue!

The shield fighter was the first to get the new exhaust animation, followed by the player ship.

It would have been nice to have bloom, but trying to render bloom against a transparent background is ridiculously complicated. This article I found here helps explain why. Basically, if your game engine or 3D program doesn't have proper alpha channel support, the best you can hope for is a post-processing type of workaround.

- Finally, I came across some VERY shocking news this week. As you all may know by now, I am developing this game in QB64, a very updated and modern version of the QBasic programming language. The website qb64.org has been EXTREMELY valuable in the forums and official documentation for learning how to use special commands and whatnot. But I recently noticed something: The website was always down whenever I tried to visit it. Thinking it was just server maintenance or something, I thought nothing of it, but then I finally got curious enough to ask on a QB64 discord server where I learned the horrifying truth:

CRAZY HUH? 

So before all this happened, people could upload snippets of code or even whole programs for others to try out. But because of the whole "ownership" issue and backlash, this one guy (who nobody really seems to know very well) just decided to nuke just about everything QB64 related.

So what does this mean for Scrapship? 

Ultimately, nothing. There is a historical backup of the original site that has all the documentation, but it now seems very unlikely that QB64 will be getting any more updates. That's fine, a lot of the new features that have rolled out I haven't been using anyways. All of the core commands and functionalities I need are still there. But it does give me strong reasons to consider switching to a game engine for my next game.

Quote of the Week:

"Don't be the one thing standing in your way."

Thanks for reading and have a great rest of your week!

16 JUL 2022:

- The above gif doesn't have all the frames of animation I would like due to the 3MB upload limit, but it gives you a pretty good idea of the state of the Shield Fighter. You can see the shield get damaged by the rapid laser, nullified by the single laser, and the ship stunned by the single laser before being destroyed by the scrap cannon.

- As shown, stunning an enemy deactivates their engines. 

- Not shown, the engines can be targeted individually.

- And then there was a bug that caused the screen to glitch out. After hours of searching and reading through log files, I found it was because an animation was starting at a frame that didn't even exist. But thankfully I got it fixed so I can move on!

QUOTE OF THE WEEK: (one I really need to listen to!)

"Strive for progress, not perfection." -- David Perlmutter

Thanks for reading and have a great rest of your week!

30 JUL 2022:

Before leaving for my business trip I was able to finish 2 more bombers. You can see the new damage animations on my latest Instagram post. 

It would have been easy to duplicate the damage states for all 4 bombers using Blender's mirror on x/y axis option, but instead I made it so that each bomber has unique damage states. 

As promised last week, here are my two cents on all the recent events surrounding the Unity game engine:

Unity is torn between 2 choices -- do they please the shareholders or do they please the users? At the end of the day, companies exist to make money, and this is especially true of Unity which exists on the stock market as Unity Software Inc. It's not mentioned as much as the Ironsource merger, but I was disappointed to hear that Unity scrapped further development of the Gigaya game demo. In a bit of irony, before I even knew what Gigaya was, I had thought to myself, "Wouldn't it be cool if a game engine had a comprehensive game project that showed off all the possibilities?" Needless to say, it's sad to hear of such a project get scrapped. 

There appear to be some nods to pleasing the users, like their acquisition of Weta Digital, but it also feels like they're trying too hard to compete with Unreal Engine's Metahuman. 

A common refrain I hear on Youtube videos is that Unity needs to fix what they have instead of adding features to it -- much like how Musk teases ideas of new projects when he hasn't even shipped a Cybertruck yet. 

As I'm sure you're all aware by this point, Scrapship is being programmed in QB64 -- no game engine here! But I am considering switching to a game engine for future projects. All this Unity news is certainly food for thought. But ultimately I have to agree with some of the more level-headed Youtubers when it comes to game engines -- game engines are just tools, and the best one is the one you are willing and able to work with. 

And speaking of game engines . . . 

Since I won't have any Scrapship development updates next week, stay tuned for my adventures in making a basic game engine in QB64!

QUOTE OF THE WEEK:

"Even if you are on the right track, you'll get run over if you just sit there." -- Will Rogers

Thanks for reading and have a great rest of your week!

6 AUG 2022:

One more week of my business trip and looking forward to getting back home and working on Scrapship!

In the meantime, I’ve been leveling up my QB64 skills:

The concept of Game Engines has been on my mind a lot recently, especially with the latest news about Unity and the amazing possibilities displayed by Unreal. 

Creating a game engine like any of those two — or even Godot — is way beyond my ability at the moment, but it got me to thinking . . . What if I made a very simple Text Adventure game engine in QB64?

Basically, it would have 2 main elements — Scenes and Choices. Scenes would be where you have your narrative, “You are in a dark forest at night.” And the Choices would link up to additional scenes. 

Creating this basic framework was pretty easy, but I quickly realized that I was missing a VERY critical element: The ability to save!

So I spent a few mornings learning how to save  data in QB64. 

Right now the program creates a temporary text file. Any inputs from the user are saved to this text file. If the user wants to save their progress, they specify a file name which renames the temporary text file.

Learning how to load data is the next item on my To-Do list.

In the context of Scrapship, this could come in very handy. Although I intend for Scrapship to be a short, one-session type of experience, the ability to save and load data would certainly allow me to do things like save user preferences.

In the context of my Text Adventure game engine, I’ll now have a way to save all the Scenes and Choices that have been created by the player so far.

Quote of the Week:

“Every man I meet is my superior in some way, and in that I learn from him.” — Ralph Waldo Emerson

Thanks for reading and have a great rest of your week!

13 AUGUST 2022:

Yesterday I got back from my business trip and turned a year older (42!)

It always feels a little weird coming back to your project after not working on it for so long, but it also feels nice to see it with "fresh eyes" and look at it in a different way. 

I've only had the one morning to work on it so far, so I focused on where I left off -- making the bomber bombs visible before they're launched. You can see above where I did a little experiment of how that might look. The ideas here are as follows:

1) Each bomber can hold up to 2 bombs. I think this gives the bombers sufficient ability to destroy the player without being too little or too much.

2) Because the bombs are visible as soon as the bomber is shown on-screen, the player has a better idea of what sort of threat it presents and how many potential threats (in the form of bombs) remain.

3) I originally made the bombs all black . . . but of course they were then invisible against the blackness of space. So I added a white border so they stand out. It looks a little cartoony this way, so I'll probably adjust the color scheme to make it look better.

QUOTE OF THE WEEK:

"Everyone must choose one of two pains: The pain of discipline or the pain of regret."

Thanks for reading and have a great rest of your week!

20 AUG 2022:

I ended up scrapping the idea of showing the bombs on the bomber. Yes, it would have been more realistic that way, but it would have also caused the following problems:

1) One of the bombs would have to be "closer" to the player than the other to look correct.

2) The bombs would have to be uniquely positioned on each one of the four types of bombers.

3) The bomber logic would be more complicated.

Instead, I thought of a color-coded system to warn the player of when the bombs would be dropped. Originally I was going to use Red, Yellow and Green. It worked, but I quickly found out that having so many colors was quite the distraction -- as soon as you see the color Yellow and start to realize that it means caution, it has already transitioned to Green meaning a bomb has been dropped. So I got rid of Yellow and now you have the Bomber you see above. Red when it is not dropping a bomb and Green when it is. Even Santa approves of this bomber!

I was hoping to get more done this week and then . . . BUG!

This one was really nasty and actually ended up being TWO BUGS that required video captures, log files and Notepad++ to finally figure it out.

1) The bombs wouldn't even draw to the screen!

2) The bombs would reset much earlier than they should.

The cause of the first bug was that I had an "EXIT FOR" command that ended a FOR-NEXT loop prematurely. So the code that needed to run to initialize some of the bomb variables was completely ignored. 

The cause of the second bug was that I had set the bombs to reset based on the status of the bomber and not the bomb itself.

So a lesson learned here is: Check to make sure your starting conditions are working properly. If not, then everything downstream is going to be affected.

But now that that's fixed, Scrapship now has bombers that attack from the 4 corners of the screen, provide a little bit of warning when they're about to attack, and all the bombers can be blown to pieces. Isn't that what we all want in life?

QUOTE OF THE WEEK:

"I GET to do this." -- Eva zu Beck

For the context behind this quote, see her Instagram post here.

As always, thanks for reading and have a great rest of your week!

27 AUG 2022:

Quite a bit of progress this week!

The cruisers now attack from 3 directions -- from the top, left and right.

The latest post on my Instagram is a video showing how that looks.

Next up -- the Battleship. I've never been completely satisfied with the Battleship design, for a couple of reasons:

- It looks too much like a  battleship and not a spaceship.

- Having 3 guns is cool, but trying to deconflict them as they rotate is a nightmare. 

- The engines on the battleship look disproportionate.

After lots of tests and experiments, I finally came up with a solution!

I chopped off the back end of the battleship and added the engines from the carrier. Not that I'm really going for realism, but it does make sense that if one were creating space battleships and carriers that they would probably use the same engine style for their capital ships. Below you can see a preview of the newly redesigned battleship:

This new design solves all of the problems I listed above. So now comes the tedious part . . . chopping up the battleship into unique segments and programming the logic for the 2 guns so they track the player properly. When this is done, the battleship can come at the player from 4 different directions (45 degrees, 135, 225 and 315).

I also found  a more efficient way to render my graphics. Previously, I was using color depth 16 at 100% compression, but have now found out that color depth 8 at 100% compression looks identical (as far as I can tell). The main upside of this is that graphics rendered at color depth 8 makes the render many times smaller in file size. This will come in handy as I'm aiming for an initial game load time of less than 10 seconds.

QUOTE OF THE WEEK:

"The ticket to victory often comes down to bringing your very best when you feel your worst." -- David Goggins

Thanks for reading and have a great rest of your week!

3 SEP 2022:

Because the battleship is much more complicated than other enemies in the game, planning often takes precedence over programming.

This week I tested the left half of the battleship which has the following features:

- The gun has 3 firing positions

- Each position has a firing indicator (green and red for firing and not firing state)

- Each position has a recoil state

- Each position has a stun state

Another challenge was trying to figure out how the player would damage the battleship. In some versions of Scrapship, the player was able to damage 11 unique segments. It looked cool, but wasn't very consistent and was overly complicated.

So although the guns are pretty complicated for the new battleship, the damage will be pretty straightforward: Only the guns on the battleship can be damaged. A shot anywhere else encounters a shield. However, the guns themselves can be destroyed fairly easily and when a gun is destroyed, that half of the ship gets destroyed as well. I do have some fears that this might make the battleship enemies too easy, but battleships will almost never be by themselves -- there will constantly be other enemies trying to destroy you or push you in a different direction. 

Hopefully by the end of next week I'll have a working battleship to show off, but for now I don't want to rush it.

QUOTE OF THE WEEK: 

"Great things never came from comfort zones."

Thanks for reading and have a great rest of your week!

10 SEP 2022:

- Scrap now rotates when it flies through space. I think this makes the game look much better!

- The scrap generated from destroyed enemies also rotates, relative to the direction it is going in. So scrap going left is going to spin counterclockwise and scrap going right is going to spin clockwise (as seen above).

- I recently discovered a new QB64 forum and saw that they even have a new version of QB64 . . . QB64PE (Phoenix Edition). As a result, Scrapship has now been migrated to this new version.

- In Embergen, I figured out how to get my exported images to look they way they do in the viewport. Embergen is the particle effect / explosion and fire software I use and it is very powerful.

- Finally, I learned A LOT about Sprite Sheets. See this link here for a thread I started here on Itch. This whole time I had been loading graphics in individually, which resulted in a load time of about 10 seconds when the game first starts. Clearly that's not acceptable.

Here's where sprite sheets come in handy: Let's say you have an animation sequence for an explosion that is 100 frames long and each image is 200x200 in size. All of this together, loaded individually, might take up 2.5 MB. However, if you pack all those explosions into a Sprite Sheet, it makes better use of the empty space and you get the same animation at a cost of only 1.5 MB! Now 1 MB doesn't sound like much at first, but when you have lots of graphics files and animation sequences, it can add up very fast. 

I downloaded this amazing program called TexturePacker that makes it easy to drag and drop your individual frames over and it can sort out your sprites in a variety of ways. Furthermore, it works with a variety of game engines and can even export the files that tell you the x and y coordinates of each sprite. Here's a quick sample of some JSON data:

But QB64 is not a game engine. Fortunately, I was able to get some help from the people at the QB64 forums and they clued me in as to how to use code to implement sprite sheets.

QUOTE OF THE WEEK:

"Never apologize for having high standards."

Thanks for reading and have a great rest of your week!

17 SEP 2022:

It’s funny how this always happens. I have one week of lots of progress followed by another with practically none. 

Before I left for my business trip, I was able to do some tests with sprite sheets  as applied to loading times. So below I’ll recap some of my observations on the different ways of loading graphics into your game.

1) LOADING INDIVIDUAL IMAGES

PROS:  Makes it very easy to change individual graphics files without tampering with the rest of them.

CONS: Doesn’t make good use of physical space, resulting in longer loading times.

2) LOADING A SPRITE SHEET

PROS: Makes better use of physical space. Only loading one .png instead of dozens (or more) individual images. Faster loading times.

CONS: Sprites need to be referenced based on their location on the sprite sheet. This may not be an issue if you’re using a game engine, but it’s more complicated if you’re using code. It also gets more complicated if the sprites have different sizes. 

3) LOADING A SPRITE SHEET . . . AND THEN LOADING THE INDIVIDUAL SPRITES INTO AN ARRAY

PROS: By placing the sprites into an array you can more easily control when an animation starts and where it ends, even allowing for an animation to play backwards. 

CONS: Although convenient, this also increases load times because you’re essentially loading all the graphics twice — once for the entire sprite sheet and then again for each sprite individually. 

For Scrapship, I’ll probably be using option 2, although there may be a few cases (e.g. animated explosions) where I might want to use option 3. 

Finally, I’m not sure exactly how QB64 differs from QB64PE, but I noticed that QB64PE consistently loads Scrapship in about 5 seconds, so that’s a huge improvement in load time without even converting all my individual images to sprite sheets!

QUOTE OF THE WEEK:

“Your time is limited, so don’t waste it living someone else’s life.” — Steve Jobs

Thanks for reading and have a great rest of your week!