Always thought this'd make for an interesting side-project, but I never found the motivation to build/plan it.

There's the matter of which technology to use for coding it. I'm doing web-dev in school with nodejs, so right now that's what I'm mostly acquainted with. I have a couple of web game projects that render stuff directly on the webpage using html canvases, and do multiplayer networking stuff via sockets. In theory it's possible to do it this way, but web+socket games are difficult to protect since front-end code is so freely available to the client.
Re-learning C++ is also a possibility but that'd be time and mind-consuming!

I've never done an isometric game before, but investigating a bit, it's not complicated to do. Fundamentally changes the rendering of map tiles, characters and such.

As for the game systems, animating the characters, linking the animations properly and moving them around sounds like a potential challenge, considering all the states a character can be in (rotating, moving, grabbing something, attacking, etc.) and how they should be able to change from one state to another seamlessly.

Pathfinding also sounds like a challenge. The obstacle map must be able to change dynamically considering all the moving characters. I've done A* before, and I'm sure it's reliable and efficient enough. Also to take into consideration is that characters need to rotate into the direction they're gonna move in before actually moving, so the character animation system should be reliable enough to support this.

The lighting/illumination system could also present complications, considering multiple moving light sources. I've dealt with this problem on a past project of mine, but I don't think it was particularly efficient, I'd have to check it again.

As for NPC AI, I'd probably just *borrow* code from the original v2 server, maybe changing anything that would seem reasonable to.

I've started a little nodejs project where I render some isometric tiles, walls and foreground objects in the proper order and position.


Potential improvements/changes over original v2?

Considering this would be more of an open-source hobby/side-project, not much attention would go towards server hosting, account safety and such.

This is more of a rambling thread where I throw ideas out in the open, motivation comes and goes, and I'd find it difficult to ever finish this, let alone progress to a playable state, but it'd make for a cool project to learn more from.

When I had issues with the client, I was thinking the same thing.
I would redo the program from the original source. That way pathfinding is nothing to think about. Same as the character movement sprites.
And so much more.

Moving up from C to C++ would be my next logical choice. They are much alike, but C++ makes life a bit easier.
Memory, for one. But also you can use something like SFML, a library to handle the icky stuff for graphics and such.

Reusing the code, like various algoritmes, would be helpful and speed things up. And the game you end up with would feel the same. That is, if you can decode the light-documented, cryptic code I would choose to use a lot of OOP, to make things easier to maintain.
Data hiding (so you can lateron make changes, and easier to locally maintain parts). Some inheritance would be nice too, a monster always has the same base, just different name, stats and looks, right? And then you can easily add extra stuff when needed, like flying. Program once, use always.

You could also make things real easy (well..), and start with C, repair the DirectX (as in:update the code to the current DirectX version), enjoy and go from there.

Current server runs on Linux. That might influence the language code you want to choose. Or...you could change that and use Windows for a server. A virtualbox with Linux is easily set up, and you can use it on 1 computer that way. Makes testing easier. Windows on Virtualbox requires licenses...
Computers have come a long way. This game doesn't require a lot of processing. So if you have an old computer somewhere in the attic, that might just be perfect for your server.

Last thing: some people would like to play this on a mobile device. Something you might want to think about.
I thought about it and decided it would be hell User Interface has to be translated, and work on 2 kind of devices. Android & Apple...a lot of testing. And worse...no default screensize.

There is no need to change the server side as it is largely independent of the client. They just needs to be able to talk to each other.
I think path finding is done server side, not in the client.

The "quick fix" would be to replace the DirectDraw in the existing client with something that is currently supported.

The server currently runs on the Red Hat 9 version of Linux.
I have converted it to run on the current version of Centos (on a VirtualBox on my PC).
It currently runs on the smallest server box I could get as the performance requirements are low.

However I have not been brave enough to move the current server to a Centos box as I would need to set up the new box properly and be able to run both versions in parallel.

In the back of my mind I recall that someone in the past tried this and hit serious data corruption problems. Unfortunately I have no record of who it was or what issues they had.
Updating to the latest Linux and client versions would have advantages but ....

That could also be an interesting alternative, to write just the client side and render whatever the server is communicating. I'd have to study the socket messaging protocol Daniel used, and get an understanding of what gets communicated when, and last time I checked that bit wasn't the most readable code

I'm aware that any important calculation (such as pathfinding) must be performed server-side, as per usual in multiplayer games. The client is there exclusively to render based on the server state.

I'm using a Linux Mint VM to code stuff so anything that would need to be run on linux can easily be done there.
An advantage of nodejs is that whatever you code (as long as you keep browser compatibility in mind) can be rendered in a mobile phone, though you do have to change the layout and stuff to be more readable/usable in a small screen.

I've used SFML before so if I decided to go with C++ that'd be my go-to choice.