0 reviews
  • Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Progress Report

Progress Report (8/16)

Hey, y'all. You may find that, from time to time, I am unable to post every Saturday. I'll try to keep that from happening in the future. No promises, though.

Localization / Keyboard Layouts

So, some raw stuff went in today that pulls the OS's language and country and runs some QWERTZ and AZERTY checks when a gmRPG game starts up. Most countries and languages are covered. Eventually, this will hook into the Localization Manager using the ISO 639-1 standard (for languages) and the ISO 3166-1 standard (for countries). I understand that someone may prefer to play a game in a different language than the one specified by their OS, so I'll build in the ability to override as the Localization Manager takes shape. You'll probably use the Menu Designer (remember that?) to draw up a classic language selection menu.

Scaling the Application Surface

So, recently, all versions of the Game Maker Studio engine exposed a surface variable called application_surface. This is the surface that everything except the GUI gets drawn on. A neat thing about the Application Surface is that it is able to be manipulated - stretched, skewed, shaded, whatever.

Naturally, this is what's going to be used for pixel-perfect scaling of a game. There are still some issues to be worked through on this front - there's a weird sort of diagonal tearing along vertex lines in the surface quad that I can only get rid of by forsaking the GUI layer altogether. But that's on me to fix; the end user shouldn't even have to mess with this stuff.

Anyway, thanks for reading.

Progress Report

Progress Report (8/2)

Hey, y'all.

Contract work's got me pretty busy, but I managed to do some stuff!

Picture Manager

Implemented the Picture Manager. This is a structure that holds "pictures" that behave much like RPG Maker's pictures do, except there is (theoretically) no limit on the number of pictures you can show. The Picture Manager object holds all pictures and picture metadata in a ds_grid structure and iterates through that ds_grid in the Draw event, drawing each picture in the order in which it was added to the grid. As this is done with a loop, I will be testing to see how many pictures it takes to cause drawing slowdown.

Right now, you can only create and destroy pictures, but there will eventually be a way to tint, scale, and change depth of pictures. The way the system's supposed to be set up, you shouldn't even need pictures that much, but I thought I'd put it in anyway. Just because I personally wouldn't use a feature doesn't mean someone else thinks the same way as me.

New Event Commands

ACTOR_CHANGENAME: This will change the first, middle, and last name of any actor in your database table. As a bonus, it updates the actor ID handle, too. This is why you should never reference an entity by a handle string. You should call gscrEntityGetHandle() instead!
ACTOR_CHANGETITLE: This will change the actor's title.
ACTOR_CHANGEGENDER: This will change the actor's gender.
ACTOR_CHANGEDESCRIPTION: This will change the flavor text of the actor.
PICTURE_CREATE: This will create a sprite picture at the specified (x,y) coordinates.
PICTURE_DESTROY: This will destroy a sprite picture given that picture's string handle.

Thanks for reading.

Progress Report

Progress Report (7/26)

Welcome back.

This week's improvements revolved almost entirely around one concept.

Delta Time

Implemented Delta Time. Delta Time is a programming technique that measures the amount of time that has elapsed between any two processing frames. It's used to make sure your game runs consistently on any computer, no matter how fast or slow.

Delta Time is used primarily to keep gameplay consistent throughout lag spikes, but on fast computers, stuff will actually move faster without it, and that's a problem, especially if your game is based around timing!

  • Updated all Event Commands that rely on timing (ENTITY_MOVE, SYSTEM_WAIT) to use delta time.
  • Updated the Movable class to make interpolation rely on delta time.


New Event Commands:

SYSTEM_PAUSE: This will pause and unpause the game when called. More specifically, this will halt all non-serial ActionQueues and the Begin Step, Step, and End Step events of all objects. Not to be confused with SYSTEM_WAIT.

Because a user can still create Actions and feed them into ActionQueues, even if the game is paused, there's potential for build-up of actions that must be handled properly. So, any player input that doesn't either pause or unpause the game should be thrown out for that step if the game is paused.

Note: unpause events should always be generated strictly from user input!

Other Stuff:

  • Removed all references to alarm events, except in very specific cases, as these won't work with SYSTEM_PAUSE.
  • All scripts currently in the gmRPG engine now use Game Maker Studio's built-in intelligent code completion. If you're editing the engine in Game Maker Studio, this will tell you a script's arguments in the status bar when you write out the code to call a script.
  • Fixed bugs in the Animated object class.


Thanks for reading.

Announcement

Back in Action

I'm pleased to tell you that starting Saturday, July 26, gmRPG will be picking up right where it left off. I'll be furnishing weekly updates every Saturday, with the aim to get the engine into alpha state by the end of the year.

As a reminder, here's what gmRPG is:

gmRPG is a toolkit for Game Maker Studio geared toward building role-playing games of all types in Game Maker. It will consist of an integrated development environment (IDE), constructed in C#/Windows Forms, that will augment Game Maker Studio's abilities in order to better focus them toward role-playing game development.

And here's what gmRPG isn't:

  • An "RPG Maker killer": this project hooks in with Game Maker Studio very intricately and relies on the runner for almost all its functionality. In this way, it will make developing Game Maker RPGs easier. There will be no attempt to program a runner for gmRPG that separates it from the Game Maker ecosystem.
  • An attempt to get money: I will never charge money for this software. At the risk of an irregular development cycle (because I *am* taking contract work during this time), I feel that it would be beneficial to provide this free of charge, considering buying Game Maker Studio is still a hefty investment* to some people.


Anyway, I'll be making progress and posting my updates every Saturday from this point forward. Thanks for watching!

- Johnathan

* However, YoYoGames made Game Maker Studio Standard "the free version", and it looks like this version comes with everything the runner has to offer, except texture management. So, I'll be looking at that in the coming weeks to see if gmRPG can support the free version of Game Maker Studio.

Miscellaneous

Capstone Complete

The Senior Design Capstone course for this semester (and gmRPG's work obligation to it) has ended as of today. I am anticipating that the project met its requirements despite not being finished. Trying to do something like this in a semester is a monumental undertaking in and of itself, and I'm happy to have even made something resembling a dent in it during what I'm going to call one of the busiest undergraduate semesters I've ever had.

If you would like more information on the academic side of the gmRPG project, please visit http://sdc.csce.uark.edu/projects/gmRPG for proposals, detailed system architecture, and presentations.

So, what now?

Don't worry, the project's not ending or being put on hiatus or being closed or anything like that. I'll continue to post weekly updates, but now that my term is over, I should get quite a bit more work done.

I'll see you next week.

- Johnathan

Progress Report

Progress Report (12/3)

Sorry, not much to report this week. In addition to being pretty complex and needing to link into a few places in order to work properly, the Gameplay Verbs interface is fighting me pretty much every step of the way. That, and I still have four other courses besides this one to worry about. Progress should come much easier over the winter break. I'll still keep you updated, though.

Changelog:

Fixed a bug in the KeyboardSelector. Looks like the flagged Keys enum is untrustworthy in its current enumerated state and should be cast to an integer. As long as the enum values are unique, there shouldn't be a problem.
Added the ability to see the current key selected upon opening a new KeyboardSelector.
Tied almost all of the Gameplay Verbs tab to the save system
Added UI restrictions to the Gameplay Verbs tab.
-Restriction on choosing a Hold Time if the Input Method is not Hold
-Restriction on choosing Base Verbs if the Verb Type is not Composite
-Restriction on choosing more than one of the same Base Verb for Composite verbs
-Restriction on choosing Input Method, Input Device, and Default Key if the Verb type is not Base
Added Delete, Up, and Down buttons to the EventCommandControl
Added Append, Insert, and Delete functions to ActionQueueScript
Added UI restrictions to the GlobalEventsControl
-Cannot Delete, Move Up, or Move Down if there are no events present in the ActionQueueScript

Progress Report

Progress Report (11/26)

Hey, y'all. (It truly is "y'all", now, isn't it?)

The majority of this week's work was spent on getting the Gameplay Verbs interface up and running. This is an immense task that includes the implementation of a few subcomponents that aren't small by any means.



First to go in was a long overdue means to pop up a virtual keyboard in order to pick a keyboard key. This is necessary because not all user keyboards have a complete keyset - a lot of laptops are missing number pads and have weird OEM configurations, so they need a standardized way to pick a key. In the instance of the Gameplay Verb interface, this is the way the user picks the default keyboard key of a Verb.

The KeyboardSelector only shows a QWERTY layout at this time. The eventual goal here is to eliminate player frustration resulting from misconfigured default controls. To that end, AZERTY, QWERTZ, and Dvorak layouts are going to be present in the final version, possibly with a way to see what an overall keyboard layout looks like across different keyboard layouts. (Remember, kids, WASD is not acceptable on an AZERTY keyboard!)



After that, I laid out the Gameplay Verb interface. As follows from last week, a Verb will be broken down into its three component parts: the Verb, the Action, and the Control Set. All Gameplay Verbs are checked globally, and differentiation based on gameplay state is handled in the Verb script. There are a few configurable settings here.

Type: there are two types of Verbs - Base Verbs and Composite Verbs.

  • Base Verbs are normal verbs ("Move Up", etc.) that take one key or button as input.
  • Composite Verbs are verbs that "build on" Base Verbs and will provide an easy way to define combo keys. Each Composite Verb can accept up to three Base Verbs as input.


When Gameplay Verbs are processed, Composite Verbs are processed before Base Verbs.

Method: this allows the user to specify a Press, Double-Press, Release, or Hold to trigger a verb.

Verb Script: this is the Event Framework script that the verb links to. These are run in Auto-Serial mode, so slowdown will ensue if the script gets too long. Keep in mind that generally, Gameplay Verb scripts do not need to be very long to do their job.

Note: there is no way at this time to define more than one button or key for a Verb. Definition of multiple keys that do the same thing will require duplication in the Verb interface. For instance, define three entries for Up that link to Up Arrow, W, and NumPad8 and make them share the same verb script.



Finally, I started work on the Event Framework. This is the IDE side of the ActionQueue, and it should look pretty familiar to people well-versed in RPG Maker. There are a few differences, though:

  • Event Commands aren't stored in tabbed pages: they're stored in a grouped ListView right beside the event script. This should make the user's life a little easier. Double-clicking on a list item will either add that command to the script, or it'll pop up a form asking for the necessary information.
  • Events in the script are stored as a tree instead of a list. This allows me to make the Event descriptions collapsible.


My goal here is to make the event commands as readable as possible. The user should be able to collapse and expand the entries at their whim and reorder them however they please. The user should not only be able to add and delete, but insert as well. Finally, it should be made very clear what sort of context the script is operating in (Global Events are much different from events on the map in that access to map entities cannot be assumed when operating from a global context).

Anyway, that's all for this week. I'm going to continue to work on this and hope that I'm able to push all the verb stuff through by the next update.

Until next week, take care.

Changelog:

Show
Implemented KeyboardSelector: this is a control that presents a virtual keyboard for the user to select a keyboard key from. This is necessary because not all user keyboards have a complete keyset (a lot of laptops are missing number pads, for instance).
The KeyboardSelector supports only a QWERTY layout at this time. The goal is to have a selector with AZERTY, QWERTZ, and Dvorak layouts so that the user may define different keys for different keyboard layouts (so WASD would be ZQSD in AZERTY).
Implemented a ResourceBox control so that things that don't necessarily require a ComboBox can have selection capability (think of this like the "Ellipsis" selector control in the RM suite).
Added a KeyDictionary in order to easily go to and from the System.Windows.Forms.Keys enumeration to an easily readable key name stored in a string.
Added a superficial implementation of the Gameplay Verb interface:
About half of this works right now. The interface allows the user to define the name of the gameplay verb, a description, its localization setting, and a default keyboard key that invokes the verb.
Implemented the EventCommandControl. The EventCommandControl is the core of the Event Framework. It's like the "eventing" interface from RPG Maker, but with a few changes:
- Event Commands aren't stored in tabbed pages like in RM: they're stored in a list next to the event script. This should make event work easier for the user.
- Each event in the script consists of an Action, the human-readable command representing the Action, and an optional description of the Action.
- Events in the script are stored as a tree instead of a list. This allows me to make the Event descriptions *collapsible subitems* of the Event commands.
Partially implemented the GlobalEventsControl. This is a Database submenu analogous to "Common Events" in RPG Maker.

Announcement

Get Game Maker Studio Standard for Free

Update:

This offer has expired as of 12/6/2013.

Update:

Check out this offer (which is actually real-valued at 75% off, for reasons explained in the original offer).

For a limited time we are offering you the unique chance to upgrade your copy of GameMaker: Studio Standard to GameMaker: Studio Professional for $25. That’s 50 percent off!

This limited time offer is available until Friday December 6, 2013 so hurry over to www.yoyogames.com and enter your GameMaker: Studio Standard Licence Key to purchase the world’s best 2D game creation software at a fraction of the cost!


UPGRADE TO GAME MAKER STUDIO STANDARD FOR FREE


That's right: you can now upgrade from the free version to the Standard Version (a $50 value) and pay nothing to do it. Download Game Maker Studio Free here.

Top Tips
  • In order to see the offer, you must be on the latest version of GMS:Free (version 1.2.1214). Once you're on 1.2.1214, the offer will become available in the project launcher.
  • To that end, make sure you license with a current e-mail address that you use frequently so if you start collecting modules or upgrades it's less of a hassle! Game Maker Studio's licensing structure ties all your modules and upgrades to one e-mail address, and if you use a spam-catcher, you're just going to make it painful on yourself.
  • Because of how the Game Maker Studio licensing structure works, this upgrade will get you $50 credit toward a purchase of Game Maker Studio Professional. I highly recommend this because it comes with all sorts of features that Standard doesn't have, including the ability to add export modules for different platforms.
  • This offer does not include a Steam key for Game Maker Studio. However, a purchase of Professional does include one.
  • I don't know if this offer is time-limited, so grab it while you can!


NOTE: If you can't see 1.2.1214 as an update, you should switch your Update Channel to Beta. You can do this by right-clicking on the GM icon in the task bar when GM launches:



Do this! It literally costs you nothing to do it and you get a pretty severe discount on the next level up if you do have the cash to drop. This program is a powerhouse that will allow you to do basically anything at all if you have the time and willpower, but only if you have a paid version.

Progress Report

Input Processing Theory (11/18)

Hey, y'all.

This update is a doozy, so I'm gonna hide the commits at the bottom for reference and broad-stroke it for you. I realize it's a day earlier than I usually update, but I have to present a progress report for this project tomorrow and I'd like to have all my ducks in a row.

So, quite a lot went into the engine over the last week. Let's take a look.

The ActionQueue

There is a new processing context for ActionQueue actions, and it's one that fixes one of the fundamental problems with the AC ActionQueue system: the inability to process input through the queue.

A history lesson: AC's ActionQueue objects worked in either a LOCAL or a GLOBAL context, and with those contexts came queue behavior. Or: a LOCAL queue needed to be triggered and a GLOBAL queue ran automatically whenever Actions were dropped in. The problem with this system, besides the whole system being constructed essentially backwards, was that it was horrifically prohibitive with regard to LOCAL queue processing. LOCAL queues needed the GLOBAL queue's "permission" to run their own queue, which was a waste of actions and processing time.

So, when it came time to do things like issue attack, item, or skill commands through the LOCAL queue, not only was an extra command needed, but these commands needed to be placed at the front of the queue. And sometimes they could back up if a command was forced too many times, leading to terrible queue interaction bugs that had me pulling on my hair in more than one instance. If issuing one-shot input commands through the ActionQueue was this painful, funneling low-level immediate input like player movement through it was out of the question.

The system eventually became a pile of hacks that used some sort of arcane sorcery to stay operational; if even one part of the underlying queue behavior was changed, the whole system would come crashing down.

Naturally, I wanted to approach this system again and build it in a way that makes sense. Here are the rules:

  • A "Manual" (or LOCAL) queue cannot run without being told to by a QUEUE_RUN command. Fortunately, it can run without asking a global queue for permission because a QUEUE_RUN command placed at the top of a Manual queue auto-runs the queue until it is empty or a QUEUE_BREAK statement is issued due to the new self-starting command whitelist.
  • An "Auto-Sequential" or (GLOBAL) queue runs automatically. It processes one action per game step until the queue is emptied.
  • Finally, an "Auto-Serial" queue runs automatically, but it processes all actions placed into the queue during that step, something I'll cover in more detail in the next section.


Input Processing

So, the system overhaul described above was done in preparation to handle everything, including player input processing, through the ActionQueue. Why bother? If it's simpler to do: 

if(keyboard_check(vk_up))

{

    y -= moveSpeed;

}

...


...then why not do that?

It's uncontrollable: something like this cannot be referenced in the gmRPG IDE. It's important to note that there are three different facets to this very simple code: there's the gameplay verb ("I want to MOVE UP"), there's the action ("When I decide to MOVE UP, I decrease my y-value by my movement speed value"), and the control set ("In order to MOVE UP, I need to press the UP ARROW on the KEYBOARD."). Of course, I can't harness any of this information if I write the player movement functions like that, so I generalize that code to: 

if(gscrVerbActive("MOVE_UP"))

{

    y -= moveSpeed;

}

...


This is better, but, still...

It makes dangerous assumptions: As the developer of this software, I have no right to assume that when the user wants their character to move up, that they want to press the Up Arrow, or W, or NumPad8, or Space or whatever. This is fine, and that's why configurable controls exist, but there's a problem.

As the developer of this software, I cannot make the assumption that when the user wants their character to move up, they actually want their character to move up. What is "up"? Is up "negative 2 pixels"? Is it "positive 2 pixels"? Do they actually want their character to move down, and they're just saying they want to move their character up because they're confused about the nature of their floor and ceiling? So a "command" structure is necessary, and that's where the ActionQueue comes in.

Finally, with this specific project, I've already made clear that I cannot make the assumption that the user knows how to write even simple code like this. So, the user will be able to define gameplay verbs and tie ActionQueue actions to them event-style, and when the IDE auto-generates that GML code, it'll probably look something like this: 

if(gscrVerbActive("MOVE_UP"))

{

    //Auto-generated by the gmRPG IDE



    gscrActionAddToQueue(gscrActionCreate(entity, ENTITY_MOVE, x, y - moveSpeed, moveSpeed), inputQueue);

}

...


This code is now completely generalized: it'll roll through the inputQueue (a SERIAL queue) and it'll be handled immediately. It won't interfere with the ActionQueue, and it'll do what it says it's going to do. A minor drawback to this system is that loading too many Actions into a gameplay verb may have some slowdown effects, but with responsible use and proper safeguards, it'll be fine.

As an aside: I ran tests for both pixel-based movement and grid snapping using this system and they both worked flawlessly at a solid 60FPS. This is here to stay.

Let's move on.

Modifier Stats

This one's easier to explain. There's now a type of stat called a Modifier Stat. This is something you can tack on to a base stat in order to affect it somehow - think buffs/debuffs, equipment, stuff like that.

With the Modifier Stat comes the ability to get a composite of the base stat and any Modifiers that affect it, like so: 

var total_atk = gscrActorGetStatComposite("Attack Power", "Equipment Power", "Attack Status");


GameManager

Most of the GameManager logic has been implemented. I'm starting to focus on serialization of important stuff like whether a puzzle has been completed, whether a cutscene has been seen, that kind of thing. I rolled all these persistent variables into one structure so that they can be easily serialized and saved to a save file.

That's pretty much it. I know this was long, but I hope it was at least marginally interesting. I'm going to start working on the ControlSet and Gameplay Verbs before the next update. Sorry there's not much to play with (or that there's not a demo by now); I really need to assemble the infrastructure before I get to cool things like tile editors and cutscene stagers.

Take care.

Changelog:

Show
Engine

ActionQueue

Fixed bug in ENTITY_MOVE: it was missing assignment of the behavior script.
Fixed some ActionQueue behavior:
an Action must now have an owner attached when it is created. This uses up an available argument. Up to 14 arguments are now allowed.
Action command scripts will now directly reference the Action owner whenever possible.
Added "null" value to engine (-999999999999), since GM has no null value.
Added ActionQueue commands SYSTEM_CALLSCRIPT and SYSTEM_WAIT. These call a user-defined script and halt the caller's queue for x milliseconds, respectively.
Fixed bugs in all stages of queue and action execution.
Performed pretty intensive testing of the ActionQueue. It took a while to get everything in order, but the two implemented actions work like a charm now. The test consists of a sequence of actions that spell out "Hello World" with SYSTEM_WAIT statements in between each letter.
Added ActionQueue commands QUEUE_BREAK and QUEUE_RUN. These commands manipulate pulling of queue actions from an ActionQueue.
Added the ability for certain queue actions to pull themselves from the queue if at the front, regardless of the queue's autorun setting. This allows queues that don't auto-run to run when issued a QUEUE_RUN command without needing the assistance of an autorunning queue to start themselves.
Added script gscrActionQueueGetFront - this returns the minimum index of the ActionQueue (in an ActionQueue, the minimum is the front).
Fixed a bug in gscrActionQueueRun where repeated QUEUE_RUN commands would speed up queue execution if SYSTEM_WAIT commands were present.
Fixed an error in gscrActionQueueGetFront: queue cannot pull an action when empty.
Added skippable property to gobjAction. If the action is skippable, it will be terminated before execution when a cutscene is being skipped.
Spent part of the day experimenting with rolling immediate player input into the ActionQueue structure. There's a problem with using the main sequential ActionQueue for this - I'll explain below.
Prepared the ActionQueue for immediate player input with the delineation of processing methods. Now, instead of autorun or manual, there's manual, auto-sequential, and auto-serial. Auto-serial is a new type of queue processing that will be used to process player input through the ActionQueue.
Tested all three processing methods with a test RPGEntity object that adds one character per action to a string that eventually spells "Hello World".
Ran input tests with both free pixel movement and grid snapping. Works great.
Fixed jitter issues with movement. As a general rule: all input in a step for an entity should be handled before the execution of that entity's InputQueue. (So, old problem, new clothes.)
Fixed issues with interpolation where ENTITY_MOVE would occasionally push p-values over 1.

Stats

Added support for Modifier Stats. These are stats that modify other stats (for instance, an equipment-HP stat that modifies a base-HP stat)
Added an ID field to the Stat data structure. This stores the stat's constant so that the stat can be easily referenced and compared with other stats and properties.
Modified all scripts that reference the Stat data structure accordingly.
Added scripts to access the ID and "modifies" field of a stat
Added gscrActorStatGetComposite - this returns the composite of a base stat and the provided modifier stats.
Tested gscrActorGetStatComposite. The user can currently make it return a composite where a modifier stat is invoked more than once, but other than that, it works fine.
Added invoke-once protection to gscrActorGetStatComposite

GameManager

Implemented most of the GameManager logic.
Added non-persistent GameManager settings
Made RPGDatabase part of the GameManager flow (finally)
AC's cutscene flags, puzzle booleans, cursor memory variables, and every other persistent variable have been rolled into one central persistent variable map for easy serialization. This map allows the user to set a name and category to reduce the possibility of collisions.
Added the ability for RPGEntities to register themselves with a central map that allows for easy entity ID lookup (a big improvement over AC's scrFindActor, which would loop through every entity in order to find the right one)
Added UserDefined_Menus stub.

General

Fixed gscrEntityGetID to use the new entity lookup map.
Fixed a bug where RPGActor was a child of RPGEntity for the sake of one inheritance property (creation of inventories)
Modified gscrDirectionToCardinal in order to accept eight directions (and to be a bit cleaner)
Added Animated master object. This is the parent of all RPGEntities (and anything else that can be animated) and the child of the Movable master object. As a result, RPGEntity gets all animation system and linear interpolation properties.
Added stub for gscrAnimationStart - this cannot be implemented until there's a means for storing animation sheets and properties.

IDE

Added null value to generateUserConstants.
Added user control for Modifier Stats.
Added GML generation for Modifier Stats.
Edited GML Generator for stats to add ID constant to each stat.
Renamed "actor_id" to "handle" in actor GML generation.
Changed database structure creation to also accommodate database settings.
Added constants for eight directions instead of four
Added QUEUE_ constants

Progress Report

Progress Report (11/12)

Hey, y'all. Sorry for the wordage in advance; tonight's update is pretty technical.

IDE Changes

  • Added "Animation Keys" control to TermsControl. This will allow the user to define custom animation key constants for use in the upcoming Animation system.
  • Added shortcut key (F10) to Resource Manager
  • Fixed a bug in ItemsControl and SkillsControl that occurs when the program attempts to pull an ItemType or SkillType to use in the type drop-down list when there are no defined ItemTypes or SkillTypes.
  • Added basic Global Game Settings window. This will allow the player to manipulate game name, version, graphics options, and other such settings. (UI elements have been placed, but they don't work yet.)
  • Added File IO class GMFileIO. This class centralizes all file input/output operations and adds limited retry functionality so as to avoid file locking IOExceptions.
  • Removed generateSpriteGMXFromDatabase function (redundant).
  • Added BackgroundWorker for the loading/saving progress bar; it actually works now!
  • Split GMLGenerator.generateAll into discrete functions in order to quantify each function's progress in the progress bar.
  • Generalized function createSpriteEntry into createResourceEntry. This will add a resource to any basic top-level resource bucket in the GMS resource tree.
  • Refactored generateSpriteGMX
  • Added generateBackgroundGMX
  • Added generateTilesetGMX. This is exactly the same as generateBackgroundGMX except it takes arguments for tile dimension, offset, and separation and passes them to the .gmx file.
  • Added direction constants to GMLGenerator.generateUserConstants


Engine Changes

  • Added ActionQueue structures and scripts
  • Added test ActionQueue action ENTITY_MOVE
  • Added gscrDirectionToCardinal - gets the cardinal direction of a degree value.
  • Added motion planning functions to create mp_grid and find path (stub).
  • Fixed bug in ENTITY_MOVE: it was missing assignment of the behavior script.


Global Game Settings: nothing to see here. It's a husk of unimplemented UI controls at this point.

Resources: so the Resource Manager window is probably going to get a little more complex. In figuring out how to process user-defined folders, I ran into a problem: when the stuff in the folder is processed, where does it get put in the GMS project? I eventually came to the conclusion that the Resource Manager needs a property window so that the user can specify what type of resource (sprites, backgrounds, tilesets, sound files, etc.) a user-defined directory contains. This property window will also contain resource settings (like origin for sprites, etc.) when a resource file is selected as opposed to a directory.

Admittedly, this is not high on the priority list right now, because it's less important compared to the ActionQueue, which I started implementing tonight.

ActionQueue: this incarnation of the ActionQueue will be undergoing some serious consolidation and augmentation compared to its AC implementation. This is to prepare it for handling every action in the entire gmRPG system. Changes from AC (some are new, some were covered in this blog's initial post):

  • Create Action and Enqueue Action (adding the action to the queue) are separated now. This has the consequence of breaking the atomicity of the Action in relation to the queue. This means that new safeguards will need to be in place because an Action can be created that is never used or that is added to more than one queue. On the other hand...
  • As a result of the split, there's a little more breathing room for arguments: an Action can have up to 15 arguments instead of up to 10.
  • In addition, proxy entities (entities that run an action for another entity) can be added using the same script that normal entities use.
  • Also, this makes writing scripts easier: a script file merely needs to create the Actions, put them in an array, and loop through that array at the end in order to add the Actions to the queue. This means that there can be a central mechanism for processing scripts. This also means that a script full of Actions can exist in the system as a collection of Actions separate from an ActionQueue, which has all sorts of disturbing implications that I'm too tired to think about right now.
  • Every RPGEntity has an ActionQueue that can be referenced directly instead of the entire system only having a GLOBAL and LOCAL queue.
  • ActionQueues are now GM objects that possess their own properties, such as priority index tracking and iteration, auto-run, and start/stop state. By default, an ActionQueue will auto-increment when an Action is added to it.
  • When Actions are created, they reference a "schema script" that identifies the Action and supplies the arguments. This is partly to provide a concrete way to reference an Action type, partly to enforce strict rules for Action commands, and partly to make for easier debugging on the user's part.
  • When Actions are executed, they reference a behavior script that is provided as part of the schema. This is much faster than the old conditional-lookup system of AC, where the queue would look among dozens of commands to find the command that matches the executing action. It also has the side effect of being cleaner.


So, as far as the ActionQueue goes, I'm making good progress. I hope to be done implementing it by next update, but it's probably going to take a while.
Pages: first 12 next last