原视频:
https://www.youtube.com/watch?v=LgbSYxf9vT4
Code Philosophy
- Simple(decoupled,linear)
- C-like C++
- Data Driven
- Do not compromise on performance
- O(N) mostly
no STL data structure, but STL algorithm is fine.
Data pipeline overview
Resouces: tress/larch.unit
(name.type)
compile
[source data] ----> [ compiled data]
- Source data ( JSON, textures,fbx,...)
- Compiled data : Packed binary ( can be platform specific)
- Separate steps: compile & run
- The windows executable is the data compiler (
--asset-server
) - Cross-compiles to other platforms
- Data compile is incremental
Data at runtime
- Managed by
resource_manager.h
- Load into memory:
load("tree/larch","unit")
- Accessed by systems:
get("tree/larch","unit")
- Grouped in packages
- Becomes bundles
Engine and editor
- Editor is a HTML5 application (Chromium)
- There is also a C# editor backend (We want to get rid of it)
- The editor viewport is the regular engine
- The engine runs in a window on top of the editor window
- It is moved in sync with the editor windows
- Engine & editor communicates through a web socket ( not a quite good solution)
- Editor reads and writes source data --> triggers compiles & reloads
- We can use the same mechanism to connect to a remote viewport
- and for example make an Android phone slave after the level editor
Extending the engine
- Engine can load DLLs to extend its functionality (Navigation,Wwise,...)
- A C based API is used for communicating between the engine and its plugins
- It's based upon query for interfaces
-
get_engine_api(DATA_COMPILER_API_ID)
-> struct with C function pointers plugin_api.h
- Plugins expose APIs that engine can query for
- (Editor has an extension system too)
Game dynamics
- Can be written as a plugin DLL
- Or scripted with Lua (LuaJIT)
- Lua API based on top of the C API
- Flow ( visual scripting language)
- Gets compiled to a "bytecode" ( of sorts)
- Interpreted at runtime
Build system
- CMAKE generates project files for the different platforms
- Ruby frontend to CMAKE:
make.rb -- engine -p ps4 -c debug
- Once generated , projects can be built in Visual Studio
- Libraries are installed with
spm.rb
(from S3)spm-packages.sjson
Platforms
- win32,xb1,android,macosx,ios,ps4,webgl,linux
make.rb -p PLATFORM
- Defines:WINDOWSPC,XB1,ANDROID,...
- Platform specific data folder
- Secret platforms:xb1,ps4
- Code for these platforms is in subrepositories
- Only the win32 can compile data
Runing on Platforms
- Usually we run in "file client mode"
- Start a file server locally
stingray.exe --asset-server -secret xHG7fHy
- (File server is the same as the data compiler)
- Launch runtime
stringray.exe --host 162.0.0.15 --secret xHG7fHy --data-dir C:\data_xb1
- Data is streamed over TCP to the client
- Can also deploy data locally (less common)
Runtime
application.cpp
- Load
setting.ini
for project - Init all systems (threading,files,resources,...)
- Lua callback
init()
- Update loop
- Update timers
- TCP/IP connection ( console server)
- System windows
- Input
- Lua
update()
- Calls update on game worlds
-
render()
( Rendering happens on render thread) - Other various system updates
- Lua callback
shutdown()