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!

24 SEP 2022:

- The first of four battleships is now implemented in the game. The logic needs adjusting and the projectile animations need some work, but so far it's looking the way I'd like. 

- I've mentioned before that .png files are often larger than their .jpg counterparts. But this week I came across a cool website called TinyPNG that does an AWESOME job of compressing png files! How awesome? Check this out!

Both images have the same dimensions and are both .png files. But the original one on the LEFT is 373KB and the one on the RIGHT (which was compressed using TinyPNG) is only 44.2 KB!!! 

373 / 44 = ~8

8 TIMES SMALLER but still looks about the same!

With that being said, I noticed that when you compress some png images, the picture quality GOES DOWN. 

The one on the left is the original and you can see how the shades of green transition much more smoothly than . . . .

. . . the one on the right which is a compressed PNG but has noticeable rings around the shades of green.

QUOTE OF THE WEEK:

"The best view comes after the hardest climb."

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

1 OCT 2022:

- The new battleship is turning out nicely! I'm confident it'll be much better than any of the previous iterations.

- I did have to fix one thing this week though. Originally I was only going to have the battleship turrets move in 3 directions. The problem here was there was an angle of about 90 degrees between each position. So when the player was directly beneath the turret, the gun wasn't even pointed at the player. Major blind spot! So after some testing I decided on a 7-position turret which tracks the player along a 270 degree arc, with 45 degrees of separation between each position.

- I also made a new graphic for the battleship projectile:

This fixes 3 problems:

1. Because it's a round projectile, I don' t have to worry about rotating images to match the angle of the guns. 
2. The round design makes it more obvious if the player takes a hit. 
3. The smaller image size (currently 64x64) is much smaller than the original projectile graphics which were a bulky512x512.

- It's getting closer to the end of the year, so I thought I'd map out a little chart for how I'm going to finish this game:

• Battleships
• Carriers
• AI
• The levels (and any bosses in them)
• Final polish, consistency checking, bug-testing, etc. 
• Release the Game!
 

QUOTE OF THE WEEK:

"The day you plant the seed is not the day you eat the fruit." -- Fabienne Fredrickson

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

8 OCT 2022:

- This week I used Blender to model the guns when they're destroyed.

There's also a model for when the front gun is destroyed. Next on my to-do ilst is a model for when both are destroyed (which destroys the entire battleship).
Want to learn a cool Blender trick?
If you are trying to deform your models, go into EDIT mode, select the FACES icon and then highlight an individual face.
Then right-click and select either SUBDIVIDE or TRIANGULATE FACES. These will give you more edges and vertices to work with, as well as create shapes within the original face.
Then you can select the smaller faces you want to manipulate and use things like rotate and move to give your model a nice contorted and destroyed look.
It's also helpful to subdivide your EDGES too so you have more vertices to play with.
But if you do this, make sure to make a copy of your original model so you can go back in case you mess up.

- In Embergen, I learned how to make a much improved projectile for the battleship:


Much better! I found out how to get the background shape to render so that's how I was able to get the nice "flaming cannonball" look to it.

- The new projectile graphic has been implemented in the game.
- The aft and forward guns now animate independently of each other.

QUOTE OF THE WEEK:
"Make friends who force you to level up."

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

15 OCT 2022:

- Growing up, one my favorite arcade games was the shmup RAIDEN. I remember it had some really impressive explosions when you dropped bombs or destroyed enemies. So I really wanted to capture that same feeling with Scrapship. Embergen software  can really create some fantastic explosion effects once you start learning how to build nodes properly and what sliders need adjusting. For the explosion in the gif above, I used a "burst" emitter and then played around with . . . a TON of different settings until I got something that looked cool. It's a lot of trial and error . . . but totally worth it!

Some of the Embergen settings -- that you're probably not going to see in many other explosion effects programs -- pertain to temperature and extinction. You can actually adjust the temperature at which flames turn to smoke. This is critical when you're trying to ensure smoke generates in a short timeframe. It's the smoke that also gives the nice contrast to the rest of the explosion. Flames just by themselves look a bit boring. Below are some of the sliders I'm talking about.

- As you can also see, I "destroyed" the battleship in Blender, so that now you can see it broken apart.

- I also made some minor changes to how the battleship is rendered. Instead of rendering a base layer and overlaying the guns, the battleship now has a top half and a bottom half, which makes it easier to swap out which variations (like if a gun gets destroyed). 

- Battleship 45 (I call it this because it's the one that faces at a 45 degree angle) is pretty much done. Last thing I need to do before moving onto the others is making sure the guns fire at the right angle because they're still off just enough to be noticeable.

QUOTE OF THE WEEK:

"Never discourage anyone who continually makes progress, no matter how slow." -- Plato

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

22 OCT 2022:

- The battleship guns now track and fire simultaneously. Looks much better this way! The guns even track the player if you try to fly around the battleship.

- I fixed an issue where the explosions weren't drawing correctly, relative to the battleship.

- Started working on the collision detection with the battleship. (I might come back to this later). The diagonal orientation of the battleship is going to make it tricky to design logical square hit boxes.

QUOTE OF THE WEEK:

"Great things are done by a series of small things brought together." -- Vincent van Gogh

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

29 OCT 2022:

- Battleships 45 and 135 are DONE! 

- Started working on Battleship 225 (the third of four battleships).

- As I planned, development of the battleships is much faster now that I already have the first one already finished. I can do a lot of copy and pasting of code and even graphics.

- While the basic battleship design is the same, each of the four are drawn at a different angle and each will have their own unique animations when destroyed in part or in whole.

QUOTE OF THE WEEK:

"It is better to fail in originality than to succeed in imitation." -- Herman Melville

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

12 NOV 2022:

- All 4 Battleships are DONE!  -- Minus some very minor adjustments.

- I also added a subtle flickering effect to the below-deck fires on the Battleships. I'm a strong believer that small attentions to detail can go a long way.

- With all that done, I started on the first of the four Carriers. The "Left Carrier" spawn point is set and can move across the screen. Animating these larger enemies can be a huge chore, so to minimize that -- and to prevent scope creep to some degree -- I've decided that the only target on the Carrier will be the hangar bay as shown above. To make it more interesting and appear as if your bullets are actually detonating inside the Carrier, I used point lights in Blender to give a nice internal explosion effect. It actually turned out much better than I planned! 

- The Carrier Fighters can use some work -- they don't follow the player as well as I would like them to. If the player is too far away they're not even a threat.

- Unlike the Battleships, the Carriers will be a little more unique, especially the ones that face DOWN or UP. 

- A lot of the enemies in Scrapship have very complicated shapes. This makes collisions between enemies and the player very tricky. If the player collides with an enemy, it absolutely has to look like it did -- otherwise the player will cry foul and say that was a very cheap death (and I would agree). This got me to thinking about how other shmups handle collisions with enemies. At the moment I'm considering getting rid of collisions between the player ship and enemy ships entirely. For one, this simplifies things because the game is not having to process  complicated hitbox coordinates. It also gives the player a little more freedom to fly around. Finally, this means that the only objects the player will have to be wary of are projectiles that are obviously projectiles that can hurt you. So if you hit a bomb or a laser, then you probably died fair and square.

QUOTE OF THE WEEK:

"More is lost by indecision than by wrong decision." -- Cicero

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

19 NOV 2022:

- The carrier now has flickering exhaust coming out the back. It's a little hard to see because of the fps limitations of the GIF, but it's there.

- The player can also shut down the engine by shooting the "single laser" at the engine block. It's currently not very evident that this is possible, so I'm looking at ways to change that. 

- When the carrier takes  a certain amount of damage, it accelerates off screen (no point staying around to get blown up!)

- Still working on the carrier fighters. I've tried several variations of movement for them. They need to be aggressive, but not TOO aggressive. The player needs at least a little time to react. 

- I also got a placeholder explosion animation for when the carrier is destroyed. It's literally the same as for the battleship, but closer to the end of development I'll be making more unique explosions in Embergen. In anticipation of this, I went ahead and purchased the full (but discounted) version of TexturePacker which is an incredibly intuitive sprite sheet tool. (Not affiliated with either company, but I do like their products).

- A long time ago I implemented the Threat Level and Morale Level bars. You can see the Threat Level bar in action above. It increases when you are actively engaging enemies because you're more of a threat. Conversely it decreases when you're not firing. Higher Threat Levels will allow for the spawning of more difficult enemies.

- It's been over 2 years since I started Scrapship. Sometimes development has been very tedious and frustrating, but one thing that has always helped keep me going are the VIEW COUNTS by people like you.

Scrapship still averages about 1 view per week . . . even though I don't really do much in the way of marketing and there hasn't been a playable version for quite a while now. The view count for this devlog is nearing 10,000 views, which I find incredible.

So here's a big THANK YOU to everyone who has ever read this devlog or played any of the early demos!

QUOTE OF THE WEEK:

"Everyone wants some magic pill -- some life hack -- that eliminates the need to do the work. But that does not exist." -- Jocko Willink

Thanks for reading and (for those in the US) have a HAPPY THANKSGIVING and a great rest of your week!

3 DEC 2022:

- The last of the 4 carriers is done! This is pretty big news because it means from here on out I'll mostly be working on things that I haven't worked on before.

- I simplified and fixed the volume levels for sound effects, music and audio.

- Organized a lot of the variable declarations, making the code much more readable.

- On game exit, it  now properly frees up a lot of the image assets to prevent memory leaks.

ROADMAP:

There are basically 3 main areas I need to complete before I can call Scrapship done.

1) GAME LEVELS

Although the game currently has its 5 levels, most of them are very empty at the moment. So I'll be working on fleshing those out. There are only 5 levels because I only have 5 tracks of music.  But to offset this, I have my AI system which will ensure "random" encounters each and every playthrough. In addition to this, I'm planning on implementing a system where the levels themselves have a bit of randomness to them. Space can be a very empty and boring place, so I'd like to make sure that there is enough "stuff" on-screen to keep things interesting.

2) SCALING 

Right now the game only works at one resolution. I had different resolutions working before, but that was before I branched off to the new version. It's one of those things that shouldn't be too hard to implement, just tedious.

3) BUG FIXES / TESTING

At the beginning of the game's source code I've started a BUGLIST to keep track of what needs fixing. Currently I'm troubleshooting an issue where the level music doesn't restart after the player dies.

IF I HAVE TIME . . .

Not gonna lie . . . working on a game like this for almost 3 years is exhausting. About this time next year I really hope to be working on another game project. So I'll be working hard to make that happen. If time permits, I might add gamepad support. I might also add custom colors to the player ship. But that's about it, anything else would be major scope creep.

QUOTE OF THE WEEK:

"Hardships often prepare ordinary people for an extraordinary destiny." -- CS Lewis

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