GameApi Builder

Starting from 2013, gameapi-builder has been under development for over 13 years now. Because we already had experience with creating a commercial game in amiga times, our next project needed to be slightly larger. Amiga game had 100 levels, so our next step was 100 different games. These 100 games were finished for finland's 100 year birthday year 2017. Unfortunately those games turned out to be too small toy samples, and thus were quickly forgotten after the birthday. The web page meshpage.org has the next level after that. We started collecting 3d graphics sample scripts immediately after 100 game samples were finished.

While building these 100 games and the next level scripts, we collected all the primitives to a node graph. First cubes,spheres,cones and toruses were created for sample 3d models, opengl rendering, texture mapping, async network url loading, matrix library. At these early times, the frame rates feature was important and required splitting the code to two parts: Prepare()-phase and Render()-phase. So performance implementation moved heavy operations to the prepare-phase.

The builder tool user interface was also built, creating node graph display and ability to edit builder scripts using property dialogs and display the end result. Emscripten was used to provide web interface for the 3d engine to run our c++ code inside a web browser.

Then we build voxels, volumeobjects, movement nodes, quake/doom style movement or walking simulator mechanisms, ability to control the scene and player with wasd keys, music playing via ogg files or behind key event responses using wav files. Then obviously .obj file loading and getting sponza and sanmiguel to work properly.

Important development was glb/gltf file rendering. tinygltf library that we used provided only the glb/gltf file parsing mechanism, but rendering was needed to use our existing 3d engine opengl features. Simple mapping from tinygltf data structures(TF) to our mesh data structure (P in builder tool or FaceCollection in the source code) provided the initial render of the glb files. Then gltf materials support made it look awesome, using khronos gltf shader makes it respect graphics designer's original intent when the 3d models are designed in tools like blender. Sketchfab 3d models were used to test the glb rendering to ensure compability to most of the gltf standard data structures. Gltf animations were implemented and is working pretty ok / we can render phoenix_bird nicely. Other glb animated models should work too, assuming the files are in correct mode when saved from blender.

Then finetuning and bug fixing found tons of errors from the technology. Ever seen a software crash when mouse cursor is kept still for longer time? Debug a crash and moving mouse just makes the error disappear? These were all fixed and now our software is nearing proper stability. Steam release was done, with nice brand images and videos (https://store.steampowered.com/app/4181720/GameApi_Builder/), and then we're keeping software stable and waiting for customers to adopt it.

Of course, customers want output from the software. Our output is handled via deploy feature. HTML5 zip files are generated by the deploy process, and node graph contains a 3-node chain: run_window -> html_run -> save_deploy. The run_window node contains game event loop, and allows rendering the game to a window inside builder tool. html_run changes the platform and provides browser version of the game. save_deploy gives you a zip file that can be unzipped to a web server directory and it becomes part of the customer homepage or web frontend. Then simple iframe tag allows placing the game to an article. ogl_transparent_canvas feature allows changing between video canvas and transparent canvas to make the output embed properly to people's web pages.

Final optimization passes used browser's profiler to improve the load-time performance. This took nearly half year time, when we did nothing else than just checked the profiler output and allowed changes only to locations which took longer than expected time to execute. Threads and 8 cpus were used to improve performance, but sadly browser-side implementation requires SharedArrayBuffer implementation due to browser security, and setting up web server to correct cross-origin-isolated mode requires a domain name, https, SharedArrayBuffer enabled, and then the threaded version of the 3d engine can be loaded to see the best available performance setup. There exists two version, NO_THREADS, and THREADED version of the engine, and sharedarraybuffer allows going to the threaded version and utilize all 8 cpus of your computers.

That's all folks,