I haven't yet added discussions under individual games, so all discussions must take place on this main news page. When I implement discussions under their respective games, I will move all relevant discussions there. That will be a while, though, as I am also working on games.
Only registered users can participate in discussions, so you will need to create an account if you want to participate. Accounts are (and always will be) free.
No postings will be visible to the public until approved by a moderator (I'm currently the only moderator).
Only registered users can participate in discussions, so you will need to create an account if you want to participate. Accounts are (and always will be) free.
No postings will be visible to the public until approved by a moderator (I'm currently the only moderator).
I watched my son and my wife play Missile Mayhem, and got inspired to play a round myself. Much to my surprise, I made it to level 17 and set the global high score of nearly 120K points! I was shocked and surprised, to say the least.
Is that worthy of a news page posting? Probably not; but I own the site, and rank has its privileges.
Is that worthy of a news page posting? Probably not; but I own the site, and rank has its privileges.
I had a surprise fake purchase yesterday, which was exciting since it was the first fake purchase made through soapspangledgames.com. Upon searching the server logs, I discovered that the fake purchase was made by a bot in Taiwan. This made me decidedly unhappy, since I don't want bots downloading and distributing my games. It was inevitable, but I wasn't expecting it to happen so soon.
As a result of this, I have removed my games from availability until I have finished credit card processing and am able to charge credit cards. For now, the site is able to go through all the steps of collecting credit card information (I will never store it or retain it!), but I do not yet have a credit card processor (hence my use of the term "fake purchase").
On the bright side, the sale and delivery process works.
As a result of this, I have removed my games from availability until I have finished credit card processing and am able to charge credit cards. For now, the site is able to go through all the steps of collecting credit card information (I will never store it or retain it!), but I do not yet have a credit card processor (hence my use of the term "fake purchase").
On the bright side, the sale and delivery process works.
You may have noticed a new item labeled "Games" in the menu bar at the top of the page. I am implementing a purchasing system directly within the Soap Spangled Games website, and am doing so for a couple reasons.
The first is for cost. Most of my games make me nothing. Zero. Zip. Zilch. I can't afford to publish on Steam, with its $100 publication fee per game. It's not realistic. I also detest the large cut of my potential sales that I will have to surrender. Losing 30% to a distributor is highway robbery. Granted, 30% of zero is still zero, but that could potentially change. Something like 5% would be reasonable. I don't intend to host for other people, but it's not out of the question. If I ever did, I would likely settle on a 5% hosting and distribution fee, and charge $1 per game entry to deter spam postings.
The second is for control. The main distributors control who sees my games, and, more importantly, who doesn't see my games. That may or may not have a bearing on who purchases my games, but it takes that control out of my hands. Distributing my own games puts that control back into my hands.
The third is because distributors like Itch enforce limits on the size of games they will publish for free. Seas of Reverence is already above the 1 GB size limit, and I can't justify paying for distribution at this point. Being my own distributor means I am only limited by bandwidth costs.
Those are the main reasons I'm doing what I'm doing.
My distribution system is in its infancy, but I'm not too far away from it being able to take payments and deliver downloads. I had to create an online payment system for my employer, so I know how to do it. My payment system is just a primitive shell at this point, and doesn't actually have the ability to charge credit cards or deliver the purchased game, but it is able to go through the motions up to the point where the game would be delivered.
The first is for cost. Most of my games make me nothing. Zero. Zip. Zilch. I can't afford to publish on Steam, with its $100 publication fee per game. It's not realistic. I also detest the large cut of my potential sales that I will have to surrender. Losing 30% to a distributor is highway robbery. Granted, 30% of zero is still zero, but that could potentially change. Something like 5% would be reasonable. I don't intend to host for other people, but it's not out of the question. If I ever did, I would likely settle on a 5% hosting and distribution fee, and charge $1 per game entry to deter spam postings.
The second is for control. The main distributors control who sees my games, and, more importantly, who doesn't see my games. That may or may not have a bearing on who purchases my games, but it takes that control out of my hands. Distributing my own games puts that control back into my hands.
The third is because distributors like Itch enforce limits on the size of games they will publish for free. Seas of Reverence is already above the 1 GB size limit, and I can't justify paying for distribution at this point. Being my own distributor means I am only limited by bandwidth costs.
Those are the main reasons I'm doing what I'm doing.
My distribution system is in its infancy, but I'm not too far away from it being able to take payments and deliver downloads. I had to create an online payment system for my employer, so I know how to do it. My payment system is just a primitive shell at this point, and doesn't actually have the ability to charge credit cards or deliver the purchased game, but it is able to go through the motions up to the point where the game would be delivered.
It has become obvious to me that I do not have time to make games of any significant size, so I have decided I am going to make the hardest games in the world: small, focused, yet entertaining.
They are going to be targeted at the VERY casual gamer. Only after I make enough money to quit my day job will I attempt to return to larger games.
I'm getting too old to plan ten years into the future, and I'm sacrificing too much time I could be using to raise my children, so I'm cutting way back on my ambitions.
I've found resisting feature creep to be incredibly difficult, which is why small, focuses games are the hardest in the world to create.
They are going to be targeted at the VERY casual gamer. Only after I make enough money to quit my day job will I attempt to return to larger games.
I'm getting too old to plan ten years into the future, and I'm sacrificing too much time I could be using to raise my children, so I'm cutting way back on my ambitions.
I've found resisting feature creep to be incredibly difficult, which is why small, focuses games are the hardest in the world to create.
Google has announced upcoming changes to its policy for Android developers. Those changes could make it too expensive for small, independent developers to publish for Android. If that turns out to be the case, then Soap Spangled Games will no longer publish games to the Google Play Store.
There are alternative Android stores, though, so I may consider publishing to one or more of them instead of Google's.
UPDATE 8/25/2024:
I just got an email from Google announcing the closure of my Google Play developer account if I don't publish an update soon. Since I've focused my time on Seas of Reference, and it's nowhere near ready to publish, and I don't intend to update Fishing For Phonics anytime soon, I have decided to let the account die and to stop publishing on Google Play.
UPDATE 8/30/2024:
I got another email from Google saying that Soap Spangled Games' Play Store presence has been removed from public view. I presume it will be deleted and purged at some point. I started going through the process of verification that the Play Store was asking for, but stopped when it wanted to publicly display too much of my personal information. Since I have never made any money from Google Play, I have no qualms about telling Google Play to piss off and die.
You should assume that Soap Spangled Games' Play Store presence is dead, as that is how I am treating it.
There are alternative Android stores, though, so I may consider publishing to one or more of them instead of Google's.
UPDATE 8/25/2024:
I just got an email from Google announcing the closure of my Google Play developer account if I don't publish an update soon. Since I've focused my time on Seas of Reference, and it's nowhere near ready to publish, and I don't intend to update Fishing For Phonics anytime soon, I have decided to let the account die and to stop publishing on Google Play.
UPDATE 8/30/2024:
I got another email from Google saying that Soap Spangled Games' Play Store presence has been removed from public view. I presume it will be deleted and purged at some point. I started going through the process of verification that the Play Store was asking for, but stopped when it wanted to publicly display too much of my personal information. Since I have never made any money from Google Play, I have no qualms about telling Google Play to piss off and die.
You should assume that Soap Spangled Games' Play Store presence is dead, as that is how I am treating it.
I use Godot as my game engine of choice, but not as my game server of choice. I have been asked a few times why I don't use Godot as my server, but instead wrote my game server using C++. There are two major reasons:
1) Godot is a resource hog. Back when I started writing OS Wars (using Godot 4.0), I chose Godot as both the client and the server. It was good on the client-side (though still weighing in at multiple megabytes, which is normal for a gaming client), but the server was also weighing in at multiple megabytes. Ugh. My C++ game server weighs in at a slim 240KB (yes, kilobytes; not megabytes).
2) Performance was pretty bad. With only one player, the Godot server was using LOTS of CPU and memory. With two players, it was consuming most of the server resources (both RAM and CPU). When I decided to write Seas of Reverence instead, I wrote the server in C++. With two players, the server was registering as idle. The C++ server could, in theory, host multiple games consisting of thousands of users on a relatively modest computer. I haven't written a stress test, but It would be interesting to do so.
There are other small reasons, but the two above are plenty enough for me.
1) Godot is a resource hog. Back when I started writing OS Wars (using Godot 4.0), I chose Godot as both the client and the server. It was good on the client-side (though still weighing in at multiple megabytes, which is normal for a gaming client), but the server was also weighing in at multiple megabytes. Ugh. My C++ game server weighs in at a slim 240KB (yes, kilobytes; not megabytes).
2) Performance was pretty bad. With only one player, the Godot server was using LOTS of CPU and memory. With two players, it was consuming most of the server resources (both RAM and CPU). When I decided to write Seas of Reverence instead, I wrote the server in C++. With two players, the server was registering as idle. The C++ server could, in theory, host multiple games consisting of thousands of users on a relatively modest computer. I haven't written a stress test, but It would be interesting to do so.
There are other small reasons, but the two above are plenty enough for me.
An interesting thing happened during development of Seas of Reverence. I was showing my family the game's progress, and explaining one of the game's proposed mechanics (I don't remember which one), when my wife said something like, "and then the players can work together to achieve the objective!"
I told her that I intended the first release to be single player only, and she looked puzzled. When I asked her what she was thinking, she told me that multiplayer games are much more appealing to more players than are single player games. She briefly explained to me what she had in mind for the particular situation I was showing her, and it was good.
As a consequence, I started working on what is going to be the multiplayer subsystem for Seas of Reverence. I had already written the meat of such a system for my OS Wars game for Godot 4, but Seas of Reverence is a Godot 3.x game. That is because VR support for Godot 4.x is not ready for prime time, but Godot 3.x's support has been done for years.
There is the additional issue that I had written both the client and server code in GDScript, and Godot is far too resource intensive as a server to support a large number of players. As such, I decided to write the server entirely in C++, and solely for Linux. Linux's epoll system is perfect for supporting a large number of simultaneous players.
Also, my OS Wars multiplayer system was LAN only, and I want Seas of Reverence to be playable over the Internet, which means I will need to use soapspangledgames.com as a central gameplay server. Since it is a very low-powered server (until I sell enough games to afford a larger server pool), the server software needs the Linux epoll so it can sleep when there is no data coming in.
The alternative (which Godot uses) is to sit in a tight polling loop looking for new UDP data. For a small number of players, this wastes a lot of CPU time. The more simultaneous users, the less time the CPU spends sleeping, so polling becomes less inefficient as the user count increases. But, at least in the beginning, the game server, the web site, and the database will all have to live together.
I'm architecting the game server into separate subsystems (one for user data, one for gameplay, and one for proxying and load balancing), so as the userbase grows, I will be able to transparently add or remove support infrastructure.
I'm not going to make a Windows server, though, as I don't have the time, resources, desire, or Windows knowledge to do so.
I told her that I intended the first release to be single player only, and she looked puzzled. When I asked her what she was thinking, she told me that multiplayer games are much more appealing to more players than are single player games. She briefly explained to me what she had in mind for the particular situation I was showing her, and it was good.
As a consequence, I started working on what is going to be the multiplayer subsystem for Seas of Reverence. I had already written the meat of such a system for my OS Wars game for Godot 4, but Seas of Reverence is a Godot 3.x game. That is because VR support for Godot 4.x is not ready for prime time, but Godot 3.x's support has been done for years.
There is the additional issue that I had written both the client and server code in GDScript, and Godot is far too resource intensive as a server to support a large number of players. As such, I decided to write the server entirely in C++, and solely for Linux. Linux's epoll system is perfect for supporting a large number of simultaneous players.
Also, my OS Wars multiplayer system was LAN only, and I want Seas of Reverence to be playable over the Internet, which means I will need to use soapspangledgames.com as a central gameplay server. Since it is a very low-powered server (until I sell enough games to afford a larger server pool), the server software needs the Linux epoll so it can sleep when there is no data coming in.
The alternative (which Godot uses) is to sit in a tight polling loop looking for new UDP data. For a small number of players, this wastes a lot of CPU time. The more simultaneous users, the less time the CPU spends sleeping, so polling becomes less inefficient as the user count increases. But, at least in the beginning, the game server, the web site, and the database will all have to live together.
I'm architecting the game server into separate subsystems (one for user data, one for gameplay, and one for proxying and load balancing), so as the userbase grows, I will be able to transparently add or remove support infrastructure.
I'm not going to make a Windows server, though, as I don't have the time, resources, desire, or Windows knowledge to do so.
I had to reinstall Kubuntu last week, as it botched an in-place version upgrade from 20.04 to 22.04. It also botched a fresh install of 22.04, so I went back to 20.04 and plan to stay there for a while.
In any event, Godot wouldn't recognize my plugged-in Quest 2. As it turns out, KDE, via it's Device Notifier widget, wouldn't recognize it either. The Linux system log showed when it was plugged in and when it was unplugged, though, so the USB port was working.
Fortunately, Linux wasn't recognizing my sound chip either. Why is this fortunate, you may be asking? Because I had this sound problem when I did a fresh install of 22.04, and I remembered my research for solving it, so getting Linux to recognize my sound chip was easy:
"sudo apt-get install linux-modules-extra-`uname -r`"
This installs a bunch of kernel modules and (apparently) device drivers. Normally, a fresh Kubuntu installation and subsequent kernel upgrades install these modules automatically. But in my case, Kubuntu's unattended upgrade did a kernel upgrade at an inopportune time, so I didn't reboot. The unattended upgrade installed a new kernel, though, as well as a new modules package.
Days later, I did another upgrade from my still-unrebooted running system, which installed yet another new kernel. However, since I didn't reboot after the previous kernel upgrade, the upgrade process re-installed the old modules from two kernels ago, which were not compatible with the kernel I was about to reboot into. Whoops! My bad!
So after I manually installed the new kernel modules and rebooted, my sound worked again (as expected), and all of Linux, KDE, and Godot now saw my plugged in Quest 2.
Yay!
In any event, Godot wouldn't recognize my plugged-in Quest 2. As it turns out, KDE, via it's Device Notifier widget, wouldn't recognize it either. The Linux system log showed when it was plugged in and when it was unplugged, though, so the USB port was working.
Fortunately, Linux wasn't recognizing my sound chip either. Why is this fortunate, you may be asking? Because I had this sound problem when I did a fresh install of 22.04, and I remembered my research for solving it, so getting Linux to recognize my sound chip was easy:
"sudo apt-get install linux-modules-extra-`uname -r`"
This installs a bunch of kernel modules and (apparently) device drivers. Normally, a fresh Kubuntu installation and subsequent kernel upgrades install these modules automatically. But in my case, Kubuntu's unattended upgrade did a kernel upgrade at an inopportune time, so I didn't reboot. The unattended upgrade installed a new kernel, though, as well as a new modules package.
Days later, I did another upgrade from my still-unrebooted running system, which installed yet another new kernel. However, since I didn't reboot after the previous kernel upgrade, the upgrade process re-installed the old modules from two kernels ago, which were not compatible with the kernel I was about to reboot into. Whoops! My bad!
So after I manually installed the new kernel modules and rebooted, my sound worked again (as expected), and all of Linux, KDE, and Godot now saw my plugged in Quest 2.
Yay!
Soap Spangled Games is a new, family owned and operated Limited Liability Company. We produce a range of video games designed to run on a variety of platforms. We target Linux, Oculus Quest, and Microsoft Windows. With Google's upcoming developer policy change, we may stop developing for Android.
We decided to organize as an LLC after producing our first game aimed at preschool children, "Fishing For Phonics," for Android. It was originally written for our (then) preschool-age son to help him with learning the Alphabet. Since he enjoyed it, we thought other children might enjoy it, too.
Note that due to Google's new draconian information abusing regime, I have decided to allow our Google Play presence to expire. We will no longer publish anything to the Google Play Store.
We decided to organize as an LLC after producing our first game aimed at preschool children, "Fishing For Phonics," for Android. It was originally written for our (then) preschool-age son to help him with learning the Alphabet. Since he enjoyed it, we thought other children might enjoy it, too.
Note that due to Google's new draconian information abusing regime, I have decided to allow our Google Play presence to expire. We will no longer publish anything to the Google Play Store.