After going through the FPS Microgame I realised that all these mods required you to pay for them, so I dropped that and searched for something else. It wasn't long till I stumbled across this 2D RPG game called Rubys Adventure.

I've been going through the tutorial on stream, here is the first of a few streams following the tutorial.

As I've started to take up streaming and learn the Unity Engine I decided I would start with one of the in-editor tutorials. They have these "microgames" that are available, I've picked the First Person Shooter one.

Anyway here is a video of me working through it:

Thanks for watching, I'm really excited to see where this goes.

​Cheers :)

So during lockdown I've been looking for something productive to do that will kil the time. I've been gaming a lot and have decided to start doing some Twitch streaming. Whilst doing this I thought what a great opportunity to dive into streaming for my software development. So I decided I would pick Unity back up and give that another whirl.

There has been a pretty steep learning curve with all this, I've had to learn how to setup all the streaming applications and get my system setup, ensuring that my audio is synced properly. I also wasn't aware of how strict the rules are with playing copyrighted music, although it makes total sense really.

Anyway this is just to be a short post, you can find links:
Twitch
YouTube

​I hope to see you on one of my channels,
​Cheers!

So as mentioned in the README, I have a few stages of development that I would like to take this project to.

The first stage was to simply use TDD to implement the Coding Kata to pass the Tests. The next stage and the one I am currently working on is to visualise the Minesweeper Board using Monogame. 

As I still wanted to progress with practising TDD I decided that I should carry it on throughout the other stages of this development and this brought up some interesting results.

As I began the visualisation phase I quickly realised that I will have to be conscious about which part of the code I test. For example, I decided I wasn't going to test any of the draw functions and these are the reasons why:

• The drawing functionality is so closely linked to Monogame that I would essentially be writing tests to ensure that Monogame is working correctly, which I'm sure Monogame already has plenty of.
• I could test that when I draw a particular square I could then check that against an image to ensure that It matches up perfectly. Of course If I ever changed font, changed background colours or provided any tweaks to the visuals then these tests would need to be re-worked. Not ideal.

​

The advantage of this forward thinking is that I could make clear decisions about what I would test. These are the decisions I ended up making:

Due to the fact that I knew that I had fully tested the Board Class and that if we are using SOLID principles then that should now be "Closed to modification". I Created a new class called BoardVisualiser which takes a Board Class as it's constructor argument which would then deal with purely visualisation of the Board. 

In the past I may have been tempted to just add some Monogame Classes to the Board class and add a draw function to it. By doing TDD that thought never even crossed my mind, which is a great sign that performing TDD leads to better architecture.

As I knew I was not going to test the draw functions themselves, that didn't mean I couldn't test anything that would be a part of the BoardVisualiser class. I realised that I would need a method to find the origin that I would need to provide to the draw calls to say where I would like each square to be drawn. It's this sort of application logic that I could quite easily test. 

I was careful to try and keep this function to use as many primitive types as I could, It would have been fairly easy for me to pass in a Monogame class to this function but that would have put a dependency on Monogame in my tests which wasn't really necessary for this particular function.

Something that is fairly interesting, is that I actually found a bug whilst performing the TDD on GetSquareOrigin function. It was a simple copy and paste error but I wouldn't have caught it until much later on when trying to draw the squares to the screen and by that point it would have been much harder to find.

​Cheers :)

So I've been working on the Minesweeper Kata mentioned in my previous blog post (When I don't have work, or a one year old to entertain) and I've finally got it checked into Github. 

​It is available here.

There are still plenty more pieces of functionality that I would like to add, most of which I've listed in the README on Github. Before doing so I thought I would write a little post mortem of how I got on with the Kata.

This isn't going to be a list of advantages/disadvantages of TDD but more what aspects of using TDD for this worked well for me.

Pros:

• By forcing myself to do strict TDD I believe the end result was much higher quality, there were a few cases where my first attempt actually failed in some not so obvious ways. These would have slipped through the net normally.
• Focusing on the Testing/Requirements rather than just implementing the functionality actually became a bit of a game. e.g. "Hmm, what are the failure cases of this function? What Inputs can I give it to make it fall over?"

Cons:

• Due to the fact that I've not done strict TDD for a while I did find myself having to delete some code as I had started adding more code than was necessary to pass the test I was working on.

Overall I've really had fun doing this little Kata so far and can't wait to carry on adding functionality and plenty more tests to the project. 

​Cheers :)

So we'eve been doing some test driven development at work but not enough to really feel as though I'm getting the most out of it. To improve my ability to write good unit tests and become a TDD star I've decided to start completing some coding Kata's. A term I've picked up recently from the Uncle Bob's Clean Code series of books.

Kata is a Japanese word that is used for a concept used in Martial Arts. The term refers to a repetitive exercise or pattern of movements that is used as a training technique for Martial Arts.

So how does this apply to programming?

Well the terminology has taken off quite a bit and there are now multiple Coding Dojo sites around that will have a list of different Kata's that a programmer can pick up and start using as a exercise to improve their coding.

Personally I'm using the Kata's as an opportunity to test myself using techniques such as TDD or to practice picking up a new language without resorting to some of the boring example programs.

So the Kata I'm taking up is a recreate of the level generation for the Minesweeper game was on the early Windows Machines. You can take a look at the Kata here.

So the main things I'm trying to achieve from this are:

• Improve my Test Driven Development (TDD) skills
• Refresh myself using C#, in particular using Monogame as I haven't used it before.

The Monogame work will actually be an extension, I will first be completing the Kata as is and then extending it using Monogame to add some Visual appeal to it.

​Okay so that's it for now I'll let you know how I get on.

Cheers