Bitphoria v1.00 Beta Released

Pre-release early screenshot of Bitphoria.

Bitphoria has been released. It's in public beta, and this is the very first (aka 'worst') version ever. Start games (don't forget to forward your UDP port if behind a router) and play with others. Dive into the scripting system and make whatever your heart desires. Let's see what Bitphoria can do.

An engine guide is in the works now, to help users better understand the various console variables and how to make full use of them as a sort of 'power user'. I'm sure anybody with their wits about them could figure out most of them just by surfing the console typing a few characters and pressing 'tab'. The confusion, by comparison to most engines with a console, will lie in the fact that the vast majority of console commands are for scripting, and not intended to be executed while in a game, or while just idling in the main menu system.

If you're the type of person who likes to get into new things, unafraid, and share your findings with others, then by all means download Bitphoria, start screwing around, and Youtube your experiences. Share this thing with the world. If you could notify me of your intentions to release a video of your time with Bitphoria that would be great, just so I could follow along and gain some insight as to what I should work on or do differently.

Final Day Thoughts

I started Bitphoria in April of 2014, focusing solely on how the world was generated, represented, rendered, etc.. I had a pretty clear vision of what I wanted the engine to be capable of, and I feel I have achieved that.

Yesterday I finally reached the 20k lines of actual code that I predicted Bitphoria would have by its release date. The scripting manual for making games out of Bitphoria is complete. I'll be uploading the game tonight for release. It's a public beta version that has all of the features I wanted but are not fully polished and probably have some bugs. The goal is to see what kind of feedback comes from releasing it in the state it is in. I haven't been actively promoting Bitphoria very much at all, and figure that if it's any good it will sell itself by spreading via word of mouth. People will post screenshots, youtubes, start making games, playing against eachother online, etc..

Only time will tell.

Bitphoria's source code folder, comprised of 20k actual lines of code.

Tomorrow I will be sharing its release on Reddit and other various online communities, so we'll see what sort of response develops. This blog itself has just been a place for me to share my thoughts, and it does get a few dozen hits a day now, but nothing I would consider a great internet success, not by a long shot. I hope some people have found enjoyment and value in my blog, and perhaps if more people knew about it there would be more people that did find value in it.

I developed Bitphoria on my own time, while being a full-time stay-at-home Dad and running an Etsy business with my wife Heidi. It's a project I've always wanted to do, that I've attempted many times for the past 20 years, and life always seemed to get in the way. It was a matter of time before I finally made something.

Bitphoria's future is in the hands of the people after today. Once it's out there I'll probably stop working on it altogether unless it starts developing some kind of following or fanbase and I begin receiving feedback. At this point, it will serve as a great portfolio piece that demonstrates how well-rehearsed I am with all aspects of game development, from graphics programming, to networking programming, procedural techniques, and everything else in-between. This is just what I could do by myself in a limited amount of time, and I could do a lot, because I always dreamed to.

Bitphoria avoids issues like asset management and art pipelines, because I didn't plan on having artists, I planned on the players being the artists, almost in the same way that Quake and Half-Life were made popular by Team Fortress and Counter-Strike respectively. It wasn't the base game that made the game famous so much as it was the creativity of the masses. I'm counting on this, somewhat, with Bitphoria, and the fact that people like to make stuff. Bitphoria is meant to serve as a platform for people to create and share their creations, by abstracting things in a highly simple fashion that is easily accessible through a simple script-based construct.

Bitphoria's initialization function.

My goal was to have three separate games for players to play that were somewhat fleshed out. I will probably flesh them out in time, but I spent more time in the engine code than I had thought I would, so this first release will only really feature the deathmatch game, and the two barely-started CTF and instakill games that are far from complete. Fortunately every functionality of the scripting system is utilized by these games, for I had to test each one while developing it, so they appear somewhere in at least one of the three games' scripts. Hopefully this, in combination with the scripting manual I toiled to produce, will allow someone to start making something more inspired than the default games. The capabilities required to make a great game is there, that's a promise.

The master server will be running once I upload and link the release. I haven't fully tested it yet, so if you're one of the first people to download and playtest with a friend, please let me know if you encounter any issues immediately, so I can rectify them as quickly as possible and get something that people can fully dive into without having to worry about being able to connect with other players.

This is going to be a sort of Wild-West time if Bitphoria picks up and people start taking interest. There will probably be bugs and simple tricks to take advantage of the game, perhaps malicious server-crashing bugs, etc. that will be discovered and exploited. If these are found I will solve them just like everything else throughout the game's development, and they will only be found if people are actively trying to enjoy it. If people want more from Bitphoria, I will work to provide it, and it will be a process but we can get it there. I've been developing Bitphoria in a virtual vacuum, without much outside influence or suggestion, aside from the few comments coming from my long-time friend Paul Hindt. Other than that, this is the first time Bitphoria will see the light of day. This is going to be the worst Bitphoria release yet, and better ones are to come if enough people are interested.

If the game is DOA and nobody takes interest, I will eventually release the engine's source code as well, because I feel it is important for people to have resources to gain inspiration, insight, and ideas from. I took a lot of inspiration from the Quake engine, and the original Cube engine, insofar as some of the conventions for game logic are concerned.

Following in the same vein, Linux and MacOS ports will not be hard to produce being that the game runs almost entirely ontop of SDL2, but I don't plan on doing the necessary steps to releasing ports unless a demand arises. The only platform-specific code involved in the engine, as a matter of fact, is the code that lists all of the games in the games folder. There is no platform-independent method for listing the files in a directory so I wrote a simple command-line that performs a 'dir' command and dumps the result into a temp file that is loaded and the names of the game files are then extracted from. Other than that everything is occurring through SDL, so it shouldn't take very much time to compile ports.

All-in-all this release could have happened sooner, but I didn't want to have an Alpha release that lacked many features from the final product. At least at this point they are present and accounted for. There are maybe two or three little things I'd still like to add in, but at this point the project needs to get into the hands of the public so we can see what happens with it and where it should go next, if it is something that's bound to go anywhere at all.

Ultimately, if Bitphoria becomes somewhat popular, I will be pushing for actually selling it. To mitigate piracy I will be selling online player accounts, following the Minecraft model, which will integrate with the master server and be required in order to play on servers that are listed on the master server. That's down the road, but is solidly the plan if, again, people show interest.

Bitphoria's Release Date Announcement

 I have decided to make my 30th birthday the release date for Bitphoria, which happens to be August 30th 2016. There are several things I'd like to finish, among bug-fixes and networking improvements, before the first release and I thought I'd share that list here. Whatever state Bitphoria is in on that day it will be released.

It is obviously crunch time now (a great motivator for me) so the things on my list that I'd like to have done might be cut short, but I will continue working on it well into the future beyond the release. This will manifest itself in the form of new and updated releases. The initial release itself is meant to serve further development of Bitphoria by allowing other people to finally start messing around, playing games, scripting games, and providing me with bugs and feedback about everything.

I plan on releasing Bitphoria as a sort of public beta, for people to get to know it and see what I've dumped almost two years of my life into. Maybe down the road I will sell it for a few bucks on Steam/Itch.io. Maybe I should crowdfund polishing it, because I clearly have something that's worth something to someone, somewhere, out there, and I think it has a chance at being a crowdfunding success (after all the hard work is done already).

Hardware contributions/donations are always welcome! ;) I'm currently developing Bitphoria on four different machines: two low-end laptops from a few years ago, a low-end pre-built HP desktop from the same time, and a custom-built desktop - all with integrated graphics. I did manage to borrow an nVidia GTX 680 in the custom-built desktop system that allowed me to record some footage of Bitphoria earlier on, but have since been without and could definitely use a decent GPU just for the sake of tuning Bitphoria's graphics to where high-end systems can be fully taken advantage of for hardcore PC gamers, as well as allowing me to record updated videos of what Bitphoria looks and behaves like. Recording video is actually my primary goal insofar as GPU acquisition is concerned, because without it I will have a harder time demonstrating the game. Worst-case scenario hopefully fans out there will take it upon themselves to youtube videos of Bitphoria. If nobody does that then I've failed at making something that sells itself, obviously, and that's the goal of any project of mine!

If the case is that nobody ever cares about Bitphoria, and it just gathers cobwebs and dust in a dark corner of the web (on this blog, and in a few reddit posts), never amounting to anything more than just a "portfolio piece" for me to acquire a dead-end soul-crushing software engineer job, then at that point I will just release the code in its entirety for everyone to tinker with and learn from. At any rate, the code will ultimately be released eventually. The 'when' of that is still up in the air, and probably will be for at least another year. But if I can earn a living for my family via my lifetime hobby then I'm certainly going to try before giving it all away. Over two decades of programming experience has gone into this project, and there are even things that I learned along the way while developing it that I'd like to invest into a new game engine project, but those are things that I'm just going to hang onto until I feel that this project is 'done', through-and-through, which includes promoting it to a respectable degree that hopefully provides it with enough exposure to ascertain as to whether or not it is something that there is interest in.

As far as my pre-release todo-list is concerned I believe that setting up a master server for people to find each-others' games is imperative, otherwise the whole project is pretty pointless if people can only start a game server, run around by themselves, and then quit out and never play it again. Scripting features and functionality seem less consequential and could be added in along the way at a later time after the initial release, but the existing setup is rather competent. Finishing the scripting documentation also remains a top-priority issue due to the fact that I wish for people to be able to start playing around with the engine itself to see what they can come up with within the creative sandbox that it represents. It has its quirks and nuanced requirements insofar as game performance are concerned (graphically, physics-wise, and networking) which is the case with any game engine out there. However, I would like to point out that it takes no game-development know-how or modding experience to make something out of, or with Bitphoria. Anybody should be able to simply open up the script files that comprise the default games included with Bitphoria and start surfing the documentation to figure out how it all comes together.

Here's my list of things left to do for Bitphoria before releasing it that I'm currently focusing on for the next few weeks:


Master Server: Write and launch a master server to run here from my home to allow players to be able to start and find/join eachothers' games. Along with this I'd prefer to invest in a domain name that points to the master server (my house IP) for the in-game server browser to download the server list from. This would actually kill two birds with one stone. Firstly, it would eliminate the learning curve of PHP and MySQL that I'd need to traverse if I were to create an HTTP master server. I *do* have enough experience with both to make it happen but I'm not competent or well-rehearsed enough to simply knock it out within a day or two - and it would require that I implement HTTP request functionality into Bitphoria, be it by hand or integrating CURL/libCURL. Secondly, running a custom-coded master server from home would allow me to easily implement a NAT-punchthrough handshake protocol to allow anybody to start a game without being required to deal with their router/firewall and port-forward. Conversely, anyone else would also be able to join any game regardless of whether or not they themselves are also behind a router/firewall. This functionality requires that the master server notify game servers when someone is trying to join them, and from what IP/port, allowing the game server to go ahead and send a 'trailblazing' packet to the client player for the sake of tunneling through the NAT and have it route packets from that client player's address to the game server. To have a console application running in the background on my desktop, written in C, using winsock or SDL_net, that would be easy to manage would be much simpler and cheaper than any remote/online option I've come across so far. If at some point there's too much traffic for my home connection I'd then move the master server program to a dedicated virtual host and simply point the domain name at that, and everything will just continue working for everyone without any changes for end-users.


Network Buffering: Implement a network buffering system to, for one, allow for the simulation of latency and its fluctuation for testing/tuning purposes. So far I've only been able to generate repulsive/gross/erratic network behavior when my daughter watches Youtube/Netflix on her machine while I have two machines sharing a Bitphoria game over our wireless LAN. Also, in spite of my efforts to fight network update jitter using extrapolation when an update packet arrives later than intended, it would seem that Gaffer's strategy (gafferongames.com) of simply buffering network updates long enough to encompass most network jitter and then subsequently emitting them to the engine internals at the interval they were intended to arrive at would be vastly more effective in its precision and lack of interpolated correction. Buffering network packets as such would also allow me to simulate internet conditions locally without having to track down willing testers (I'm not really a 'people-person', and I have no more computer friends left) and fine-tune everything for what I like to think of as the 'fringe-market' - people who don't have high-end gaming systems (a netbook) or fiber-optic connections. I'm of the mind to release a game that looks prettier the better the setup, but also is completely performant on less ideal setups. Why focus on one area of the market if you can focus on the entire market?

Scripting System Documentation: Finish the scripting system documentation, which would include indications as to where inside of the the sample/default games that are packaged with the initial release that users can find examples of each script command, along with tips/tricks. Also, early on I made it a point to document everything that I script for Bitphoria because I know that people out there should be encouraged to tinker around and pull everything apart.

Artificial Intelligence: Add in simple AI functionality that allows an entity to seek out other entities and designate them as its target, which it can then follow or aim at. This would make it possible for simple zombie-type enemies that just follow players and harass them while they try to carry out other things. I'd like to include some kind of simple navmesh generation that is derived from the distance field of the world but I am thinking I am just going to literally index the distance field and use that for obstacle avoidance while entities try to pursue other ones. If a target is unreachable then it could back out following the distance field outward until the target is visible again, or a new target is found.

World Generation Modes: Add options for the style of the world generation itself. Right now it's a fixed algorithm and starting a game server entails selecting a random seed and then a vertical-scale which is forwarded to clients so they can then generate the same world themselves and play. The world is generated as a 128^3 volume and there's a lot more that could be done with it than just leaving one algorithm in there for people to experience.

Physics Attachment: Entity attachment which allows for an entity to literally attach itself to another entity and inherit its position/motion, with or without an offset that is oriented with the entity being attached to. This could be used for CTF games or power-up modes that want to display some kind of visible effect.


These are more-or-less listed in order of priority. What actually happens by the release date is still completely variable, these are just my intentions and goals, and it's hard to say what exactly will occur as I pursue each bullet point.