Procedural Generation Methods are now Complete!

I haven’t updated recently, so this post will cover the title content, as well as other small updates.

Milestone #3 (see blog title) has been achieved! Even if it’s about a month late… – I’m just trying to complete everything as fast as possible at this stage. I finished coding the Walkers algorithm last week, over the course of 2 days. Here’s proof!

Procreate's Walkers Algorithm

Procreate’s Walkers Algorithm

Walkers create dungeon and cave levels like Cellular Automata, although Walkers levels look more man-made than those generated with Cellular Automata. See the previous post if you want to compare the results of the two algorithms.

This algorithm took me around 2 days (about 6 hours total) to code – about double the time required for the other ones. It took longer to code because it had more classes and parameters that had to be debugged. I had one main problem throughout the coding, where the walkers weren’t changing direction very often. This was because I was creating lots of Random objects regularly within loops, which decreased the actual randomness. See this webpage for a detailed discussion on this.The walkers started stumbling around in the squiggly lines shown in the previous image, once I took the Random object out of the loops and forced it only to be used for all of the random requirements. The Random object is now a static property on Walkers in Walkers.cs.

Having completed the 3 algorithms, I can now start working on the game objects, which are part of Milestone #4. Users will be able to create game objects via the Game Object tab, once this next milestone has been completed.

Algorithm Parameter GUI Labels

You probably noticed the addition of parameters GUI labels in the previous image – i.e. Min walkers, Max walkers, etc. These were the result of the work I did today! Each algorithm has parameters that change its behaviour, and Procreate lets users modify these values. I’ve completed most of the parameter GUI labels, other than one for the Randomise Level algorithm, which will require some kind of list or panel that the user can drag and drop game objects into. This one will require a little thinking!

I’ve also bound the labels to the algorithm data in the code, so code will update as soon as the user makes changes to the parameters. This required a stack of code-writing, which you can see in MainWindow.xaml.cs – lines 87-213. I’m hoping to push most of this functionality into the Procreate’s xaml file, using Data Templates, so the xaml.cs file isn’t as big.

Advertisements

Adding Cellular Automata to Procreate

I added the cellular automata algorithm to Procreate today. There weren’t really any issues along the way, which is excellent! You can view its code here.

Cellular automata is most suited to generating natural cave or dungeon levels for 2D games. Its completion marks 2/3 algorithms completed! Even if they are being completed very late… Next on my list is the walkers algorithm, then I can start hooking the algorithms up with Procreate’s GUI. Only a few weeks of the project left!

Here’s an image of the new cellular automata algorithm in action.

Procreate cellular automata

Level Created with Cellular Automata in Procreate

The Big ‘Level not Updating’ Bug – Solved!

I’ve been struggling with a bug for the past few days, but no more!

I started coding Procreate’s randomise level generation algorithm, which is the first of three that Procreate will be capable of. All was going well – the code was all working, and subsequently the level was being randomly generated from a pool of game objects.

However there was a problem – the level was updating in my code, but this wasn’t reflected in the drawing of the level! So there was an appearance that Procreate wasn’t doing anything, which was a big concern because somebody using Procreate needs to be able to see the changes they are making to their level. Not being able to solve this bug would mean that Procreate would be useless.

The Problem, in More Detail

Procreate’s level consists of elements (level elements), which each had a string for the location of the element’s image – for example, grass, sand, a tree, etc. These are stored in Procreate’s C# section. These strings were than linked up with Procreate’s XAML file, which would load and draw them in the actual application. WPF refers to this linking as ‘data binding’.

I wanted the data binding to cause the application’s level to update every time the level was updated in the code, however this was not happening. The data binding was linked to the level elements, however it was never being alerted if an element’s image location was changed (in which case it would have refreshed the level).

So I spent a few days trying to create manual alerts, however I couldn’t succeed. I tried creating property change notifications for the level elements, however I didn’t understand completely how to use them, which resulted in the notifications not working. I got lucky in the end.

I read about a developer having his 2D game level refresh correctly when he reallocated the level’s memory, and while this isn’t the best option, it produced the result I wanted desperately. By setting the application’s object linked to my level to null, and then setting it back to the level again, I was able to force a level refresh by the application. You can see where I’ve done this in the UpdateLevelView function in this file.

From this result, I guess that any updates in the level itself are passed onto the application successfully, and without much input from myself. The level is a list of list of level elements, which I imagine have update change notifications built in already, and they seem to be doing the job.

I can progress with the development now that I’ve resolved this issue. I’ve added I picture below, so you can see my positive results at the end of this arduous experience.

Randomise Level algorithm is now reflected in the level's appearance

Randomise Level algorithm is now reflected in the level’s appearance

Guiding Bitgold’s Development with PXP

One of the courses I’m studying currently requires me to complete a test case of applying a particular software development methodology to one of my projects. Today, I chose to apply PXP (Personal eXtreme Programming) to Bitgold.

PXP

I was interested in applying XP to Bitgold if possible, after doing a little reading about it last night and finding that its process is simple. There’s a major problem though – XP is tailored for multiple-person development teams – conversely, I’m Bitgold’s sole developer. So I did some research to see if XP could be altered for one-person projects, and found Agarwal and Umpress’ introductive paper for PXP.

PXP is a derivate of XP, made to be used by single-person teams. It features some key areas of XP like testing, factoring and integration, although it reduces features like pair programming. The process starts with user stories, which are then broken into features, which are broken into tasks at the start of each iteration. Generally the most important features are prioritised to be coded, refactored, integrated, and tested very often. The PXP white paper (referenced earlier) details the PXP process.

I made a Trello page this morning, to organise each of these items. The page reads basically from left to right in sequential order of when the work will be completed. Basically, iteration tasks will be added, and they will progress to the right through each of the phases until they conclude in the release phase. I’ve created user stories for Bitgold, and broke them down into features and tasks. Although I’d created requirements prior to using PXP, it was easy to backstep a little to transition my current work into the PXP process.

Bitgold’s Trello page is a high level description of my workload – it is supplemented with external documents that describe the work in more detail. I completed some test documentation after putting the Trello page together.

Test Documentation

PXP, like XP, requires a large amount of testing (possibly more than what’s ideal for a single developer…). Prior to starting a development iteration, I had to create assurance test plans for validating that Bitgold has the required required features after a few iterations have passed. I created such test plans for each of the features, which can be found at Bitgold’s GitHub repo.

Having these done means that I can now resume development! So I’ll start working on linking Bitgold and JSON.net up after the weekend, as part of my first iteration. PXP has been very easy to use with my project so far – hopefully it doesn’t create any issues later on!

Documentation and Development Updates

This post covers the things that I’ve worked on this week, which included Bitgold’s design, planning and early development. As always, you can check out Bitgold’s GitHub repo if you want to access the work.

Design

Bitgold’s design is detailed in the design document, and summed up currently in the following images.

Bitgold Component Diagram

Bitgold Component Diagram

Bitgold Class Diagram

Bitgold Class Diagram

Implementation

I’ve created a WBS and Gantt Chart to show how I plan on developing Bitgold. These are presented in the implementation plan, however I’ve included them below.

Bitgold's WBS

Bitgold’s WBS

Bitgold's Gantt Chart

Bitgold’s Gantt Chart

These images show how long I think it would take me to develop Bitgold (a fortnight), however they are unrealistic because I actually need to have completed the project within a week. So I’ll attempt to be ahead of schedule in order to have the work all done on time.

I’ve put together the following milestones to go with my schedule:

Bitgold's Milestones

Bitgold’s Milestones

Development

Most of the documentation work happened a few days ago – today’s work focused on starting development! I had to code out the Bitgold’s local classes (i.e. classes that don’t access any Internet API), and this progressed without any issues. I was able to code every class in the class diagram, using Microsoft Visual Studio 2012 for my IDE.

Bitgold is a library, so I set it up as a library in the IDE, which means it creates a DLL and PDB when I build. You can view it on GitHub here. I’ve also created a console application BitgoldTest, in order to make sure the library’s working. This wasn’t something I’d planned for, and it took me a bit of researching to figure out how to include the Bitgold DLL in BitgoldTest, however I haven’t reached any unexpected problems with it yet.

So, at the end of today’s work, the Bitgold library can be linked with any C# project (you’ll have to build the DLL yourself though), and you can create its basic components, however it doesn’t really do anything. Next up on the agenda is adding JSON.net to the library, which will probably happen tomorrow. In the meantime, here’s a preview of how to use Bitgold!

Bitgold Library Code Preview

Bitgold Library Preview