Grill is a programming platform. The primary goal of Grill is to facilitate rapid game design (or, application design... games are harder =) ). The absolute requirement of a game is its playability, which demands high performance. Without high performance, the game play is irrelevant. However, achieving good game play requires flexibility and ease of use. Achieving this requires a multiple front attack. On one front, we need abstractions that make development easier; such abstractions include closures, inline array constructions, native matrices, associative arrays. Designers need these features. However, solving these features in a language that permits high performance usually introduce... ugly and unmanageable code. However, ugly and unmanageable code is usually the fastest (up to some constant in terms of the algorithmic complexity). In terms of algorithmic complexity, doubling the speed of a basic operation in a quadratic time algorithm quadruples the speed of the algorithm. On the other front, we need to utilized the raw power of modern machinery. Grill is my solution.
Grill is designed to facilitate multiple aspects of game development: construction of the GUI, event handling, agent decisions, game logic, scene construction, and scene rendering. As functionality moves from the game engine to the virtual machine, the virtual machine requires high performance. Grill is designed to handle this task. Unlike many scripting engines, Grill is statically typed. Every feature of Grill is designed with the ability to translate into C++ and have native compilation. Furthermore, specific features can be optimized and compiled into C++ where other features are left in the scripting engine; this lets games be mod-able.
A Grill based application is really a set of services controlled by a virtual machine. The virtual machine imports functions from C++ and interprets an abstract syntax tree language (GrillAst); the function interface is shared between both types of functions. This let service developers write optimized services for rendering, audio, scene management, physics, and artificially intelligence (i.e. Bayesian networks). By separating services from logic, we can enable the productivity associated with scripting languages with C/C++.
Yes! An extremely useful construct of scripting languages and functional languages is the ability to treat functions like objects. C++ has function pointers, but that is not enough. The next step is having a closure, a function pointer connected to an environment (hidden parameters). This feature lets GUIs in JavaScript/Action Script be designed very easy. Diving further into productive features is the concept of ducking. JavaScript support for ducking is implicit to the object structure; namely, every object is an associative array. The problems with associative arrays and dynamic typing are the inability to know how interface changes over a project are propagated. Grill utilizes the idea of structure contracts; namely, a structure contract is a collection of related typed variables. All structure contracts are related by a type-member subset relationship; that is, if a structure contract, X, has all the same members of the same type of another structure contract, Y, then Y can be used as X.
Done: Fire 1.5 : 100% (Automatic DOM Generation (C++, C#, and GrillScript typing environment) ) Working/under revision: GrillScript : 100% (C# Compiler from GrillScript (*.gs) to GrillLisp (*.gl) GrillServ : 100% (C# Compiler from GrillServ (*.gsd) to C++ (*.cpp) ) GrillLisp : 100% (C++ AST Optimizer from (*.gl) to GrillAst GrillAst : 95% (C++ Interpretter) GrillWT : 80% (C# Well-Typing checker) Coming: GrillC++ : 10% (C++ Rewriting of GrillAst to C++, for native compilation) Planned: GrillML : 0% (Ocaml GrillScript Compiler [type inference]) GrillByte : 0% (C++ Byte Code Compiler and Interpretter) GrillJIT : 0% (C++ Just in Time Compiler) GrillShader : 0% (C++ AST compilation to GLSL/HLSL/Cg [or C#, haven't decided yet])