Soooooooo… The last post might have been a little confusing. As part of parring back my initial goals and changing a few things here an there, I ended up moving from a c# client to a TwinBasic client. One of my other goals is to remove as many external dependencies as possible to distribute with the mmorpg client.

One of the side effects of the move is steam integration. It is pretty straight forward in .Net, but there is absolutely zero integration available for TwinBasic. Giving that tW is meant to be 100% compatible with Visual Basic 6 and Visual Basic for Applications, plus other features and can compile in 64-bit… Some people consider it the successor to VB6 as the language adds more features while keeping backwards compatibility.

With the above said, VB6 came out in 1991 and discontinued in 1998. Steam came out in 2003, and to date, there is still no integration between the two. Now… Steamworks dll is basically a standard DLL. VB6 and TW can integrate with those fine. However, there are quite a bit of gotchas and I really don’t have time to figure all that out. I’ve been in .NET (and Java) land for too many decades to have patience for something that should have been solved decades ago.

You know that whole saying, time is money? Well… that is the route I will be taking soon. Roughly $1400 to pay for the integration work. And winsock… whew. TwinBasic’s road map shows winsock support in 2nd quarter 2026 (ref: github.com/twinbasic… ). I can’t wait that long. So this means paying someone to create integration for that. Until then, I am currently using Socket Tools ActiveX controls. Which means distributing Socket Tools' installer. Hopefully, that will be temporary until the replacement is integrated. Oh joy. And all of this for a 100% free (no subscription, no mtx) mmorpg.

With that said, I am seriously considering using ko-fi for one off support to help with the monthly fees and one time payments for stuff like music, art, integration work, etc. No pressure or anything. There will never, ever be any advantage, no cosmetics or any of that stuff for supporting this way. Probably an icon next to name in chat (or on map), and perhaps a different name/chat color. and name in the credits, of course.

Ah yes, the whole reason I wrote this.. So… this means I no longer have to finish building out the email/password/validation loop in this new client. Only integrate steam Ids and authentication tickets. I absolutely detest storing email and passwords as it is, quite frankly, none of my business. SteamIds however, will be stored in the database as it is needed to map to your characters.

With that said (I seem to be saying this a lot)… This also means that there is no need for an account only release as part of the “release small, release often” development. Instead, the first release will allow character creation. This game will be a skill based game. No, not a twitch game, but a classless game. Ala sort of like how Eve Online is. But.. as an mmorpg. So creating a character will be something like.. pick a name and a race. Race perks will be fleshed out as the game gets fleshed out. For instance, Dwarves might get a +5% stamina or pure hp. Elves might get a mana pool bonus, etc.

So… skill based game. Level up the skills you want to emulate the archetype you want your character to become.

So first deployment will unfortunately have a socket tools dependency and installer. You will be able to create/delete your characters. This will leave the second deployment to actually do .. something.. in a map. hmm..

With sarcasm!

I am almost at the point to deploy the game server for account admin functions. But… I forgot something. I needed to finish setting up the proxy server and the windows server. oopsies! As some of you may know, the current server diagram is:

client -> proxy server -> game server -> database -> backups

The game client will never directly connect to the game server nor the database, and certainly not the backups location. So, if I ever had to move the game server onto a different windows (or Linux) server, all I have to do is repoint the proxy server to the new server box via config file, reboot the proxy and everything will still run as normal with sub second downtime. yay?

With the above out of the way, I was able to test the game client going through the proxy and everything works as expected. Now I get to finish the database admin tasks, create an installer, get the patcher working, and get discord up and running as I want it. And last but not least, getting the website updated with all the info.

As you can see from above, there is a lot of administrative tasks to do just for the first version to come out. subsequent versions should have much much less admin tasks… with exception of steam and itch.io integration points.

Wow! It has been a while! 49 days since my last Osinia devlog. ouch! I am so sorry. Real life caught up with me at the end of summer and beginning of the school year. Priorities. Sometimes I hate them. Ah well.

I have trimmed down my expectations and added some new ones. So in short, the initial client is now developed in TwinBasic (basically the spiritual successor to Visual Basic 6. It works quite well. The client is in 64-bit and restricted to run in Windows 10 and higher. The restriction is mine. I figured I will support the current Windows OS plus the OS version before it. I am working on a Windows only client for now.

I DO have a C# version of the client but I am putting that to the side for now and concentrate on the TW (Twin Basic) version. This also means no extensive in-game UI (well, on the rendered map, that is). Not with the TW client unless something comes up on the TW side. The C# version works extensively in the game ui. So… someday, perhaps, I’ll get around to finishing the C# version or if TW catches up enough, I’ll just stick with TW.

So… server side is developed in C#, while the client side is now coded in TwinBasic. Took a few day but got Networking working good enough between the two. Also working extensively with DirectDraw7…. yes, technology from 24+ years ago. It works fine on Windows 10 and 11 and it is easy to use. Due to one of those hard knocks life lesson of.. work smarter, not harder, it is usually always good to work with easy to use tech…. as long as you know the underpinnings.

I am sticking with C# on the server side for two reasons. I use it extensively on my day job for back end development, processes, etc. I am intimately familiar with it. And I have quite a few tools and components I have gathered over the years that makes development quite smooth and quick. While it is possible to use TW (and VB6) for server side development…. that would be an insane decision. It does not do well for server side for many reasons.

There is one piece left that I need for completing the collection of components/wrappers for the TW client. And that is integration into Steam. This is a huge deal as I have no interest in storing any of your information, only your steam id. Once that information is completed…. oh… right, I still need some kind of audio for music + sfx. Hmmm…

So with this.. pivot, here are some of the additional costs:

$52/mo Twin Basic (Ultimate Edition) $200 Socket Tools 11 Subscription upgrade (I love this product and their support is top notch) $250 TW DirectDraw 7 integration

Plus:

??? for steamworks integration ??? for sound library (probably Bass or fmod)

Ugh, and I just remembered that I rewrote the server to simplify it immensely for now. I can always built it back up to the complex beast I had before. But for now.. I have to lower my scope and all that fun thing.

So that is my rant for this post.

Soooooooooooooooooooooooooooooooo

I will be releasing the client in extremely small chunks at a time. Iterative development, I believe it is called. And I mean REAL BASIC to BETTER to OMG!

Until Steamworks integration is implemented, the client will prompt for an email address and password. The server will send out a verification code to confirm the email address is valid, then you are good to go. I will enforce 2FA via email from the get go, in order to log in. There is no excuse for any client/server software to NOT have it.

That account component will be replaced with steam once that is setup.

So the above will be the first build. The 2nd build will address simple character creation/deletion. Then the plans for the 3rd build is some kind of “in game” component to build off of.

Until steam integration (AND hopefully itch.io integration), the client will be downloadable off the www.osinia.com website (when ready), and I -hope- to have an auto-updater/patcher working well.

Anyways, see you next post!

Well, hello there!

Ironically enough, all of my development has stalled when I developed lower pack pain after watching Jurassic World Rebirth. I joke with my kids that it was due to how bad that film was. But alas…

Dipped my toes back into async programming and pulled my toes right back out. Turns out, it really isn’t needed for an extremely small scale MMORPG after all. huh!

So getting back on track…

Did some development on the map editor. But one thing I learned. Visual Studio is getting updates every few days for some reason. But those updates doesn’t get any QC applied and there are memory leaks up the wazoo. Broken autocompletes and several other glaring and embarrassing bugs that would have been caught if there was a QC team.

One of these days, I am going to learn not to upgrade if my current version is working fine.

Someday…

So… Work smarter, not harder… then work harder… then back to smarter… -sigh-. The cycle never ends. Changed up the database again. With an abstraction layer, the change is really… 5 minutes of work at most. Adding some POCO <-> DTO translations to keep layers/domains separate. Also keeping in mind that eventually, some day, the game server(s) will be running on Linux. But for now, I was able to secure a sweet deal on a more stable windows VPS that can serve as dev/qa/prod with a reverse proxy running on linux.

I figure as I get with-in 6 months of retirement, I can swap out the database layer and hosting to linux to keep costs down even more. Until then, I just got to quit making architecture changes and keep moving forward in features, etc.

Spent today working on the tileset editor and some QOL to keep me sane. At the end of the day, the ugly Tileset Editor is complete enough for general usage.

For those wondering why the pace is so slow. There is… so many hours in a day, and this is only a one-man dev “team” at the moment. With the under-the-covers backend stuff out of the way, I am working on the developer and content creation tools. Once those are far enough along, I can create content that you, the players, will see in-game. It all takes time.

Well, another coding session completed.

Soooooooo.. Project Management. It can be very useful, especially at work. It can be useful for your personal projects as well. There is something called a dependency chart. It is an upside down tree where you split out the project into components and split those out into dependencies, and so on and so forth. Once everything is broken down, then a very nice MS Project file can be created and timelines for each piece gets created. Once you add times to the smallest components, the software literally accumulates all of the times into the final timeline for the project. It’s really a nice piece of software.

Too bad I didnt use it for this project.

-sigh-

So… While starting to map out the map editor.. I realized I need tile sets … … .. so I created a tile set editor as this game is based on the 4 elements and each tile should align with one element.. … so that is what I was working on. Once that is done, I will be working on the animated tile editor. Up to 1000 frames per animate tile.

Since each map can be of “unlimited” size, and consists of 4 layers under the player/object layers and 4 layers above. Not including any background or weather layers. I want to make sure that each tile on each layer in each location could be animated. I am thinking of 4 layers below and 4 layers above though that number may change by the time I get serious with the editor.

That is it for now!

Well, the last few days was working on tools and creating a resource manager. You know how useful a resource manager can be? Loading textures, fonts, music, etc on demand, keeping track of references, all that fun stuff. Very useful when the manager is shared among different projects like the client and tools.

Speaking of tools..

I had to build a fricken converter to convert all the graphics into a slightly custom file format in order to store the width and height of sprites and tiles with-in that file. I couldn’t use an image’s property to add custom properties… would have saved a lot of headaches.

The good part is that it’s an easy 3 line change in the resource manager to load such a change and the rest of the projects don’t need any changes.. yay?

I am currently working on the map editor. I could have easily used Tiled, and was seriously evaluating it. However, just like my evaluation of existing game engines, it is way more than what I need, then I would have to create a translator between it’s tmx/json file format to one that is more friendly and much quicker to load for my engine.

It did give me a few ideas, however…

Eventually, I will need to post screenshots.

Be warned, a lot of rambling technobabble, and… yuk. Bring coffee.

You see, I tend to do things the hard way, make mountains out of mole hills, then go back and redo everything from the ground up the right way… or the less wrong way… then redo it again and again until I get it how I like it.

Much like my approach to everything in life..

My ultimate goal is an old school 2D MMORPG with grid based movement, old school graphics, with “new” school features. Makes sense, right? This is to be my ultimate, 100% free game that should last well into my retirement and.. hopefully, my death bed. How is that for depressing?

I have worked for the Gov for decades now. Hoping between COBOL, Natural, Java, Visual Basic 5/6/.Net, and C#. Not to mention some light Database Administration (MSSQL & Oracle), Server Administration (Windows, Solaris), and some server and workstation hardware administration under my belt. So, I have dabbled around a bit over the decades.

Throughout all of the above, I have settled for a little bit of everything above and a whole lot of Java/C# development. The majority of the programming tasks were backend applications and processes until the last 2 decades where some of my work took me to the front end (help!), web development.

Home, is a different story, purely C#, Windows/Linux Server Administration, MSSQL, and mySQL administration. My front end experience was from roughly decades ago using DirectDraw7 with Visual Basic 6 and Purebasic (PB). I haven’t touched those languages in years, due to focusing mostly on work and family. Now that the little ones have mostly grown up, I have a little bit more time to devote on this ultimate project.

With this project, I wanted to work with what I was comfortable with. However, when looking at the gamedev landscape. Things have changed. And not in my direction (2D).

So… I dug up my old Visual Basic 6 license and installed that puppy on my Windows 11 Pro box. And was extremely lucky to find some old burned CDs that had some directx dlls and got to cracking… just kidding, installing and running was a bit of a pain and… directdraw isn’t supported any longer. It was replaced by… Direct2D.

And.. Direct2D doesn’t work with Visual Basic 6 (VB6). Hmm. And VB6 isn’t supported.. hmm. And I was spoiled by C# and no need for separated runtime installs (it just distributes or comes with windows updates, etc, etc.). So.. VB6 was out of the picture.

One of my requirements was to be able to run the client on Windows, OSX (yes, I have a mac mini for development 😀), Steam Deck (so Linux), iPhone/iPad, and last but not least, Android. And must be 64bit. None of that old 32bit cruft. So with all of that, VB6 was way out of the picture. Okay, lets see how PureBasic has progressed. Well… not much in the direction I had hoped.

So… while looking for a VB6 alternative, I came across Twin Basic (TB). I mean, just look at it. It is beautiful. Definitely a flood of emotions working with it. The developer is wonderful, the community is wonderful. What more could you want? Well… it is subscription required for the features I require. That is okay as I don’t mind supporting that way. It works with old DirectDraw DLLs, which is good. However, those DLLs are not cross platform compatible. So that was one strike.

It does work nicely with Winsock. However, absolutely did NOT want the server side to be in Basic, no matter the dialect (too spoiled writing server side C# fun stuff!). So I looked around for a network library that is compatible with both TW and C#. I found my old license (and) subscription of Socket Tools. Tested a few things out and TB is compatible with it, and, of course, C# has no problems on it’s end. Success?

Well, technically yes! Got a POC (proof of concept) going with a TB client and C# server. Got some stuff rendered on the screen via DirectDraw. Everything seemed fine. Also, TB doesn’t have an issue with dpi differences, which is kind of a big deal now days. However, being stuck on Windows for the client bothered me. The code couldn’t be reused across OSes at this time. While Linux/Mac/Android are due this year, there is no mention of iOS… hmm..

I would also have to figure out a way to use a cross platform graphics library other than DirectX. I.. really do not like reinventing the wheel. And I am not willing to sit on my thumbs waiting around. Life is too short. So I kept looking…

Here is where I went a little off into the weeds. There are some gamedev engines I started looking into. Unreal and Unity both have assets for making 2D games… but 2D mmorpgs? There are a very few, but overly complicated setup and development. Basically, those are 3D engines first, and 2D features somewhere lower on the list. Plus, both engines are bulky for something that should run lean and mean.

Around this time, I wanted to make sure I did -not- have to worry about authentication and account verification. So I wanted to use a pre-existing service that has all of that built in and has integration points with whatever tools I will be working on. itch.io did not have anything at that time. GoG was both not reliable and didn’t have any system at the time. And Epic had no such system. That left Steam. Fine.. Forked over $100, and got my steamworks kit. For iOS, Apple has the Game Center and Google has Google Play. Server side, this is a little easy as you can grab the person’s unique Id per platform and merge back-end accounts if wanted.

Along came Godot. Server side, client side, 2D first. Server can run on Linux (A must for future retiree budget constraints). Has C# integration for client and server so anything with .Net integration will work fine with Godot. Perfect? So I thought… The tools leaves a bit to be desired and the games made with it might as well be 100% open source.. there were no attempt at optimizing things. Too slow, too clunky.

~sigh~

I had to roll my own 😭. C# on both client and server side. The goal was to use Winforms for the client side. Got a week or so into that before I realized that WinForms for .Net still has major bugs from the early 2000s that makes it … worthless to put it nicely for anywhere but a controlled environment. The dreaded DPI. You can design forms in one DPI, and it renders wrong on another. In other words, things don’t look the same on different computers… something that was solved by everyone else decades ago… Microsoft hasn’t gotten around to solve it for WinForms. This is a known bug and issue was raised (I bet, yet again), with no solution in sight. So….

Second client rewrite (thankfully, wasn’t far into the first client), is 100% graphics (no WinForms), SFML with TGUI for the UI. Unlike most developer communities, these two are awesome and actually love what they do! A breath of fresh air 😃! My job this weekend is to get this new client up to speed of the old client… List, Creation and Deletion of characters and the ability to “choose” a character to play. All in the confines of a graphical interface instead of … WinForms. Yuk.

Onto the server side, this is the 2nd rewrite. Was able to reduce a -lot- of code and it is -almost- caught up to the previous version. At my job, I have done some database migrations in the past. Data migrations isn’t a big deal as the big 3 databases have standard data types. Application/processes migration isn’t a big deal as long as they were designed correctly. During my time, I have noticed that most are not designed properly in that aspect.

Thankfully, my servers are. Out of all of the database software, I am absolutely in love with Microsoft’s SQL Server. Especially when working with it in C#. It’s like a breath of fresh air compared to IBM’s DB2 and Oracle’s… Oracle. But I digress. Keeping in mind the need for a budget database and that I absolutely do not want to be bogged down on DBA duties when I retire. I migrated the server from using SQL Server to mySQL. The choice was mySql or Postgresql. Errr. I had -some- experience with mySQL… so that was my decision. Paying roughly $15/month to let someone else manage it, host it, and I get to dev against it. Win-win. But I do miss SQL Server….

Lets talk about Steam and their buggy SDK. Both the Windows client and the Linux/Windows server uses the Steam SDK for Account authentication. This allows me to store the unique Steam Id in the database as a reference and still be compliant with EU’s GDPR. It also allows me to integrate achievements, cards, and Steam does have a nice game landing page… Anyhow, I came across a “well known” dirty secret Steam won’t tell you about. The SDK will break if you run it on Linux for a game that isn’t listed as “Released” on Steam. I spent like a week trying to find out why my server runs fine on a Windows server but not on a Linux server. There is an appId you can use “480” to test a very small amount of features (not usable in my case). But that worked… my appId did not.. had to find out the hard way then find some references online but not in the SDK docs. Still pisses me off that such a crippling bug is not in the SDK docs. So for now, my server runs on a windows server… but periodically, I deploy it to a linux machine under a different appid to make sure I didn’t break anything on my level.. ugh!

Let’s talk finance so far. I have to be aware that my retirement income will be 1/8th of my current income. Yeah yeah, Gov does -not- pay anywhere close to my field’s standard rate when not retired. You can forget it when retired. So… keeping that in mind…

Domain: $12/yr. Website Hosting: $20/yr. Windows Server Hosting: $35/mo. Managed Database Hosting: $15/mo. QA Linux Server Hosting: $5/mo. Gateway Hosting: $5/mo. (soon Prod) Linux Server Hosting: $5/mo.

So… combining all of that per year is something like.. $812/yr. ($68/mo.). Roughly 1/2 of that is the Windows hosting. However, that goes away once the game releases which reduces the costs to $420/yr ($35/mo.). That is still a hefty chunk out of a retirement check.

Of course, that is without a proper setup. There should be one gateway per server, one database install per server, etc. Plus the network diagram is literally…. Client -> Gateway -> Game Server -> Database Server.

All traffic between the gateway/game server/database server are internal traffic (the LAN, if you will). That leaves as fat as a pipe as possible for the gateway server <-> Clients without any bandwidth penalties.

There really should be a cluster of every step of the way (at least 2 servers per step). But… then you get much more expensive. And there is no reason to do that when my expectation is < 10 people playing 😁

There are “one off” costs such as any licensing that is needed for libraries (if any). I still need to do some kind of music and sound FX. I looked at SFML.Audio but I hear it has issues on OSX (I’ll have to verify). If it does, then my second choice is BASS and third choice is FMOD. Both can cost money, even for free games, depending… Then there are the assets themselves. Music, sound FX, graphics. Some I have purchased already, but I would like to commission everything and have them in game before I retire.

The fun part about knowing you will retire, is that you better get your (big) expenses paid for before you retire.

With all of the above said, even though I absolutely hate reinventing the wheel, sometimes you got to do it (mostly) from scratch to get things done the way you want them.

The next post should be screenshots (or video?) of character creation, deletion, selection. Nothing fancy as I concentrated on both the hardware and software infrastructure first. Just now getting into the viewable stuff.

See ya next time!