Beta GMSugar: Easy Constructor Scripts for GMS 1.x and 2.x


GMSugar v0.0.2
The ultimate constructor utility collection, now in beta!

GMSugar is an experimental library that provides an alternative syntactic sugar to replace GML's repetitive pattern of initializing arrays, data structures and other dynamically allocated types. With constructors instead of line-by-line setting calls, you can quickly build your data in a visually intuitive new way.

GitHub: Link (for developers) | Workbench (for contributors)

Current Features
  • 1D arrays and 2D arrays (row- and column-major variations)
  • Buffers
  • Clickables (HTML5)
  • Data structures (All ds_* types)
  • Datetimes
  • Networking client and server sockets
  • Paths (polygonal and curved)
  • Surfaces

What can I do with GMSugar?
With GMSugar, you can save keystrokes spent initializing your data and present your data in an easy-to-read, self-documenting way. Compare these examples of code with and without GMSugar.

2D Arrays:
With GMSugar:
//Row-major interpretation
array = Array2(2, 3,
  "foo", "bar", "baz",
  583, 907, 371
// Column-major interpretation
array = Lattice(2, 3,
  "foo", 583,
  "bar", 907,
  "baz", 371
Without GMSugar:
array[0, 0] = "foo";
array[0, 1] = "bar";
array[0, 2] = "baz";
array[1, 0] = 583;
array[1, 1] = 907;
array[1, 2] = 371;

With GMSugar:
map = Map(
  "Alice", 583,
  "Bob", 907,
  "Caitlyn", 371
Without GMSugar:
map = ds_map_create();
ds_map_add(map, "Alice", 583);
ds_map_add(map, "Bob", 907);
ds_map_add(map, "Caitlyn", 371);

With GMSugar:
msg = Buffer(
  buffer_u8, 2,
  buffer_f32, x,
  buffer_f32, y,
  buffer_string, player_name
Without GMSugar:
msg = buffer_create(buffer_grow, 1024, 1);
buffer_write(msg, buffer_u8, 2);
buffer_write(msg, buffer_f32, x);
buffer_write(msg, buffer_f32, y);
buffer_write(msg, buffer_string, player_name);

Help grow GMSugar!
GMSugar is a work-in-progress and would greatly benefit from developer input. If you have any suggestions for new constructors/use cases or bug reports, please open an issue or contribute on GitHub.


aka fel666
How have I not seen this before! Very cool stuff!
I can imagine this being very useful to define other things like vertex formats too.


Member this a wrapper of custom functions around the less-robust functions that GMS provides for the same features (arrays, maps, etc)?

Because something I keep wanting them to implement are code functions to create, edit, and destroy custom texture pages for load-time sprites and tilesets. Yes, the underlying functionality technically exists, but it involves completely rebuilding the entire drawing routine to implement (don't get me started on how GMS currently handles run-time sprite creation). I want to be able to define an empty sprite, set how many sub-images it has, the texture page it uses, and the uv coordinates on that texture page where the sub-images are located, building a sprite from the ground up, in code, at run time. Similar idea for tilesets. It's not as if this data doesn't exist. It does -- this is, in fact, the exact data the engine uses to draw sprites and tiles -- it's just black-boxed from the user.