Open thread - discussion about project direction

[eezstreet]

The following are things that I want to tackle before getting into the complexity of a map renderer:

• Standardized types. Instead of DWORD this, WORD that, let's use the following types: uint32_t, uint64_t, uint16_t, uint8_t, int32_t, int64_t, int16_t, int8_t.
• Fix the audio system. Currently broken and doesn't support music.
• OpenGL renderer. The current SDL renderer has bugs.
• Investigate high CPU usage.
• -direct aware filesystem. The current filesystem does not detect for -direct, but it should. Likewise, the MPQ access should be made transparent. Instead of querying for something from an MPQ and -then- opening it through MPQ methods, just use one call for opening a file. (The modcode should have no access to the MPQ code whatsoever)
• Cleaned up DC6/DCC placement, draw either DCC as component based tokens or as overlays/missiles.
• Generalize some of the existing data structures that are commonly used, but not put into formalized classes (looking at you, hash maps)

Then, the next steps can be:

1. DS1/DT1 loader
2. Map placement
3. Entity control, placing of Type 1 and Type 2 objects in DS1s
4. Movement
5. Basic inventory management
6. Basic combat (Normal Attack/Throw only)
7. Basic monster AI
8. Skills, magic items, ... the finer elements that make up Diablo 2
9. Scripts for quests
10. Mod support, .txt compiler, tools, plugin support, etc.

I want others to contribute what they think should be done to the code to make it something you're more willing to contribute to. I'll listen to any feedback, but understand that there are certain things that I am not interested in doing at this point:

• Porting to Nintendo Switch, etc platforms (see point 10 above)
• Widescreen support (see point 10 above)

Converting to another programming language is not something I want to do. I understand that not everyone is interested in writing super-verbose C/++, but I want to keep the project as close to the original game as I can get, minimize the number of dependencies that I have, and keep support for legacy systems.

Likewise, this is meant to be a self-contained project that others can learn from, so there's a lot of hand-crafted algorithms like hash maps. I originally started this project because I wanted to learn how to make my own high-performance isometric game engine, and having minimal coupling between components is ideal. If I decided later on to go the route of std::ifying or boost::ifying stuff later on in the name of performance, it's much easier to graft that kind of system onto what I have here, instead of doing it the other way around.

...plus, modern C++ looks gross, I'm sorry. :(

But here are some good things to discuss:

• Overall structure of the project (is having modcode separated into DLLs a good idea? bad idea?)
• Naming conventions
• Things you genuinely want to see changed

[geekifier]

(I hope this is a good place to post this comment, as I did not think it warranted a whole new issue).

Are you aware of the OpenDiablo2 project? They seem to have a small team, and are getting quite a bit of contributions. They also seem to have the plan and TODO list laid out as well.

I know you're probably pursuing the C direction for the reasons you described above, and they went with golang, but with how labor-intensive remaking a whole game engine can be, it would be great if you guys could somehow join efforts. They are also working on HellSpawner, which is going to be a toolset - perhaps that's a piece that could be shared?

Given portability of golang, it has certain benefits; for example, I was able to run it on my mac with just a couple commands. The work you guys are doing is my only hope of being able to play D2 natively, as Apple has discontinued support for 32-bit apps in MacOS.

Anyway, I thought I'd mention it, as it seems like both your project and OpenDiablo2 are sort of in alignment as to the approach and goals. This is in contrasts with some other efforts, like porting D2 to the Unity engine for example. Thanks for taking the time to work on preserving this great, classic game for future generations :).

[nunotexbsd]

It will be great if both OpenDiablo2 and OpenD2 projects work toguether to achieve a higher goal: play Diablo II/LoD on modern OSes like Linux and POSIX UNIX like *BSDs.

I've helped testing porting devilutionX to FreeBSD and it runs smotth and very stable.

A few time ago I've ported OpenDiablo2 to FreeBSD repology.org so more people test it.

Thanks,

Nuno Teixeira

[eezstreet]

This project was actually started before OpenDiablo2. I have just been a lot slower to develop it due to IRL issues.

I have contributed some to OpenDiablo2 already. The main reasons I don't want to outright scrap OpenD2 and migrate to OpenDiablo2 is due to language choices and development direction. OpenDiablo2 used C# at first, scrapped the entirety of the code, then went to Go, then had to rewrite the majority of their code base to support a JIT compiler. I think they also have JavaScript scripting support too? In other words, it's a pretty volatile codebase and I don't really have time to commit to learning a new one every time I become interested or have time to work on Diablo related stuff again.

The choice of Go is a pretty peculiar one to me as well, as Go isn't really designed for games. It would make more sense to embed it or V8 into the game to handle scripting, but that leads me to the next issue, and that's interoperability.

I want OpenD2 to be as interoperable with the vanilla game as much as possible, and not introduce any new features unless they are critical. That goes for network access, save games, and mod support. With the exception of Battle.net, the executable and any extra files needed (configuration files etc) should serve as a drop-in replacement for the original game.exe and should seamlessly appear as any regular client in a network game. I don't get the impression that the OpenDiablo2 devs want to do this (as indicated by their code loading the .txt files instead of the .bin files, and editing the look and layout of the main menu).

That being said, our goals definitely run parallel to each other, and I would consider engine development to follow these tracks:

• OpenDiablo2: Bleeding edge prototype, proof of concept

• OpenD2: Measured and optimized product.

• Unnamed Project: This would be a fork of OpenD2 that is customized to enhance mod support, with things like a system of plugins, more TXT files, script ability, and so on. I'm still architecting what this will look like.

[geekifier]

What you wrote above certainly makes sense.

I am curious, does the announcement of Diablo II: Resurrected by Blizzard affect your plans and/or motivation?