UOX3.org

As some know, I love to dabble with c++. I like learning how to use the new standards, etc. Unfortunately macOS hasn't fully implemented c++20, so I
am fairly restricted to c++17. But that is ok, as by now c++17 is supported on most platforms.

I am curious on what a c++17 rewrite of UOX3 would look like. Not perhaps a total redesign, but a rewrite. So I have been dabbling on on off on many starting positions. With the new year approaching, I thought I would make it a true concerted effort, and see how far I got.

Given that, I have a few insights from my previous dabbling. If I don't want to redesign "everything", it would be helpful to have a code base that I can examine and keep design aspects. Given that, I knew it would be important to have a version of UOX3 without JS that can compile. So that was the first thing to do. I have that up on my git, uoxr. But this uox (UOXR) does NOTHING, so don't every use it for any operational purpose. It is just a code storage for me to go and look at (and others of course, if they so choose). The build up version is UOX4 (I will probably rename that to just UOX, but who knows). This is my dabbling area of what I want to trudge forward.

Now a few words:
My targets are ARM macOS, and Windows.
The standard I am using is C++17 (and it is expected to use at least that)
I am attempting to use the new auto style of methods, to reinforce that this is c++17.
I want to keep things simple, so I don't plan on hundreds of settings.
Backward compatibility is not a must, but you will see that I don't stray to far.
I am not using spider monkey initially (JS). There are several reasons:

• It is a pain to build a newer version and pollutes your machine with several requirements in terms of tools/compiliers

• It is an unneeded complication to obtain a working core.

I will probably add some scripting at a date, when the core is functional, and I can determine a consistent manner to expose data/functions.

Why I am mentioning this:

• Well, to motivate me is the primary reason.

• Perhaps generate discussion.

• For those who want to play with c++, something they might want to play along with.

Is this a "takeover" of "your favorite emu here"?
Nope, I don't plan to come close to other emus that have had 20+ years behind them. Just a project to dabble on.

What I am hoping for?
Well, first that I keep motivation to trudge forward over the months to come. But more important, to expose and perhaps engage in conversation on
C++, and design. I want to learn as well!

Note:
I do macOS natively, so the windows project/compiling always lags. I don't have a VS project yet for UOX4, but will once I get to a reasonable base (in a week or so). I use the VS Community Edition 2020 or whatever the latest is, 64 bit. (for what it matters, I use Win 11 on a tiny Beelink SER3 (Ryzen 3750).

UO Data
One thing you may notice, is I handle UO Data differently. I parse the data files on startup, and for each tile, include a pointer to a structure that contains all information about that tile. I do this to save lookup the information, which essentially every use of tile requires. This is a case where one can understand how 20 years later might have a different context then when it was initially done. Originally, memory was tight, so one didn't want to load everything in memory. Memory mapped files, interpreting on the fly was used. This also had the benefit of fast load times, which if the program required frequent restarts (which originally it did crash more then it does now), that was an advantage. But in todays world
, one can read it all into memory, parse the data into known useable structures, and associate the data with all needed information at startup. Eliminating that during run time. also saves a few execution cycles when it may actually count.

Text Parsing
UOX4 uses a standard format and parsing mechanism for all text input. Although the syntax is very similar to UOX3, it is not an exact duplicate. Inheritance is handle via the parser, and the syntax. For simplicity sake, it uses the following definition: All keys are processed in lower case (so they are case insensitive), and everything in [] (section header) is treated lowercase.

Currently UOX4 uses the following extensions to indicate what type of text data it is:

Late to the party, but honestly if it were me, I wouldn't even be doing it in C++ these days. Part of that would be the fact that I haven't seen and used much of modern C++, but some of it is also just the improved tooling and readability I've seen and gotten used to in other languages/platforms (particularly the .NET and Java space).

Of course, regardless of what platform you land on, I'd probably start with a different architectural base as well. The existing base is heavily single threaded by nature, and in a world with cores coming out the wazoo, it's not the greatest fit. It's not that the old one was bad, but we live in a different world from initial implementation.

The one thing I learned about my time with UOX3 as much as anything is - patterns and containers matter aka the right tool for the right job. Be it arrays vs maps, sorting and order of operations, all that sort of thing.

Given my druthers, I'd probably look at an event driven scenario with pools of worker threads to do the heavy lifting, where "things that happen" are just events to be consumed. A walk packet? That's an event. Double click? Another event. You'd have an incoming sink that would subsume all the requests and plant them on the work queue, and probably a single dedicated thread (or maybe 2-3 depending on size) that properly barriers sockets and sends responses back to avoid cross-thread contamination.

Of course, it gets ugly once you start worrying about concurrency (2 different worker threads having to operate on the same NPC for different reasons), but then that could be down to granular world region locks and what not.

I'll be interested to see how it turns out for you.

Ok, last message was completely garbled, trying to do via phone.

So I will summarize:
Tools = always something new and fancy. My experience is the best tool is the one you enjoy. You can have fun and make great programs from various. After all this isn't work. I still perfer C++ since it is supported by more then one vendor and almost every conceivable platform. NET for example, although pushing to cross platform, is till primary one vendor, and has such, platforms like my Arm Mac still don't have a formal release of the tool suite. But in the long run tool, are great, and they will always be another on the horizon. At the end of the day, it isn't that big of factor in the outcome of the final product.

Containers/patterns = I would modify that slightly, to data organization, consistency, and abstraction. Those will factor more in my experience. Picking the wrong container, can be replaced pretty easily (depending on your environment), but data orgainization is much harder to refactor. Consistency allows one to develop patterns that are easily reusable across the program. (as a side note, I noticed that the use of list in c++ is become less and less used, with the advent of the improvements in vector and static_vector). Containers can greatly impact performance, but are also easily (normally) replaced, code/data organization isn't.

THe concept of thread pools/worker threads is a good one. I see it as a central "run loop" like main thread, the joker thread feed.
Balance is the key though, not over working the threading, where it just becomes too complicated.

The other MAJOR factor, is FUN and learning. This is a hobby, and not a production item. I have never seen this as a project to compete with UO shards, hosting 100s. I have seen it more as an opportunity for people to get exposed to some programming, learn, try out things, and have something at the end of the day they can play and enjoy with some friends.

Yeah, but some of these tools aren't all that new.

From a comfort factor, I'd probably land on Java these days. It's not the highest performance language, but man, the level of testing and automation available is a god send. On a code generator I've written for work, I've got near 1000 unit tests now and whenever I do something a little unexpected it catches it. Combine with code coverage and other things, it does make life nice. And we're slowly layering integration tests above.

.NET Core is an interesting target, but it's still relatively immature on other platforms.

It's that constant tension between Data and Code, where over time things change - never a simple "This is the way" in all forms.

The problem is, as always the one I had with Uni assignments back in the day - 80% of the time is learning something, and once learnt, finishing it off is a challenge without wanting to move to the next problem

That last part is SO true. Finishing is always the key. I suffer from that a lot *grin*. I love to explore, learn, refresh my learning, and my understanding. Never stop learning, why I like programming I suppose.

Yea, I find Swift to be my favorite if I I really just wanted to pick my tool set. But I realize that is way to localized for something that is run a client that doesn't even run on its major platform.