So I promised I would talk about patterns and traits. When I wrote about the concepts of the Controller and the RuleSet, I already hinted at using the Strategy pattern. I was right, because that turned out to be exactly what I needed. And I was wrong, because the classical Strategy pattern is an ill match for Scala.
In this post I will explain how I implemented the Strategy pattern using Scala traits, and how this turned out to be an unsatisfying approach.
In my previous post, I explained some concepts for improving my city builder simulations. By now, all code has been implemented, reimplemented, and reimplemented again. This has resulted in a codebase which, in my humble opinion, resembles real Scala. As a bonus, it also does what I wanted it to do.
I will talk about collections, traits, design patterns, and having fun with Scala. This post is dedicated to Scala collections; the traits and design patterns will be discussed in the next post.
So far, I have created a number of actors that together make up a simple, non-exciting simulation. However, controlling these actors is still done in an ad-hoc fashion.
In the next couple of posts, I will extend the simulation with supporting objects that make it easier to create and run different kinds of simulations. This post is dedicated to the theory behind these next steps.
In this post, I will introduce Actor states, the Controller, Rule sets and Settings.
In this post I was planning to add Citizens to my simulation. I did, and it turned out to be as exciting as watching termites mate.
So instead, in this post I will add Citizens to my simulation, clean up my codebase, factor out all duplicate code using Traits and refactor the act/loop/react by introducing partial functions.
In my previous post, I created a specification for my Harvesters. Now it's time to actually implement them and let them conform to that spec.
This post is mostly about messaging between actors, the different choices in handling those messages, and the impact these choices have on the concurrency of your system.
In my previous post, I introduced the Producer actor. Now it's time to introduce the Harvester.
In this post I will define the specifications of the Harvester and show how to test the concurrency of the eventual implementation.
In order to do this, I will also dive into some of the cooler features of Scala, especially foreach, map, list-comprehensions and futures.
In my previous post, I showed how the Producer worked by adding some example code to my Simulation object. This might be very suitable for small projects, but in the long run I always prefer to have unit tests. In this post I will show how I added Scala unit tests to my project.
Now that the project has been set up, it's time to start creating the first steps in our simulation.
Every city simulation game I've played begins the same: getting workers to obtain raw materials. So let's create a text-only simulation that does just that.
This post is about Scala syntax, Scala Actors, Scala messages, and examples of pattern matching.
In this post, I will explain how I set up my first program, allowing me to create and run an extremely simple Scala program in my favorite IDE using Maven.
I'm currently in the process of learning Scala, and decided to use this blog to share my learning curve with the rest of the world.
I am going to create a large-scale simulation as experienced in the games Ceasar, Settlers or CivCity. I do not pretend this will result in a full-blown game, but it will contain many of the aspects found in those games.
For those not knowing those games, the concept is simple: you, the player, are expected to turn a piece of land into a thriving city. This is done by attracting citizens, having them harvest food and resources, having them process those resources into essential and/or luxury goods, and not going broke in the process.
I chose this goal for two reasons: first, one of the selling points of Scala is the support for event-based Actors and the possibility to run thousands of them in a small JVM. To me, this sounds exciting. Secondly, creating simulations is just a lot of fun.
I am not planning to write a tutorial for absolute beginners; the best way to understand each step I make is to be me. As it turns out, being me is a not a transferable skill, so let's assume the following requisites:
When writing the blog entries, I will assume the following knowledge:
Furthermore, I will assume the reader has the following software installed:
