Final Report
During GSoC 2018, my goal was to "add new frameworks and content to Terasology". Despite the initial project plan not working out as well as I had hoped, I believe I not only made a valuable contribution to Terasology in terms of content, I also believe I have made important notes and observations for the future of the project as an effective near-total outsider.
What has been achieved?
- "Kallisti" - a framework for virtualizing "fantasy computers" geared towards usage across arbitrary JVM-based engines.
- An API for communication between "Kallisti-side" and "engine-side" objects and concepts.
- A fully-functioning implementation of computers following the API outline of the "OpenComputers" mod as the first supported "fantasy computer".
- A simple simulator with JSON-based definitions for using said fantasy computers standalone, as well as testing the library's behaviour.
- "KComputers" - an implementation of Kallisti for the Terasology engine.
- In-game displays capable of both viewing in-game on the block, as well as in an UI.
- Item-configurable "Computer" block.
- Example peripheral implementation: Transposer, for manipulating neighboring inventories.
- A forked version of the no-longer-maintained JNLua project, integrating various patches, as well as cleaning up code and adding new bugfixes/improvements developed specifically for MovingBlocks.
- A forked version of the similarly no-longer-maintained Eris project, which is a fork of Lua 5.2 and 5.3 allowing for persisting virtual machine states. During GSoC, I have updated it to use Lua 5.3.5.
- Important observations about missing frameworks for the future, preserved on the Terasology Slack instance and being compiled into useful notes for the development team.
- An implementation of Barrels, developed during the bonding period as a way to learn the codebase's specifics further - unfortunately, the source code has been lost (see below), but screenshots remain: Screenshot 1, Screenshot 2
- Assorted pull requests to Terasology: #3387, #3411, #3430, and as a way to try working with the codebase pre-GSoC #3327
Where can the code made specifically for GSoC be found?
What has not been achieved?
In general, as I feel my output at GSoC 2018 overall has been slightly sub-par - even if the initially agreed-upon goals have largely been met - I am pledging to finish all of the stated goals for GSoC 2018 within the next month or so, as to be satisfied with my contribution to the project under the GSoC program. I also plan to help maintain all three "big" repositories further, with a particular focus on JNLua due to its general-purpose usefulness. (Note that, as to not interfere with the evaluation projects, said work will only begin after August 22nd - during the evaluation period, the repositories will be effectively "frozen".)
From the project plan:
- An API in Terasology for allowing per-world storage. It will be added shortly after the evaluation period is over, as it is an important omission forbidding usage of key Kallisti features, such as persistence, in the game environment of Terasology.
- An automated testing framework for Kallisti - I never arrived at a good vision of how it should work. If I arrive at one in the near future, it will probably be added as well.
- Multiblock monitors. They are not crucial, and work on them has been started during GSoC.
- Adjusting the Terasology sandbox to support KComputers without "lifting" the sandbox. The approach for doing this is done and decided upon, however the change has many ramifications which need to be discussed and tested before releasing - as such, it had no hope of being done during GSoC with many other large changes being simultaneously developed. It will also be worked on in the near future.
- Implementing an I/O peripheral for KComputers to communicate with the Signalling module - the latter has noticeable limitations of use preventing such an I/O peripheral from being adequately implemented. The source code of the attempt is preserved here.
Unfinished Terasology-related projects done during GSoC:
- Migration of the Gestalt engine from v5 to v6. This has actually been started on, but other priorities were more important during the project's realization. This will also be finished after the evaluation period.
- Contribution of Barrels, "GUI-less" inventory container blocks. I have written the source code for them before GSoC (during the bonding period), but unfortunately lost it. Parts of it have been rewritten from memory (MeshRenderComponent) to faciliate the development of the KComputers module. I hope to also bring it to Terasology in the future.
Bugs found during development:
- A few synchronization issues in dedicated multiplayer instances. Cause unknown, noting that Terasology is fairly GPU-intensive (speaking as an user of an Intel integrated graphics card) which does not help debugging two instances of it simultaneously.
Near-future plans unrelated to the GSoC project plan:
- Lua 5.4 is coming; JNLua and Kallisti will both definitely receive support.
- There are a few TODOs in the source code for areas which meet the project plan's requirements but could be improved further, or have some limitations. Those could also be tackled.
What should be done in the (far) future?
Regarding changes in Terasology's engine mentioned above, this will be part of a separate forum post due tomorrow morning (before the evaluation date is up, of course).
Regarding changes in Kallisti, I think an important thing to work on is adding new architectures to Kallisti, in particular a low-level "opcode-emulated" architecture to try and adjust the API to better cover new use cases.
As for KComputers, it could definitely use some addons (I hear a minecart add-on is already being developed, as is an update of FluidComputerIntegration to utilize Kallisti's computer APIs) and polishing!
What challenges were faced and what have I learned?
- Working with an entirely foreign, highly abstract/"academic" Java codebase. While I have spent a long time developing in Java, I haven't had a chance to work extensively on a project which tries its best to utilize good practices of object-oriented design, as well as game engine design. The takeaway from this is being better and more experienced at gathering information from them and working with them, which will definitely aid me in future projects.
- Time management! As I have never held a "job" before this, combined with effectively working "from home", I found it particularly hard to manage time to efficiently devote to the project, which led to a few issues along the way - while almost all goals were met regardless, I could have definitely done this better.
- Communication and teamwork. A few times along the way, it turned out that I was insufficiently clear to my mentors with regards to what I was working on. As such, I had to use tools I haven't previously incorporated widely in my development practice, such as diagrams, in order to try and find ways to more clearly state my design concepts and intentions.
- Changes! As I have decided to work on Terasology as a near-outsider to its source code, I had to change designs and concepts rather often to match engine best practices.
I'd like to thank my mentors for the help and support they've provided, even if the road was somewhat bumpy, and apologize for my shortcomings at my very first "job-like" development project. I hope that, when we meet next time, I will be able to provide even more valuable contributions to the project.
Finally, I'd like to thank all of you who have been following the project's progress for the past three months. I hope you'll find the contributions useful.