Get Noticed 2017

Entries regarding the “Get Noticed” competition.

Get Noticed - post-mortem

As you could have noticed, my participation in the competition has ended a while ago by me not adding new posts on the blog. Unfortunately, it turned out that finding time for regularly developing a software project is something that is beyond me. My job and private life need some attention, too.

However, it doesn't mean that the project for the competition will get abandoned. Admittedly, I'm working on different things at the moment (which I'll also attempt to describe in the near future), but I'll definitely go back to Ktulu Online. When exacly? Time will tell.

It's a shame that it ended this way, but it happens in life. If the competition launches again next year, I'll definitely try again :)

Ktulu Online - progress (20.03.2017)

The project keeps going forward, although slowly. Using TDD has let me overcome my creative blockade and I managed to make good progress, especially taking into account the time I could spend on the code. The main improvements are in the area of the Manitou (server) and player (client) API, which has finally started taking shape - starting with writing the tests helped a lot in forming a pretty detailed vision.

Even though I still don't have much to show in the project, I'm hoping that something interesting will emerge this week. Coding hasn't felt this easy to me since a long time :)

That's pretty much it with regards to the progress. I'll write a bit more about the problems I have encountered when trying to define the API of the objects in the next entry - some of the problems have interesting aspects related to the properties of Rust. It might be an interesting read for people who still don't know much about this language :)

Ktulu Online - progress (2017-03-13)

In the end I haven't found time for writing yesterday, but the good news is that there is some progress in the project 🎉 I decided to implement the sequence of game "stages" first.

As I mentioned in the previous entries, there is a cycle of nights and days in Ktulu. Additionaly, various things happen during the night - characters wake up and use their abilities, whole fractions wake up as well. There is a predefined sequence of all these events and it should be reflected in the code.

There isn't much to say here, actually ;) As I mentioned before, I decided to start by writing a test, which was supposed to check whether a structure describing a moment in game goes correctly from "before the beginning" to "night 0, the Prostitute's turn". Then I implemented the structure itself, developed the test a bit, improved the code and so the current version slowly came to be. It contains two arrays (corresponding to the sequence of the zeroth night and of the other nights) and a method that mainly just iterates through these arrays for the activities during the night, passing briefly through days.

The code will probably need some further modifications (primarily in order to better represent the activities of the fractions during the night), but there is already something to build on. There is a good chance that the development will get easier now :)

TDD - Test Driven Development

I have done almost nothing related to the project last week - the main reason being, unfortunately, a lack of time and tiredness in the few free moments. This wasn't the only reason, though. I managed to start trying to write code a few times, but then I was realizing that although I have a general vision for the future of the project, I don't really know where to start and how to quickly get something executable and testable (and the possibility of testing the code is a huge motivator). I've decided to try to overcome my creative blockade using TDD - Test Driven Development.

The idea behind TDD is pretty simple - we start coding by writing tests. We add a test, which initially won't even compile, because the code that is supposed to be tested doesn't even exist yet. When we have the test, we write some proper code - just enough to get the test to pass. When we see green color in the results, we refactor the code (if there is a need for that) and go back to writing the next test.

This approach has numerous advantages:

  • We achieve a full or almost full test coverage of the code, because we never add code if we don't have a failing test.
  • It's easier to focus on defining a convenient API - a test is basically a piece of code that uses the API provided by the tested code, so when we write it, we already know whether the API is easy to use and we can modify it in case it's not.
  • A part of the above advantage is that we write cleaner code - the tested code has to have appropriate structure in order for testing to be possible at all, and it usually makes future modifications easier.
  • Finally, the thing I hope will help me - we immediately get some executable code that uses the library (if we are writing a library), so we can (or even must, actually) run it and see how the code is doing.

There are, of course, some disadvantages as well, the main one being for me that to a programmer not used to TDD (so one like me :p) such an approach isn't very intuitive and one has to be careful not to go back to writing the functional code first.

It's already late today, but tomorrow I should have some time to try this idea out and see how it works in practice. I also hope to have something for a next blog entry then. Until tomorrow, then!

The rules of Ktulu

While writing the last note, I realized that I have to describe the rules of Ktulu here. Even for Polish readers the only thing I could do was link to a document on an external website, which made little sense, as nobody would probably read it anyway. The readers that don't speak Polish were in an even worse situation, because they wouldn't be able to understand anything I've been writing about the game. This made me decide to write a short summary of the rules on this blog.

Before I start the explanation, I'll just mention that there are multiple versions of the rules. The one I'll be describing is the one I am the most familiar with, and I intend to implement it in this project.

Some background

The background to the game is as follows:

A long time ago, in North America, an alien spaceship had crashed. The Indians living there found the alien emitter and took it for a statue depicting their god - Ktulu. The Indians worshipped the statue, which was made of rare and precious metals. Then, the white people came to America, killed a majority of the Indians and took the statue from them. They settled a small city called Bum-bum City where the Indians had lived before. The statue was the city's pride, it attracted many tourists. However, some bandits decided to steal it and succeeded. The game begins on the night when the theft happened.

The basics


Ktulu Online - a draft of the architecture

With the first competition entry behind us, it's time to start developing the project - and what better to begin with, than a general draft of the architecture. Speaking from experience, although starting coding right away without any plans can lead to some working code quickly, it usually makes it much harder to develop it further. I wouldn't want to get stuck halfway through the project having to start from scratch, so I'll first think a bit about how to structure it well.

Firstly, the main purpose of the project is making it possible to play Ktulu over the internet - so we will be dealing with some kind of a network app. One of the players will start a server, and the others will connect to it as clients. It will probably be the most convenient to put both the server and the client into a single executable (so that the host won't have to start multiple programs), but it's just a detail. What's important is how to divide responsibility between the server and the clients.

[Update: Before further reading, I recommend checking out the rules of the game.]

The roles of the server and clients

In the original game we have the game master (called "Manitou"), who controls everything - he knows who is who, who has the statue (unlike in Mafia, where one cares only about killing all the opponents, in Ktulu the majority of goals revolves around "the statue", being initially in the possession of Bandits), he tells the players to open or close their eyes and counts the votes during votings. The server will play this role - it will remember the full state of the game and issue appropriate commands to the clients. The only thing the clients will do is telling the server about the decisions made by the players.


Get Noticed 2017 - start!

I decided to take part in a competition called "Get Noticed" (in Polish "Daj Się Poznać") this year and it starts today. So, as some introduction:

What is it about?

In short, the competition is about developing a software project for 10 weeks and writing about it on a blog. I've been meaning to breathe some life into this blog for quite some time now, but I've always lacked motivation. When I heard about this competition, I thought that it might be something that will let me overcome my laziness and finally give me something to write about. I have some projects still waiting for their turn, so I chose one of them and decided to register. Let's get to work, then!

The project

My first idea for a project for the competition was to finally move the procedural universe generator forward a bit (I've written about it in a few entries under the name "The Universe Project"). I was worried, though, that I won't be able to create anything meaningful in just 10 weeks. That's when I turned my attention towards one of the other projects that I had started in the past, but never finished - "Ktulu Online".