Note: It's recommended you read the master branch version of this document to make sure all the information is up to date.
We've moved to using GitHub Issues for issue tracking. Feel free to take a look and assign yourself if you're interested in working on something, or report bugs/features not yet included.
Also come join the Discord channel to discuss the project with others (see the "nt_semantic_sequels" and other related channels under the channel group "Architects").
The overall goal is to create a reimplementation of Neotokyo for Source 2013 MP engine, with the source code opened for viewing and editing (with certain limitations; see the Source SDK license for legalese). Original NT assets/IP are mounted as dependencies, and aren't part of the repository. It's like a mod of a mod.
The end result should hopefully be a shinier and less error-prone rendition of NT, with the source code and more cvars providing room to fine tune game balance, or come up with completely new modes entirely.
To see the Table of Contents, please use the "Outline" feature on GitHub by clicking the button located in the top right of this document.
It's recommended you fork the master branch, and pull request your work there back to it.
See README.md in this repo for setting up your build environment (currently supporting Windows/Linux).
To be safe and avoid problems with VAC, it's recommended to add a -insecure launch flag before attaching your debugger.
In the CMake Target View, right-click "client (shared library)" and click on "Add Debug Configuration". This should show a json file. Then, make sure it's similar to this (changing the game path to where you have it):
{
"version": "0.2.1",
"defaults": {},
"configurations": [
{
"type": "dll",
"exe": "C:\\Program Files (x86)\\Steam\\steamapps\\common\\Source SDK Base 2013 Multiplayer\\hl2.exe",
"project": "CMakeLists.txt",
"projectTarget": "client.dll (game\\client\\client.dll)",
"name": "client.dll (game\\client\\client.dll)",
"currentDir": "C:\\Program Files (x86)\\Steam\\steamapps\\common\\Source SDK Base 2013 Multiplayer",
"args": [
"-allowdebug",
"-insecure",
"-dev",
"-sw",
"-neopath",
"C:\\PATH\\TO\\NEOTOKYOSOURCE"
"-game",
"C:\\PATH\\TO\\REPO_ROOT\\neo\\mp\\game\\neo"
]
}
]
}
On the sidebar, click "Projects" then under your current kit, click "Run". Set the following:
| Property | Example value |
|---|---|
| Executable | ~/.steam/steam/steamapps/common/Source SDK Base 2013 Multiplayer/hl2_linux |
| Command line arguments | -allowdebug -insecure -dev -sw -game "/PATH/TO/NEO_REPO/mp/game/neo" |
| Working directory | ~/.steam/steam/steamapps/common/Source SDK Base 2013 Multiplayer |
Then under Environment, expand by clicking "Details" and add in:
LD_LIBRARY_PATH=[INSERT_OUTPUT_HERE]:/home/YOUR_USER/.steam/steam/steamapps/common/Source SDK Base 2013 Multiplayer/bin
SDL_VIDEODRIVER=x11
SteamEnv=1
Next is finding the steam-runtime under the Steam installation. This can be found
using the following command, replacing $HOME if Steam is installed at another directory:
$ find "$HOME" -type d -name 'steam-runtime' 2> /dev/null
Assuming default directory, it might be in either: ~/.local/share/Steam/ubuntu12_32/steam-runtime/ or if using a Debian based distribution: ~/.steam/debian-installation/ubuntu12_32/steam-runtime/.
Then change to that directory and replace [INSERT_OUTPUT_HERE] to the output of:
$ cd <STEAM-RUNTIME-DIR>
$ ./run.sh printenv LD_LIBRARY_PATH
After this, you should be able to run and debug NT;RE, just make sure to have Steam open in the background.
Example settings for debugging from Visual Studio solutions:
| Configuration Properties->Debugging | Example value |
|---|---|
| Command | C:\Program Files (x86)\Steam\steamapps\common\Source SDK Base 2013 Multiplayer\hl2.exe |
| Command Arguments | -allowdebug -insecure -dev -sw -game "C:\git\neo\mp\game\neo" |
| Working Directory | C:\Program Files (x86)\Steam\steamapps\common\Source SDK Base 2013 Multiplayer |
Break pointing and stepping the method CServerGameDLL::GameFrame, or relevant methods in C_NEO_Player (clientside player) / CNEO_Player (serverside player) can help with figuring out the general game loop. Neo specific files usually live in game/client/neo, game/server/neo, or game/shared/neo, similar to how most hl2mp code is laid out.
Ochii's impressive reverse engineering project can also serve as reference for figuring things out. However, please refrain from copying reversed instructions line by line, as the plan is to write an open(ed) source (wherever applicable, note the Source SDK license) reimplementation, and steer clear of any potential copyright issues. Same thing applies for original NT assets; you can depend on the original NT installation (it's mounted to the engine filesystem by a shared neo header), but avoid pushing those assets in the repo.
This project uses the CMake build system to generate ninja/makefiles and is integrated with IDEs such as VS2022 and Qt Creator. When modifying the project file structure, look into CMakeLists.txt and cmake/*.cmake.
In shared code, clientside code can be differentiated with CLIENT_DLL, vs. serverside's GAME_DLL. In more general engine files, Neotokyo specific code can be marked with a NEO ifdef.
No big restrictions on general code format, just try to more or less match the other SDK code style.
- C++20 within GCC 10+ and MSVC v143+ support.
- STL generally shouldn't be included in as it may conflicts with existing similar functions.
- Valve likes to ( space ) their arguments, especially with macros, but it's not necessary to strictly follow everywhere.
- Tabs are preferred for indentation, to be consistent with the SDK code.
- When using a TODO/FIXME/HACK... style comment, use the format "// NEO TODO (Your-username): Example comment." to make it easier to search NEO specific todos/fixmes (opposed to Valve ones), and at a glance figure out who has written them.
- For classes running on both client and server, you should generally follow Valve's C_Thing (client) -- CThing (server) convention. On shared files, this might mean #defining serverclass for client, or vice versa. There's plenty of examples of this pattern in Valve's classes for reference, for example here.