Restructure repo to contain the entire project

[jmickle66666666]

As pointed out in #69, there are some issues with the way this project's structure in git. I am gonna host the entire project instead of just the DoomUnity library, but there are some things I need to do before this:

Clean up and pull (or just delete) any forks I have, I don't want to leave any open when I change the structure because fixing conflicts would be a nightmare.

Start a new project file with the current library added, and use that as the base for the new repo. My current project for work on the engine has a ton of irrelevant stuff outside of the Doom things.

Replace my current build script to a cross-platform system using SharpZip, as it is a useful part but currently uses shell script execution instead of a zip library.

[IsaiahKelly]

Start a new project file with the current library added, and use that as the base for the new repo.

Does this mean you're planning to create a completely new repo or just restructure the current one?

I'm actually working on a project of my own to port content from an obscure doom-like engine called ACKNEX 3 (GameStudio A3) to Unity. Now due to the similarities between the two engines your repository should be very helpful to me. So thanks for sharing your work!

However, due to the extreme similarities I've been thinking it would be a lot more beneficial if I created a very generic framework for Unity that would allow for the importation / conversion of multiple doom-like engines (e.g. Doom, ACKNEX 3, Duke Nukem, etc.).

This would not only encourage collaboration between multiple developers, but also ensure maximum popularity and utility for the project, since it would be covering all the most popular 2.5D game engines out there. In fact, there already seems to be some interest in such a thing. My own work on such an obscure engine alone like ACKNEX3 will probably not benefit anyone else at all.

So would you be at all interested in working together on a more generic and larger scope project? You can of course continue to work on just Doom support as the foundation, while I work on adding ACKNEX 3 support as well. Then we can look into adding support for other engines in the future.

I think the key here would be to just keep the larger goal in mind while building support for just a few engines at the start. So we can create it in such a way as to allow for easy additional engine support in the future. Of course this would all mean we would probably want to rename the project to something more generic to better reflect it's grander purpose.

What are your thoughts on this? No problem if you're not interested, I just thought I'd share my thoughts. I can always just go off and do this by myself, but it's always better to work together with others when you can.

[jmickle66666666]

I think if there were to be a shared repo, I would have to split my Doom Wad library code into a separate repo from the Nasty Engine. This isn't entirely a problem, it would just mean working with 2 repos for this project instead of 1. The code is already semi-agnostic in a lot of ways, everything in the WadTools folder is intended as the Library part, and everything in the GameScripts is Nasty's engine code.

My intention was to keep the same repo, no point abandoning this one. A good solution could be to eventually split out parts of the library section into a separate repo, but the main concern is that it is still being heavily modified as I work on Nasty.

So I'm not entirely against the idea; I think it may be a little early, but you are welcome to use the code in your repo and eventually I may start transitioning it away from Nasty's codebase eventually.

[jmickle66666666]

Also you just reminded me: https://github.com/sirjuddington/SLADE/issues/616

heh

[IsaiahKelly]

Also you just reminded me: sirjuddington/SLADE#616

Ha! Wow I totally didn't realize you were the same person I talked to over there. Small world. 😄

Yeah, converting the contents to Doom was one of the possible paths I was looking at. Since I could then use it in a Doom source-port or even export the map data to use in Unity.

[IsaiahKelly]

I think if there were to be a shared repo, I would have to split my Doom Wad library code into a separate repo from the Nasty Engine.

In restructuring this repository for such a purpose, I would delete the Nasty engine content completely and replace it with a new generic, game agnostic engine (used for all supported games) in a new separate repository. Then make each import module (e.g. DoomUnity WAD library) a submodule of it.

Perhaps I can start work on such an engine in a new repository and we can explore possible integration with your wad library?

I think a helpful rule to follow here is to keep the import tools for each game completely decoupled from the game engine. This way we can build a kind of universal "retro" FPS engine that can be used for pretty much any game or thing you want, without reinventing the wheel every time.

Note: I still don't fully understand how your Nasty engine works exactly or why you need to build a wad to make it function. Not exactly sure what the reason is for doing that. Why can't it run natively in Unity?

[jmickle66666666]

To clarify: Nasty itself is a user-end doom engine, that happens to run in Unity. It is an "example implementation" of the DoomUnity library that I originally started. The engine wad is necessary for certain aspects of making Doom mods work in Nasty correctly; for instance externalising a lot of hard-coded information from Doom. Keeping it in a Wad rather than a folder (or zip, etc) is both easier for modders to work with and also just a cute implementation.

I should however, get rid of the python script and instead use C# to build the wad, so it is possible from inside Unity (and automatically).

The WadTools part of the code (I believe) is completely separated from anything else in the project, so that should be able to be used standalone anyway. I even tried to avoid using using UnityEngine; where I could; to make it agnostic even to Unity.

Personally I'd like to keep Nasty a Doom engine as it's main goal, but I'm happy for it to share code with another engine, especially for the game implementation of Doom content.

[IsaiahKelly]

Sorry, I'm still a little confused.

So if I understand you correctly, Nasty is a custom (non-source-port) Doom engine, and the wad tools/library is used by both Nasty and Unity. Nasty can run native wads, while the wad tools can be used inside Unity to import/convert wad content for use in Unity? Is that mostly correct?

I guess my confusion here comes from the intermingling of the two, and I'm not sure where one stops and the other beings. I probably need to study your repo better before going any further here 😃

[jmickle66666666]

That is mostly correct, yeah! Nasty began as a test project for the wad tools, just to see if stuff in the WadTools library was working. The clear distinction of stuff are the WadTools and GameScripts folders. They could be renamed DoomUnity and Nasty respectively for instance.

Everything in WadTools should only rely on other things in the WadTools folder (the one exception being WadFile.cs which requires SharpZip to handle opening PK3 files, which I should make optional)