GameMonkey Script

Hi,

It would be interesting to post a message in this topic if (and only if) you're writing/have written something for GM ( like DrEvil-Ob's GM debugger, Downgraded's gmSDL, ... ), so new users can have an idea of what is available to them.


PLEASE DON'T POST ANYTHING ELSE (questions, comments, ...).
Do it in another topic or send the author a private message.

Thanks.

GD Edit: Stickying for a while

Hey - good idea. Here's the GM-related stuff I'm working on:-

gmBind - 0.9
Description: Class binding tool for GameMonkey Script
Status: Unsupported
Notes:
Already out in the wild and used in a few places. Was an early experiment with GM and binding, has a few large flaws and I'm generally not happy with it. Useful for simple binds only.

gmSDL - 0.2a
Description: SDL binding for GameMonkey Script
Status: In-development
Notes:
A few things have changed since I last worked on this and I lost a bunch of WIP code in a HD crash, so progress has been put back somewhat. Simple PacMan game is partly complete. gmSDL will be used as a basis for some tutorials on GM when I get time to do them (and finish gmSDL!).

gmSerialize (unreleased)
Description: Serialization experiment for GameMonkey Script
Status: Sleeping
Notes:
An experiment on serialization of a gmMachine. Currently only types can be serialized (in/out to Xml, binary, text or whatever plugin)

gmPlugin (unreleased)
Description: Experimental plugin system for GameMonkey Script
Status: Sleeping
Notes:
The idea behind this was that you can add functionality (types/functions/etc) to GM at runtime by loading from dll/so. Currently on-hold waiting for a better way to 'describe' GM types.

gmBind - 2
Description: Class binding tool for GameMonkey Script
Status: Sleeping
Notes:
A better, OO version of gmBind. Currently on hold due to it being mainly a group of 'bitty' experiments that haven't been melded together yet.

Introduction to GameMonkey Script - Part 3
Description: Threading/Advanced Tutorial for GameMonkey Script
Status: In-development
Notes:
Writing a large(ish) article to expand upon my further two pieces of work for GameDev.net

GameMonkey Documentation
Description: More documentation for GM
Status: Ideas stage
Notes:
Write a min-guide to using GM from both the language and binding POV.

gmgx (unreleased)
Description: Simple Game API Framework based on GameMonkey Script
Status: On hold
Notes:
Used to experiment/prototype simple game ideas. API is simple to understand, everything is powered by GM Script and high-level functions are provided to GM by the engine.

Data-Driven Entity System
Description: See name for info
Status: In-development
Notes:
Data-driven entity system and article behind implementation. System uses script-agnostic system but is built on GM by default.

GameDB
Description: Entity-based Database System
Status: In-development
Notes:
Create & query entity sets by attribute values/tags. Scripting language agnostic design but comes with GM interface by default.

GM Debugger
Description: Remote debugger for GM Script
Status: In-development
Notes:
Uses some extensions to the gm debug code which I can probably talk Greg into merging in with the main code base.

Some Screenshots
Empty Window, before connecting
Globals Tab, user type list.
Globals Tab, nested tables, vec2 and vec3 info.
Autos Tab, instruction ptr, value of 'this'.
Break point, value of 'this'.

I've added callbacks in GM, similar to the AsString callback that allows custom types to provide debug information for use in the remote debugger. You can see an example of this in connected2.jpg, where the actual numeric coordinates are shown for the custom position3 and position2 variables, which are vector3 and vector2 custom types. Additionally, in connected3.jpg, a more complex type is bound, which is my 'bot' type, and here it shows his name, functions, and event table.

Finally, as shown in connected1.jpg, the debugger also recieves all the functions for custom types. Currently they are marked by being surrounded by <>, but these aren't global variables, the <> markings are the current method of showing them to be types. By expanding the + next to the type name one can view all the bound functions for that type. I may mark them seperately in the global table or color them or something to keep their seperation from global variables more obvious.

The breakpoints and step buttons are all working currently.

Things Left to do:
The very bottom left window is going to be an input window, where any valid script can be entered and it will be run in the connected GM. Also I still need to finish the watch windows.

Any other requests let me know.

gmMachineEx
Description: Extended gmMachine providing direct classes/functions binding, new thread functions and a simplified way of calling scripts functions.
Status: Finished.
Notes: "Gold".
Download link: http://www.mediafire.com/?am4z1secwpz

ptr
Description: A smart ptr desgined to be use with gmMachineEx to avoid dangling pointers.
Status: Aborted.
Notes:
This smart pointer will act as a classic pointer.

gmConfigData
Description: GM as game/app configuration data file. The goal is to provide a human readable, editable, commentable config file. This file will be converted into C++ a data structure with a simple access interface.
Status: v0.2. ~50% or less complete, Sleeping.
Notes: Need to implement more types. Here is the current code.

Edit: (25 Mar 08) Fixed bug, updated file.

gmCodeOptimizer
Description: A GameMonkey modification and class to optimize scripts at runtime.
Status: Early In-development(and going slow)
Notes:
A modified gmMachine to support more opcodes that allow scripts to execute faster, and a class to analyze and optimize compiled scripts at runtime. This project is currently in slow development as I am also writing my own virtual machine to learn more efficient ways to execute and optimize code, and a game engine that I can use as the development platform for gmCodeOptimizer.

gmConsole
Description: A simple console/shell that can be used as the basis for an Allegro project
Status: In-development(but near completion of v.1.0)
Notes:
A simple Allegro template that uses ConAlleg as a way to input GM scripts as a way of debugging programs that are based off of gmConsole. This can be easily modified to be used as the basis for an allegro program, and will also serve as the development testbed for gmCodeOptimizer.

gmAllocator
Description: A custom allocator for game monkey.
Status: About to start
Notes:
An allocator which will replace all new & delete calls in GM. This will allow me to just give GM its own little bit of memory to work inside of, that way I have even tighter control of allocations, and reduce fragmentation.

downgraded - I'd be quite interested in using gmSerialize, sounds like a life saver for saving & loading of games

Serializing a scripting system is pretty complex. Moreso probably for GM, given that you would likely want to serialize your gmThreads that are running perhaps, as they likely contain important state information about the entity they are running on, depending how you use them. You'd also need to have a gmSerialize callback for each user type, similar to the AsString callback, inside which you might need to be able to serialize an entire object, or if you are serializing your game objects on the native side you may need to recursively serialize the global table and save out a handle to any user objects that can be resolved and 'reconnected' after a subsequent load. Depending on how you use the scripting, it could be extremely difficult and frankly not worth the effort imo.

Still trying to work out what would be a nice way to implement save games, assuming that the script is running at the time. I guess I'll look at that before I start work on my next game. Mind, just storing all inputs to the game could potentially work and just feed them back in from the start...but would prove to have nice long load times *sigh*

Many games these days just save up until the last checkpoint, and so can avoid the issue of trying to save out a bunch of script state. You simply load the save game at that checkpoint and the locations of enemies/pickups are commonly not even saved. In an open world game for example, the save game essentially saves what missions you've done, how much money you have, your inventory. Not always does it save everything so you can just drop back in mid-mission later. That's the simplest way to avoid the problem altogether.