Silence?
Back on July 7th I wrote about Fasteroids, the game I developed a few years ago. In that post I mentioned that I had some significant changes in mind for a new version. Then I went silent for a bit on social media about the game. This is an update about what’s going on with Fasteroids.
Bumps along the way
When I last wrote about Fasteroids the main thing I had in mind was changing the game so that it could be scaled up to 4k resolutions. Why 4k? Because now I can, and because I think it will provide a good foundation for future games.
I made a mistake… I followed some videos about resolution, without reading the comments on the videos. After things didn’t work I discovered that even the person who posted the tutorial made a comment saying “don’t use this.”
As most of you know, I’m not a developer. My full-time work is as a computer refurbisher for a not-for-profit organization. I had not had a good vacation in over a year, so mid-July my better half and I spent several days up north on vacation. While it would have been a good time to spend some extra time working on the game, I also wanted my better half to relax, so I didn’t bring my laptop.
When we got back the weather started to get brutally hot. So my wife and I spent a good amount of time away from home.
Then I ended up getting sick. Thankfully, whatever I had was not COVID-19, but it was enough that I didn’t do anything except lie down, drink water, and sleep for the better part of 4 days.
Lots of excuses for not working on Fasteroids, but I did manage to do a few commits on the day I wrote the last post, on the 21st of July, and a bunch of August 4th.
What’s up Doc?
Trying to to create something that’s scalable is proving to be quite the challenge. I hard coded 1024×768 in a lot of places thinking “I’m never going to change this, this is just a practice game for me to get into development.” As a first game I probable should have just left it alone several years ago, but I was finding playing and coding some parts of it really fun. And when I compared it to a lot of other Asteroids-like games I found I liked my game better… in most cases. Sure, there were issues. But, there’s just something about the game that makes me want to get it to a better state.
The changes I made today are as follows:
- I adjusted some graphics that were 1024×768 to 640×360 so they can be scaled later
- I fixed a bug where UFOs were not spawning because the object was now out of the room (due to the fact that the background/room was originally 1024×768 and I’d placed the object in a spot outside of 640×360)
- I changed the warp key from ARROW DOWN to either SHIFT key. I tend to mash keys when I get nervous and I kept warping when I did not mean to.
- I made some changes to the speed of the UFOs, and which spawn when. You should see more green UFOs than any of the other colours.
- I also made some adjustments to the points given for each UFO that’s destroyed
- This introduced a sprite bug I need to fix. When you destroy a UFO, a point value is displayed. This is done with sprites rather than text. Because I changed the value of each UFO I now need to change the sprites. This needs to be checked to make sure the values are correct.
- I made some changes to the code for Asteroids to reflect the resolution change.
Going forward
One of the things I noticed when I fixed the UFO spawning issue, was that UFOs were speeding across the screen way too fast at 640×360. I could barely react. This wasn’t a problem at 1024×768. It seems like the smaller the screen, the faster objects move across it. Conversely, things might appear really slow when I get 4k working. It appears like I’m going to have to detect the resolution and a set a speed for the UFOs based on the screen resolution. The larger the display, the faster the UFOs need to move.
Back when I first made Fasteroids available, the menu system was very simple. Later I saw a very complicated, but clever way, of structuring the menu, so I implemented it. But I feel like the menu system is a bit too much. I’m thinking I should simplify it again, and cut out some of the “features.” Feature creep made Fasteroids less fun to develop.
Changing the menu will likely mean removing some of the options/features in the game as well. I’d like to do fewer things, but do them better. (Rather than have a slew of half-implemented features done poorly)
The user interface text and the asteroids look a bit blurry at 640×360. I plan to redo the asteroids and text. Right now some things are not centered. I also believe there’s a better way for the user interface to be implemented, but I need to do a bit more research on that topic before implementing it.
I might also consider releasing a MacOS X binary in the future, but this will likely be only for Intel-based Macs (since that’s all I have access to) – so it may not happen at all.
Gamemaker under Xubuntu Linux
One of the other reasons I stopped developing Fasteroids was that I completely switched to using Xubuntu Linux, and didn’t really want to use Microsoft Windows on any of my home PCs anymore. I thought about re-creating Fasteroids using the Godot game engine, but I had 0 experience with Godot, so it would have been a monumental task at that point. Now that Gamemaker runs reasonably under Xubuntu I’m doing 90% of the development and testing under Xubuntu (on my desktop computer). For the last 10% I’m switching to my laptop, which now runs Windows 10 again. That 10% is making a Windows-binary, and testing the game on Windows. For all the coding, sprite creation, and music, I’m using software under Xubuntu Linux.
Changes
I’m sure some things will change. Given that I work full time elsewhere, and have other obligations, I don’t expect to get a lot done quickly. But I do plan on trying to spend a little bit of time every day, or every other day, trying to do something.
There may be brief absences, like vacation or sickness, that prevents me from doing as much development as I’d like, but I’m going to try to improve things bit by bit.