Gdengine is a game design documentation engine. Gdengine automates render processes of various kinds of document formats, enable designers to utilize multiple variables that is used across design documents, and can be easily integrated to git based version control systems.
- Why made a game design engine?
- Gdengine workflow
- Intsall
- Dependencies
- Currently supported renderers
- Basic usage
- Supported macros
Because it is hardly sane to write documents in XML files when documents changes so often and have to be versatile at the same time.
XML is not suitable for VCS. There are two major formats for game design documents: PPTX and DOCX. Those are XML files and includes so many representational tags which makes it harder to utilize VCS. Though subversion somewhat enables better version control for the file formats, you lose many features as trade-off.
Game design document changes often, which is unideal but realistic. Designing process itself is not so painful becuase there are no limits in tooling or environments. Jira, google docs, notion, or any other collaborative tools you name it; what fits a team is the best tool. But time comes when you have to make a contained and statically built document. Those documents are prone to errors such as typos and outdated informations.
As much as I believe programmers should not be accountable for memory errors, I believe game designers and other developers deserve better game design processes. This is the reason why I made a Gdengine.
Gdengine is a tool for game design documents creation. Gdengine does two jobs.
- Process macros in index file.
- Render the index file into a target format(platform).
There are various predefined macros built in gdengine for easier documents creation. These macros let user to create multiple formats without modifying index file. You can also define your macros or add style files for deeper representational customizations too, though you need to make macros fallable if you target multiple formats at the same time.
Refer release page for installation.
You can build the project by yourself but you need to install following binaries so that gdengine can find such binary from environment path.
# Build binary youself.
cargo install gdengine
# You also need to manually install following binaries
# - Marp
# - Chrome or chromium
# - Pandoc
# - Graphviz
Extra dependencies if you build gdengine yourself
Caveat: Chrome has higher priority over chromium
Document renderer
- marp (slide as html,pdf,pptx)
- mediawiki (web served wiki page)
- mediawiki_preview (for preview)
- pandoc (docx, or say ooxml compatible file)
Component renderer
- flowchartjs (flowchart, html)
- flowchartgvz (flowchart, png, pdf)
- gdlogue (Dialgoue, html, png, pdf)
- webuibts (web based ui with bootstrap)
To be updated
- plotter ( Plot chart )
- gcalc (prbability calculation)
# Init
gde init
# Init project with extra git flag
gde init --git
# Render with given renderer module
gde render -m <MODULE_NAME>
# e.g. render with marp backend
gde render -m marp
# Render with pre-defined test scripts named wiki
gde test --target wikiGdengine uses r4d macro processor intenrally and all r4d built in macros are supported. You can utilize every r4d macros inside gdengine project.
Basic rad configuations are,
- All auths are open by default
- All macros are greedy by default
- Macro expansion is lenient + purge by default
- Use comment option of start. Comment character is
%. - Macro character is
$.
- Docx renderer with docx-rs with markdown-pulldown-parser
- With possibly domain specific language designed for docx generation
- Create a separate crate for converting markdown into pptx file
- Compile static binary of dot renderer rather than using system path or use flou-cli
- Easy documentation ( Though I found it is very hard )
- Cross platform without hassel and (possibly) without nodejs
- Intuitive macro definitions
- Useful document forms (pdf,pptx,html,docx)
- Various component renderings (dialogue, flowchart, webui)
This is a new cross platform implementation of previous gdmarp program.
Gdengine was recreated in Rust because gdmarp lacked several core features that follows.
Firstly, gdmarp uses M4 macro and it prohibits usage of ' and ```````.You can
change quote syntax but there is always a tradeoff that hardly tolerable for
text based rendering program.
Secondly, gdmarp is a shell script which collaborates multiple command line programs. Which means it is never meant for non-unix operating systems. And to make matters worse, some command line utilities were GNU specific version and used non-POSIX standard functions. Converting existing code into POSIX-compliant codes were painful and sometimes just possible for some features. Other platform was recommend to use docker image which was not the most ergonomic way of using command line utility.
Finally, gdmarp became just too big to maintain as a form of dynamic scripting language. Shellcheck is a great program, however I just missed so many features from complete programming languages and especially Rust.