[tcaudilllg]

The GCS module project is on indefinite hold... I've kinda lost interest.

What I'm working on right now (have been working on in terms of my more recent developments) is a Javascript-based engine that is nearing completion. This engine runs on a dialect of BASIC and fulfills the "virtual machine" requirement of the GCS project. Although I could just , I haven't needed to so far because it's Javascript/DHTML which is kinda modular in itself.

The design is an entity-based system similar to DIV. It's like the SceneLion scene graph software I made earlier, but has interactivity and multiple maps. My aim is for it to be capable of doing action RPGs, tactical RPGs, and anything in between.

I intend to run an online tactical RPG with it. I'm thinking of making the game an open world where people can create whatever characters they want -- the only condition is that they must be "free" (CC-SA or something similar). The play will be similar to Shining Force, and will feature the persuasion system I discussed in this thread. The game will have an overarching storyline, the theme of which will be "the challenge of promoting a new idea".

[tcaudilllg]

I said I'd make this thing easy, and easy it damn well is. I have added several commands specific to the design of inventories and equipment.

The inventory system relies on three fundamental elements: keys, lists, and slots. The list is an array vector that can also be accessed as a hash. Lists consist of items that fit in designated slots. Slots are created with preset limits which constrain the number of items of a given type that a list can hold.

Here's an example.

[tcaudilllg]

I made it more concrete. The key system became an equip system, and the list system became a simple inventory system. However, I may refine it to allow for multiple equip systems and multiple inventories on the same character.

I also added a new variable type, "counter". Counter variables are variables that have an arbitrary limit. When this limit is passed, a specified flag variable is set and the overflow is voided out. Variables like these are great for HP and magic limits (like 999) and for terminal velocity values when applying gravity. When the value falls below the limit, the flag is unset.

[tcaudilllg]

I added in a map definition language, based on BASIC. It seemed a choice between something mostly numeric and XML, so I went down the middle and wrote the thing in BASIC. It's somewhat bulky, but it's probably cleaner than XML.

Here's a sample. It defines a 2x2x2 map.

[Malignus]

How does the tile numbering go: across or vertically? Which is to say:

1 2
3 4

or

1 3
2 4

?

[tcaudilllg]

Across.

I like it because BASIC syntax is so much easier to parse than XML, although I grant that XML has its uses.

BASIC is ideal for parsing key/value pairs.

[tcaudilllg]

Got the map editor functional... layers, persistent world scripting (that feature I had planned for Worldyne, where you could edit the world in real time). So now I'm at the tweaking phase.

For my first game, going to make it something like Tower of Druaga, I think; that is, tile-x-tile movement. There will be a jumping function similar to Final Fantasy Mystic Quest. Think of it as FFMQ with a Tower of Druaga-like fighting system.

Gameplay centers around limited energy and fatigue. Everything requires energy aside from standing still. When you stand still, you gradually recover energy. Walking takes a little bit of energy. Items take a little more, and fighting takes a lot. Monsters also have energy, and change their behavior based on how much energy they have available.

Here's an example monster script that I made for testing purposes:

[tcaudilllg]

With the map system done, all that's left is the task of organizing the maps into a coherent game system. Simplifying this task isn't easy: the reigning method is a confusing "project" concept borrowed from Visual BASIC. What we want to do is make project consolidation as easy as possible without sacrificing power.

The game is made up of tile maps, which run on boards. Each board has a player character which is able to move between maps. This allows the user on the one hand to move about the game world, and on the other to interact with various menu systems, all of which use different maps. The alternative is a layers system which is altogether too confusing.

To demonstrate the power of this design, consider the case of a Zelda III clone. To faithfully reproduce the Zelda III engine, you need a HUD map, a text display layer, a layer where game play takes place, and an inventory screen. In Gamestar, each of these would use a different board, complete with its own set of maps. For the dialogue layer, you might only need 1 map; for the HUD, you might need several (especially for dungeons); 1 map for the inventory; and finally however many maps as exist in the actual game world. To transfer control between maps, you activate and deactivate action on these maps in accordance with the situation. Deactivating the player, for example, prevents further action along these maps. The maps never leave memory, and are a part of the fabric of the in-game situation. This makes complex designs trivial to implement.

Boards are setup through a 2 step process:

• Board is registered at the config menu and saved to a (user specified) configuration preset file.
  
• Starting maps for boards registered in the config preset are specified in game presets. This way you don't have to load a config preset for every game.
  

For testing purposes, I also intend to implement game state files which will permit the preloading of actor properties. This will allow that maps be play tested in various states of character development, instead of requiring that the game be gradually played through.

[tcaudilllg]

Actually, I'm thinking about just having every game be a list of maps. This way you could add maps to a game, then load the game itself in the editor later and choose from a list of maps to edit in the game. I guess this is closer to what's normally done, and now I see the reason.

[tcaudilllg]

Here's my new design.
- Make each game a list of maps.
- Preset configurations can be loaded into a game which specify cell size, tile size, screen dimensions (in tiles), and number of concurrent maps (useful for such features as HUDs, menus, and battle systems).

I'm thinking through a save file design now as well.

[tcaudilllg]

I discarded the map list design. If I had implemented it, it would have meant using too much memory (enough to hold all the maps in memory at once).

I implemented the boards and the presets. I also implemented a variable watch system and a function for "committing" preloaded variable values.

I believe I'm a few hours away from finishing the project, but I lack motivation.

[tcaudilllg]

OK I think I've found some motivation. However, this motivation is the encouragement of creativity. As such, I'm only going to release the single board version. The version I am releasing contains 16x16 tile maps which do not scroll. And, there is only one map per game.

I want to turn the clock back to the single-screen play era, and see what can be done with it.

If the response is good, I may find motivation to release a side-to-side scrolling version... something along the lines of Star Tropics.

[Mattias Gustavsson]

[tcaudilllg]

Here's that monster script revisited, this time with built-in functions:

[tcaudilllg]

Next I'm going to add two distance functions, one for calculating distance between two tiles and another for reporting all the tiles within a certain distance. Also, a function to return all the actors on a given tile. "For each actor on tile", "For each actor on tiles in group".