buildat/doc/todo.txt

75 lines
3.9 KiB
Plaintext

Buildat TODO
============
- Modules should be run in threads.
- Design how to manage scenes in a future-proof way
- Implement easy Lua scripting on the server
- Allow creating Lua modules on the server, for those who don't like C++
- Allow recycling the same Lua code on the client and the server
- Move all Lua functions from client/app.cpp to a reusable location so that they
can be used from server-side Lua in the future
- New things in meta.json?
- disable_module
- override_module (in such a way that the module will be gotten from the
server with it's original name, and with the name of the overridden
module. The overridden module will still be loaded and be available to the
overriding module in some way.)
- Doxygen for the C++ interfaces
- Copy compiler flags (at least -m32/64 and stuff like -D_GLIBCXX_DEBUG) from
CMake to RCC++
- Support Cereal's shared pointer serialization in Lua
- Automatically fetch and build and patch Urho3D when building buildat
- Maybe no
- Automatic buildat root detection so that the server and the client can
generally be started with any working directory in either the in-source or
windows-installed configuration
- Precompiled mode
- Singleplayer UI
- Show all exceptions and errors on client using ui_utils.show_message_dialog
- Allow creating and destroying arbitrary amounts of replicated scenes
- magic.sub_sync_node_added -> replicate.sub_sync_node_added
- Use tags for module dependencies (tags, require_tag, disallow_tag), and
auto-tag each module at runtime with game_<current_game>
- Threaded mesh generation
- If an error occurs on the client in module initialization, show error and quit
- Show sandbox_test status at corner and don't show dialog unless something is
found
- Local split-screen multiplayer: Two options:
- One Urho3D instance with systems in place to manage two UIs and things in
the same instance (may be impossible)
- Allow connecting the input systems of multiple windows, which is simple
but less automatic and most people don't know how to get rid of window
borders
- Maintain a global budget of background processing per frame so that a long
woxelworld:update and ThreadPool::run_post() will not be run on the same frame
- Pre (lod) geometry can take up to 2500us, and post can take 7200us, which
means this will have a visible effect.
- Multiple replicated scens and voxelworlds, with threading, for servers with a
lobby and multiple worlds
- Don't emit all world generation events at once
- Handle module load order properly in reloads (unload by popping from top,
then reload everything until top)
- When reloading a module, unload all dependants first; then load dependants
again
- Each module should be able to choose whether they want their dependants
unloaded or not; eg. network can just store the socket fds and be reloaded
without anyone noticing
- Altough, network is very rarely modified so it doesn't really matter
- If a file tracked by client_data is deleted and re-added, it won't get updated
before server restart(?)
- An option in the server to just compile and quit (to be used when one wants to
check for compiler errors but not actually run anything)
- Saving and loading of the world
- Redirect stdout and stderr of compiler to log so that it's readable on Windows
- voxelworld: An easy way of turning a piece of static voxels to a dynamic node
- Fix server from crashing to socket "no error" on windows when a client
disconnects
- Keep track of voxel instances with handler_module defined on the client, and
call the handler module in construction and destruction
- Make some kind of an ace of spades clone (or less of a clone); something that
requires the game to control the creation and deletion of the world anyway,
and implement the required interfaces
- Check that modules are accessed in order of dependency to effectively maintain
recursive locking
- Fix everything in /games/
- Use builtin/main_context