81 lines
6.1 KiB
HTML
81 lines
6.1 KiB
HTML
<!doctype html>
|
|
<html>
|
|
<head>
|
|
<title>Townengine Wiki : About Townengine</title>
|
|
<link rel="stylesheet" href="style.css">
|
|
</head>
|
|
<body>
|
|
<h1 style="margin-bottom:0in">T1. About Townengine<span style="float:right">{twn}</h1>
|
|
<a href="index.html">Go back
|
|
<p><a name="introduction"></a><strong>T1.1 </strong><strong>Introduction</strong>
|
|
<blockquote>
|
|
<p>Townengine, {twn}, is an opinionated game development framework designed around specific set of ideas:
|
|
<p><b>Simplicity.</b> It makes assumptions that trickle down to your game code. There's no delta between frames, nor resolution change.
|
|
Textures have constant known size, not requiring scaling.
|
|
<p><b>Managed state.</b> Designed around this we can provide hot reloading at any point,
|
|
serialization for save files and debug dumps, as well as synchronization over network, without any user code.
|
|
Every frame apparent engine state is cleared, which removes another variable for you to handle, - when to initialize.
|
|
There's no need for you to call `LoadImage()` of sorts before using it in render, you just pass filepaths around.
|
|
Input is initialized anew each frame, making rebinds trivial.
|
|
<p><b>Device care.</b> Older hardware is still used in many parts of the world,
|
|
which users might not otherwise be able to make games they dream of.
|
|
Restrictions also constitute in desired aesthetics. Graphics capabilities are limited, but
|
|
what is present, - is heavily optimized. It is rather different from performance-driven approach that tries to take
|
|
advantage of the latest hardware and features, sacrificing both the reach and portability in process.
|
|
<p><b>Portability.</b> Written in C11 with all dependencies being in C, it's possible to compile it to most platforms.
|
|
SDL2 is at the center and you cannot get better than this. Default graphics API is OpenGL 1.5 with extension detection.
|
|
As an example, it builds and runs on Haiku OS with LLVMpipe.
|
|
<p><b>Language agnosticism.</b> API is restricted to minimize the amount of glue code.
|
|
Language interpreters don't need to be part of the engine itself. Anything with C ABI support can link to it.
|
|
/share/twn_api.json schema is provided for automatic binding and annotation generation.
|
|
<p><b>Use-case orientation.</b> It doesn't try to be a yet another general purpose engine conquering all and nothing.
|
|
Instead we seek particular use cases and implement the most essential parts.
|
|
User code copying should be promoted instead of delegating it all to the engine, this way we don't restrict.
|
|
<p><b>Iterability.</b> Defaults provided for most of the API, making initial code faster to spring.
|
|
Hot reloading works for both assets and code.
|
|
<p><b>Low latency.</b> Care is given to various incarnations of feared latency. Engine is fast to build, allowing for low commitment local patches.
|
|
Startup time is profiled and frequently looked into. Streaming is used as much as possible.
|
|
<p><b>No-Versioning.</b> We don't stick to releases and "contract" obligations for things to remain stagnant.
|
|
It's fair to ask end user to put little effort if they need newer set of features, instead of putting all the burden on us.
|
|
You can always just stick to particular version you started the development of the project with,
|
|
{twn} doesn't need system wide installation.
|
|
<p><b>Bounded.</b> Most places assume runtime limits, to help with portability and growing out-of-hand complexity.
|
|
Frames cannot take more than sane allocated time, breaking off infinite loops.
|
|
<p><b>Toolable.</b> External editors are the way, with their own separate modes of being. Simple web socket interface will be defined for that.
|
|
</blockquote>
|
|
<p><a name="wiki"></a><strong>T1.2 </strong><strong>Wiki</strong>
|
|
<blockquote>
|
|
<p>Purpose of this wiki is to collect information on various usages of {twn} across the genres, FAQ style.
|
|
You're welcomed to contribute to it. It's written in HTML so basic you can edit it by hand.
|
|
Just check <a href="template.html">template.html</a>.
|
|
<p>Content is divided into chapters, where prefix specifies its category. Currently following prefixes are used:
|
|
<ul>
|
|
<li><b>T</b> for townengine; development and apis.
|
|
<li><b>G</b> for gamedev; guides and FAQs on game making.
|
|
</ul>
|
|
</blockquote>
|
|
<p><a name="abi"></a><strong>T1.3 </strong><strong>Procedure Interface</strong>
|
|
<blockquote>
|
|
<p>For native code ABI defines convention to ease tooling integration. Platform/compiler C ABI is assumed,
|
|
but it should be trivially expressible in JSON-RPC as well.
|
|
<ul>
|
|
<li>32 bit floating point is the only numeric type.
|
|
<li>Procedure parameters can only use basic types, with no aggregates. Exceptions are Vec, Rect and Color types.
|
|
(see /include/twn_types.h)
|
|
<li>Enum types are allowed, but must be converted to floats. Identity strings are preferred.
|
|
<li>No opaque nor pointer types allowed, use string keys if needed. Think of it as data base relations.
|
|
<li>Only null terminated string is allowed as a sequential type in both parameters and returns.
|
|
<li>Return value could be a simple aggregate that is translatable to a dictionary of primitives, without nesting.
|
|
<li>Symbols should not contain numerics. For example, sqrt2 must become square_root.
|
|
<li>/share/twn_api.json file is hand-kept with a schema to aid automatic binding generation and tooling.
|
|
<li>Parameter names should not collide with keywords of any language that is targeted; if so happens, parameter alias could be added.
|
|
Currently forbidden: <b>repeat</b>.
|
|
<li>Procedure can't have more than 8 parameters.
|
|
<li>Decimal portions of floating points are lossy both due to rounding errors and text representation,
|
|
thus they cannot be relied to hold for equality. Integer parts of floats are good up to 2^24.
|
|
<li>Returns must be restricted/closed on being constant over frame, parameters or asset frame.
|
|
</ul>
|
|
</blockquote>
|
|
</body>
|
|
</html>
|