Early Spring 2017 (8 Weeks)
For my second Directed Focus Study (DFS) course, I chose to build upon my Network system built for my Coingrabber game and make it into a proper Zelda game with Online co-op. The priorities for the first sprint (January – March) focus on the fundamentals of getting the game to be online coop, while the second sprint (March – May) focus on fleshing out the gameplay. As of the time of writing, this page will focus on the first sprint.
Unlike Coingrabber, Zelda Co-Op uses a dedicated host for its net ownership logic. Clients send their commands via their controller over the network, then the host processes the input, performs the actions the player wants to do, then sends the player the results of their actions.
Zelda Co-Op features data-driven dungeon layouts that allows any user to create their own dungeons for the game.
First, individual rooms are constructed via drawing pixels on a 14 by 10 sized image. This is aided by a TilePalette defined in the DungeonData XML file. A TilePalette allows users to designate a color to a tile sprite, so that any color could be used to represent any tile in the game. I created the TilePalette feature because I wanted to avoid hard coded values for dungeon tiles, and wanted to be able to support multiple dungeons in the future. With this system, it is painless to change a dungeon from a stone theme to a volcano or a water temple.
Second, rooms are stitched together to form a dungeon via the DungeonLayout XML. This XML contains two nodes, the RoomDefs and the DungeonLayout. Room Definitions takes the filepath for a room and gives it a easy to read name such as “entrance”, while also initializing each room. The DungeonLayout node takes the rooms defined in the previous node and then connects the rooms to each other. First, the game iterates through all Room nodes to find the starting room, and places that room at the origin of the world. Then, it iterates again through the list and moves the rooms to their correct positions For example, if the room node “entrance” declared “northRoom=”room1”, then “room1” is physically moved to be north of “entrance”. After that, “entrance” sets its north connecting room to “room1” and vice versa. Only rooms that are marked as “unplaced” will be shifted to the correct world position.
Enemies are also handled by the DungeonLayout XML. On the RoomDef node, users can define a dataFile file path. This file is an image that places enemies in the spots marked with a red pixel. During development, it was discovered that having too many enemies sending updates at the same time would clog the NetworkUpdate message, preventing entities from getting updated on the clients. To fix this, only entities that are in the same room as the player will send their updates to that player.
Other features include basic AI for the enemies and players being able to shoot arrows and kill enemies. The total amount of enemies are tracked at displayed for each player.