Learn C Games Programming

An intriguing Matchbox based learning machine

Posted on January 28, 2021January 26, 2021 by David

I mentioned Menace the other day. This was a “Learning Machine” implemented entirely with Matchboxes. This was back in the 1960s. The idea is that a simple game like noughts and crosses (aka Tic-tac-toe) can be played by a crude form of learning computer.

You need enough matchboxes for every possible position in the game. That’s 304 matchboxes and you start but putting four coloured beads into each box for every possible turn. These represent the possible moves. To make a move, you pick the box corresponding to the position shake it and draw a bead out and play that move.

And so on until the game is finished. Then if Menace (as it was called- Machine Educable Noughts And Crosses Engine) won, you add three beads to each winning Matchbox, put one back in if its a draw and remove all of that colour if it lost. Gradually it becomes better at winning.

There’s a far detailed write up here. It’s an intriguing technique though possibly not the easiest to apply as it requires you to have a matchbox for every position in a game. Fine with noughts and crosses but impossible with chess. Instead of Matchboxes, it could be done way faster in software.

It needs games with determinate moves and not too many, though I suppose with RAM in modern PCs, a few million moves would be manageable. One possibility would be the L game. I’ve never heard of anyone doing that, and it would make for an interesting project. I’ll add it to my list of future projects. Now I wonder how many possible moves there are in a L- Game? It’s made more complex because you can optionally move one of the single pieces as well as the L-Shape which can be rotated and flipped and it’s a 4 x 4 board not 3 x 3 as in noughts and crosses. .

Thinking about Slay tutorial 7- Game AI

Posted on January 27, 2021January 25, 2021 by David

Having just published Slay Tutorial three, making the Onslaught game play well as a computer opponent(well up to 8 of them) has been weighing on my mind. I have played the original Slay perhaps a couple of thousand times, so I’m reasonably familiar with strategy.

There’s almost 500 games on the Slay game chooser screen shown with four different sizes of islands; the four boxes. Usually by the time I’ve played through all games here (probably taking 18 months to two years) , I can start again and have forgotten what it was like. Plus I think it randomises the starting positions so you get a lot of replay value.

In the first Slay Tutorial I published a map of the tutorials and so far am sticking to it. Tutorial seven is the one for the game AI and its on my mind. I play all the Slay games at the same top intelligence level and even it sometimes makes stupid mistakes like leaving an area vulnerable to splitting and losing all units due to starvation.

The main aim of any player is to expand their territory at the expense of other players. Joining territories can be one tactic as its lets you support the bigger units. The 2 point unit is a Peasant then there’s Spearmen (6 points) , Knights (18 point) and Baron (54 points). Getting a Knight early on gives you a big advantage as it can defeat castles and too often I’ve seen a territory with one or two spearmen get trapped by castles and destroyed in a few turns.

Likewise putting a castle down early on can secure a territory for a while. Or if you have a larger area, a couple of castles can shield your flanks so you can focus yoyr troops against one enemy and not worry about other players moving in.

Self Playing

In Slay once you are eliminated the games plays through until one player beats everyone else. But self-playing can also be a useful way to have computer players learn. One possibility is to try and implement a “matchbox” AI. This was done with Tic-Tac-Toe (noughts and crosses for us Brits) with Menace, Now it may be that Onslaught is too complex to implement that but there’s a lot of RAM available, so if I can limit the number of setups that it recognises then maybe?

Anyway there’s a fair bit of time and Tutorials 4-6 to do before I get to Tutorial seven.

PS

If you move the mouse over the About Me, you’ll see a link to a page that has short cut links to all blog posts along with the title of each. It’s a quicker way of navigating.

Thinking about my Inselkampf reimagination

Posted on January 26, 2021February 16, 2021 by David

Database schema — Image by mcmurryjulie from Pixabay

In an earlier post on web games, I mentioned an old multi-player web game that I used to play and which was discontinued in 2014. I have a rough design for this and am busy learning Blazor as I believe that would be the best technology to use. It lets you run C# programs in the browser, no JavaScript needed. This simplifies input with verification and also updating the web page without having to do lots of messy Ajax stuff.

But being a web game there is a web server involved and the big question is what sort of data architecture to use? The most obvious one is probably using a relational database behind the scenes. That way each game (with up to 1,000 players) is held in a single database in about 12 tables. I’ll probably use MariaDB.

I did consider doing everything in RAM but its a terrible abuse of a web server and rather restricts it to running one or two games. Pulling stuff out of a database is much less strain on the system than having a few hundred MB of RAM tied up per game. A web server can support multiple games which helps keep the costs down.

Also with a web game, it raises the possibility of caching certain static files on disk to improve throughput. This blog uses WordPress but has a cache so when you view a page, it’s almost certainly been pre-generated rather than built on the fly.

An example of a web game that I admire is Torn.com.

Slay tutorial three published

Posted on January 25, 2021January 25, 2021 by David

This is a typical map produced by the generator. One large continent with coloured hexagons from 8 players arranged in clumps and individual hexes. It’s not quite perfect- in the top right corner there is a single blue hex but its not bad.

I’ve just published Slay tutorial three with the source code in the file onslaught2.zip on GitHub. I’m quite pleased with the map generator which is based on the one I devised for Empire and which I covered in an earlier blog post. It does a lot and quick enough that when you press the N key it can generate a new map in a fraction of a second. C + SDL2 is very fast even when drawing nearly a thousand hexagons every frame. It’s mostly in just one file (for now) with timing code and a data file for generating maps in separate files. The main file is just over 600 lines long.

As it needed a fair bit of debugging, I made it cross-compile in Windows or Linux (and probably Mac OS but that’s not tested). You can load the solution file in Windows with Visual Studio or put the files into a Folder with Visual Studio Code on Linux. Included in the zip file is the assets folder which has all the individual hex graphics and a .vscode folder with JSO files for doing the build with clang on Linux. I’ve compiled it and run on both Windows and Linux. The SDL2 Window is 1300 x 768 pixels wide.

A newish game platform

Posted on January 24, 2021January 23, 2021 by David

Web games have been largely Flash in the past though that took a nosedive in the ‘tens (2010 onwards) and Flash is officially no more as of 2021. The spirit lives on in JavaScript games and there are innumerable games in JavaScript. That said, I’ve never been that keen on JavaScript. I talked about Web games in a post back in December and particularly that I saw Blazor as a possible game platform.

Today though I discovered Awesome Blazor on GitHub and it includes 18 Blazor web games including a multiplayer dungeon which is shown (I think it looks like a bit Pacmanish personally) . Most of these are ASP .NET Core 3.1 (which became .NET 5 late last year).

Some games will use wasm (Web Assembly) while other use C# in a terminal. As a simple proof of concept but nicely done, have a look at the virtual train set online. You can lay track and then run one or more trains along it. Impressive as a demonstration of what you can do with C# and Blazor in a browser.

A look at a Raspberry Pi Pico

Posted on January 23, 2021January 23, 2021 by David

As you probably know I do like my Raspberry Pi. But the RPi Pico is a different kettle of fish. I’m only mentioning it here because it is programmable in C/C++ and some may find it a less say overwhelming place to learn C than say a traditional Raspberry Pi.

What’s different between a Pico and a Pi 4B? A Pico uses a microcontroller- basically a CPU with built in RAM, bit of flash RAM, real time clock. RAM is tiny compared to any Pi. Just 264 KB (That’s still much more RAM than my CBM Vic-20 in 1981 with 3.5 KB of RAM!) and 2MB of Flash RAM. The CPU, an ARM CPU designed in the UK runs at clock speeds up to 133 MHZ. A Pi 4B runs at 1.5 GB, over 11x faster.

The biggest difference is that a Raspberry Pi runs any operating system you want. Microcontrollers are different. To run a program on a Pico you have to program it into Flash RAM first. You can do this with drag and drop. See here for C/C++. The Pico is an embedded system. RAM is used for data, stack etc but not the program which runs out of Flash RAM.

But if you like hardware then this is an excellent place to get started. You get all these (see here for Specifications).

26 × multi-function GPIO pins
2 × SPI, 2 × I2C, 2 × UART, 3 × 12-bit ADC, 16 × controllable PWM channels (PWM I’m guessing is pulse-width modulation).
Accurate clock and timer on-chip
Temperature sensor
Accelerated floating-point libraries on-chip
8 × Programmable I/O (PIO) state machines for custom peripheral support

So what about games? Not really. Or at best very simple games using the single LED. No, this is about learning C (or C++ or even- shock – Python) and interfacing hardware. You might for example put one of these inside a drone to provide control software.

So someone wanted to know how to go about creating a dating sim

Posted on January 22, 2021January 20, 2021 by David

This was a question in the reddit gamedev subreddit.

Here’s my answer. “Think about how you might make it work as a roleplaying game. You’d have a set of characteristics- age, cuteness, physical attraction, charisma, boldness etc. Have your characters roll 3 6 sided dice to get these. Then you can work out an easy scoring system by comparing similar characteristics.

So once you have a basic matching algorithm, your game has to let the player find potential dates. In the gym, supermarket, dating site, college etc. Perhaps you get an initial idea about someone you meet and then you get multiple dialogs where you try and figure out how to ask them out. Choose the wrong phrase (e.g. “Do you spit or swallow?” ) and you won’t see them for dust. Maybe if the person you are asking out has a large personality they’ll laugh at your humour and say yes.

Then you have to decide what wins the game. Getting to first base, 2nd, breakfast? Or you get a low score when they tell you they’ve decided to become a nun because of you…

How you implement it is entirely up to you? Things like renpy, or maybe you’ll do the whole thing. For the possible target market I think you might have to make it graphical. Perhaps a comic-book type approach? That way you don’t need too many drawn backgrounds.”

This is the kind of thing you might use Renpy for. What is Ren’py? Ren’Py is a visual novel engine used by thousands of creators around the world that helps you use words, images, and sounds to tell interactive stories on computers and mobile devices. These can be both visual novels and life simulation games.

I got the screenshot from Wikipedia. Talk about breaking the fourth wall! And yes Ren’py has an irritating apostrophe in the middle!

Thoughts about the Onslaught map generator

Posted on January 21, 2021January 17, 2021 by David

Map — Image by DarkmoonArt_de from Pixabay

With the 2nd Tutorial under my belt, I’ve ben thinking about the map generator which is the subject of the third tutorial. I suspect it will be based on the Empire map generator which you can read about from an earlier blog post.

The difference is that there will only be one continent not several and it has to occupy between maybe 50% and 80% of the specified map size. These are 20 across by 15 deep (small), 30 x 20 across (medium) and 40 across x 30 deep (large). On a 1024 x 768 Window, I managed to fill it with 31 across by 28 deep, so I’ll need a larger playing Window. The current one is 1024 x 768.

The Empire generator works by first scattering a number of land and sea points in an empty grid then growing layers around each point in the empty cells, stopping when a non-empty cell is found. I’ll need to modify it so that the starting land points are near enough to form a single continent when grown and reject any map that has 2 or more continents.

I also put Onslaught on my Raspberry Pi and found that it runs a lot slower than on the Hyper-V Ubuntu. I can only put this down to the number of hexagons. a screenful at 1024 x 768 is 31 x 28 hexagons and that requires 868 blits ( each a call to SDL_RenderCopy). Each blit copies 1088 bytes in VRAM. That’s almost 1 MB of VRAM being copied in itself each frame which is not that much for a GPU but there’s probably some overhead for each blit and I imagine that could be the performance killer.

Kilo- a thousand lines text editor in C

Posted on January 20, 2021January 17, 2021 by David

Developed by Salvatore Sanfilippo aka antirez and licensed under the BSD 2 licence, kilo is a simple text editor in one file.

If you are learning C and want to see how to write a utility, this might be a good example to follow. Warning though he does use pointers so make sure you’ve learnt them first!

I had a stab at writing one quite a few years ago but it wasn’t very good. I have a suspicion that writing a good text editor depends upon you first creating a good implementation of the text storage. Solve that and it’s downhill for the rest.

I’ve added this to my curated library of C code, on the C Code link on the top menu.

Onslaught (aka Slay on Linux) tutorial two published

Posted on January 19, 2021January 17, 2021 by David

I’m quite pleased with this. It took about six hours in total to create including the time to create the graphics. Running in Hyper-V under Ubuntu 20.04, it draws a screenful of graphics in about 65 microseconds.

I took the hexagon drawing code from the AboutEmpire.zip code on GitHub and modernised it for SDL2. The Empire code uses Surfaces from SDL1 while this uses Textures from SDL2.

There are nine hexagons with all but the dark one having an internal border.

I think the orange and salmon hex look a bit too close, so I’ll change one of them.

The tutorial goes into a bit more depth. about the program (which is just over 200 lines long) and can be found on GitHub in the file Onslaught1.zip.