Note: It's recommended you read the dev 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.
It's recommended you fork the dev branch, and pull request your work there back to it.
The dev branch will periodically get merged back to the master branch, as new things become stable enough.
See build instructions 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.
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 Valve's VPC system to generate its makefiles and VS solutions. When modifying the project file structure, instead of pushing your solution/makefile, edit the relevant VPC files instead (most commonly "client_neo.vpc" and "server_neo.vpc").
Running the VPC scripts in mp/src/... after a change will regenerate the solutions and makefiles on all platforms. You may sometimes have to purge your object file cache if you get linker errors after restructuring existing translation units.
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. These are also defined with the VPC system described above, in the $PreprocessorDefinitions section.
No big restrictions on general code format, just try to more or less match the other SDK code style.
- C++11, except...
- Use const (or #define) over constexpr; while it is a part of C++11 spec, the v120 MSVC toolset that Source targets on Windows doesn't support it natively.
- 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.