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!

10 DEC 2022:

- Added a background to give the Railgun Store menu more contrast.

- Created a Random Number Generator

- Threat and Morale bars only show on-screen when needed (fighting enemies)

- Music and sound now work properly when transitioning from one level to another.

- Stars speed up and slow down properly when transitioning from one level to another.

- Removed a lot of redundant/unnecessary code.

QUOTE OF THE WEEK:

"Dreams are watered by hard work."

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

17 DEC 2022:

- Added a Scrap Collected counter that displays for a little while and then goes away when not needed.

- Created more background scrap.

- Finally learned how to make a decent asteroid in Blender! (shown above)

- Started reading "Procedural Generation in Game Design" by Tanya Short and Tarn Adams (one of the creators of Dwarf Fortress).  I'm only about 20 pages in, but already this book has been well worth it, as it make some very good points about when and how to use procedural generation in games.

- I checked out ChatGPT this week and was pretty impressed with its results. What is ChatGPT? Imagine a Google that answers your question by creating its own response instead of pointing you to a bunch of websites. Here's an example of what ChatGPT can do:

But what's even more cool is that you can literally copy and paste code into ChatGPT and sometimes it will point out your mistakes and explain them. I even asked ChatGPT to write me an outline for a Pong clone in QB64 (a modern version of QBasic) and it did just that. 

ChatGPT does have limitations. It won't entirely write your code for you. Also some of its responses can be very generic (or even wrong). And it pretty frequently rejects input because so many people are trying to use it. 

Nevertheless, I think it's a good tool to have in your game developer toolbox. If you don't have time for StackOverflow or a specialized forum to answer your question, there's a chance that ChatGPT might be able to answer your question right away and point you in the right direction.

But . . . I can also see ChatGPT becoming a crutch for a lot of people instead of doing their own research and work. Ideally, people should have at least a basic understanding of how to do things (math, programming, etc) without having to rely on software to execute or explain it.

QUOTE OF THE WEEK:

"In the information society, nobody thinks. We expected to banish paper, but we actually banished thought." -- Michael Crichton, Jurassic Park

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

24 DEC 2022:

- Started making the Level 1 satellite destructible! 

- Scrap can now rotate counterclockwise. 

QUOTE OF THE WEEK:

“Success usually comes to those who are too busy to be looking for it.” — Henry David Thoreau

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

31 DEC 2022:

- Satellite now breaks apart into collectible scrap. This is good progress towards getting Level 1 finished!

- Shield fighters, bombers and cruisers also break apart into collectible scrap.

- Despite some business trips that have kept me away from my Desktop, this has been a productive year for Scrapship! I was looking at this year's devlogs and the game is showing improvement in just about every area, but primarily the enemies (some of which had to be redesigned once or twice).

QUOTE TO START YOUR NEW YEAR:

"The way to get started is to quit talking and begin doing." -- Walt Disney

Thanks for reading and have a great rest of your year! Make 2023 great!

7 JAN 2023:

- One of the levels for Scrapship will have a black hole as the background. First I tried Blender — placing random white stars and then rotating the image at high speed. It looked okay, but not chaotic enough. Next I tried Embergen which you see above. They had a hurricane template that I adjusted to look a bit more like a black hole. I don’t think it’s there yet, but it looks decent. What do you think? 

- For the very first level, I started to create a routine that would allow the backgrounds to be procedurally generated. This way the earth and moon won’t always appear in the same place every playthrough. 

- I fixed a bug where the scrap image from the satellite was not keeping its form (you can see this bug in last week’s gif). 

- I’m on a business trip the next 2 weeks, so I won’t have much in the way of updates, but I’ll still update this devlog as I always do and leave you with a . . .

QUOTE OF THE WEEK:

“The only way around is through.” — Robert Frost

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

14 JAN 2023:

Still on my business trip so no real Scrapship updates but I have been reading a couple books about procedural generation.

At a very high level, procedural generation works like Mad Libs.  The human user comes up with the parts of speech to make the story (hopefully) hilarious. But coming up with the parts of speech could just as easily be generated by a computer program that generates random parts of speech. 

Though most talk of procedural generation revolves around RPGs and roguelikes, I’ve been thinking about how procedural generation would apply to a shmup like Scrapship. 

Your average shmup has pre-scripted waves of enemies. This is good if you want a predictable experience for people who like to chase high scores, but not very good if you are looking for replay value. 

It’d be very easy to make Scrapship just throw random enemies at you from random spawn points, but that could all too easily turn chaotic. There could be too few enemies . . . or too many. Or maybe they all spawn from the same region and start overlapping each other. There’s a lot that can go wrong with procedural generation. So this is why the concept of “guardrails” is important. Procedural generation works best when a HUMAN sets limits on what is and isn’t allowable. Without these “guardrails” it is all too easy to run into the “10,000 bowls of oatmeal” problem — lots of variation, but not much meaningful variation — one bowl of oatmeal is not much different from  the thousands of other bowls of oatmeal.

The ideal enemy generator for Scrapship needs to fulfill these requirements:

Spawns enemies appropriate to the player’s current performance. 

Spawns enemies in such a way that there is little to no overlap.  

Spawns enemies in quantities that won’t cause the game to lag. 

Occasionally does something completely random to keep things interesting. 

I already have a system in place that addresses most of these things, but another problem with procedural generation is that it is impractical from a human standpoint to vet every single possible combination. Some developers handle this by making an AI that plays the game and records data from each playthrough. This is a great way to see if some levels are too easy or too hard, especially if you don’t have a lot of human play testers. 

Before going on my business trip, the biggest problem I was encountering was enemies vs. lag. As cool as it would be to spawn 3 battleships against the player, battleships are large images and take longer to draw to the screen than smaller enemies. And that’s before factoring in large background images.

Below are some possible ways to handle this problem:

- Limit the number of large objects that can be on screen at any given time.

- Spawn enemies relative to the current framerate or expected framerate. 

- Scale down enemies and/or background objects so they draw to the screen faster.

- See if there are any ways to make the graphic files smaller (jpg vs png, cropping the image, deleting metadata, etc). 

What are your experiences and thoughts about procedural generation? Does your game use it or have you played a game that made good use of it? Let me know in the comments below!

QUOTE OF THE WEEK:

“Always deliver more than expected.” — Larry Page

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