Feb 20, 2018
As I mentioned in my last post, I recently started at Red Badger, and I now have an official employee profile page! Go check it out at https://red-badger.com/people/david-basalla/!
Also, I came across a couple of my blog posts from my time at GOV.UK. Unfortunately they are not the most exciting posts, as they’re just detailing some production incidents, but hey, any publicity is good publicity! :D
PS: Writing these updates is so much easier with the new Contentful -> CirceCI workflow, very pleased with it!
Feb 11, 2018
Feb 5, 2018
We’re using Contentful to manage web content for a project at work so I thought I would give it a go to combine it with Jekyll to maintain this website. It was an interesting learning experience, diving deeper into CircleCI and deployment logistics.
Before this change, I would add any new content as code in my Jekyll repository, build the site and then manually copy everything to my host server via ftp. Now I can create or update blog posts in the Contentful web UI and the changes are automatically pushed to my host server via the Contentful webhooks and automated build scripts in CircleCI. I’m planning to open up the repo on Github soon.
Jan 18, 2018
In an attempt to be a bit more professional about this website, it’s now being deployed via CircleCI 🎉 I’ve been looking at it as part of my new job at Red Badger, more on that hopefully soon…
I mostly just followed the Jekyll and CircleCI docs. The actual deployment to the server is done with the
net/ftpruby library, since using the
ftpcommand line tool didn’t allow for conveniently copying a directory tree structure.
Aug 15, 2017
So I dusted off my MatchThree game the other day, after roughly 8 months of not looking at it. I had left it in a pretty wonky state. The last thing I did was to turn it into a puzzle/RPG hybrid a fantasy twist, where matching gems would harm the other player.
However I quickly realised that what I had programmed just wasn’t fun. In part that was because my game concept wasn’t very well fleshed out. However I also found that it was difficult to iterate on, and various bugs and glitches made the core game play mechanic not very enjoyable. I think part of the fun of a game like Candy Crush is the really solid underlying game engine, which just feels satisfying when you match gems. Part of that may be down to the art and graphics, but obviously you need solid game mechanics underpinning everything. With my game prototype it felt like I was building on an unstable foundation. So as a first step when picking this back up, I ripped out all that code and went back to basics!
My focus was on making the matching system work more reliably and smoothly. After reading through the code (that I wrote), I was amazed how confusing and hard it was to follow. After several attempts to fix some minor bugs, I decided a more drastic approach was needed.
Having worked on Rails now for a couple of years, I was curious whether I could apply a more rigorous architectural style to the code (over the jumbled mix of objects that I had). Doing some research, I found an excellent resource on technical Game Design by Robert Nystrom. However none seemed to fit my particular problem. A particular issue that interested me was the separation of game state and graphical display. Apparently that’s not as straightforward in games, since the loop is much tighter as compared to web apps which utilise the MVC pattern to separate out business logic, application logic and rendering of the views.
I am currently reading about Domain Driven Design, which puts emphasis on having a clear domain model with strict divisions between business logic and other application logic. It made me think about the classes that I currently had, and I realised that some of my classes were just doing too much. For example my
Boardclass was a giant object that handled all the complexity of gem matching and refilling the board. So I started splitting obvious related bits of code into separate classes (for example a MatchingShapeFinder class for determining whether there was any match on the board, as well as
MatchedGemCounterclasses). Following this strategy made it much easier to reveal where the problems were in the code, and to focus responsibility on individual objects, rather than lumping it all in class which became really hard to parse. I’m still not 100% happy with the class that I’ve got, but abstract concepts like a
GemManipulatorare harder to pin down than concrete concepts such as
Board, etc. Check out the code here if you’re interested in this sort of stuff…
What even is fun and what is next?
I’m fairly happy with the game engine in its current state now, in that it feels more stable and better structured. The next phase will now probably be to turn it into an actual game. From my brief experiment with the puzzle/RPG hybrid it strikes me that making something that’s actually fun to play might be quite hard! I’ll probably have to take another good look at the current addictive puzzle games, such as CandyCrush and Puzzle Quest. I suspect part of it is the sense of a challenge as well as progression, which might be fun things to implement.
Finally, here’s a link to the current game.