The Project Gamma Development Progress Blog

Parser and code generator in fcsc

Mar 21, 2013 by DX-MON |
Further to my earlier post, the compiler now supports assignment parsing leaving just the C-style comma statement left to do (easy enough but requires a working system for scope tracking and variable tracking to make sense to implement).

I'd estimate the compiler to be 90% complete now seeing as it also generates code for the ternary operator and in implementing assignment support I also tied up a pile of loose-ends in the way the parser handled statements, rendering a small portion of parser code redundant pending removal.

Unfortunately, all things to do with compilers and the subject of parsing have a habit of being very technical, so as a summary for the not-so-technically-inclined: the compiler now understands the language I defined for it with the exception of one bit of grammar, and is able to partially generate a computer program from descriptions in that language.

Signing off,

fcsc Code Generation

Mar 20, 2013 by DX-MON |
Well, work has continued on the compiler which is now around 85% complete.

Progress this time has been made in the area of code generation and storage. The compiler successfully generated code for the first test script last night, almost perfectly matching my hand-coding of it. This makes the compiler suitable to replace the hard-codings used so far and brings the project closer to release seeing as this allows the game's screen layouts to be scripted and greatly reduces the design-to-product time for each screen element.

I plan on getting back onto AutoUpdater's case as soon as I have the missing program elements to complete the client side.

Till next time,

Future Consciousness Script

Mar 02, 2013 by DX-MON |
Well in continuation to my post last night, fcsc now parses complex logic and statements, however has yet to get an assignment parser.

This means that the compiler is now around 80% complete pending code generation sequencing which I have been doing manually.
I post about this as it's the first time I've succeeded in building a non-toy compiler as my C compiler efforts became held up when I tried implementing typedef and structs (IE, custom data types) - not helped by the compiler being written in pure C and being my first.

There will be more to blog about soon as there are several tools that are about to have new releases made and it heralds the upgrade to the new-ish VFS architecture which has been held off by AutoUpdater not being ready. This also means we have a way to program game screens without them being hard-coded - something that has been bugging me since the start of the project.


AutoUpdater and engine scripting languages

Mar 02, 2013 by DX-MON |
It has been way too long since my last post, and a lot has happened - more than I'd want to put in a single post.

I'm in my final year of Uni, however this has not stopped me from using an hour here and there to take a break from my Uni project and modules to put time into the project.

This post is to cover two major areas:
  • AutoUpdater
  • Game engine scripting

Much work has been put into AutoUpdater to complete the service and improve on it's security.
Safe to say, the version that is shortly to be released is both a complete rewrite of the client and the server.
Client side, rSON was created to parse the server output having identified JSON as a good format to pass update meta-data in, and updating, even of the updater's own executable, is now possible.
Server side, a switch has been made in response format from a custom text protocol wrapped by HTTP to JSON so that integrity of the transmission is better verifiable and assured.

Game engine scripting
For a long time I had been looking for ways to integrate pre-existing interpreters or languages into the engine - the first abortive attempt being made with Python, which although a lovely language for what it's designed to do, was a horrid choice of interpreters to try to integrate with.
Finally, about a year ago, I gave up that search and decided to write my own restricted context Byte-Code Engine. Designed with an extremely simplistic RISC instruction set, and 64-bit registers/stack, this finally allowed the sort of scripting on events I was trying to achieve with the other interpreters and languages I'd trialled and failed with.
But that wasn't good enough - you had to know the instruction set in binary and know how to craft instructions the way people did in the 50's and 60's (yuck!) and an assembler would have been no better really. I wanted a proper language I could write event handlers in that the rest of the team can also use to the same effect. So was born Future Consciousness Script (FCS for short) and it's compiler, fcsc. This C-like language has a mostly working compiler that outputs Byte-Code binaries for the game engine and integrates with the layouts system as a source of events. Much better.
The platform supports read-only use of the game engine VFS, sockets to create network protocols with, a wide array of crypto for password and other hashing and cyphering, and more.
Release of this new language to the team for acceptance testing and tweaking will be done when AutoUpdater is released as the compiler should be finished by then.

Disclaimer: For all those out there now shouting their heads off at me that rolling my own engine language was stupid "because it'll be buggy" - compilers and crypto are my special interests, and the engine itself is designed such that if you hack the game engine with it, you modified the engine yourself outside of an FCS event handler therefore not my bug.

Hopefully this post is not too techy (although imho tech-talk is quite unavoidable when talking about scripting the engine),