Ladies and Gentlement, we have a UI


It’s not a functional UI. The game doesn’t play yet, but all UI elements are present and rendering. To be totally honest, I’m fairly certain that this entire UI could have been programmed by a seasoned code-jockey in like a day. It has taken me (according to my git), about 17 days.

I am a little concerned that I might be shooting myself in the foot somewhere around here by setting the thing up to render without any other functionality, like gameflow or states or anything of that nature. I have some skeleton code in place for the various game phases (modeled after the actual game phases: Planning, Execution, Reset), but none of it does anything yet and it is totally possible that as I start building in that functionality, that there will be inefficiencies.

C’est la vie, I suppose.

Anyway, as you can see, all UI elements are rendering. You can turn any bit of the UI off with a click of one of the three buttons on the bottom of the screen. The player element mats are individually switched (though this could become tedious, I’m trying to do things which will keep the screen from getting cluttered).

The thing I don’t know at this point is whether the rest of the process will be faster or slower than what I’ve done so far. I mean, all I have left is to actually program the game. The entire data structure that represents the game in its initial conditions is in place. The UI is rendering. Basically, I’ve set the game up on the table. Now it’s time to tell the computer how to actually play the game.

And I thought Twilight Imperium had an awful setup time.

Lasst die Spiele beginnen.

He shoots, he scores!


I don’t suppose that in the entire history of development diaries, there has ever been a more detailed one for such a tiny hobby project. I mean, I Kickstarted Shadowrun Returns and their dev diaries are often months apart. And they are a multi-million dollar project. As of this writing, there hasn’t been a peep from them since January.

Anyway, it’s not like people are reading this right now. This is something for me to preserve for posterity. Sort of a chronicle of my attempt to become a computer programmer and game designer in less than a year from scratch at the age of 31 (now 32). Call it a quest. From God. Or Shiva. Or Quetzalcoatl. Yeah, probably Quetzalcoatl.

Anyway, from the screenshot above, you can see that a scoreboard has been implemented, which reflects the variable starting point totals that you get with a random board setup. I think the colors look stupid at this point, but this isn’t about beauty, this is about functionality.

Also–and you can’t see this from the screenshot–the action board can now be dismissed at will by clicking the button on the bottom of the screen that looks like an eyeball. It’s actually a player pawn icon from the game board itself. The other two icons are currently placeholders for the two other dismissable/summonable HUD elements.

That’s where I’m at. Getting tedious, but still fun.

Ich bin die Dunkelheit, du bist die Sterne.

Ladies and Gentlemen, we have a HUD


Every time I click ‘run,’ there’s a very high chance that the program will throw some sort of exception. And, since I’m a n00b, there is a likelihood not statistically different from 100%, that the exception will be a nullPointerException. I don’t know why. Apparently, every time I declare a new variable, I have this annoying tendency to forget to initialize it. Considering I initialize all instance variables to null, and then just tell myself that I will initialize them in the constructor (or elsewhere), I just forget. In the case of this HUD, there are some arrays that are supposed to be, basically, null. At least for the time being. So I have a subroutine that generates sprites to render and if it doesn’t find anything there that needs rendering, it throws a nullPointerException. I fixed it though. The program no longer tries to generate sprites if nothing is there to be generated.

Anyway, what I wanted to say, was that, since I’m always expecting the program to crash on load, when it doesn’t and, indeed, works exactly how I want it to, my heart does this weird little leap and there is a sharp intake of breath. It’s pretty neat. I’m shocked and then elated. And then I remember there’s so much more work to do.

What you’re seeing here on the right is the worker-placement board. This is important since this is, technically, a worker-placement game. It’s the place where the players take turns choosing actions to perform each round. It looks complicated, but it isn’t. The super neat thing is that the action-board renders independently of the game board. I can move the game board around and the action board stays still. There are two or three more things to add to the UI and then I can start implementing more functionality. And little things like game rules.

Ich wünschte, du wärst schöner zu Tieren.



The way that Dominant Species calculates dominance is weird. If you look at the image, you will see that on the corners of each hex is an element. A food source. On each animal’s player board (not pictured here), there is a row of element tokens as well. An animal’s dominance score is calculated by looking at each element token on the player board and then counting the number of elements on the tile. Then you add it all up. This turned out to be a tricky thing to code. A bunch of nested for loops. I actually managed to find a few handy functions in the Java standard libraries that helped (the basic Java API is positively vast, if you’re not already aware).

Anyway, now I’m at the point where I need to start implementing some actual functionality. This is kind of a terrifying prospect for me. We will see how it goes over the next few days. If I have time.

Viel Glück

All the little creatures!


The data structure which will represent the game is, for the most part, complete. Of course, this is the mathematical model that represents the state of the game at any particular time. Specifically, the very beginning. The functions and interactivity are not there yet. All the user can do right now is open the game, start a new game, interact with an option panel to determine the number of players, their colors and respective animals, and then begin the game, after which the randomly generated world will appear.

Remember, this is just a board game, so there is not procedural generation here. The terrain tiles are drawn from a deck of tiles (in Computer Science terms, it’s a Stack!).

But this is huge for me. The damned thing is rendering. From here, my path is clear. Establish game states, demand input from the user, and start keeping score. The UI is proofed. I know how it will work. I can present the world to the user. It’s… really something special for me.

I have also added a new feature to my workflow on this project. Git. It’s…remarkable in many ways. I wanted to install a git repository here on this domain, but since this is a shared hosting plan (the cheapest possible plan available), and I would have to pay about 3 times as many dollars for a VPS, I cannot do it. I’m not sure I’m up to the task of running a VPS, to be completely honest. So I’m hosting the git repository over on assembla and it is working out just fine. They aren’t charging me any dollars and it has completely changed the way I work on this project.

I used to talk a lot of politics and even discuss some science on this blog. I haven’t in quite some time. That’s not because I’m not still interested in politics. I am. I just hate it right now. Maybe later this week I’ll expound on that a bit. But I might not.

Be advised: New link on the sidebar to Sean Froyd PhD, a colleague and friend who blogs way more than I do and often has interesting things to say. I’ve been involved in some of his projects in the past. And there’s also the possibility of joint work in the future. So he’s up there on the bogroll!

Ninja edit to the Bogroll: Notes from the Apocalypse. Some very interesting projects from my good friend Dr. Quaddle, a doctor after my own heart.

Überprüfen Sie sich, bevor Sie sich zu ruinieren.