Monday, May 18, 2009

Design and client

The above shows a quick overview of the design so far, and to begin with I will not go into any deeper details then that. The newest classes that do not have any description are Client and Rimor. Rimor is the main starter class that bootstraps the application, and will also hold the main loop of the application.

Client will hold the graphical representation of the game, and this part still gives me some trouble. Drawing the map for the first time is easy enough, but keeping it updated is a little more difficult. Every time an update happens on the map, the client need to update its representation. I do not want to redraw everything for every update, but only want to update the relevant parts. I have a few ideas on how to do, which probably will involve having the client some sort of tile concept. I will start coding and to experiment with various solutions.

Friday, May 15, 2009

The Player

There is a distinction between the player, and the representation of the player called an avatar. The avatar only knows enough about the player state to show an accurate representation of the player in the game, which could be items that become visible if worn. The player is the person playing the game, and information regarding that.

To represent this distinction there will be two separate class called Player and Avatar, and the following UML diagram illustrates the initial idea of how they should be placed.

The map knows the position of the Avatar, and the tile on which the avatar is placed also holds a reference to get any state modifiers for the tile. The player holds a reference to the map, to which the player can inform and changes to its representation.

I remember the distinction between Avatar and Player from some of my university work, and would like to try to use it.

Map

The map being used also needs to be stored, and for this I will be using a sqlite database. In this database the maps are stored with information about size, and individual tiles are also stored along with information about objects placed on them. This gives the following:

When the application loads, a dedicated MapFactory class will handle the loading of the map.

Tile State

As mentioned in my last post, I had some problems on how to handle states on the tiles of the map.

As a solution I will have a class called TileState, which holds the actual state of the tile on which it is referenced. But it will not only the tile that holds the reference, but also all the objects that are placed on the tile will have a reference. When a change happens in one of the objects, they can report this change to the TileState instance. When an object is added to the tile, it will have to consult the TileState instance any modifiers it has to the state, this will also happen when the object is removed from the tile. It will be necessary to have a counter to the boolean style states, such as if a tile is passable.

Instead of having the objects updating the state individually as leave the tile, an alternative would be having the tile query all objects again. I will not be doing this alternative, as this would require more computational power, and I therefore want to see if I can avoid it.

Thursday, May 14, 2009

Mockup

This is a mockup of what I will be creating, which is just a basic room with an avatar moving about.

I had actually done some basic designing before doing the mockup, which was a bad idea. The graphics that I have chosen behaved differently than I expected, specifically it is the walls being rendered on top of a tile. So basically I started designing before having a complete picture of the requirements ... naughty me. I should know better.

The way the map will be rendered is first are all tiles rendered, basically the floor. Then on top of the tiles, all items, avatars and walls are rendered.

My initial thoughts are that walls, items, avatars etc. are map objects that are placed on tiles. The map objects do not in any way refer to the internal state of a map tile, but are just an object located on a tile. An obvious example of an attribute for a tile would be if it is blocking or not, i.e. can an avatar pass through? But then again it may not be as simple. There are instances where a map object would manipulate the attribute of a tile being passable or not. This could be chest that does not allow, unless it is smashed. This could be solved having the tile knowing which objects are stacked on it, and these objects have state modifiers which the tile can query. I will be going back to the drawing board and work some more on the design.

Wednesday, May 13, 2009

Graphics

I know from previous experience that graphics can be time killer. So to begin with I have decided to run with the graphics from the great Crossfire MMORPG game. They are not the most pretty, but they are functional and they are there.

My plan is to do at lot of experimenting in the beginning, so looks is not on the top of agenda.

Welcome to Rimor

As my day job requires me to work with HPS and Cobol, I feel my OOP skills becoming rusty. To keep them sharp I am taking up an old dream of creating my own RPG.

I will in this blog post my ideas/questions/solutions as I go along.