9 JAN 2021:

This week I found the primary reason for the lag: Nested loops. One block of code alone was checking around 600 calculations. Thankfully I found a way to reduce this significantly by re-ordering the code.

With that issue out of the way, I also started work on a "new" enemy. The shield fighter. There were a few early demos with this enemy, but this new version will be completely redesigned and destructible.  I'm really excited about this one because it will add a new level of strategy to the game!

Click here for the latest demo

23 JAN 2021:

As I mentioned in my last week's post, I had a major decision to make and this week I made that decision:

Starting fresh! 

Surprisingly, I got quite a bit accomplished and I feel that things are moving in a very promising direction.

Here are the most important things I got done:

A NEW ASPECT RATIO

Scrapship will now use the 16:9 Aspect Ratio (instead of 1:1). The game will still take place in a square-shaped arena, but the far left and far right parts of the screen can now hold all my debugging variables, as seen in the partial screenshot above.

THREE SCREEN RESOLUTIONS

Instead of a screen sized 1000x1000, the options are:

1280 x 720

1920 x 1080

2560 x 1440

I think those three will be adequate for most players. Will one of those work on your computer? Please let me know in the comments!

BETTER SCALING

Most of my time was spent here. In previous demos of Scrapship, going fullscreen resulted in a very stretched and pixelated image. I've since learned a LOT about proper scaling techniques in video games. There is still a lot of testing I need to do here. I have code that will allow for automatic scaling, but it's very math-intensive (lots of sin and cos). If it bogs the game down too much, I'll have to look at other ways to achieve the same effect. 

========================================

My strategy this time around is to make sure the menus, screen resolutions, scaling, etc are all working as intended before putting in the actual gameplay. I like to think of this as the "canvas" for the game. You can have a great game, but if the screen the game is played on is not optimized, it's not going to look very good. By analogy, you could be a good painter like Da Vinci or Caravaggio, but if you suddenly have to paint the Mona Lisa on a canvas the size of a postage stamp it's probably not going to look as epic as you imagined.

One of the biggest things I've had to get used to this time around: Referring to screen positions as percentages instead of absolute values. If you place an object at coordinate 100, 800 and then resize the screen, things will look out of place. But if you make that coordinate a percentage relative to the screen size, then things fall into place where they're expected.

Thanks for reading!

Play the old version of Scrapship here.

30 JAN 2021:

Scrapship got its first donation!

This is really exciting for me and definitely motivates me to see the game through to completion!

One of the most important things I learned this week: Scaling works . . . but it also causes the image to "tear" a little and look a bit more jagged than usual. Scaling also sets the x and y coordinates to the center of the sprite instead of the upper left-hand corner. Basically this means that scaling will make hit box calculations much more tedious and complicated to write in code. So with that in mind, I still plan on using scaling, but only in specific instances.

Automatic monitor resolution: I also learned that QB64 has a command that returns the width and height of the current display. Using that, the game now automatically detects your monitor resolution and picks the most applicable window that will fit the screen! I tested this with my BenQ monitor at 2560x1440 and then tried it on my smaller Sceptre monitor at 1920x1080.

A proper pause button: The original  pause button stopped the game -- and that's it. The new one I'm working on shows a "Paused" indication while still showing all the frozen action on screen. Eventually I'll integrate a menu system of some sort so that the player can change things like sound and display settings mid-game.

Hide / unhide debug tools: Allows me to see the game as the player would see it, without all the variables cluttering the side of the screen.

Like any game, Scrapship uses a lot of pictures in various formats and I'm also learning a lot about how to display graphics as "cheaply" as possible.

Imagine you need to make a black box with a thin white border. I did some experiments with Aseprite:

A 1280x1280  .jpg of a black box with a white border -- 33kb.

A 1280x1280 .png of a transparent background with a white border -- 5.8kb

A 1x1280 .jpg of a vertical white line and a 1280x1 of a horizontal white line -- A dirt cheap 452 bytes!

So definitely look at all your options! I was surprised to see that the first .jpg was more "expensive" than the .png.

Thanks for reading!

Play the old version of Scrapship here.

13 FEB 2021:

This week I thought of an even better way to do the opening animation for Scrapship. It also incorporates my idea for a better Settings menu.

The previous versions of Scrapship animated the ship dropping to earth by cycling through about 30 .png files. I recently learned how to accomplish the same effect just by scaling the image! This means I only need one .png file to get the animation started. With these savings in file size, it also means I can make a longer and more dynamic animation without adding too much to the total file size of the game.
I'm not ready to show it off yet, but it's looking promising. Above you can see a small preview of the cockpit of your Scrapship. I added the chair, monitor, joystick and cockpit glass transparency. The rest of the ship was modeled by @another_blender_user on Instagram (who just got first place in a Blender art competition hosted by @polygonia.development).

I also played around with the text-centering feature . . . and ended up having to scrap it. It works if you use QB64's default font, but using a custom font causes the text to never center properly without doing a ridiculous amount of manual adjustments. But I did learn that I can work around this by just making my menus and text in Powerpoint (which is GREAT for centering and aligning text and adding colors and effects) and then using pictures of the text and then centering the pictures.

Side note: Scrapship is programmed in the QB64 version of the QBasic programming language and the first-ever QB64 Game Jam is right here on Itch.io! Of course I was too busy with Scrapship to join in on, but I'll definitely be checking out the game entries. It will be interesting to see what the more experienced programmers at the QB64 forums are able to come up with!

Thanks for reading! May the muses find you working!

20 FEB 2021:

It's coming together nicely!

This week I made the new settings screen which is shown above. What I like about this design is that you can view ALL of the settings on one page (the original version had sub-menus and back buttons that didn't always work properly).

A most welcome surprise was figuring out how to get the text centering feature to work after all! 

The "Intro" of the game is now almost back to its original state. When I run the program it goes like this:

Basic Controls guide (while game assets load in the background)

Settings screen

Opening animation

Start of main game loop

I still have some work to do on the settings screen and the opening animation, but once that's done, the "foundation" for the game will be set and I can start on the fun part: Putting the enemies back in!

Fun fact:

24 February was the release date of the very first Scrapship demo -- it's been almost exactly a year that I've worked on this project! I realize my progress is a bit slower than some indie game developers I follow, but I'm just happy that I'm still going. I usually start projects, get burnt out and then never return to them again. So daily small improvements has absolutely been key to my progress so far. 

As I look back at the condition of Scrapship last year and compare it to today: MAJOR improvements. 

Something special for those that have followed me this far:

A lot of indie game developers here on Itch.io ask: What are "typical view / download" rates for my game?

Of course that varies from game to game, depending on the quality and genre. Shmups or Shooters may be one of the most traditional types of games to make, but they're not as popular as FPS or platformers, etc.

For an unfinished space shooter I think these are some really good numbers. Keep in mind that some of these views and downloads are from the same people since I was releasing new demos every month.

What do you think about these stats? Are they more or less than you expected? Please let me know in the comments below!

Thanks for reading and have a good rest of your weekend!

6 MAR 2021:

The "foundation" of the game is nearly done. Screen resolutions now scale properly. I've also improved the Settings screen so that it only shows valid screen resolutions.

Important Game Dev lessons learned this week:

1) When programming, you can often do things in a very concise manner (less code to read), but the downside is that it might be harder to understand what those lines of code are supposed to do. Sometimes your program makes a lot more sense if you code things out in a longer, more explicit form. This is what I ultimately had to do to solve my issues with screen resolutions and objects not scaling properly. Of course you can always condense/consolidate the code again after you're confident that everything works and you understand how it works.

2) "Boring" work can really make your game a lot better. You've probably noticed that the past few weeks there haven't been any updates on enemies or actual gameplay features. But taking this time to allow for different screen resolutions makes the game look more professional and accommodates players with smaller monitors/laptop screens.

What's next?

The main game loop! As a quick test, I'll see if the player ship can properly collide with another object and "die" before prompting the player to quit or try again. 

Once that works, the "foundation" will be stable enough that I can confidently start re-importing enemies and game logic.

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

13 MAR 2021:

Simplified main game loop is complete! This means you can start the game, crash into a test object and then decide to keep playing or quit. If you decide to keep playing it loops back around to the beginning -- with no loading times!

The riskiest addition this week was copy/pasting the code so the player can shoot. Thankfully it worked! Up to now, most of the new features had to be programmed from scratch.

I also shortened the opening animation by nearly half. Each frame is a 1 to 1.5 MB .png file so they add up pretty quickly.

There is still some work I have to do on the sprites and the other two weapons still need to be added back in.

HAHA! I literally just now figured out how to do something I've been wanting to do for a LOOONG time: Render the Bloom effect while maintaining a transparent background. This is a game-changer! Now I'll be able to add a natural "glow" effect to anything that needs it. 

For those that are interested, here is how I set it up in Compositing (using Blender 2.9x).

Have you used Blender in your indie games? Feel free to share your experience in the comments!

In other news:

I got a small job doing the English Localization for a game on Steam called "Destroy the Demon Army -- Modified". It was an educational experience because I had never worked with .xaml files before and the game itself was fun to play! 

Although gamedev is my primary focus, I am also open to beta-testing and proofreading your game. If you're interested just contact me at 40wattstudio@gmail.com

Have a good rest of your weekend!     (and don't forget about Daylight Savings Time)

20 MAR 2021:

Two of the 3 weapons are now programmed back in. I also added a "hitbox" debug mode (shown above) which will come in really handy.

The debug mode that I added to this version of Scrapship has already proved useful: Earlier this week I was able to use it to troubleshoot some problems with the player bullets and I also discovered that my original code that I had copy/pasted over had an error in it that was causing a random stray shot occasionally.

In Other News:

I signed up for another Game Jam!

The BASIC Game Jam starts in 11 days and can be viewed here.

I'll still be working on Scrapship during this time, but this will give me an opportunity to "recharge" a little and, more importantly, actually finish something. So I"m really looking forward to it!

Thanks for reading! For more frequent updates please check out my Instagram @40wattstudio.
Have a good rest of your weekend (and for some of you, Happy Newroz!)

3 APRIL 2021:

-- Thanks to my excellent debug system, I fixed a bug where the game would crash if left idle for a few minutes -- a background function would keep trying to shrink down a graphic that was already reduced to its smallest size.

-- I've designed the code so that only ON-SCREEN objects check for collisions.

Hit detection can be VERY "expensive" in a shmup. Some bullet-hell games (like Dodonpachi Daioujou) are made so that hits are only calculated on every other game loop.  In all previous versions of Scrapship, I was checking for collisions whether the object was on-screen or not.

-- Just started to code this out, but Difficulty is now determined by how often the enemy spawns, not by the number of ships.  The previous "Wave" system I used for Difficulty definitely worked . . . but it was also nightmarishly complicated and some lines of code had to be written in very specific places.

If it works as I intend, the player will be able to change Difficulty mid-game -- something that could not have been done in previous versions.

-- The spawn-code for the Fighter enemy has been added back in. 

Thanks for reading and have a good Easter weekend!

10 APRIL 2021:

-- Added banking animations to the enemy fighters. 

-- Added some simple movement AI.

-- Started programming the hit detection for the different segments.

-- Lesson  learned: If you have an image you really like (with a transparent background), do NOT edit it in Microsoft Paint -- it will remove the transparency and turn it a solid white color.

Thanks for reading and have a good rest of your weekend!

17 APRIL 2021:

-- Scrapship has hit a milestone! Over 100 downloads! Sounds small, but for an unfinished game in an over-saturated genre I think it's really good. Thanks to everyone for their support!

-- Finished the hit detection for the enemy fighters. In the above .gif you can see the AI at work and the new banking animations. What do you think? 

-- I fixed the player bullets after I messed them up in Microsoft Paint. They're a little different looking but pretty close. 

-- I had very briefly added the particle explosions back in, but it was making the code very complicated so I took it back out. I'll work on that more later. 

-- Added Credits option to the  main menu and started adding those screens back in. 

In other news, I'm about 40-50% done with my QBasic Gamejam game. Look for that one towards the end of the month!

Quote of the Week:

"A user interface is like a joke. If you have to explain it, it's not that good." -- Martin LeBlanc

Thanks for reading and have a good rest of your weekend!

1 MAY 2021:

- Fighters can now attack and damage the player! The logic is still WIP which is why both wings are shot off instead of just one. But what is really cool is how the ship appears damaged even when viewed from different banking angles. 

In other news, my game Wallet Warrior has been submitted to the Jam for All Basic Dialects #1. Voting ends in about a week. It was a fun experience and I learned some new techniques that I hope to later implement into Scrapship!

Quote of the Week:

"No risk, no story."

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

7 MAY 2021:

- Better AI for the enemies! Each enemy type will have 3 levels of AI along the lines of Easy, Normal and Hard. At each level they get a little more aggressive. On Easy, the fighters just fly straight down the screen. On Normal, some fighters will now bank towards the player. On Hard, some fighters will rapidly bank across the screen.

- Fighter damage. If you shoot off the left engine of the fighter, you would imagine there would be a reduction in speed, right? That's exactly what happens now!

- Player cockpit can now take damage! Still playing around with this one, but it looks promising. It will take 2-5 direct hits to destroy the player. Two hits only if the enemy manages to hit the cockpit twice. 

- Better Hit Detection. All "hits" from projectiles are based off the location of the middle-most pixel of the sprite. Not only does this make the hit detection more realistic, it is also more forgiving -- a projectile can graze your wing and still miss.

A QUESTION ABOUT DIFFICULTY:

What should make Scrapship "Difficult"? 

The level of the AI?

The amount of damage the player does? 

Both?

Something else?

Right now, not only does the AI get better, but the player damage is decreased the harder it gets. But perhaps this is going a little too far. 

Please let me know in the comments below!

Quote of the Week:

"The only disability in life is a bad attitude." -- Scott Hamilton

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

15 MAY 2021:

- Enemy fighters can now be stunned! Stunned fighters will continue on their last-known trajectory and will not fire back at you.

- Difficulty changes. Difficulty only affects the AI of the enemy ships, not the player damage. In the gif above you can see some of the new flight patterns the enemy ships take.

- Thoughts about scrap: I'd like to make the scrap in this game more meaningful and/or interesting. It is SCRAPship after all. One idea I've toyed around with is adding physics so that the scrap can bounce around when collided with. Another idea is that scrap can be destroyed with energy weapons by the player OR the enemy, but weapons with mass will propel the scrap.

Quote of the Week: 

"Don't show off, show up!"

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