It’s been a few days since last post, in this one, I want to talk about basic GUI implementation in the game, how to create a very simple addon system to support flexible extensions.

After we’ve got the very limited version of the game running (we can load an atlas and show sprites with it after last post), next steps will be adding more features, at this points, it’s better to have a way to communicate with the running game easily. For example, when I want to tweak some parameters in game, it’s not very efficient to repeatedly do these steps: change it in code, recompile, rerun to find the best value, instead I prefer to run the game, and use some way to change the parameters while the game is still running.

There are different ways to support this kind of communication:

• Provide some REPL (read, evaluate, print, loop) for running game, this is a very powerful way, but need quite some logic to support, especially for a compiled language like F#, many game engine will use some dynamic language for scripting purpose.
• Special development environment to provide extra features, e.g. when you run your game in Unity Editor, you can see many runtime information with editor UI, and can adjust many values with built-in inspector, 3rd party tools, or your editor extensions.
• In game GUI, menu bar, tool bar, or any UI you created for in game control purpose

In last post, we did load an atlas and show a simple sprite from it, this one is mainly on refactoring, extract common logic for all games, which can be reused later.

Game.TexturePacker

Moved the texture packer library from Tank.Content here.

Game.Engine

Move game abstraction here, it’s very simple now, the logic is same from last post, just create base class, and ways for customization.

Was down with a really bad flu last week, can’t work on anything at all, feeling much better today.

What to Cover in this Post

We’ve setup the environment, got these command line tools to be running: dotnet, paket, fake, now we are gonna use these tools to start development.

Since this is a from scratch tutorial, I’ll try to explain how I create the game itself and the game engine underneath, also will talk about some reasons behind the way I chose.

This post will focus on the basic skeleton of the game, How I organize the codes and assets, use the libaries to create a minimal runnable game that can load an image and show it on the screen.

In this post, I’ll explain how to setup development environment for this tutorial, you should be able to build and run the demo after following the steps.

Platform Components

.NET Core

.NET Core is the free, cross-platform, open source .NET platform, which is supported on Linux, macOS, Windows, you need the current version (v2.2.101) to run the tutorial codes.

• Official web site: https://dotnet.microsoft.com/
• Source code: https://github.com/dotnet

Reasons to choose .NET Core:

Before start writing individual posts, I’d like to talk about some general ideas about this tutorial.

Target Audience (Who)

• Familiar with at least one programming language, and don’t mind to try a new one (if you don’t know F# before).
• Interested in game development, want to create some simple games for fun.
• Have some time to spare, to really learn something like writing a game from scratch, plan to spend a lot time on it, it’s really fun to me, but also quite hard at first.

Planned Contents (What)

• I will write serious of posts about how to create this tank game from scratch, talking about what tasks need to be done, how to get each step forward, readers with no experiences should be able to follow these posts, and hopefully learn enough to create their own game.
• Along the way, I may also write some posts on specific topics, which may not directly related to current steps, but related to game development in general.

Have been working on game development for a few years now, making game is indeed quite fun, it shares much with other kind of software development, while it also has its uniqueness. Always wanted to write more on it, though not really have good idea about how to start.

I’ve been working with a couple of game engines, mostly Unity3D, IwGame on Marmalade, Cocos2D, Phaser, created some own frameworks, did experiment with a very simple game engine in Elm as well. Most of them were designed in a similar way, provide similar components and tools. As game developers, we usually don’t need to dig much in the game engine itself, but we should have a rather clear understanding about its structure so we can work on it efficiently.

I’ve decided to write some tutorials on game development, a very basic one, in my mind, it’s mostly for developers without much experiences with game development, but curious in it. I’ll try to share some of my understandings with game development, explain core components of game engine.

I’ve been doing quite some F# coding lately, which is really nice, plan to write more about F# later, here I’m gonna talk about how to build DotNet projects with Fake.

I’ve put common logic as libraries, then can share them easily across multiple projects, so I need to create NuGet packages. I’ve already created more than a dozen individual libraries, it’s clear that I need an automated process to manage them, or it’s very tedious to keep proper version of libraries in each project.

I’ve did some small work around Fake to make such process, which works quite nicely for me, I plan to write two articles on this, this one will explain the basic structure, and how I use it to manage multiple projects easily, the next one will talk about how to create NuGet package, and how to use a hacky way to do local development easily.

In the last few months, I’ve created an actor frameworks in which each actors is in functional reactive way in F#.

Basically each actor is created with the Elm Architecture, everything is strong typed, can be run on Dot Net Core, or in browser with javascript generated by Fable, also can be run on mobile or desktop devices with Xamarin or Dot Net.

It costed me much time and efforts to get it to current state, learned a lot along the way, will try to write something before I forget the details.

Back in 2013, I was working on my first Unity3d game, it’s a simplified RTS game for tablets, the first version took us (3 developers including me) about 2 years to hit the iOS app store, did learned quite some lessons during the process, wanted to write some blogs for a long time, though never really did.

We released the game at 2015, but the game wasn’t successful commercially, and our small start-up company run out of money. I was still making games after that, planned to reuse some lib codes created along the way. Then I realised that the quality of these libs can be improved much (due to time pressure, and lack of experiences)

The most useful module was a custom data context class I wroted, it was rather simple, just an object with a bunch of properties, and event channels, both can be watched, e.g. when a property been set to a new value, all listeners will be triggered by a callback. On top of these properties and channels, I create a simple layer to interact with the data context via requests, such as get or set or fire, then on top of that, I create a simple text parser so diffrent section in config files can trigger different action in the system, e.g.

"selection" : {
    "_": [
        "sprite/destroy?key=selection",
        "sprite/do?key=selection&prefab=squads.effect_sprite#color=1,1,1,0&sprite=flash&zoom=1.0&play.flash&done.flash=destroy",
    ]
},

Why bother with a preprocessor?

I was quite busy working on our RTS game on iPad for almost a year, we are quite close to our first public version now. It’s developed with Unity3d, using uLink as the network library. Created a quite nice data context system on Unity3d, so non-developers can update pure visual part of the system without developers’ help, will write some entries on it later when got time.

SILP is a very small side project come from the process working on it. It’s a simple language-agnostic preprocessor.

There are many discussions about whether a programming language should include preprocessor, most people seems agree that preprocessor is too error-prune and sacrifice readability too badly, and there should be seldom cases that an alternative can’t be find to replace the preprocessor usage.

I agree that in most cases we don’t need preprocessor though there are several cases that I would like to have a preprocessor in my tool set for cleaner codes or can remove some trivial typing. Here are 2 examples: