Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

SCRAPSHIP (Done!)

A topic by 40wattstudio created Feb 16, 2020 Views: 22,647 Replies: 428
Viewing posts 201 to 328 of 328 · Previous page · First page

14 MAY 2022:

So much progress this week that I can only properly show it off in a Youtube video!

- My experimental branch of Scrapship has been successful and is now the main branch!

- The game now detects the player's desktop width and height and goes to a windowed fullscreen by default. This gives the game a more cinematic effect and creates a lot more playspace.

- The screen moves around the player instead of the player moving around the screen. This massive improvement allows the player to scroll infinitely in any direction while imparting a greater feeling of freedom and space to the experience. To me, it doesn't make sense to confine the player to a narrow corridor of action like you see in a lot of shmups. Especially in a game that takes place in . . . space.

- Reworked AI system that allows a LOT more enemies to spawn. This is still a work in progress, but even as-is, I see it as an improvement over the last version. 

- The THREAT BAR. You'll see this as a red bar on the left side of the screen. Certain actions (like firing your weapons or damaging enemies) will cause it to increase. The game gets harder as the Threat Level increases.

- The MORALE BAR. As you destroy enemies, their morale decreases. When it reaches a set point, the railgun appears allowing you to go to repair your ship and go to the next level.

- More collectible scrap on-screen. Some is "free scrap" that floats around, but destroying enemies also generates scrap that can be collected. Scrap can be spent at the railgun store between levels. The scrap also helps give the player a sense of movement through space.

- Prior to this update, Scrapship was almost at 11,000 lines of code. The current version you see in the video only has 7,500 lines of code. I was able to accomplish this by consolidating a lot of redundant subroutines.

BONUS:

Morale is displayed using a counter that is broken down into hundreds, tens and ones digit spaces. One of my challenges was writing the code to make this decrement properly. Side note: I initially tried a modulus route, but that was returning incorrect values.

Below is the code I used to accomplish this. The same principle can be used in any programming language.



Quote of the Week:

"Pleasure in the job puts perfection in the work." -- Aristotle

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

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!

(+1)

Looks pretty good. Reminds me of Space Invaders. Look forward to playing the demo when I have time.

Thanks for the comment! Space Invaders was indeed an early inspiration, but the game will play much differently. Also, just a reminder that the current demo is for the old version of the game. It's changed quite a bit since then.

(+1)

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!

(+1)

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!

23 JUL 2022:

Was out of town most of this week, but managed to do some programming and Blender work. The shield fighters are pretty much done, they're just missing some logic for when the engines activate. The general idea is that the shield fighters usually have their engines off (because they're already in motion and moving at a constant speed). And usually the AI will pick another enemy to spawn. However . . . what about the situations where spawning another enemy could negatively affect the framerate? That's where the exhaust animation comes in. Instead of spawning a new enemy, the existing shield fighters will fire up their engines and accelerate towards the player. It's easier to make an existing enemy "harder" than to draw a new enemy on the screen.

Bombers are next on my list. There are 4 variations of them . . . or rather, they attack from 4 different directions. So this morning I worked on the first one.

The next 3 weeks my day job has me going on business trips, so I won't be able to get much done. I'll still do my Saturday devlog updates, just don't expect much (or any) progress during this time. Actually, now that I think about it, that would be a great time to talk about my thoughts regarding the latest news surrounding the Unity game engine. Stay tuned for those thoughts!


QUOTE OF THE WEEK:

"If you can learn to enjoy repetition, you can achieve what normal people think is impossible."

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

However . . . what about the situations where spawning another enemy could negatively affect the framerate? That's where the exhaust animation comes in. Instead of spawning a new enemy, the existing shield fighters will fire up their engines and accelerate towards the player. It's easier to make an existing enemy "harder" than to draw a new enemy on the screen.

Interesting, how do you determine that?  Do you just have a hard limit on the number of concurrently spawned enemies?

There's a counter variable that I use to keep track of how many times the main game loop iterates in one second. Usually it's well over 60 fps. But large graphics -- planets and capital ships -- are what really cause performance to take a hit.

To fix this, I will have some code along these lines:


IF fps > 60 THEN

    SpawnNextEnemy

ELSE

   IncreaseAttributeOfExistingEnemy    (make enemy go faster, etc)      

END IF


But like you mentioned, I have also experimented with hard limits on enemies:

IF NumberOfActiveCapitalShips > 2 THEN

     IncreaseAttributeOfExistingEnemy

ELSE

SpawnAnotherCapitalShip

END IF


Both ways get the job done and they can even be combined.

Interesting, I don't know if I have seen that approach before.  Theoretically then, faster hardware will tend to produce a different experience than slower hardware, because it will usually favor adding more ships over upgrading existing ones?  Have you done much comparison of older vs. newer hardware?

I haven’t done any hardware testing yet, but you make a good point. Ideally, the experience should be about the same regardless of what hardware one has. 

You could always split the difference.  Maybe if fps>60, alternate or randomly choose between a new ship and an accelerated one, instead of always spawning a new one.  That would close the potential gap a bit, and would also mix it up a bit more when performance isn't an issue.

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!

(1 edit) (+1)

5 NOV 2022:

Just got back from another business trip (Ft Carson, CO) so didn't get to work on Scrapship very much. But battleship 225 is about 95% done. I just need to make the fully-destroyed version of the battleship in Blender.

      

QUOTE OF THE WEEK:

"If you are working on something that you really care about, you don't have to be pushed. The vision pulls you." -- Steve Jobs


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

(+1)

nice ship

Thanks! I started on the 4th one this morning.

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!

(+1)

26 NOV 2022:


- Finished the "Right Carrier" or 2 of 4. It's called that because it moves left to right. Fun Fact: I finished this one on Thanksgiving morning.

- Carrier Fighters have better AI now for their kamikaze attacks. If you stay still, they head straight for you. If you bank left or right, they plan a course to intercept.

- Started on the "Up Carrier" (3 of 4). The "Up" and "Down" Carriers work  differently -- the hangar can't be attacked as they're protected by the engines, so those are what need to be destroyed instead.


IN OTHER NEWS:

- I was going to upgrade my Desktop PC  to 32 GB of RAM . . . only to find out that the type of RAM I was going to install was the wrong physical size for the slot. Doh! So I'm still stuck with 16GB, which is fine enough for what I do.

- I downloaded Unreal Engine 5.1. My Desktop can run it -- if I don't mind waiting 5 minutes for it to initially load. The new interface looks nice though so I will keep it in mind for future projects.

Here are the summarized recommended specs are for those of you that are also interested in trying it out:

  • 64 GB RAM                                                        ( will work with 16 GB, but much slower to load)
  • SSD Harddrive ( > 500 GB)
  • NVIDIA GTX 970 or greater                    ( don't forget to update your drivers!)
  • 6-core processor @ 3.4 GHz                     ( 3 GHz works fine too)

- I also downloaded Godot since I haven't tried that in a while. Although the 3D demo level looked good, I find the game engine itself to be not very intuitive. But because it's not Unity and it's VERY lightweight, I'm still keeping the Godot option on the table.


QUOTE OF THE WEEK:

"The greater the difficulty, the more the glory in surmounting it." -- Epicurus

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

(+1)

Seems like you’re making steady progress. I tested the game after a long time, and will come back when I have time to play it properly. At least the menu music is now stuck in my ears.

It will be interesting to hear about your experiences on Unreal. I’ve been thinking of trying it, but also I have to upgrade my computer first. Simultaneously running Unity, Visual Studio, Blender, Substance, Gimp, dozens of Chrome tabs and various other things is quite a load for hardware, and judging from the noise my GPU makes, it cannot take it much longer.

Thanks for checking it out! If the menu music is stuck in your ears then I guess that was money well spent :)


As for my own experiences with Unreal (4 mostly), I like the layout of the engine and workflow. Blueprints is perfectly fine with me because I'd rather connect nodes Blender-style than learn C++ from scratch.  But the huge project sizes and considerable hardware prerequisites are what make me wonder if Godot or Unity might be a better option. Like if you make An Awesome Unreal 5 game, yeah that's cool, but how many people are going to have computers that can play that?  So that's something else I'm thinking about as well.

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!

(+1)

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!  

(1 edit) (+1)

21 JAN 2023:

Just got back from my business trip last night! 

Since I wasn't able to work on Scrapship, I spent some time learning more about QBASIC and basic computer concepts, especially how "Random" Number Generators work. Why is "Random" in quotes? Because computers are actually just using PSEUDO-Random Number Generators -- run any RNG long enough and you'll start to see little patterns here and there.

In a nutshell, most RNG programs take a Real World value, like time and then perform an operation against it to generate a random number. 

This ties into Scrapship since the game makes heavy use of "random" numbers. As I soon found out, not all "random" number generators are equal! In some cases you might even be better off writing your own!

What you see above is called a RANDOGRAM or a histogram that tracks random numbers. This is a visualization I made to see how the QB64 RNG looks like.

It has a nice "random" static look to it and the colors are almost equally distributed. 32,000 instances of each color (red, blue, green, purple). 

Now if we applied this to Scrapship, that would mean that if I spawned 4 types of enemies, the spawn-order would have a lot of variance, but ultimately each type of enemy (e.g. shield fighter, bomber, cruiser, battleship) would spawn about the same number of times. If you wanted an output that was more irregular you'd have to tweak the original RNG or make your own.

I had mentioned earlier how I had been reading about Procedural Generation in game design. That, coupled with my experiments in RNG led me to try creating random maps -- possibly for a future game???

Below you can see my early attempt at procedural map generation:

 

It looks pretty good -- but there are still some straight lines that are a little too obvious. 

When I tried to do this with the built-in RNG from QB64, it looked awful because -- as mentioned before -- it tends to distribute evenly. You can render a thousand randograms and you'll almost never see "slabs" of similar colors next to each other. So if you want to make a continent made out of pixels, you got to be creative.

If you're interested in Random Number Generation I highly suggest this website that has some excellent articles to read and tech demos to try out!


QUOTE OF THE WEEK:

"Timing, perseverance, and ten years of trying will eventually make you look like an overnight success." -- Biz Stone

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

(+1)

Hi,

it's quite incredible how you kept focus on your game for so long, I saw the first posts compared to what you got now, it has been a long way ! Congratulations for that.

Regarding procedural generation, I don't know QBasic, you'll get great results using Perlin noise, even if you don't have ready-to-use library or code, it's not that's hard to implement. It generate very nice smooth patterns full of clouds that can be turned into mountains and water for a on-the-ground game (exploration/mining, RPG, whatever), in space like your game, you'd to decide which level is what, for instance you can generate value between 0 and 9 (after rounding up), each one could be bonuses, resources and some enemies.

It's also pseudo-random, so the same seed will always produce the same pattern, useful for testing.

Here is a little example of what I've made years ago in C# & MonoGame using hex numbers instead of tiles for debug (with SharpNoise library):


Like the quotes you add to your posts ;).

Cheers.

Hi Infini-Creation, thanks for the kind words and feedback! 

Perlin noise does sound intriguing and I've seen it mentioned quite a bit when I was researching procedural generation. Simplex noise is another type I remember being talked about. 

Your InfiniteTileMap looks like an efficient tool for debugging. Not sure if you are in the process of making any games, but I wish I had made more debugging tools like that early on because it saves so much time troubleshooting problems as the project gets larger.

(+1)

You're welcome ;).

There are a few algorithms for noises, Perlin and Simplex are two of them, I guess there is no need to fully understand everything behind for using them, and implement them may not be too hard to do if no one already done for the language you use, in C++ there is quite a huge probability some already exists.

It was in fact not fully debugging tool, then numbers are just to have a quick view of what was generated, then replaced by tiles gfx, it become a nice world to play on like below when it is partially done:


here with some "developer's assets".

The strength of using noise allow to have an actually infinite worlds with very tiny memory footprint as the same seed generate the same map and "moving" is just generate a new map with a little shift in each step to one direction.

I guess this is experience talking, as a professional software engineer, I did lot's of such small step to move forward with the least possible issues (it's like building a house, starting by foundations which have to be strong) and I'm always interested by making game but never really get fully committed to I've only started doing some core stuff, until now maybe, Godot is very great tool and simplify a lot's of annoying low-value work.

28 JAN 2023:


This week was all about the Cargo Ship boss enemy! 

Originally it was orientated horizontally but I quickly realized a couple problems with this:

  • It would be strange to have the cargo ship moving left/right when the  player is mostly moving up/down.
  • Too much lighting made the 3 guns harder to see. 
  • Having the guns rotate to follow the player would be a headache to program. 

So instead, I tried a vertical orientation, muted the colors of the cargo ship and changed the colors  and positions of the guns. 


I'm still working on it, but I think this looks much better and will make for a more interesting boss fight.  These 4 guns will be stationary, but the cargo ship will be able to move around left and right while still moving forward. Right now all the guns fire the same type of projectile, but I'll probably change that a little. 

IN OTHER NEWS: 

Hopefully I'm wrong in this, but I'll probably have to look for a new job in about 2 years. As a result, one of my goals is to finish Scrapship before that happens. I'll be trying really hard to finish it this year, but even if it doesn't it's almost guaranteed to be done the year after that. 

So time is very precious right now. I've noticed that I'm the sort of person that easily gets sidetracked -- ESPECIALLY when it comes to Youtube. But just this week I came up with a couple of productivity hacks that I think will help me to focus more:

  • I now use 2 web-browsers and not just one. Firefox is for "lazy me", so lots of entertainment-related bookmarks and accounts. But now I also have the Vivaldi browser, and this one is exclusively for "busy me". This one has all my gamedev bookmarks and accounts. The idea is that I will only have one browser open at a time. So when Vivaldi is open, I'm not seeing any "entertainment" content that might get me sidetracked. So far it's worked really well!


  • To further encourage myself to be more productive, I made it easier to start up all the content that I use for "busy me". I did this by creating a batch file that automatically opens the Vivaldi browser to my 40wattstudio email, itch.io dashboard and 40wattstudio YT account with all my gamedev-related subscriptions. It even automatically opens up QB64, which I am using to make Scrapship. Less time clicking and typing = more time programming!

On the side, I've been slowly teaching myself how to program in C++, mostly using the YT tutorials by Codebeauty. Having tried python and java, I finally decided to learn C++ due to its long history and use in programs like QB64 and Unreal Engine.

QUOTE OF THE WEEK:

"Be undeniably good. No marketing effort or social media buzzword can be a substitute for that." -- Anthony Volodkin

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

4 FEB 2023:


- Scripted the movement for the cargo boss enemy.  Possible directions of movement are up/down/left/right and diagonal in four different directions. 

- Fixed a bug where the player position would shift right after being hit by the battleship.

- Fixed some scrap spawning/scrolling issues.

QUOTE OF THE WEEK:

“I don’t believe in luck. I believe in preparation.” — Bobby Knight

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

11 FEB 2023:

- Scrapship is over 11,000 lines of code. There's a lot of it that can be consolidated, such as the battleship projectile hit detection which I fixed this morning. 

- The cargo ship can damage the player now, but there is a bug where it doesn't always register a hit. 

- Once I get that bug fixed, both the battleship and the cargo ship boss will be able to use some of the same code.

- The past few months there has been an elusive bug where the game crashes after warping to the next sector. I have it narrowed down to the "Scaling Earth" subroutine. Pretty sure it's because a number is going negative when it needs to only be positive for the math to work.

QUOTE OF THE WEEK: 

"A year from now you may wish you had started today." -- Karen Lamb


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

18 FEB 2023:

Scrapship has been in development for 3 years now! I started on 16 February 2020 and have been working on it daily ever since (excepting business trips, vacation and illness). How have I managed to stay motivated to work on this project for so long? I just do a little bit -- 1 hour -- every day. Some days or even weeks I feel like I'm making no progress, but others I feel like huge breakthroughs are being made. Ultimately, I have faith that the end result will be worth the effort. And I've certainly learned A LOT about game development along the way.  The game is certainly getting closer to done, slowly but surely. I'd like to finish this year . . . but I'm also not going to rush it. 


- Made an animation where the cargo ship guns power up to indicate that they're active. 

-  As seen in the gif a couple posts above, the cargo ship's guns were all red. Now, guns that are active are green and only inactive guns are red.  This also helps with the color contrast -- a red projectile coming from a green gun looks much better than a red projectile coming from a red gun. 

- Cargo ship can damage player

- Fixed the bug where scaling the size of the earth was causing the game to crash (a variable was resetting to true when it needed to stay false). 

QUOTE OF THE WEEK:

"You don't concentrate on risks. You concentrate on results." -- Chuck Yeager

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

(+1)

25 FEB 2023:

Got a LOT done this week! Yesterday I worked off and on most of the day. 

- As I write, I'm in the process of re-rendering the opening animation. This time it will take up the whole screen and not just a square portion of it. This will be much more immersive. Only downside is that the .png files are pretty large, but maybe I can trim them down some to make it more practical. 

- Speaking of trimming down .png files, I cropped all of the images for the battleships and carriers. These were greatly impacting load times. A single battleship graphics folder would be 15MB -- but after cropping the files I got it down to 3MB. Load times also decreased which is excellent. 

- The player can now destroy the cargo ship guns. But I still have to make the destroyed versions in Blender and some explosion effects in Embergen. 

- Also re-organized and simplified some of the code, especially for the player bullets. 

- How convenient, Blender just got done rendering, so here's a gif of the new opening animation! The game is meant to be played in a widescreen format.

- I have a business trip all next week, so probably not much in the way of updates next Saturday.

REMINDER: It's almost the end of the month! You've been working hard! Make those 1s and 0s happy! Back up your harddrive!


QUOTE OF THE WEEK:

"He who is not courageous enough to take risks will accomplish nothing in life." -- Muhammad Ali


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

4 MAR 2023:

No updates as I was on a business trip this week. And my back hurts (again). I'll elaborate more next week.


QUOTE OF THE WEEK:

"Stay hard! -- David Goggins


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

11 MAR 2023:

It feels good to sit again!

I promised last week to elaborate, so here goes:

If I were in an RPG and there were stats for "Back Strength" or "Back Health", I'd probably have stats like 40 (out of a possible 100). My posture sucks most of the time and it doesn't take very much for me to pull a muscle or something that messes it up for a couple of days. 

Now I don't use the standing feature very often, but I am grateful that I had the foresight to buy a standing desk (pictured below).

Problem was, even standing still was sometimes painful. So this time I went to a chiropractor because I really couldn't figure out what I did to hurt my back. Apparently my lower spine was torqued a bit to the left. 

After a couple visits and days off I started to feel better, thank God. So because of that, I was able to get back to work on Scrapship!

Updates for this week . . .



- Scrap can move from right to left.

- Cargo Boss guns can be destroyed

- Cargo Boss can be destroyed

You'll notice that there are still some things missing: The guns need explosion animations and the explosions in general need to be reworked so they're not all the same. I saw that Embergen (the software I use for explosions) will be moving to version 1.0 pretty soon, so hopefully I can take advantage of that to make more cool effects for blowing things up. 

In Other News . . .

There won't be any updates for Scrapship until 7 April. Yep, another business trip. This time I'm going to South Korea, so that should be interesting! I might still do the weekend update, but also maybe not . . . it depends on my internet situation over there. So if you don't see my devlog get updated the next few Saturdays, don't panic! I'm just busy with work is all. 

QUOTE OF THE WEEK:

"Small is not just a stepping-stone. Small is a great destination itself." -- Jason Fried

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

18 MAR 2023:

Almost forgot it’s Saturday! 

I was able to work on Scrapship a little in the days before I left for South Korea:

- Level transitions now work all the way from level 1 to level 5. Even the music transitions correctly. This is a pretty significant step towards getting the game done. 

- Scripted one of the background images for the final boss fight.


In other news . . . So yeah, I’m in South Korea now for a business trip. 18 hours worth of flights just to get here. But totally worth it (I think travel is one of the best ways to spend money). 

My hotel room has a flat screen TV almost the size of the mattress and a DESKTOP computer in the room. Of course the IT tech in me is saying , yeah probably not a good idea to use the Desktop computer, who knows what it has installed on it (keyloggers, etc). Besides, I bring my own computers.

Speaking of computers, this brings me to an interesting thought: How much do you think about the hardware that your potentials players use? Unreal Engine 5 looks bloody amazing, but one thing that does scare me away from it is the fact that it requires such a beast of a computer just to develop or play games on. If you’re targeting players in countries that don’t have the income to buy the latest graphics cards then you might be better off developing in Unity or Godot. Surprisingly, I read that electronics (especially phones) are more expense in South Korea than in the US. 

QUOTE OF THE WEEK:

“Set your goals high, and don’t stop till you get there.” — Bo Jackson

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

25 MAR 2023:

Weekend 2 of 3 of my Korea trip, so no Scrapship updates this week.

QUOTE OF THE WEEK:

"Live out of your imagination, not your history." -- Stephen Covey

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

1 APRIL 2023:

Weekend 3 of 3 of my Korea trip, so no Scrapship updates this week.

South Korea has been a blast! Last week my coworker and I found a PC cafe and played some Starcraft (when in Rome . . . ) and some Overwatch 2. A lot of the games on the PC's required a Battlenet account to play.

Looking at other players in the cafe, I saw that they played a variety of games, not just RTS or FPS. Some were playing a soccer game of some sort.  

On the metro, just about everyone is staring at their phones. One guy was watching a playthrough of some FPS and I saw a girl playing a Candy Crush-style puzzle game. I think it's fair to say that mobile gaming is still alive and well. 

On TV, I found an eSport event going on (RTS), but I also found a channel where two players were playing Go (basically Asian chess with black and white stones). This just goes to show that people like the classics just as much as the newer stuff. 

QUOTE OF THE WEEK:

"Failure is success in progress." -- Albert Einstein

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

8 APR 2023:

Finally back from my S. Korea trip -- and the jet lag sucks! It was 27 hours from the time I left my hotel to the time I walked in the front door of my house.

In spite of that, I was happy to sit back down to Scrapship and get going on it again. This week was mostly bug fixes and minor adjustments, but there were a lot of them:

- Fixed bug where earth would vanish when it was still on-screen

- Fixed bug where music restarted every time volume adjusted

- Music files stop and close when game ends

- Commented out scaling code for ships and explosions

- Fixed game tips

- Fixed opening animation graphics

- Adjusted player launch sequence (between levels)


As fate would have it, I have another business trip starting next week -- Ft Drum, New York ( at least it's not the middle of winter). I just can't seem to get a break, can I? Fortunately it's only for a week and a half and then HOPEFULLY my schedule should be free for a little while. 


QUOTE OF THE WEEK:

How you do anything is how you do everything.


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

15 APR 2023:

- I use Embergen software to do all the explosion effects in Scrapship. They just launched version 1.0  a couple weeks ago, so I upgraded my version of it and started familiarizing myself with the new features. One of the biggest things missing in Scrapship right now are different explosions. I have a couple to work with, but obviously it'd be nice to have more variety. And now that I know how to use sprite sheets, I'm hoping I can have that variety with relatively little cost in game performance.

- So far I have 2 more scheduled business trips this year (4 weeks), so that's obviously going to cut into my development time but I'm hoping I can still get the game done or close to done by the end of the year. 

- I have a question for all of you: Do you prefer being able to play a game as it's being developed or do you prefer waiting until a game is completely finished?


QUOTE OF THE WEEK:

"If you don't have a strategy, you're part of someone else's strategy." -- Alvin Toffler


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

22 APR 2023:



Whew, glad that uploaded! It was 2.986 MB and the limit is 3MB!

- As you can see, I've been working with Embergen 1.0 this week.  Sorely missing from the game at the moment are explosions for minor hits on enemies. The above explosion comes pretty close to what I'm looking for although the in-game version will be much smaller. The actually rendering and exporting was pretty easy, but -- as before -- the hard part  was figuring out how to get the exported frames to look exactly like the viewport frames. 

In my RENDER--> Export settings I had to change my Alpha Blending Mode to Straight Alpha to get the right look. 

- I've found that 20 frames of animation is sufficient for these small explosions. Five frames show the explosion going from nothing to full blast. The next 10 are to ensure those pretty explosions stay on screen long enough for the player to see them. The explosion fades away in the last 5 frames. 

- Right now this folder of 20 frames is about 577kb, but I'll be able to get that even smaller by using a sprite sheet, which I successfully tested and integrated several months ago. 

- Ideally, each ship will have a different "minor hit" animation and possibly a different animation depending on what weapon you use.


QUOTE OF THE WEEK:

"An investment in knowledge pays the best interest." -- Benjamin Franklin


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

29 APR 2023:



- There are now two different explosions when you hit an enemy. A smaller one when you use the "rapid laser" and a larger one when you use the "scrap cannon".

- More importantly, I reworked all of the explosion animation code so that I can show multiple "damage explosions" at once. This took a while to figure out. But it had to be done because there's no point spending time in Embergen making fancy explosions that are only going to be shown once per enemy. 

- One of the nice things about Embergen is that it has a nice amount of PRESETS: 


So I can take a prefabricated effect that is close to what I want and adjust it to my purposes.  Right now I'm trying to make a lightning or electric discharge sort of effect (which they don't have  a preset for, but a few come close in principle). I also saw that they have Premium Presets, the first one being clouds. So if you don't want to buy the Embergen software, you can just buy some presets. Think of it as Kitbash but for explosions, clouds and particle effects. Pretty cool. I'm not affiliated with Embergen by the way, I'm just happy that I found an "explosion solution" that fits my minimal  budget.

- The majority of my development time is going to be in Embergen the next few weeks, with minor code adjustments to get the explosions to line up properly over the enemies. 

QUOTE OF THE WEEK:

"A problem is a chance for you to do your best." -- Duke Ellington


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

6 MAY 2023:


- It took all week and lots of experimentation, but I finally made a lightning effect for the "stun gun"! 

- Below you can see my Embergen node tree for it:


- I always seem to encounter this problem -- rendering bloom. The bloom effect with the lightning looks amazing, but trying to capture it in the final render is elusive if not impossible. So I took the animations to Aseprite:


Here are the Aseprite notes I took on how add some Alpha  while still retaining the bloom effect of the original image:

Open your first image in Aseprite and select "Agree" for "load the following files as an animation."

Click the Layer "Continuous" button in the timeline (links all frames together for changes) (rightmost arrow in above pic)

Click the lock button to upper left of colors to unlock color editing. (leftmost arrow in above pic)

Click down arrow and sort by brightness (or whatever)

Select Sprite --> Color Mode --> Indexed

Use eyedropper tool and click on a color

Change Alpha value (below the color rainbow, not the two color bars below it (middle arrow in above pic)


QUOTE OF THE WEEK: 

"Hide not your talents, they for Use were made. What's a Sun-Dial in the shade?" -- Benjamin Franklin

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

13 MAY 2023:

Hours of gamedev this week = ~9


- Final Boss can spawn in 3 different orientations (experimental)

- Enemies only become stunned after the final frame of the lightning animation

- Simplified main menu

- Enemies don't spawn when bosses are active

- Railgun won't scroll off screen and get lost

- Enemies won't hurt player when railgun is active


QUOTE OF THE WEEK:

"If you always do what interests you, at least one person is pleased." -- Katharine Hepburn


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

20 MAY 2023:

- Redesigned Final Boss model 

- Left and right guns for the final boss can be damaged separately



Above is the original model. But I quickly saw a couple problems with it. 

1) Too many unnecessary parts extruding out from it. This also meant that I had to zoom out to fit it all in the frame. By getting rid of the extruding parts, I was able to zoom in more for a larger, simpler image.  

2) I got rid of the right "machine gun". I still want there to be  a sort of "machine gun" weapon for the final boss, but not one that I have to have any fancy animations for (like on the battleship, which was an absolute headache to code).  Below you can see a preview of the new version:



QUOTE OF THE WEEK:

"A game is a series of interesting choices. " -- Sid Meier


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

27 MAY 2023:


- This week's update ties in directly to the Quote of the Week. Last week's Final Boss design was ok, but not entirely to my liking. So this week I experimented with a new design that you can see above.  I like how this version has more symmetry and it's given me new inspiration for how the Final Boss battle should play out.

- I also made a cool beam attack animation in Embergen and tested it in-game. 


QUOTE OF THE WEEK: 

"If you aren't sure which way to do something, do it both ways and see which works better." -- John Carmack


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

(+2)

Very inspiring to see such dedication and regularity in the updates, keep up the good work !

(+2)

Thanks for the encouragement!

(+1)

3 JUNE 2023:

- About halfway done with rendering some of the gun animations for the final boss. The left and right guns each have the three following states:

  • Banking Left, Idle, Banking Right
  • Damage level from 0 to 2
  • Disabled status (0 or 1)

If my math is right  3x3x2 = 18 different states for the final boss.

I've always liked banking animations in shmups -- they make movement look so much more natural. Plus they also inform the player what direction the enemy is going in. Without banking animations, there is no telling if the enemy is going to move up, down, left or right until it actually starts doing so -- and by then it may be too late for the player!

Having played a good handful of indie shmups here on Itch I've noticed that the better ones try and do some sort of animation for the player or the enemies. Sure, it's more work (sometimes a lot of work) but it really does look better in the end. 

This week's update is a bit short since I had (another) business trip last week, but the following week or two should be back to normal.  


QUOTE OF THE WEEK:

"It is a beautiful truth that all men contain something of the artist in them." -- Walt Whitman


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

10 JUN 2023:

- Started programming the AI for the final boss. It can currently move in 8 different directions.

- Left and Right guns can be stunned and damaged (no animations yet).

- Aseprite came to the rescue when I was trying to figure out how to crop multiple frames of animation all in one go. This cropping will mean smaller file sizes for that animation and more accurate hit detection against the player.

- I'm being deliberately scarce on gifs and images of the final boss -- to me, they should always have a bit of mystery to them until finally encountered.

QUOTE OF THE WEEK:

"I think that inside every adult is the heart of a child." -- Shigeru Miyamoto (Creator of Mario and Zelda)


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

17 JUN 2023:

- Sometimes I tinker around with side projects that give me new insights into how to do things. This week, those side projects taught me how to make my code both more readable and more practical. I implemented this into Scrapship by reworking some of the code and even creating a few new functions. 

- Previously, the vast majority of my sprites were positioned using hard-coded coordinates -- which I now realize is very awkward and inefficient. The new subroutines I created can now position objects relative to the dimensions of the game screen. A good handful of still images use this new method for positioning, but I still have to figure it out for the images that are embedded in arrays.

- I also worked on the final boss beam attack animation and came up with my best iteration of it yet just this morning. 

- Once the final boss is done (still got damage animations to do), it's just a matter of going over the game from start to finish and polishing as I go along. 


- Something fun. If you need something to do this weekend, I highly recommend walking around in nature and listening to the Skyrim soundtrack.  I don't get to do it as often as I'd like, but when I do it sometimes feels like living the game. 


QUOTE OF THE WEEK:

"Games shouldn't only be fun. They should teach or spark an interest in other things." -- Hideo Kojima (Creator of Metal Gear)


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

(+1)

Hey dude, I've been following you for a while. Interested to see where this ends up, and props to you for keeping on. 

(+1)

Thanks Alpha King and it's cool to see that you have a new project in the works!

(1 edit)

24 JUN 2023:

- Started creating animations for when the final boss gets damaged.

- Perhaps more importantly, I created a subroutine that handles sprite sheets. For shorter animations, I've found that it's still best to cycle through them the old way, but for longer animations of 100 frames or more, this new  subroutine works splendidly! With sprite sheets I can pack more frames into a smaller space than if I loaded them in individually. For my sprite sheets I've been using TexturePacker which is really nice and intuitive.

- I also discovered (rediscovered?) the Sprite --> Trim feature in Aseprite, so I've been using that to get rid of any unnecessary transparency around the edges in some of the larger images. Simple but excellent way to reduce file size!



QUOTE OF THE WEEK:

"Constraint breeds creativity."                         (I heard this one when I was listening to Episode 71 of The Game Design Round Table podcast.)

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

1 JULY 2023:

- Still working on the final boss attacks and animations. 

- In Blender I was having issues where the lighting//coloring on half of an object was slightly different from the opposite side. This week I learned that it was because of my normals. Going into Edit mode, highlighting everything and pressing Shift + N reworked all the normals so that the lighting and coloring was consistent. 

- I'm up to 11,500 lines of code now, so I've been cleaning up the code so I don't run into . . .

- A bug. This one had me puzzled for several hours. Thankfully I just got it straightened out this morning. A bug like this can be pretty demoralizing but a combination of reviewing log files and looking at the code base from a previous version helped me find out what was wrong.


QUOTE OF THE WEEK:

"When things get harder, and the obstacles get tougher, it just means you leveled up." -- Lilah Pace

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

8 JULY 2023:

- The final boss is coming along nicely! It actually looks and behaves a little differently than it did before. You can stun the left gun, the middle or the right gun individually -- and they're animated! The guns can also be damaged incrementally. 

- The only downside was that the final boss graphics took about 30MB (which for QB64 QBasic is a massive amount of data to load in). So I experimented with some different methods of drawing the sprites to the screen:

 

This is a WHOLE image. Notice all the dead space to the right of the gun. This makes the file size for this one frame 188 KB. Not cool. The only positives to this method is that 1) I can position every image off of the same upper left coordinate and 2) No cropping/trimming required.


This is  a CROPPED image. You can safely delete the dead space to the right of the gun and anything below the gun. This shrinks the file size down to 60.7 KB. Major improvement! It also benefits from making it easy to position. But some manual cropping is required to get it this way. 

This is a TRIMMED image. This is when Aseprite trims all around the image so that all dead space is deleted. This shrinks the file size down to 59.6 KB. Now that doesn't sound like much, but here's a comparison of the folder sizes using the 3 different methods:

WHOLE IMAGES = 30 MB                           CROPPED IMAGES = 23 MB                   TRIMMED IMAGES = 18 MB

Trimmed images almost halve the original folder size! So clearly that's the way to go. But there is one problem with trimming images. When Aseprite trims the image, it also trims away the original position in the upper left corner. So now the individual sprite segments that make up the final boss no longer align properly. 

To fix this, I took the cropped image width ( or height) and then subtracted the trimmed image width ( or height). This aligns all of the images properly. 


- Now that I finally figured all this out, I can apply this same logic to other enemies in the game. 

- I'm on Threads! It was really cool being able import my Instagram profile to Threads on Day 1. I plan on posting there a little more frequently than I do on Instagram and sharing my thoughts on gamedev and a few other things as well, so feel free to check it out!


QUOTE OF THE WEEK:

[This quote comes from Episode 75 of the Game Design Roundtable Podcast]

"If you can't make it good, make it short."


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

15 JULY 2023:

- Final Boss can now drop bombs! This is in addition to the beam cannon attack that it already has. Because the beam cannons are easy to dodge, the homing bombs force the player to move around the screen more. 

- At the moment, only one bomb can be dropped at a time, but I'd like there to be a possibility of multiple bombs dropping for increased difficulty. 

- Not a whole lot of progress this week as I was on vacation, but well-rested now and looking forward to more progress next week!


QUOTE OF THE WEEK:

Never beg for a seat when you can build your own table.


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

(+1)

22 JULY 2023:


- Bombs now have an explosion animation! It's currently not very efficient (the sprite sheet is 2.8MB) but it works so I'm going to run with it unless I find a more practical solution. 

- Final Boss can now be destroyed. It's a nice challenge too! The bombs increase speed as the boss gets weaker. But the bombs will never outpace the player. Even so, you will be forced to move around a lot to avoid taking damage. 

- I also added text declaring how the final boss destroyed you (e.g. "The Final Boss hit you with its beam cannon", etc). 

- There is a bug that has been plaguing the bombs for a long time now -- sometimes they'll get "stuck" near the player and never detonate unless the player moves. It's very intermittent and therefore very hard to troubleshoot. It has to be fixed though so that will probably be one of my main focal points for next week.


QUOTE OF THE WEEK:

"Never be limited by other people's limited imaginations." -- Mae Jemison


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

29 JULY 2023:

- Bomb bug appears to be fixed. A huge part of that was reworking the log file code to facilitate better debugging. 

- I also figured out a way to consolidate the way enemy projectiles are handled. Now there is only one subroutine to handle the shots for battleships, the cargo boss, bombs and the final boss bombs. 

- My debug program is much improved now. The upper left of the screen shows what iteration of the game loop is currently being shown. This then matches up with the text in the log file so I can pinpoint what is going on in the code at a specific point in time. 

- Ok, so this last one is not Scrapship-related, but I was so amazed by this fact that I just have to share: Did you know that the clouds and bushes in Super Mario Bros use the same shape, just different colors? It’s true! Look it up on Google. I think that’s a good example of doing things efficiently. 


QUOTE OF THE WEEK:

“There’s a way to do it better — find it.” — Thomas Edison

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

5 AUG 2023:

- As it turns out, the bomb bug is NOT fixed.  In the GIF above, the bomb is supposed to either hit the engine or the cockpit. But it's hitting neither and just getting stuck. A look at my log file revealed that this is because, for either segment,  only 1 of the 2 coordinate positions were met. 

Basically the game is miscalculating what the player middle x and middle y coordinates are. So apparently I need to rework that -- which is fine because I planned to do that anyways. :)

- Not much else this week as I just got back from another business trip last night. 


QUOTE OF THE WEEK:

"When the uncreative tell the creative what to do, it stops being art." -- Tony Bennett

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

12 AUG 2023:

- Bombers now have this cool scaling-down effect when they first appear on-screen! This was something I've been wanting to do for a while.  


- I was pressing CTRL + S to save in Aseprite when I noticed these coordinates pop-up on screen. They show you the x and y coordinates of where the trimmed image would be relative to the original image. Because of this, I did a test of trimming all the satellite images and then positioning them. This worked wonderfully and has 2 huge upsides: 1) Being able to trim away all that excess transparency = smaller images = shorter load times. 2) I can use QB64's _WIDTH and _HEIGHT functions to auto-return those values and use them for hit calculations! Now I just have to do this for the rest of the images in the game . . .

To get those coordinates, you press CTRL in Aseprite. Sometimes you may have to do the following for this to work: Make a stray mark anywhere transparent. Then get rid of it with the eraser. Then press CTRL and the coordinates should show up. 

- I also learned how to generate a Console screen in QB64 using $CONSOLE. This would be invaluable for debugging! The only problem is that the console window doesn't want to stay on top of the game screen where it would be most useful. 

- Started working on a subroutine so that the game will display properly at any resolution up to 2k or so. 

- Lots of work on the programming side to try and get things more consistent (naming conventions, etc). 

- A lot got done this week, but I also put in a lot more hours than usual. 


QUOTE OF THE WEEK:

 "Side content is meaningful because you can miss it." -- Joel Burgess (?)

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

19 AUG 2023:

Sometimes game design requires you to move backwards to move forwards.

 Though the game is 90% done now, there were a good handful of bugs that were impeding progress. I also didn't have any code for a critical aspect of the game: proper scaling for different screen resolutions. Instead of trying to fix bugs and implement scaling in a project with nearly 12,000 lines of code, I decided to "start over" -- which only means that I am starting with zero code and slowly adding things back in. 

And so far the results are amazing and well worth it! I've been putting in several hours a day so that has helped as well. 

- The game now scales properly up to the max screen resolution of 2560 x 1440. 

- The game starts in a Windowed Fullscreen mode that leaves the taskbar accessible. A press of the F key toggles Fullscreen mode.

- For the first time, you can exit the game or go Fullscreen while the game is loading. I accomplished this by embedding an "input listener" within each DO LOOP that loads the graphics.

 

- The settings screen has a nice little keyboard animation based on the keys the player actually presses. I had tried this before, didn't like the results and took it out; but the new version is pretty much perfect. 

- The sound and audio adjustment sliders don't have the "echo" effect bug if you hold down an arrow key for too long. 

- Text of any size can now be properly centered on the screen. (Last time I was just guesstimating the positions). 

- New troubleshooting tools include a logfile, a new buglist  and an in-game overlay that can be toggled on and off. It has already helped me solve a few problems. 

- In-game timers to keep track of how long it takes graphics to load. 

- 1,000+ lines of code have already been transferred over and re-worked. So it's going pretty quickly. 


QUOTE OF THE WEEK: 

"Sometimes you have to move backward to get a step forward." -- Amar Bose


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

26 AUG 2023:


- Player ship explosion now has more of a 3D look to it. I can also change:

  • Size of the particles
  • Speed of the particles
  • Duration of the animation

- Added option to skip the opening animation when starting the game. Can also be skipped while playing. Just about every game designer out there will tell you that animations/cutscenes should have a Skip button, regardless of how short they are.

- Settings can be accessed whenever the game is paused. Previously you could only access settings at the very beginning or between levels. 

- Assets are properly freed when you exit the game. This prevents memory leaks.


QUOTE OF THE WEEK:

"It's better for AI to be stupid than for the player to be bored." -- Ananda Gupta (Game Design Roundtable Podcast #93)


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

2 SEP 2023:

   

- You can't have a game called Scrapship without lots of scrap! This game was somewhat inspired by the movie Gravity  -- especially the parts where space debris is flying everywhere (right GIF). I spent a lot of time this week re-working how the scrap moves. Previously it only moved left to right or right to left. But now scrap  starts small in the background and scales larger as it gets closer to the foreground. 


- Reworked how the player ship is "put together". It still uses segments, but in a such a way that hit detection against specific segments will be much more accurate.

- The selector "loops around" on the main menu screen. So if you're at the topmost list entry, pressing up will take you to the bottom of the list and vice versa. Saves the player some keystrokes.

- Added a player win condition to the main game loop.

- Improved subroutines that handle image, audio and sound loading.

- One thing Scrapship needs more of is backgrounds. I found a program called Space Engine Pro that sounds very promising, especially because it can generate a ton of space-related content that can be used commercially. If you have any experience with Space Engine Pro ( or know of a good alternative) please let me know in the comments!


QUOTE OF THE WEEK:

"I see games . . . as the ultimate combination of art and technology." -- Todd Howard

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

9 SEP 2023:


- Collecting scrap is no longer a thing. Instead, they can hurt you -- as shown above -- or you can shoot them down. Shooting scrap will allow you to repair your ship between levels. 

- Scrap gets outlined in green when it is in range (to hit the player or be shot down). Aseprite has an excellent outline feature that made this part nice and easy!

- Added a sound effect every time the player gets hit.


QUOTE OF THE WEEK:

"The only place success comes before work is in the dictionary." -- Vince Lombardi

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

15 SEP 2023:


Doing this devlog a day early as I have a last-minute business trip scheduled for tomorrow.

- Increased the variety of scrap

- Satellite generates scrap that can be destroyed after a small delay

- The scrap from the satellite can also damage the player if you run into it

- Fixed the layering so that scrap is properly assigned "background" or "foreground" relative to all other objects

- Fixed a bug where the left and right wing segments were sheared off

There won't be any major Scrapship-related updates the next 2 weeks, but I'll think of something gamedev-related to post and of course the weekly quote.


QUOTE OF THE WEEK:

"Golden rule of level design -- Finish your first level last." -- John Romero


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

23 SEP 2023:

This week and next I’ll be talking about other stuff —no Scrapship updates this week as I’m still on my business trip. 

Thoughts on the Unity pricing scheme:

When you fill out an application to start a business, one of the fields you have to enter is something like “Purpose or goal of your business” and from the books I’ve read, the usual answer is “To make money”. So on the one hand, I understand that Unity is trying to do just that. But on the other hand, I do think they went about it the wrong way. It really did come across as if a bunch of suit-and-tie executives on the 40th floor made the decision without even thinking to talk to actual developers about the sort of impact this would have. 

It’s good that they walked it back, but like I’ve seen a lot of developers say, trust is hard to earn back. I totally agree. 

I do think this has underlined the importance of staying flexible with how a game is made. At the end of the day, game engines are like tools in a toolbox. Some are better at certain tasks than others, but a small hammer can still drive in a nail like a big hammer can. Or even a flat side of a large wrench. 

I’ve heard of a lot of Unity devs talking about switching to Godot or Unreal but I’d like to propose a third option — code the game yourself in C# (the scripting language Unity uses). Now you’re not even using a game engine and have ridiculous amounts of flexibility. And yes, there may be a steep learning curve. 

Scrapship is not made with a game engine. It is programmed in QB64PE which is a more functional, modern version of QBASIC. The freedom of programming a game from scratch is unparalleled. Anything I want to do, I can, assuming I know how to do it. Some people might think that you need to already be a “master” of a programming language to even start making a game — I’m telling you that you don’t. Prior to making Scrapship, my knowledge of QBASIC came from modifying existing programs back in High school and trying to make my own, a 20-year gap, and then watching a Youtube tutorial series before getting back into it. IF . . . THEN, DO . . . LOOP, etc were my initial building blocks and I just added on to that knowledge as I went along. 

All I’m saying is, keep your options open — some people even make games in Excel! 

QUOTE OF THE WEEK:

This week I’ll be recycling a quote from one of my favorite vloggers, Eva zu Beck, who is currently halfway through a 60 mile ultramarathon this weekend. 

Running  a marathon is a lot like making a game in that both require tremendous amounts of discipline — especially if you’re a solo developer. What Eva found helped her was coming up with a mantra that would help motivate her through the low points. In one of her vlogs, she shared what her mantra was: 

“I GET to do this.”

Instead of imagining running as something she had to do, she reframed it as something that she was privileged to do. As she points out in several of her videos, girls in Afghanistan can’t partake in a lot of sports that we take for granted. 

There are lots of us here on Itch trying to fulfill our dream of making a game, but there are some places in the world where making or even playing a game is probably unheard of. A quick look at Wikipedia shows that the only game from North Korea is “Pyongyang Racer”. How sad is that? 

So when you’re getting frustrated with your game development and ready to throw in the towel, just remember that you are doing this because it was a dream you had. No, it’s not something that you HAVE to do, it’s something that you GET to do. 

“I GET to do this.” 

(+1)

30 SEP 2023

Last weekend of my business trip, then it’s back home and back to working on Scrapship!

While researching a quote for this week’s devlog, I came across some by the creator of The Sims, Will Wright:

“On vacation, I totally unplug. I don’t bring a laptop with me.”

“I find it refreshing to unplug from it for a while. You kind of forget how deeply you get embedded in it.”

Lacking context, I’m assuming the “it” he is referring to is “game development”. Assuming that’s the case, I totally agree. A vacation — or in my case, a business trip — can give one a pleasant rest from the rigors of making a game. 

So I haven’t been working on Scrapship the past 2 weeks, but that doesn’t mean I haven’t been doing gamedev-related stuff. 

I’m already thinking about my next game. 

I won’t say too much about it yet — things can change — but it will make heavy use of procedural generation, emergent narrative, and persistent states. 

If that sounds overly ambitious, it may very well be, but to that end I’ve laid out several “guardrails” to ensure I don’t scope creep the hell out of it. 

But if it all works out, this game will be “infinitely” replayable. Even I as the developer will be finding new things all the time.

On this business trip I’ve already got a nice long list of notes for how different game mechanics will work. Some of these I have already prototyped in the past.    

QUOTE OF THE WEEK:

“The programmers of tomorrow are the wizards of the future.” — Gabe Newell

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

7 OCT 2023:


Finally back from my business trip (and very very jetlagged!) Nonetheless, here are this week's updates:

- Adjusted the "scrapstorm" so that it looks like the debris is hurtling towards you faster. 

- As shown above, not only the player, but the satellite can also be damaged by scrap now. It will look better when I make some explosions in Embergen.

- Fixed a nerve-wracking bug where the player shots were getting cut short after destroying some scrap. Like seriously, I spent more time fixing this bug than anything else this week. Thankfully I got it figured out just in the last hour or so. 


QUOTE OF THE WEEK:

"Never trust a computer you can't throw out a window." -- Steve Wozniak

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

(1 edit)

14 OCT 2023:


- Spent a lot of time this week making explosions in Embergen! There are 4 just for the satellite:

  • explosion after being hit by player's rapid laser
  • explosion after being hit by player's scrap cannon
  • explosion when a satellite segment is destroyed (shown above)
  • explosion when the entire satellite is destroyed (shown above)

- Explosions can be a little random by having a different angle at which they're drawn. I had also experimented with random scale, but that complicated positioning and images scaled larger just don't look as good as 1:1 images. 

OTHER NEWS:

- Recently finished listening to episode 104 of the Game Design Round Table podcast. It mentioned a good website, whose writer is the source of this week's quote.

- I also came across this website that features news from around the video game industry.

- Haven't had too much time to play games, but I have enjoyed a couple hours with The Bloodline. It's basically a low-poly Skyrim made by a single indie developer. I asked him on Instagram how long he had been working with Unreal Engine 4 and he said "about 4 years", which sounds very reasonable for a project of that scope. 


QUOTE OF THE WEEK:

"Many players cannot help approaching a game as an optimization puzzle." -- Soren Johnson

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

21 OCT 2023:


This week I started looking at my options for making backgrounds in Scrapship.

The main goal is to have a wide variety. Every time you play a level, there should be a good chance that the background will be different. 

So far I’ve tried: 

  • Blender — I can make good planets — if I have good textures to work with. Can’t really get much of a bloom effect though when saving with transparency.
  • Unreal Engine 4 — Same as above, but does a better job of creating an atmosphere effect.
  • Textures for Planets — Has the ability to make tons of different planet textures — but at a lower resolution. 
  • Space Engine Pro — Lots of realistic variety and uses transparency, but in some of my testing the resolution is still too low.

- Above is a screenshot with an Asteroid background from Space Engine (jpg format). Looks nice, but the downside to jpg is that it will make it more difficult to create dynamic backgrounds that don’t conflict with different layers. PNG format can fix this, but at an often huge cost in file size. 

Currently I plan on working with Space Engine Pro some more to see what I can do, but I am also looking at another option:

GEOGEN!

So JangaFX, the company that creates Embergen (which is what I’m using for explosion effects), just recently announced that they are making GEOGEN which will allow one to make planets and geographical textures. From what I gather, it’s around the beta stage, so I might have to wait a while if I want to try it out.  (I am not affiliated with JangaFX btw, but I do like their software). 

Currently on a business trip this week and next, so there won’t be much in the way of Scrapship updates, but of course I’ll think of something to post.


QUOTE OF THE WEEK:

“Ideas are easy, games are hard.” — Rob Daviau (episode 105 of the Game Design Round Table podcast)

(The context behind this quote was if game developers should be cautious about sharing ideas for upcoming games they want to make. In his estimation, one shouldn’t be too worried — even if you have a great idea, actually turning it into a reality is such hard work that it is unlikely that someone would try and steal your idea and beat you to market.)

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

(+1)

28 OCT 2023:

Just got back from my business trip last night. Since there are no Scrapship updates for this week I'll share with you the latest cool gamedev-related things I've come across:

  • Saw a really good YT video between Jordan Peterson and Robert Sapolsky where they discussed Game Theory as applied to human behavior. Very deep discussion! Watch the video for +10 to your Intelligence.
  • In particular, I found this gem in the comments section. Great stuff if you're contemplating the next Skyrim or Dwarf Fortress. The post was by @BillWiltfong

This is the best talk anyone has ever done for giving game designers ideas on how to describe and stat out a human race in a fantasy RPG.

"Humans are the race of people who are driven, never satisfied, always yearning for a future they can never see. The limitations of their lifespans, far shorter than those of elves and dwarves, produces a people who strive in everything they do to transcend the limitations of their finite lives. Yes, they yearn for an eternity they cannot fathom, but the only means by which they can reach it is to find the greatest struggle, and face off against it. This is why humans have spread further from their homelands than any other race, and why humans are found in every climate and every niche. If it can be done, humans will find how it must be done, for the only option for a human to fail, and yet continue on in another lifetime with another effort, is to give the future to his or her offspring, set and prepared for even greater works."

- Also saw this Star Engine Tech Demo which looks really promising for the future of game engines. The real test though will be how easy it is to work with and how much support it gets. 24 minutes well-spent!


QUOTE OF THE WEEK:

"The path of maximal adventure is better than the path of infantile satiation." -- Jordan Peterson (from the video mentioned above, 1:21:42)

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

4 NOV 2023:

- Made lots of 4k backgrounds with Space Engine Pro this week. Steam says I've used the program for about 15 hours.

- The backgrounds are oversized jpg images that are then compressed, using this awesome online tool that I found. Compressing the images decreased the initial load time by half! Nice! Because the images are oversized, I can position them on the screen with a little variation.

- I continued working on planets as "middleground" objects and to give a slight parallax effect. But there were 3 problems:

  • Although Space Engine Pro can generate png's with transparency, it can only go up to 1024 resolution (in skybox mode). So all the renders were not very detailed.
  • Even small png's caused the game to lag noticeably.
  • Getting the planets to look right during level transitions was . . . not impossible, but not worth the effort that would be required to get it working properly.

- Obviously performance is better than "looking cool" so I made the decision to scrap the "middleground" planets entirely. 

- When a level is completed, the player will warp to the next. Above you can see a preview of that (minus the railgun which I haven't added back in yet). 


IN OTHER NEWS:

- Started playing Red Dead Redemption 2. All I have to say is, wow, the level of immersion and detail in that game is amazing. There were quite a few parts that felt more like a movie than a game.  

- Have you ever thought about how much you spend on Steam? I made a spreadsheet and calculated that I've spent over $800 on games -- most of which I haven't completed or even play anymore. Sad, isn't it? As a result, an early resolution of mine is to only buy games that are on sale.

- Star Ocean: the Second Story R just released -- so it's definitely not on sale -- but they did have a demo. And what a demo it is! I remember playing the original on the PS1 and couldn't get into it. But this new version is just fantastic! Loving the 2.5D art style.


QUOTE OF THE WEEK:

"True creativity flows only from stillness." -- Eckhart Tolle


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

(+1)

11 NOV 2023:


Put in quite a few hours this week, including most of yesterday! Above you can see how Scrapship looks when the whole screen is visible. The warping is because I'm forcing the game to change levels rapidly. 

- Added in all level backgrounds:

  • Levels 1 and 2 is a random planet background
  • Level 3 is an asteroid field
  • Level 4 is a random deep space background
  • Level 5 is a black hole

- Ensured that music changes during level transitions

- Added the titlescreen back in.

- Asteroids can be destroyed (needs an animation though)

- Added option for Captions On/Off as there will be some voiceovers integrated later.

- Mostly done adding the shield fighters back in. The big win here was that I was able to reduce file size 80% by trimming with Aseprite and hand-jamming coordinates to reposition segments. I plan on doing this same thing to all the enemies.

- After much thought, I also made some last-minute design decisions:

  • I got rid of the easy/normal/hard difficulty levels as the game is designed to adjust difficulty in-game anyways. 
  • Removed the railgun and ability to heal between levels. Because the game is designed for a short play experience (~15 minutes), I think it makes sense to have the game be harder rather than easier. So it will definitely be more roguelike in the sense that you only have one ship, one life! Also I was never happy with how the railgun looked as it was something I threw together in Blender.

Getting rid of things like this has also helped motivate me as it's less stuff to have to worry about. 

So how close to done am I? It's always hard to tell. The parts that are left to do have already been done before, they just need to be re-integrated into the new build. Lots of copy and paste, but also sometimes I have to recalculate coordinates and make minor edits to graphics.  

No promises, but things I will probably add in towards the end:

  • Gamepad support
  • Multiple languages for the captions (and maybe the audio?)


QUOTE OF THE WEEK:

"You must be prepared to work always without applause." -- Ernest Hemingway


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

18 NOV 2023:


- One of the harder effects for me to create has been the "electrocution" effect when you hit an enemy with the single laser. Thankfully I found this video that has an excellent (and up-to-date) tutorial on how to make lightning effects in Embergen. I tested about 10 or 15 different variations before settling on the one you see above.

- Also worked on scaling so that the game looks right at smaller resolutions. This is something that I have to do for each object that goes back into the game, so it's a little tedious. 


QUOTE OF THE WEEK:

"Every complex system starts as a simple system that works." -- Amy Jo Kim

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

(+1)

25 NOV 2023:

No updates this week due to Thanksgiving vacation. But here’s the motivational . . .


QUOTE OF THE WEEK:

“The only thing standing between you and your goal is the story you keep telling yourself as to why you can’t achieve it.” — Jordan Belfort

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

(+1)

Hey 40watts! Just thumbed through your devlog for the last three years! It actually made me emotional seeing the simple square asset prototype to now being a full blown indie game with mechanics and polished up graphics of your desired style. I wanted to ask if you need music and sound for project seeing as its at 80% completion. Making sounds and music is my fulltime job so I wanted to go ahead and reach out to see if you were in need of it :) Otherwise, keep going strong! Would love to see the final product in action. - Jake

(+1)

Hi Ohpal! Thanks for taking the time to look at my devlog, there's a lot of entries for sure. 

I already have music and sound effects for my game, but I do like to keep a list of potential composers / sfx artists for future projects, so I'll keep you in mind.

(+1)

2 DEC 2023:


- Continued reintegrating the shield fighters. It has rocket flames again. 

- Moving away from sprite sheets as it causes issues on lower screen resolutions. Thankfully I can still get the animations to look correct with little or no impact on performance.

- In previous versions, the player explosion particle effect happened in a sort of vacuum where all of the background images would be absent. I fixed that this morning, as shown above. So now when you get destroyed, all the background objects are still there and active.

- Fixed a bug where the electrocution effect was animating in random locations.


QUOTE OF THE WEEK:

"There is little success where there is little laughter." -- Andrew Carnegie


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

9 DEC 2023:


- Scrap is not just a threat to the player, but to your enemies as well! I think this is a nice touch in the name of consistency. It would be weird if scrap hurt you and not the enemy ships. 

- If you look at the right-most shield fighter, you can see a new explosion effect I made in Embergen. 

Some notes on the gif above:

- Enemies aren't moving because it's easier to test them for hit detection when they're stationary. Movement will be added later when I do the AI.

- This is what the full game screen will look like (hopefully not that small though, although I have tested it on a 7" monitor.) Ideally you'll have a 32" widescreen monitor.

- Very minimal UI and what UI elements you do see will be integrated into the environment. Above you can (kinda) see 2 of them: The orange dot on the player ship indicating what weapon is currently selected and the green outlines of the scrap indicating when they are a threat to the player. 


QUOTE OF THE DAY:

Sharing two that I just read in StephanRewind's excellent Atlantic '41 blog here on Itch.

". . . a good composition always alludes to something more, outside the boundaries of the canvas."

". . . you make a game for other players too, and you can't always assume that they'll play it as you intended."


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

16 DEC 2023:

- Trimmed and logged coordinates for the bomber graphics. Originally the bomber sprites took up 3MB, now they only take up 1MB!

BEFORE:



AFTER:



QUOTE OF THE WEEK:

"Software and cathedrals are much the same -- first we build them, then we pray." -- Samuel T. Redwine Jr.

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

(+1)

This is awesome! :D

Thanks BlueJumperFox, glad you like it!

23 DEC 2023:

- Now that the bomber sprites are all trimmed, I started putting the code back in so they appear in the game. Originally I was using a scale function to draw them, but found that the trimmed sprites have major coordinate issues. Basically none of the bomber segments were aligning properly and just looked like a jumbled mess. Really didn’t want to spend all week troubleshooting that so I took an alternate route where I just draw the sprites to the screen directly with _PUTIMAGE. 

- Not a whole lot of progress this week and next . . . but progress nonetheless!


IN OTHER NEWS:

Godzilla Minus One is a lot of fun to watch! Until yesterday I hadn’t been to a movie theater since before Covid. 


QUOTE OF THE WEEK:

“First do it, then do it right, then do it fast.” — Addy Osmani


Thanks for reading and have a Merry CHRISTmas!

30 DEC 2023:

- Started adding the bombers back into the game. All 4 types are assembled and drawn correctly and can also be damaged. 

- Fixed a graphical inconsistency where part of the bomber tail section would be floating unattached to anything if the middle segment was damaged while the wings were intact. 

- I forgot to mention this last week, but this devlog just passed 15,000 views. Thanks to everyone who has read, liked and/or commented over the years! 


- Scrapship is made using QB64PE, a modern version of the QBasic programming language. If you're interested in the QBasic programming language -- or just want to try some retro-style games --  check out the 5th QBasic Game Jam which is wrapping up soon. Although I'm always asked to participate, I usually don't since that would detract from my progress on Scrapship. But it is fun to play and rate the games and see what other people can do.


PLANS FOR NEXT YEAR:

I really want next year to be the year that I finish Scrapship. I was hoping it would be this year, but my job has a lot of business trips that take time away from game development. So  we'll see how it goes, although there is also a big possibility that I'll be changing jobs next year as well. Either way, I'll keep chipping away at this project until it's done. 


QUOTE OF THE WEEK:

"It's never too early to think about performance." -- Rebecca Parsons


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

6 JAN 2024:


- All-new bomber explosion which you can see at the very end of the gif above!

- Added back in most of the bomber code. The bombers above don't move as they're still in a testing phase while I work some bugs out.


The 5th BASIC Game Jam had some really good entries! My favorite two were a puzzle game called TapOut and a side-scrolling endless runner called Ruins of Zeugma.


QUOTE OF THE WEEK:

"If we wait for the moment when everything, absolutely everything is ready, we shall never begin." -- Ivan Turgenev

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

(+1)

13 JAN 2024:

- Bombers and bombs are finished.

- Started adding the Cruisers back in.  Almost done with that. Just this morning I was working on getting the attack animations to work again. 

- On the sticky note on my monitor I have 7 more TO-DOs before I can call the game done:

  • Cruisers
  • Battleships
  • Carriers
  • Cargo Boss
  • Final Boss
  • AI (for all enemies)
  • Other (voiceovers, gamepad support? minor adjustments, bugs, playtesting, etc) 


QUOTE OF THE WEEK:

"Always do what you are afraid to do." -- Ralph Waldo Emerson

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

(+1)

Keep up the good work buddy!

Thanks Trisani Studios!

20 JAN 2024:


- Finished adding the cruisers back into the game. 

- Created a new cruiser explosion animation. 

- Started working on the battleships. This is going to be tedious. As you can see from the screenshot above, just one battleship has a dizzying number of gun sprites to cover all the different firing positions and states. As with all the previous enemies, I huge change here will be the fact that I'm trimming all of the images to save space.

Above is one of the guns before trimming. As you can see there's a lot of wasted space above and left.  The real benefit to keeping it like this is that it allows me to place the image using just one x,y coordinate.  For all the guns in the first screenshot, I have to use Aseprite to get the updated coordinates which I'll then have to update in the code so they draw correctly. Hopefully I'll be able to draw more than one battleship to the screen without losing fps. The last build of Scrapship could handle one battleship but lagged with the addition of any other enemies.

I'll see how the "trimmed" battleships work, but if I deem it impractical then I'll revert to my original files (in the ORIG folder) and go with that.

- Also updated my version of Aseprite to 1.3.2. You can update Aseprite by going to their website.

- You can get spend a lot of time trying to make an explosion in Embergen -- especially if you're doing it from scratch. But a quick and effective workaround I've found is this: Take one of the presets and view the explosion from top-down instead of making an animation of the default camera angle. Then change some of the values to your needs.  This allowed me to make the cruiser explosion in less than an hour.


QUOTE OF THE WEEK:

"Those who keep learning will keep rising in life." -- Charlie Munger


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

27 JAN 2024:

- The first of four types of battleships is mostly back in the game. It can be drawn to screen and both guns can move and fire.  Lots of coordinates! I keep a stack of scratch paper for writing all the values down after I get them from Aseprite:

Then I have to program all that into the game:

Then I test it to see if it works properly:

Now I just got to do that workflow for the other 3 types of battleships and add the damage code back in.


QUOTE OF THE WEEK:

"To improve is to change, so to be perfect is to have changed often." -- Winston Churchill


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

3 FEB 2024:

If you look at last week's GIF, you'll notice that the forward gun "jumps" when it fires. This was a bug I noticed just after I posted my devlog. As it turns out, this bug was present in several other firing positions as well. I tried manually adjusting the coordinates and still couldn't get it to line up or display properly. I'm sure if I kept at it I'd figure it out, but troubleshooting it was taking quite a bit of time. In the end, I decided to revert back to the old battleship code and untrimmed images. One step back, two steps forward . . . 

- All 4 battleships draw to the screen and fire correctly. No "jumping" bugs.

- After doing some tests, I concluded that the trimmed battleship images didn't really improve performance all that much. Trimmed and untrimmed versions of the battleship still exhibit noticeable lag. But the real cause of this is not so much the battleship as the background which covers the whole screen and is drawn every iteration. So I might have to regulate the larger enemies like the battleships and carriers to "deep space" levels where the background is mostly black with no large background images to process. 

- To finish the battleships, I need to re-add the code for damage and make sure some of the animations still work.


QUOTE OF THE WEEK:

"Opportunity is a haughty goddess who wastes no time with those who are unprepared." -- George Clason


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

(+1)

10 FEB 2024:

- All the battleship code is back in the game. They can now be damaged and destroyed, as well as damage and destroy the player.

- Fixed a bug where the battleship gun explosions didn't stay aligned with the ship.

- Added all the variables required to make the battleship scale at different screen resolutions.

- Right now I'm thinking that the battleship needs to be strictly a "deep space" enemy against a minimalist background to keep the framerate up.

QUOTE OF THE WEEK:

"Let's optimize for player experience rather than what we think will make more money." -- Ron Carmel


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

(+2)

17 FEB 2024:

- The first of 4 types of carriers is now back in the game. So far it looks like I'll be able to use trimmed carrier graphics for a slight performance boost.

- Tested the battleships on my son's laptop and ensured that scaling works properly.

- Scrapship enters its 4th year of development! I never would have thought I'd be working on a "simple shmup" this long! But to keep things in perspective, I only do an hour of gamedev a day, excluding vacations, illness and business trips. Regardless, it is still a challenge to stay dedicated to a single project for so long. You might be wondering, does he ever feel like this?


And the answer would be "Yes, quite often!" I have a "dream game" idea that's been in my head for a while now that I'm eager to get started on. But besides all the motivational quotes I surround myself with, there is a particular meme that has been very helpful in staying focused . . .

QUOTE  MEME OF THE WEEK: (One of my favorites)


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

(+1)

24 FEB 2024

- Two of the four carriers are now back in the game.

- Restructuring the carrier code so all 4 types can use it.

SIDE NOTES:

This week I found some interesting YT videos about programming language speed, like Assembly vs C++ vs Python. It's amazing how much slower some high-level languages can be when tasked to run a "simple" task like counting to a billion. There were no "speed test" videos for QB64 (QBasic) though, so I made a little program to see how long it would take QB64 to count to 1 billion:



If I run it without printing to the screen, QB64 can finish it in 2.197 seconds. But if I uncomment my PRINT statement it takes considerably longer: 7.6 minutes!

I think speed tests like these are good for understanding what your programming language is capable of so you can pick the right language for the right project. Imagine programming a complex game like Dwarf Fortress in Python!


QUOTE OF THE WEEK:

"A comfort zone is a beautiful place, but nothing ever grows there."

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

(4 edits) (+1)

Nice to see you're sticking with your project until the end, you really understand the importance of finishing something you started! Props to you!

I just noticed your attempt to benchmark QB64, and I couldn't hold myself from giving you my two cents on that matter as I worked on developing benchmarking applications for embedded devices for 4 years of my life.

Your loop only has a print command in it, which basically has the same implementation on almost every language, it's a OS interruption basically (interop), so you're not actually measuring the performance of your language but rather measuring the OS interop to print a value. The interop sometimes hold the application until it has completely executed your task, in this case printing a value, so that's why it takes minutes to finish your test.

The simplest but accurate language benchmark I can think of is maybe a MD5 solver for a very long string, or something similar, anything simpler will most likely diverge from the actual purpose of the benchmarking.


Now there's a good overall simple rule to know if a language is fast or slow: How is it converted into machine instructions?

The fastest languages out there are the LLVM compiled languages, like: C, C++, Fortran, Rust and Zig

The slowest are the interpreted languages, like: Ruby on Rails, Python and JavaScript

There are also some languages that are not exactly interpreted, but something like compiled to a intermediate stage just to be translated into machine code, they are like the "half way" between compiled and interpreted languages, like: C#, java and Lua. That's why, although very slow comparing with languages like C++ and Rust, they are still quite fast (mostly what slow them down is a system called garbage collection).

As for QB64(I never used it) but it seems like they can be either compiled (not LLVM though) or interpreted too, so yes it can be very fast, just one step behind languages C++, Rust and Zig.

Hi FearCode! I'm admittedly inexperienced when it comes to benchmarking programming languages so thanks for the insights! Not exactly sure how I would implement an MD5 solver, but I saw on YT that another benchmark method is to see how many "passes" a programming language can make in 5 seconds when solving for all prime numbers. 

According to its creator,  "The QB64 compiler converts BASIC code into C++ code, and then uses a third-party C++ compiler (GCC) to compile the C++ code into an executable file."

For now I'm pretty happy with QB64, mostly because it's what I'm familiar with and pretty easy to work with. But if I need something blazing fast I'll definitely be checking out those low-level languages. I've played around with C++ a little bit, but I'd have to really dedicate some time to get to a point where I can work with it.

(1 edit) (+1)

Interesting, didn't know the compiler converts to C++, yes, then if you just switch away from GCC (to clang or msvc) it may be as fast as C++ itself (depending on how good this converter is, ofc)

About the video from dave's garage, it's okay-ish, but not enough, I use this site as a good reference, they are old timers, and have a lot of benchmarks from mandelbrot to reverse complement. As you can see: C, C++ and Rust are the fastest on an average of all their cases (note that unfortunately they don't use a LLVM for C and C++ which could make them even faster).

For games I do recommend C++, it's not only blazing fast but also the best in terms of content and tools produced for game development, but to be honest you can make a very good and efficient game on any language.

Java. for instance, I have a history with it and oh boy it's a painfully annoying language, specially for game dev, but still it was minecraft's first development language, it all comes to how you make it, as long as you leave the heavy lifting to the GPU you can even make hardcore games in python (that may be too much lol, Lua maybe?) 

So yes, if you're comfortable with QB64, go ahead I and finish it up in there, I know it will be just fine

(+1)

2 MAR 2024:


- I have a business trip the next two weeks, so I challenged myself to finish the carriers before I have to go. 

- Carriers are done! I made some pretty significant changes to them this time around.  The up and down carriers were being problematic so I removed them completely. For at least one of them, I would have had to rework the original Blender files to fix some issues and that would have taken who-knows-how-long.

- Carrier fighters can attack from up to 4 different directions. I wasn't entirely pleased with the old carrier fighter logic, so I created this new attack method for them which is much less math-intensive. And in my opinion it's a lot more interesting and fun.

- Scrapship is currently up to 11000 lines of code. There is only about 3000 lines of code left to transfer over and reintegrate. 

- As for my sticky note on my monitor, the only things I have left are "Cargo Boss", "Final Boss", "AI" and "Other". 

- 12 of the 16 sticky note tasks have been completed, so I'm about 75% done.


QUOTE OF THE WEEK:

"That's what games are, in the end. Teachers." -- Ralph Koster

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

(+1)

9 MAR 2024:

Still on my business trip so no Scrapship updates, but I am looking forward to getting back so I can finish it up. 

I’ll be changing jobs in the near future, but this shouldn’t affect development of Scrapship as I only need an hour a day to work on it.  If I’m unemployed I’ll probably work on it even more — it’d be a nice break from job hunting and studying for IT certifications.

QUOTE OF THE WEEK:

“Excuses are the nails used to build a house of failure.” — Jim Rohn

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

(+1)

16 MAR 2024:

Got back from my business trip a little bit early! Saw the winter weather in the forecast for Colorado Springs  and said "nope!" Apparently a lot of other people had the same idea. 

- This allowed me to get a little bit of work done on my return. I've started putting the Cargo Ship boss back into the game. So far it's mostly a matter of copy and paste, but there are a few minor glitches I need to iron out. If all goes well I should have it done by next week.


- Ever wonder who 40wattstudio is? Well wonder no more because I made a version of myself in Dragon's Dogma 2 Character Creator (free on Steam!)

Even with all the customizability, I'd say it's about 80% accurate. Needs to look about 10-20 years older and slightly less hair on top. And there was no option for glasses (or any other accessories).

Anybody else play around with the DD2CC? I think it's pretty cool and a great way to get people into the game before it comes out.


QUOTE OF THE WEEK:

"Create with the heart. Build with the mind." -- Criss Jami

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

(+1)

23 MAR 2024:

- Cargo boss is pretty much done but needs testing to make sure the scaling works on different screen resolutions. After this I'll be able to start work on getting the final boss added back into the game!


QUOTE OF THE WEEK:

"A game for everyone is a game for no one." -- Arrowhead Game Studios

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

(+1)

30 MAR 2024:

- Cargo boss is done! This includes scaling. 

- Final boss can be drawn to screen, take damage and shoot lasers. Currently working on the bomb attack it has.


QUOTE OF THE WEEK:

"Finding opportunity is a matter of believing it's there." -- Barbara Corcoran

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

(+1)

6 APR 2024:

- Final boss is done! I also managed to improve some of the hit detection.

- The single laser has some new functionality! It is the only weapon in the game that can be used to shoot down bombs, whether they're fired from bombers or even the final boss! 

- Now that the enemies are done I can start working on the AI!


QUOTE OF THE WEEK:

Your focus determines your reality.

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

13 APR 2024:

- Started working on the movement/AI! 

  • Shield fighters spawn in a variety of formations
  • Bombers swoop in and spawn in a variety of formations
  • Cruisers spawn in a variety of formations (in progress)


QUOTE OF THE WEEK:

"The most valuable thing you can make is a mistake -- you can't learn anything from being perfect." -- Adam Osborne

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

20 APR 2024:


- Cruisers can spawn in a variety of formations (down, left to right, right to left and cross pattern)

- Battleships can spawn in a variety of formations. 

- Also tested scaling works properly by running the game on a 7" display.

- Tried out Geogen to see what it was capable of in regards to creating planet graphics, but it's still very primitive (only version 0.2). There was a very promising program called Space Fabricator by Imphenzia, but it appears that the software is no longer available. 


QUOTE OF THE WEEK:

"Success has many fathers, but failure is an orphan." -- Tim Cain


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

27 APR 2024:

- Carriers can spawn in a variety of formations.

- Cargo boss AI is done. Also fixed some bugs:

  •  Explosions were in the background instead of the foreground.
  • Cargo boss "jittered" after becoming active.

- Final boss AI is done. Right now I'm making some changes to HP values and how different weapons react to different segments.


IN OTHER NEWS:

When doing a long project like a video game, it's a good idea to have smaller goals to work towards. For example, earlier this year I learned about this  Conqueror app (non-affiliated) and I've found that it's really good for motivating me to get outside more and exercise. I started the Great Wall of China virtual challenge in late January and just finished yesterday -- 161 miles in 90 days. Besides the health benefits of walking regularly, working towards short-term goals like this help you to stay consistent and remind you what success feels like. 

I also noticed that walking regularly helped clear my mind and gave me great opportunities to think about problems encountered while working on Scrapship. 

Some good ideas for other short-term goals: Reading a book, watching all the videos of a certain YT series,  getting a certification or degree -- anything whose completion can give you a great sense of accomplishment can help you stay motivated  on longer projects. 


QUOTE OF THE WEEK:

"The fears you don't face become your limits."


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

4 MAY 2024:

- Almost done implementing a new way for explosions to be handled in the game. Previously, each enemy type could only show one type of explosion. Now, each enemy  can explode up to 7 different ways, along with rotation and scaling variations. Makes the space combat look much more dynamic! Also, explosions have some logic to them so that weapons like the more powerful scrap cannon will always show larger explosions than weaker weapons. As you can see in the gif above, I still need to work on the hit detection a little so that explosions show up directly over the object instead of at the very edge of it.

- Reduced game load time to about 9 seconds (was 12 previously.) Because I can now scale explosion animations, I reduced the default size of some of the larger ones and also removed empty and excessive frames. 

- Trimmed some of the level backgrounds. Some of these were originally 3k pixels by 2k pixels or larger, so making some of these smaller by removing extra black space has also helped give a performance increase.


IN OTHER NEWS:

The BASIC programming language turns 60!  For those of you new to this devlog, one of the oddities of this project is that it is being written entirely in a modern version of BASIC called QB64PE. As you can tell by the 4+ years I've been working on this project, writing your own code is quite the challenge, but you end up learning so much more about actual game development than if you had just used a game engine. While most people associate BASIC with primitive text adventures and ugly pixel graphics, one of my goals with Scrapship has been to show how awesome the language can be for game development.


QUOTE OF THE WEEK:

"Don't count the days. Make the days count."

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

(+1)

11 MAY 2024:

- Simplified the explosion animation function and fixed a bug that was causing the game to crash when 2 different explosions were on screen simultaneously.

- Trimmed the rest of the level backgrounds. This brings the initial load time down from ~9 seconds to ~7 seconds.

- Adjusted the explosion animation coordinates for the satellite and shield fighters.


QUOTE OF THE WEEK:

"An essential aspect of creativity is not being afraid to fail." -- Edwin H. Land


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

18 MAY 2024: 

- This week saw a lot of minor refinements across the board, with the big end result being that I'm now in a "good enough" place to start working on levels. Maybe a minor bug here and there -- but that I'm aware of -- nothing game-crashing. There are always improvements that can be made, so I'm doing my best to squash my perfectionistic tendencies.

- Minor hit box adjustments for all enemies  -- mostly for animation purposes. 

- Fixed a long-standing bug where some of the shield fighters would overlap when in formation. 

- Shield fighters now have 5 different formation types.

- Started placing enemies in their respective levels.


QUOTE OF THE WEEK:

"You not believing in yourself is a tragedy. Stop that."


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

25 MAY 2024:

- Added a spawn timer for enemies. What's unique about this is that it adjusts based on player performance. If the player is doing really well (not taking damage, destroying lots of enemies, etc), then enemies will spawn sooner. But if the player is doing poorly (taking damage) then the enemies will spawn less frequently. This mechanic essentially gets rid of the need for "difficulty levels" since they are adjusted in-game automatically. Still need to work on refining this.

- Fixed a bug where the carriers had a missing frame of animation causing the game to glitch out.

- Fixed a bug where the cruisers caused the game to get stuck in an endless loop. Thank God for log files or I would have never figured this one out!


QUOTE OF THE WEEK:

"A negative mind will never give you a positive life."


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

(+1)

1 JUN 2024:


- Made some good progress on the AI this week. In the picture above you can see the player engaging a bunch of different enemies, including a battleship. There is a nice sense of unpredictability as to which enemy will show up next. 

The game handles the smaller enemies well enough, but I am noticing lag once the battleship (or any larger enemy) goes active. So to fix that, I'll have to find ways to trim down image sizes (most likely the level backgrounds) and/or spawn larger enemies when there isn't much activity going on. It's a balancing act between fps and difficulty.

Right now the logic goes something like this: Every time an enemy goes active, the spawn timer increases. Every time an enemy goes inactive by being destroyed or going off screen, the spawn timer decreases. Then on top of this there is a calculation based on how much damage the player has sustained. The game gets a little easier the more damage you take.

- I changed the outline of the scrap to red instead of green. My reasoning for this is because scrap can damage you and green almost invites the player to fly into it! So instead I tried a red outline, which communicates the dangerous aspect of the scrap better, but admittedly doesn't have quite the color contrast as green did. I probably just need to thicken the outline a little and it should be ok.

- Battleships can now flank the player if there is more than one. This also prevents the battleships from spawning on top of or too close to each other. 

- Fixed some more game freezing bugs involving shield fighters and bombers. Every now and then I'll see some other bugs but I'm not going to worry about them too much unless they actually cause the game to freeze or crash.


QUOTE OF THE WEEK:

"Challenge yourself; it's the only path which leads to growth." -- Morgan Freeman


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

8 JUNE 2024:

- Lots of progress this week, probably bringing Scrapship the closest it’s ever been to being released! I’m actually taking it to a friend’s house this weekend to have him try an early version of it.

- Fixed the load issues by scaling down some of the background images to 1/4 of their original size. Load times are now consistently between 6 and 10 seconds. 

- Infinite foreground asteroids in level 3.

- Added a new star background to the 4th level. This will allow me to spawn larger enemies without causing lag. 

- Increased final boss health to make it more difficult.

- Cargo boss now scrolls down the screen when triggered.

- Lots of bug fixes (and thankfully none of these were game-crashing ones). 


QUOTE OF THE WEEK:

“The only way to do great work is to love what you do.” — Steve Jobs


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

(+1)

Congrats on getting so far with the game. It looks amazing!

(+1)

Thanks TheMetalCarrotDev! Looking forward to finishing this project soon so I can start something new!

15 JUNE 2024:

- The game now keeps track of how much scrap you've destroyed. Added a scrap counter to the stats screen.

- Levels only transition when X amount of enemies have been destroyed and all scrap is off screen.

- Enemies now reset between levels.

- Cargo boss only appears when X amount of enemies have been destroyed. After this, it slowly scrolls down the screen and limits player movement to the X axis. When the Cargo boss is entirely on-screen there is now a slight pause before triggering the animation that starts the boss fight. 

- Fixed bug where Cargo boss was being destroyed prematurely.

- Fixed bug where player damage wasn't being persisted between levels.


QUOTE OF THE WEEK:

"Seek what sets your soul on fire."


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

(+1)

22 JUNE 2024:

- Finished level transitions.

- Cargo boss stays in bounds when scrolling on screen.

- Added a timer that determines how long each level is. 

- The entire game can be played from start to finish with the exception of some sort of transition to the credits roll and a few other minor things to fix. I certainly don't plan on adding anything new at this point, just adjusting things as they are. 


QUOTE OF THE WEEK:

"Challenges are what make life interesting, and overcoming them is what makes like meaningful." -- Joshua J. Marine

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

29 JUNE 2024:

Lots of minor additions and fixes this week as the game is very near completion:

- After beating the game, player will get to see a stat screen showing how many enemies they destroyed.

- Battleships deactivate if they are a certain distance off-screen.

- Carrier fighters are slightly brighter for better color contrast.

- Cargo boss can scroll down the screen faster if the player flies forward. 

- Deleted about 400 lines of code by simplifying types and removing unused variables.

- Fixed bugs where objects kept moving when the game was paused. 

- Fixed bug where stars were not scrolling properly.


Still the occasional graphical glitch here and there, but so far haven't encountered anything game-breaking or that would cause an unfair player death. AI still needs some work and I need to verify the game still works at different resolutions.

I happened to see that Space Engine Pro (what I've been using for my space backgrounds) just got a new update where you take high resolution screenshots. Although it's tempting to take advantage of this I know it's just going to cause lag because I've already had to scale down or use lower resolution versions of some of the graphics.

QUOTE OF THE WEEK:

"Don't wait for the right opportunity, create it."

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

6 JULY 2024:



Lots of progress on a variety of things. Also doing lots of playtesting to see if anything is broken or needs adjusting.


ADDITIONS:

- New galaxy backgrounds to level 4 to make it feel less empty (see screenshot above).

- Galaxy scrolls in and out during level transitions.

CHANGES:

- Only one carrier spawns at a time now to prevent overlap and lag.

- Reorganized hit detection code based on current level.

- Black hole speeds away faster when final boss destroyed.

OTHER: 

- Copied the contents of this entire devlog (minus comments) to Word so that there is an offline version.

BUG FIXES:

- Shield down animation restart glitch when hit with single laser.

- Battleship 225 image misalignment between the top and bottom segments.

- Objects not pausing on pause screen.


A big thanks to everyone for helping this devlog to reach 20,000 views!!! As I was copying the devlog to Word I was also moved by all the supportive comments over the past 4 years. 


QUOTE OF THE WEEK:

"You only fail when you stop trying."


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

13 JUL 2024:

- Battleships and carriers deactivate if off-screen for a certain amount of time. This also fixed a bug where  level 5 never triggered.

- Continued working on AI system. It's getting closer to where I want it to be.

- Fixed game-freezing bugs and glitches related to the pause screen.  The game could only be paused by stopping all the code that made things move. A truckload of boolean checks took care of this, but was causing all kinds of weird graphical glitches. Next I tried a different approach and made a special subroutine that would only display the objects, but even that experiment was all kinds of buggy. Ultimately I went with a much simpler pause screen to avoid getting rid of it altogether.


QUOTE OF THE WEEK:

"Perfection is not attainable, but if we chase perfection we can catch excellence." -- Vince Lombardi


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

20 JUL 2024:

- Made quite a few last-minute fixes to the game. Some of the levels were noticeably laggy and the level transitions themselves weren't my favorite. But in the end I think it's better to have a smooth and consistent gameplay experience -- even if it means removing pretty graphics. So I removed the skybox backgrounds and the performance is vastly improved -- no more lag! There are still background objects (stars, asteroids, planets). I might add a couple more small objects in for variety.

- The asteroid field in particular got a complete overhaul. Instead of using an asteroid skybox, I procedurally created my own and the final result looks very good!

- Reworked all the level transitions so that one level seamlessly blends into the next.

- I'm finally happy with the AI.

- The game is more fun than I thought it was last week. You can stay around and shoot down the enemies or almost play it like an endless runner and avoid most of them.

- Added voiceovers.

- As far as running the game on my PC is concerned, the game is probably 99% complete -- a couple bug fixes and maybe some more background objects, but that's all.

- Tested Scrapship on my son's laptop and the experience is the same for the most part -- there are some bugs that need addressing, but nothing game-breaking.

- Scrubbed the code to fix some inconsistencies and bugs.

- Looking forward to finishing this thing!!!


QUOTE OF THE WEEK:

"Find radical joy in the hardest of pursuits." -- Eva zu Beck


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

27 JUL 2024:

- Not much to report on my end, just minor changes and tweaks here and there. For the most part I’m just waiting for feedback from early playtesters to see if there are any last-minute bugs or changes that need to be implemented.  So I don’t exactly want to call Scrapship done, but it pretty much is. Unless some major game-breaking bug pops up or something you can expect to see it by the end of August!

QUOTE OF THE WEEK:

“If people are not laughing at your goals, your goals are too small.” — Azim Premji

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

3 AUG 2024:

Playtesting continues. Expecting to release the game sometime this August!

- The full game will be 100% free. No ads and no microtransactions.

- Apart from the initial download, no internet connection is required to play Scrapship. I love offline games.


QUOTE OF THE WEEK:

“Consistency is what transforms average into excellence.”

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

10 AUG 2024:

- Got some good feedback this week from one of my early playtesters. Good to hear that Scrapship seems to be working fine on other computers and -- most importantly -- no game-crashing bugs. 


- Game will be released sometime this August!

- The full game will be 100% free. No ads and no microtransactions.

- Apart from the initial download, no internet connection is required to play Scrapship. I love offline games.

- No AI was used in making Scrapship . Everything is made by humans.


QUOTE OF THE WEEK:

"There is no hard way around hard work. Embrace it." -- Roger Federer

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

17 AUG 2024:

- Adjusted final boss so that it needs to have both guns destroyed before it can take damage. This makes it a little more challenging because it was way too easy to beat earlier.

- Added a brief animation when the final boss appears (it warps in the same way that some of the cruisers do).

- Improved battleship and carrier spawning/despawning.

- FIxed an issue with the galaxy background not scaling properly.

- Added difficulty settings -- Easy, normal and hard. This is based on the strength of your weapons. Easy = 2x more powerful. Normal = 1x power, Hard = 1/2 power.

- Biggest milestone this week though was going through all 13,000+ lines of code and adding/removing comments. Was also able to find ways to simplify some of the code by consolidating several IF . . . THEN statements.


- Game will be released sometime this August!

- The full game will be 100% free. No ads and no microtransactions.

- Apart from the initial download, no internet connection is required to play Scrapship. I love offline games.

- No AI was used in making Scrapship . Everything is made by humans.

- Full source code will be available for purchase for people interested in modding or programming. Apart from donations, this is the only way the game will be monetized. Let me reiterate again that the full game is 100% free.


QUOTE OF THE WEEK:

"We don't stop playing because we get old . . . we get old because we stop playing!"


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

(+2)

24 AUG 2024:

SCRAPSHIP

IS

DONE!

Whew! What  to say?  It's always been one of my "bucket-list" goals to make my own game. Thankfully technology has gotten to the point where it is completely viable to make a video game on your home computer.  But what really got me started was finding a thumbstick with some of my old QBasic programs I made in High School . . . nearly 20 years ago. Then I found that there was a newer version of QBasic, called QB64, that allowed one to run their old code on newer machines. That was a game changer! After that, I found an excellent Youtube QBasic series by SchoolFreeware that covered all the new QB64 features. The final project in that series? A Space Invaders clone. That was enough to get me thinking about the capabilities of QB64 . . . and what I could potentially do with it.

Development started early 2020, just before the pandemic. Released a couple demos where I was just toying around with different ideas. Started the whole project over once or twice.  It took over 4 years -- but keep in mind I was only working on it an hour a day unless I was sick, on vacation or on one of my many business trips.

Scrapship is far from a perfect game . . . and there are LOTS of things that could be improved on, but I am proud of what I was able to accomplish. Some of which I would deem rather complex (for QBasic at least). For me, the most remarkable thing is that I even finished it, because the truth is that Scrapship was never my dream game. A cool game, sure, but not my dream game. The secret to staying dedicated to a project for such a long time is consistency. Small doses of it, in my case.  Motivational sticky quotes help.

But now that it's done, I'm super excited about the future of 40wattstudio. For one, I just got accepted to WGU (Western Governor's University) where I will be pursuing my bachelor's in Software Engineering (C# path). This is mostly to increase my employment chances as I'm currently unemployed. In my spare time, I'm looking forward to working on some "dream game" projects I have in mind.  I won't share too much, but I've always liked Skyrim (and its incredible mod support) and I've poured countless hours into various versions of Civilization. So something along those lines. 


QUOTE OF THE WEEK:

"Dreams are watered by hard work."

Thanks to everyone for their support over the past few years and for making this one of the most-viewed Devlogs here on Itch.io! Have a great rest of your week!

(+1)

Well done! I've enjoyed watching the development of scrapship, really motivational stuff!

Thanks Spacepiano, happy to be of encouragement!

(+1)

Looks like my notes for my game except its on actual paper and its so much that I have a folder RESERVED JUST FOR those notes. And thats just the notes for one game. 

There certainly is a nice simplicity to paper that makes it good for a variety of gamedev situations. I keep a pile of scratch paper on my desk. 

Viewing posts 201 to 328 of 328 · Previous page · First page