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.