I am working on Perenthia again, doing some re-design work to try and make the game fun but also maintainable by one person, me. I am going to catalog my development journey and the design decisions made along the way. I am trying to take what I learned from the prototype/alpha stage and improve upon it with realistic goals and tasks. Since it is just me working on it, other than contracting out the artwork pieces, I need to stay focused on making it fun and trying to implement the features that I think will be fun.

I have actually already started working on a re-usable library to host multi-player games. I have the basic framework in place which includes a base GameObject that provides a dictionary or properties and implements a behaviors system to allow custom behaviors to be created and attached to objects. I also have a master Game class that can be started and runs the server frame loop, updating the world and any loaded objects, behaviors or game components. I used MEF to define externally loaded components and data libraries. The Game class expects an IWorld implementation, some repositories for objects and users and optionally a list of IGameComponents. The IGameComponents are updated with each frame loop so I figured those would be good for creating things like a weather component, pack AI, etc. The IWorld is also a game component but has a few specific methods defined to access data contained within the world from the Game object. Behaviors are simple objects that can be attached to a game object and also contain and Update method that is called during the game object’s update method.

All this is server side code intended to run a virtual world. In addition to the re-usable game server I have a Perenthia specific library built on top of it that defines the aspects that are unique to Perenthia itself. For instance, Perenthia contains a Skill and Race object and loads that data during the world initialization. The underlying virtual world framework is not aware that skills and races exist, just that game objects are being added, removed and updated.

For data storage I put all world data that loads with the world initialization into SQL tables and a few external flat files. User and player data I am going to store in MongoDb to take advantage of the document storage mechanic and store an entire player object as one record. After using relational data for years to store objects and wiring up code to handle the relationships, etc. I find the document storage a refreshing change. I took a look at EF and code first but could not obtain the same level of ease of use as with a document store. I ended up having to code way too much logic specific to how the objects are stored rather than just saving them.

For the initial game client I decided to go the Html5/Javascript route to be able to present to the majority of players. I am using SignalR for the client to server communication and worked out some generic interfaces in the underlying server framework to allow for switching the communication technology. I am also using ScriptSharp to build the client side game logic. I find that using ScriptSharp is helpful as you get compile time errors and can resolve some issues up front without having to use console.log statements for everything. The string typing of objects does help to catch some case typos, etc. that are common for me when doing Javascript.

I have also created a world building tool for use with Perenthia. It allows me to draw the tiles that make up the world and save them as flat files for world initialization on the server. Using ScriptSharp I also coded some logic on the client to retrieve and load the maps. I can manage some of the SQL table stuff using the world build but want to get it to the point where I can add objects. My plan is to drop objects onto the map where an object resides within a tile, so not completely to scale or anything. My initial thoughts are to be able to add things like shops, taverns, etc. I also want to be able to add things like trees that can be cut down or a rock quarry for mining. I just not have not gotten to fleshing out all those details as of yet but that is the general plan.

What I am currently working on is randomization of creature encounters. I created a table to hold creature templates and then cataloged them by terrain. So for instance, in grass one might encounter a rat or kobold. In addition to that I created a feature in the world builder for editing creature zones. I store some zones in the database and then draw them on the world tiles to create the creature zones. So what I am working on is when a player moves onto a tile, if an encounter should happen I check to see if any creatures exist for the current terrain. If creatures exist I randomly get one with the level range marked by the zone. I am also thinking I may not return any creatures that are too low level for the player so you are not bogged down by encounters in low level areas and can move more freely into higher level areas. Once I get to where I have some decent encounters I am going to move on to the item system.

Part of the Perenthia re-birth is to get the game running in the cloud on Windows Azure. I started an Azure 1.2 web role project to handle the game. I got some of the basic stuff working like authentication and character creation. With the release of Azure 1.3 SDK I had to install IIS 7.5 components. Since I did not install it previously I had to run “aspnet_regiis –iru” to setup the IIS mappings for .NET 4 and I had to install the “HTTP Redirection” component for IIS 7. After getting all that setup I am up and running with Azure 1.3.

Because I am scaling the game down a bit and restructuring it to run with basic html and a variety of devices I am essentially re-building the game. I have a lot of code to work from and the concepts are already defined but I do have to do some new things. With running in the cloud some of the previous in-memory stuff I was doing has to be setup to store that in-memory data either in the database or in Azure Storage. For instance, when you connect to the game you get a token or session that identifies you. That token contains a reference to an in-memory object that stores the user id and currently selected character of the player. While I could setup and use .NET Sessions with some providers to store the data in Azure Storage I am going to continue to use the existing system I had in place and store in the in-memory data in Azure Table Storage.

I have some additional in-memory data that will either scale back to database driven queries or work the same way as tokens/sessions with table storage.

After many months of not working on Perenthia I find myself once again desiring to see it complete. The last revision I did on Perenthia was some time ago and involved a Silverlight UI with a C#/SQL 2008 backend.

During the course of development on Perenthia I discovered some of the pitfalls of attempting to develop a role playing game by one self. Mainly, the inability to handle content creation on a large enough scale as to appeal to players and have enough interactivity to make the game fun. I have been thinking lately of ways to reduce that load and still keep the game fun. I have some new ideas I want to put into place and re-release Perenthia with these concepts.

Among the changes I plan to implement will be scaling the game down to function solely in an HTML environment. This will enable me to provide a mobile version that works on all phones with a browser and keep the feature set the same for both phone and web.

I have begun to refactor pieces of the code and am making heavy use of jquery for the character creation screen.

I thought I would share one of the core concepts I implemented in Perenthia that has been working quite well. Early on in development I decided to create templates and instances in regards to game objects. A template would define common, unchangable properties of an object whereas an instance would be the opposite. An example would be a Sword; there is a template for a Sword that defines its damage value, price, required skill level, etc. 

I have one table that stores all the objects for the game. Since objects being actively used are loaded into memory and the table is indexed for those queries it runs pretty fast. Since I store all of the objects into one table I make heavy use of the XML data type in SQL 2005 to provide a bunch of XML Serialized Key/Value pairs that define the properties of an object. On the code side of things a dictionary provides the underlying data store for properties of the object. For instance, the Sword example above has a Power property that is used in combination with the wielder's skill in swords to determine damage. The Power property just fetches the Power value from the properties dictionary using the property name. This works a lot like the dependency properties, just my collection serializes to XML for database storage. When an object is loaded from the database the xml from the template is retrieved and added to the object, then the object instance xml is dropped into the object, overriding any template properties of the same name.

This property dictionary also allows me to store whether or not the property belongs to a template or instance. If the property belongs to a template then when the instance is serialized and saved to the database those template properties are excluded. Likewise saving a template does not serialize and save the instance properties. This structure allows for a lot of flexibility with my objects and has been working out quite well. I probably would not have used serialization and xml the way I am if I was doing a typical call to the database qith each request as the extra overhead would not have been worth the effort. However, since my objects are loaded into memory and my saves are background threaded I experience a lot of benefit of an easy to use object.

I shuld note that players character data is stored in a separate table from the core objects table. It follows the same design buy allows me to migrate and change data in the objects table without overwriting player data, since players are essentially the same as mobiles. 

I have been working to modify the tool I wrote for building the Perenthia world. The tool started life as a WinForms application, migrated to a WPF application but is now a part of the Silverlight Client UI. Since all of the actions are role based and controlled with permission on the server having it in the main client UI allows me to make use of all of the framework already in place for Perenthia.

The world builder UI connects to the server via WCF services tailored for world building. What this will also give me is the ability to open up the world builder to allow users to create custom dungeons, towns, etc.

Some features of the world builder are a background map of the world so I know where to place rooms, zoom capabilities that scale the map, draggable map and the ability to drag items, creatures, NPCs, etc. onto rooms on the map and configure the properties of each.

I uploaded the Perenthia Armorial Version 1.0 to the Perenthia Alpha site tonight. The Perenthia Armorial is a way to provide external access to Perenthia information. The first version includes the Player Bar feature, where you pass a player name to the service and renders back HTML with player details.

The call to http://alpha.perenthia.com/Armorial/Armorial.ashx?n=Aldarian renders the following:

For those waiting, Perenthia is almost ready for alpha. I have a few more things to complete and then the first phase of the Alpha will be ready. Hopefully you have had time to look over the various races, attributes and skills on the Perenthia web site and will be ready to create a character and begin your journey.

Here is a list of the remaining tasks I need to complete before Alpha, this does not include testing and fixing bugs with these features, just implementing them:

• Spellcasting (Basic framework is in place, just need to define some spells and test them out)
• Monster drops, including currency, gold, silver, etc. (They don't drop anything right now, stingy)
• Help (Just need the framework in place as the help will get compiled during the alpha)
• Quests (May not finish these for the first phase of alpha, want to try and keep it simple to start)
• Some UI cleanup (got some windows not responding to updates from the server)
• Content (Need to finish adding monsters to the dungeon, just the one dungeon for alpha)

I thought I would include a couple of screen shots along with this update. The first is a shot of the map window of the world builder tool I wrote for managing the places and things within the Perenthia world. This is the shot of the Alpha testing area, a small village called "Delcor". This view is actually a windows forms application with a WPF (ElementHost) control for rendering the map. The little red dots are NPCs that I can actually drag around into other rooms on the map after I create them, makes for moving the monsters in the dungeon a lot easier. :)

This second shot is the game user interface showing the same map that I was working on in the screen shot above.

I am still plugging along on my games, working mostly on Perenthia and checking out the new stuff in Silverlight 2 beta 2. I want to try and get the Perenthia beta 2 up and running by the middle or end of the summer, free time permitting.

 I haven't blogged much lately but I have been working on a lot of stuff. I will try and get some posts together to outline some of the stuff I have taken advantage of in developing Perenthia such as adding files as links in Visual Studio and then using partial classes to separate server and client logic and multi-threading in Silverlight and how to avoid cross thread access, which you will get exceptions on now in SL 2 beta 2. I will also try and get some screen shots of Perenthia, quite a bit has changed since the last screen shot I posted and I would like to get some of the new ones up.

Perenthia currently provides "wilderness" areas where monsters roam around waiting to attack players who wander beyond the safety of the towns. I had originally wanted the wilderness to auto generate instead of how it works now where all the wilderness "tiles" are stored in the database. This caused over 150,000 records to have to be entered into the table and really limits expanding the word since I have to basically draw all the tiles.

For the Perenthia Beta 2 I worked out a "Regions" table to store a rectangle x,y,z value. The Regions table also stores the min and max levels required to venture into the region. Towns located within regions also carry a safe indicator so that monsters will not auto generate. Using this concept I only have to create the towns or places of importance and can let the "wilderness" be auto generated. 

The auto generated wilderness is infinite in that each wilderness place visited is created and stored on the player record. Wilderness is also exclusive to the player so that monsters generated will be available only to the adventurer. A lot of games have done this with dungeon instances and I thought it was a good idea to implement in Perenthia. There will be ways to interact with others and I still have some work to do to handle group play but wilderness is intended for solo players. Now, given that wilderness is infinite I don't want players getting lost so, the last non-wilderness place they visit will be stored on their player record and if they log out and log back in they will be reset to the previous non-wilderness place. It's kind of a fast way to cheat your way back to town if you get into trouble but I am OK with that. I would rather players leap back to town before their character dies than wander aimlessly around thousands of tiles from civilization. I want the wilderness adventuring to be a fun way to earn gold, not a potential for grief.

Quests may require adventuring through the wilderness to find hidden places so logging out when you are in trouble will cause your quest to take even longer. I think this will be a good trade off because quests will offer greater rewards than adventuring and should require a higher level of mastery.