Algorithms

<< < (3/4) > >>

tcaudilllg:
Not alone, no. Not enough time to think of something decent, I don't think. I'm a very slow decision maker, and you're giving me too many options. :)

As for this thread, I think I'm about done with it. It's painfully obvious that the camera algorithms go ditto for sprites, so... I think that's it. Everything else we already covered in the NPC engine thread. Although, these algorithms deal with an entire map worth of data. Fine for small maps, but not so great for large ones. Need still a formalized solution for the "excerpt tiling" technique.



The sprite management algorithm is a more complex version of the camera definition algorithm.

Sprite Algorithm: Managing Sprites[/i]
For each moving sprite:Get all tiles the sprite is currently onUnregister the sprite from all tiles it is currently onGet the tiles of each corner of the sprite's boundary box.Compute all tiles within or on the boundaries of the boxRegister the sprite on all tiles within range of the boxRegister each tile holding the sprite with the sprite itself[/li]
[/list]

Sprite Algorithm: Control sprite visibility
Check the tiles in the camera's view.If a sprite is present on a visible tile, show it.Cycle the sprites
When a sprite moves, set a movement flag respective to it.If the movement flag is set for a sprite, update its tile.If a sprite moves onto an invisible tile, hide it.[/li]
[/list]

Sprite Algorithm: Cycling sprites
Loop through each sprite
Check the move flagif the move flag is set, manage the sprite.collision test for every sprite also on those tiles[/li]
[/list]

Code:


for (index = 0; index < spriteLimit; index++)
{
    if (sprite[index].move == true)
    {
        manageSprite(index);
    }
}


Richard Marks:
Its intentionally simplified. You only need to come up with something really simple that follows the flowchart logically, and includes all the items on the item list.
Not exactly rocket science, nor is it a complicated project.
My code is likely going to be under 1000 lines total. ;D

tcaudilllg:
Saving Algorithm: Save a properties list

Saving is often treated as a laborious enterprise, but in general the saving should be done with nothing more than a loop through items to be saved. The items themselves should be prepared in a function specific to the task. This generally cuts down on coding time per save function, because only half of the process is repeated instead of the whole thing. (who wants to write save functions? Not me...)

Procedure:
Assign each property to be saved to elements of an array, storing both the name and the value.Save the array.To save the array: join the properties together into one string, seperating the name the name and values components with a designated seperator, and the properties from each other with another such seperator.
Code:

index = 0;

propertiesToSave[index].name = "XCoord";
propertiesToSave[index].value = "0";
index++;
propertiesToSave[index].name = "YCoord";
propertiesToSave[index].value = "0";
index++;

saveData = saveProperties(propertiesToSave, "=", "\n");

// write saveData to disk


function saveProperties (properties, componentSeparator, entrySeparator)
{
    propertyList = "";

    limit = properties.length;
    for (index = 0; index < limit; index++)
    {
        propertyList += properties[index].name + componentSeparator + properties[index].value + entrySeparator;
    }
    return propertyList;
}



Parsing Algorithm: Parse a properties list

Parsing a properties list is a complex, two-step method.

Procedure
Declare the line and component seperatorsSplit the properties list with the line seperatorSplit each property into two componentsTo obtain the property name: get the first componentTo obtain the property value: get the second component

Code:


data = "XCoord=0\nYCoord=0";

lineSeperator = "\n";

propertyList = data.split(lineSeperator);

nameIndex = 0;
valueIndex = 1;

limit = propertyList.length;
for (index = 0; index < limit; index++)
{
    components = propertyList[index].split(componentSeperator);
    properties[index].name = components[nameIndex];
    properties[index].value = components[valueIndex];
}


tcaudilllg:
Now two vital NPC algorithms: controlled sprite creation (useful for weapons and projectiles), and transfer of data between maps.

NPC Algorithm: Exchange data between maps

For purposes of this algorithm we distinguish between temporary NPCs and persistent NPCs. Temp NPCs are eliminated when the map is closed, and remade from scratch when it is reopened. Their data is intrinsic to the map. Persistent NPCs are independent of the map: their data is stored whenever the map is closed, and may be accessed by other maps.

Procedure:
Suspend all NPC activityDistinguish between temp NPCs and persistent NPCsDestroy the temp NPCsPreserve the player's propertiesSave the persistent NPCs propertiesRemove the sprites of the persistent NPCsclose the mapopen the destination mapposition the playercreate the player's spriteload the temp NPCs for the new mapcreate the NPC sprites
It is the responsibility of temp NPCs to invoke persistent NPCs into a given map, via a scripting command suited for the task.

Map Algorithm: Destroy the map

Procedure:
Destroy all tiles.Destroy all tile data.

NPC Algorithm: controlled NPC creation

This algorithm is useful for creating weapon NPC such as bombs, projectiles, and even sword swings. The idea is to copy the caller's coordinates to the created, and offset these by a specific number of tiles. This function is best called by a script command.

Procedure:
create the new NPCset the NPC's coordinates to those of the calling NPCproject the NPC in the desired direction by the required amount of tilesshow the NPC
Once the NPC has been projected into the map, it can behave on its own. It should have its own script for this purpose, which should be provided in the caller's code.


Next, the player and NPC cycling.

tcaudilllg:
The player is just an NPC which responds to input. Rather than concentrate on what differentiates the player from NPCs, it is best to create algorithms for "actors" which can behave either as NPCs or player characters. The most important of these is the cycling system which moves the game forward.

Building an Actor Cycling System

Actor cycling systems create a sense of time in the game world. Creating a sense of time involves several component factors:
there must be a switch to turn time on and offSpecific functions of the actors must have access to the time switch
The ability to turn time on and off is very important. There are several reasons to pause time.

transition between mapsshow dialogue boxesplay menu maps
A menu map is a special sort of map which is used to control the game's characters. There are dialogue menus and control menus, but these are effectively the same. They differ slightly in that dialogue menus only require that the suspension of the player's time, while control menus require that time itself be suspended for the entire map.

Menu Algorithm: call the dialogue menu

Procedure:
Suspend the player actoractivate the dialogue submapTo call a main menu: suspend time on the map; open the menu map
Elements of a Menu Map

On menu maps, player input is accepted by the cursor. The cursor moves between tiles which execute scripts when activated. The cursor can move to different areas of the menu by activating specific tiles or by invoking its own functions.

Elements of an Actor Cycling system

The challenge of creating a cycling system is the problem of managing multiple maps, each with its own timeline. While this may seem like a daunting task, we never have use for more than three maps at once. One requirement is that we distinguish between field maps and menu maps. We account for this in the algorithm.

Map Algorithm: Cycle the Maps

Code:


if (gameInProgress == true)
{

    if (mapType == "field")
    {
    // process field maps
    }
    else
    if (mapType == "menu")
    {
    // process menus maps
    }
}


This algorithm allows us to exit the game at any time by doing nothing more than setting the gameInProgress flag to "false". Further, we can switch the map type by doing nothing more than resetting the mapType variable, meaning that maps of either kind can be open concurrently, even if only one or the other is active.

Dialogue menus are maps whose tiles are drawn by code, not merely loaded, and are always overlayed on top of the field. Dialogue menus involve partial suspension of the field time. When the dialogue menu is up, actors stop receiving input. It is the responsibility of the dialogue menu control function to disable physical interaction by setting the appropriate flag.

There is no need for a title menu function per se; the title functions can be performed by dialogue menus overtop of a field map which exhibits the title.

Navigation

[0] Message Index

[#] Next page

[*] Previous page