MY ROGUELIKE III PROGRESS REPORT 6

This week I got nothing visible on screen done. But I am only working here…

First priority was creation of Interplanetary travel system. I effectively copied everything done in interstellar travel system to support this with a new interplanetary travel display. However, it also meant I had to think carefully map system for interstellar, interplanetary and planetary movement. In essence it was all planning with a pot of coffee and pen and paper. Frustrating but necessary work with little to show at this point.

The second priority of the week was use of JSON files. In reality what was being worked was rethinking of the directory structure and how/why these files are accessed and changed. I soon came into conclusion that there are two possible approaches:

1) Player can modify things within game going through numerous menus and inserting values she wants to use in game. For instance how galaxy is generated. This is massive undertaking from programming standpoint and effectively means building specialist campaign generator software.

2) Player can access and change JSON files used to generate things. Then she starts the game and uses files found in particular campaign setting. In essense I need Default files that are accessed first and then I need <CAMPAING_NAME> files that override key-value pairs of default files when/if necessary.

I settled to idea that I would have a Data directory which would have separate directories for Default and <MyUniverse> campaigns.

Second problem is a question of maps and other data that needs to be generated and tracked during the game. Logical answer would be some kind of database but I decided to use JSON files as interim solution. My idea was that this way I can do testing easier as these files can be manipulated into whatever I wish.

My solution was following:

First, game reads material in Default directory.

Second, game reads material in <MyUniverse> directory with the same file name(s) overriding material of the Default directory.

Third, game reads material in <MyUniverse> directory without same file name(s) adding to lists of stuff found in Default directory.

This allowed me to override everything for a total conversion or just add new stuff to test. I think that it serves to industrious player too as it allows her to flexibly add-on or even rewrite entire material if necessary.

Example on doing code:

dynamic jsonobject = JObject.Parse(Json);
foreach (JProperty iter in jsonobject)
{
if (iter.Name == ”GalaxySize”)
{
GameSettings.GalaxySize = iter.Value;
}
}

Other Things I did:

I added acknowledgements page and a simple Game Guide page to guide players how to play game with.

I made a simple random name generator which now creates random names from letters to all random star systems. It is quite crude and allows similar names (why not?) but it is a start.

Activities with Future Potential:

I decided how the game map telescopes between different layers. My original 9×9 map became SubSector. The next level was Sector made of 9×9 SubSectors and SuperSector was made of 9×9 Sectors. In order to save memory only subsector (and neighbouring subsectors) where player’s spaceship is currently is kept in memory. Nothing is generated unless player goes there. The ”generated parts of space” are simply stored in JSON files to be added when necessary.

Next Week

Travel across Orbital system of individual planet is next and after that perhaps drawing a map of a planet for landing location. However, proper data files need to come out first.

Finally the game needs ”limited FTL system”. Jumping between systems and going to planets is core fun but there must be some limits to what can be done and why.

** Strategic Numbers: **

Maintainability Index: 88

Cyclomatic Complexity: 1057

Depth of Inheritance Hierarchy: 3

Class Coupling: 114

Lines of Code: 2059

MY ROGUELIKE III PROGRESS REPORT 5

This week I did my first interstellar jump. Is this the Childhood’s End?

It soon dawned to me that creation of my first actual GameSystem actually meant creating everything else first. 😦

I started by creating a space sector of 9×9 (81 cells) with density of 50% of cells filled with stars. Each Sector and star system is a separate game object. I also made sure that center of each sector would have a star system. This system is currently random but in future it will be pre-set allowing me to write predefined adventure locations in future.

Next item was a simple spaceship GameObject that has Captain (intended for player character). At the same time it was necessary to add PlayerPosition component to player that would hold sector and system data as well as spaceship under command.

With a hero in a position and spaceship to boot it was time to start writing first proper system. I soon noticed that my original idea of each GameEngine holding a number of game systems that would be called all the time just did not work with interstellar travel. There was no logical reason to assume that hero would travel all the time.

Thus I reworked my System concept into following: First there should be careful consideration whether this or that particular game engine works in real time or turn based.

1) The real time engine would use systems as before running through a list of relevant systems during each update.

2) Turn based engine would use systems as methods that would be called according to selected actions in menus. Since these classes do not hold a state they work well as static classes with static methods.

I changed my Interstellar travel system into a static class and called it when character wants to travel and it worked like a charm. Now my hero can move between star systems within a single sector.

Other Things I did:

I finished off my language support and it works very well. Now the game assumes language to be English and I can now switch it to Finnish as well. From now on it is just a matter of adding new strings to embedded resource files. I thanked Microsoft for making globalization easier than ever.

Second major change was division of JSON files to different directories and making code read all of those files in each directory. This simple change allowed me to plan for adding new interstellar activities and items in future without messing with old files.

Activities with future potential:

I also started to work on helpful game modes. Player/Party Info screen, Game’s internal Encyclopedia for information found, List of rumours that fuel adventures and missions and a logbook where all activities are logged. So far no functionality but screens are there for the future.

I did some changes to console UI methods too: I added a neat utility method that allows me to read maximum of X chars long string from console and has working backspace. I simplified display showing so the material will be shown neatly in left, center and right columns.

These changes should allow me to write and present a dialogue system in future…

Next Week:

First priority is interplanetary travel. First I am going to need a interplanetary system display with functionality to choose where to go. If everything goes well, the next step is actually moving to/from different planets within a system.

Secondary priority is the rethinking of how JSON files are used in game. I need to support both default game setting and random/semirandom game generation and JSON files are easy way to do it. Thus I also need to clean and reorganize the JSON files to support this…

Strategic Numbers:

Maintainability Index: 89

Cyclomatic Complexity: 626

Depth of Inheritance Hierarchy: 3

Class Coupling: 101

Lines of Code: 1101

 

MY ROGUELIKE III PROGRESS REPORT 4

This week I finished my work on component based architecture. Do I play to win or am I just a bad loser?

Component based architectures are all rage in the internet but unfortunately there is very little good discussion of pros and cons of various ways to implement them. According to my studies there are three broad ways to go on with the architecture:

1) Implement everything inside a large GameObject with all necessary fields and methods. GameObject will then have a number of flags that allow gameobject ot bypass unwanted ”component methods”. This is very easy to implement (everything is flat) but amount of code bloat (and difficulty of copy/pastah code) seems to make it a code maintenance nightmare.

2) Implement everything (fields and methods) inside GameComponent objects that belong to very slim GameObject (that has a simple list of GameComponent objects it goes through at every update). This is very flexible approach and it has no (actually little?) component dependencies. However, data – component coupling is tight making combination of data from multiple components difficult. This can be solved by making new components but it seems like making code bloat too?

3) Implement fields inside GameComponents while moving relevant methods to GameSystem code. GameObjects have simply identifier (typically integer number and perhaps a tag text string too). This separates data from systems but coding is somewhat tedious.

I had originally used approach 1 but this week I tried approach 3 which seemed to come together quite well in the end. I used following approach:

EntityManager has: Dictionary<GameEngineType, AbstractGameEngine> GameEngineList Dictionary<GameSystemType, AbstractGameSystem> GameSystemList Dictionary<int, AbstractGameObject> GameObjectList Dictionary<GameComponentType, Dictionary<int, AbstractGameComponent>> GameComponentList

Engine has: List<AbstractGameSystem> SystemList

System has: nothing as it is pure game mechanics system.

Object has: int Id

Component has: nothing but relevant game stats

Since my game had no functionality within GameObjects and GameComponents it made no sense to have message system have message handler in either. However, there was need to trigger all kinds of activities in game. Since I was not certain what they were, I used a simple OnMessage method which will use switch – case to do something when necessary. What these are will depend on actual systems so I did not changes to corrent system.

Other Things I did: This week’s second theme was choice between abstract factory design pattern and factory method design pattern. I chose factory method as it was more familiar to me and I used it to create components, objects, systems and states. I also moved all my JSON script handling things and files to work under entity manager as this simplified game engines and game context. Now it has necessary methods to read all my game objects and associated components and create them as needed.

Activities with future potential: I tried to do time associated random activities but so far I am having problems creating a suitable random encounter system.

Next week: Next step is making working interstellar travel a reality in this game.

Strategic Numbers:

Maintainability Index: 91

Cyclomatic Complexity: 278

Depth of Inheritance Hierarchy: 3

Class Coupling: 82

Lines of Code: 436

MY ROGUELIKE III PROGRESS REPORT 3.5

This is a simple example of how to read a JSON string into a dynamic object and then parsing it.

String jsonfilecontent = @”{ ”monsterlist” :

[

{ ”Name” : ”Janne”, ”PhysicalAttribute” : [ 10, 11, 12 ] },

{ ”Name” : ”Kemppi”, ”PhysicalAttribute” : [ 13, 14, 15 ] }

]

}”;

// Parse JSON file contents into JArray

Newtonsoft.Json.Linq.JArray jsonresult = Newtonsoft.Json.Linq.JArray.Parse(jsonfilecontent) as Newtonsoft.Json.Linq.JArray;

// Use dynamic keyword to turn json string into a dynamic c# object list

dynamic monsterlist = jsonresult ;

Console.WriteLine(monsterlist[0].name); // Janne

Console.WriteLine(monsterlist[0].PhysicalAttribute[1]); // Strength = 11

You can also use List…

List<Monster> monsterlist = Newtonsoft.Json.JsonConvert.DeserializeObject<List<Monster>>(jsonfilecontent);

WARNING! This code is written without my actual code and right out of my head so it might not work properly but you get the idea…

 

MY ROGUELIKE III PROGRESS REPORT 3

This week I learned to love the potential of JSON.

I started my JSON journey by moving from Microsoft’s pure .NET Framework to using Newtonsoft’s JSON.NET framework. It has a very powerful feature: It allows using dynamic binding with JSON parsing. In essence this means that JSON file’s contents are now part of dynamic object which can then be accessed in code quite easily. Even better, you can set these accessed elements as var variables and set them to associated GameElement lists and variables. This simplifies problem of reading and writing JSON files considerably.

Messaging system was the next item in agenda. The basic goal of any messaging system is to send orders and cause effects on engines, systems, objects and components. There are tons of different messaging systems available but I started my work on thinking the two basic ways to do it: one-to-one and one-to-many.

Observer design pattern allows one to many relationship where subject changes cause action in all subscribers. This allows for example causing effect of weather to hit all persons in a party. Second method is to simply call some message handler method of a target GameObject that will (according to message type) order message target to do something. This is effectively one to one relationship. This allows for instance sender give money for services to target. I implemented both ways and tested them.

Thinking about messages I got following thoughts and ideas which were part of my final implementation:

-Messages themselves should be structs rather than classes in C# so they are quicker to create and destroy.

-Message should have information about sender, target, message type and data.

-Message type should be enum. This allows making message handler with switch -case syntax. Wrong and unnecessary messages can be simply ignored by going through default path. Number of different message types must then go to hundreds in a full game.

-Some messages must be delayed somehow and triggered later. Since my vision is to use game time as a constantly advancing thing I can simply create use a system where messages in message queue are compared to current game time and dispatched when game time is over the delayed triggering time. Thus some messages are added to message list that is checked whenever game clock advances.

Other Things I did:

I decided to use enums as keys to some objects in my game. I gave all GameState objects enums as keys and also changed my code so that they were instantiated immediately at game’s start. This made code a bit cleaner and easier to read. I will eventually use enums with GameSystems and GameComponents too…

I wrote a dice roller character creation system and made sure that game’s seed number is currently 42 to make testing easier. The dice roller currently just rolls number of dice and calculates their numbers together. Additional dice methods need to be supported in future…

Activities with future potential:

There are also future benefits such as adding animals and NPCs as JSON files. This also serves to help me achieve another ”requirement” of Roguelikes, that the save files (and defines) must be written as UTF-8 Text files…

My two message systems work but I think they need to made more flexible in future. There is also several weaknesses. Systems currently send messages to GameObjects only. It might be necessary to send messages to game states and game systems too…

Next week:

Currently I can create a GameObject for player hero and add it to my list of entities. I can also add a new GameComponent that holds physical attributes for character. My hero creation is also randomized. However, it all comes across as a bit weak.

I am currently rethinking just how my different objects should be really handled in the game. Use of enums as id is one approach and I need to look again a bit of polymorphism too to see if I can shave my code simpler.

The second target is building some kind of gameobject factory. I am currently pondering should I use abstract object factory or perhaps a factory method.

Strategic Numbers:

Maintainability Index: 91

Cyclomatic Complexity: 252

Depth of Inheritance Hierarchy: 3

Class Coupling: 72

Lines of Code: 457

My Roguelike III

How do most roguelikes deal with window sizing and ui elements/maps?

This week I have been working on problems of UI. I decided to use proportional sizing and anchoring by writing my own methods to handle menus, screen clearing and text positioning.

I have anchored only few things to corners and edges: game clock and game version as well as what game mode is being used.

The UI itself is based on concept that game has 0-25%, 25% to 75% and 75% to 100% column areas in use. I have thus three columns and I will have game activities in leftmost column, the selection and display in center and additional details and end results shown in rightmost column. I strive to avoid showing unnecessary statistics but maintain them behind single key button that shows game element’s statistics, historical data etc.

This kind of UI is possible because my game currently has almost no real time gameplay elements and it is more of selecting a choice.

There has been discussion about right size for rogue-like and consensus seems to be that poor eyesight requires 70xXX sized display (I used it before abandoning fixed size).

 

General Coding Advice…

I found this from Roguelikedev in reddit: ”I’ll do the most brain-dead, straightforward implementation I can, adding comments about what’s supposed to happen next and then fleshing it out with code as I go. Then, once it’s actually up and running, I’ll go back and do some refactoring and minimal optimizing. Rinse and repeat.

I feel like I eventually end up with well organized and maintainable code, but it’s not like I took the straightest road to get there. Anyone else code like this? Or are you more organized from the get-go, making a solid plan and then simply executing it? What works for you?”

I always try to plan before implementation. My planning is based on thinking and selecting implementation I believe will be useful. In my case I typically think suitable software design pattern I am going to use. Thus my design work is mostly thinking the rough flow of the code followed by looking places where design patterns can be used to my advantage.

During the actual implementation I create a minimum viable product through test driven development.

Once feature works I ponder how much of it can be moved to various utility and definition files of my game. I use this approach as it increases number of useful methods that can be reused when necessary. This also reduces amount of copy paste and thus code maintenance.