January, 2021 | Learn C Games Programming Blog

Month: January 2021

Santa Paravia en Fiumaccio

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

I could understand you thinking “have I flipped my lid?”. What kind of a title is “Santa Paravia en Fiumaccio”? It’s actually the name of an old game written in C. A much more sophisticated Hammurabi if that makes sense. You can read about it here on Wikipedia.

I was digging around the web looking for games in C with source code and came across a reference to it. I found it on archive.org though that version is a bit bashed up, All the < and > are displayed as their HTML equivalents – < and > so you need to do copy and replace on that. Plus a few of them have spaces between the & and the lt/gt!

That was about a thousand lines long. However I thought, why not do a search on the web specifically for it and found a cleaned up and slightly longer version on GitHub by DNSGeek. If you dig into his repository list you’ll see he’s also done a Python port with graphics! It also includes the instructions for playing it in a PDF.

If you try and compile the C source code, you’ll find that a curses library is missing. I’m not sure that it actually needs it so I commented out the include line and it didn’t seem to mind. Under Visual Studio, it complains because of the strcpy functions that should be strcpy_s.

So I’ll fix the little things and see how ityplays. You just have to love a game that has functions with names like SerfsDecomposing() and SerfsProcreating()!

Other simple game ideas

Posted on January 30, 2021January 30, 2021 by David

Dice — Image by Ana Carolina Franco from Pixabay

My recent blog about the L-Game reminded me of other simple games and I did a bit of digging on the web. If you are ever looking for ideas for games or game mechanics, take a look at the Wikipedia page on abstract strategy games.

It reminds me of my teenage years when I used to get Games & Puzzles magazine. Here’s an interesting list of subjects from there, many with links. I wrote my first game for my O-Level (you were allowed to do games in those days) based on game I saw in Games & Puzzles magazine. It was a tennis game using 2 dice. Here’s the game play details.

The tennis court is split into 12 segments numbered 1-12 with the net between segments 6 and 7. Bit Like this:

   Opponent
-----------
12        1
11        2
10        3
9         4
8         5
7         6
--- Net ----
6         7
5         8
4         9
3        10
2        11
1        12
-----------
   You

The ball starts with you. To serve, you roll two dice and move the ball by the total. So if you get less than 7 then the serve failed as the ball doesn’t cross the net, otherwise it moves the ball by that amount so it ends in segments 7-12.

If for example you rolled 9 then the ball would be in segment 9 which from your opponents point of view is 4. The opponent can now roll either one or two dice and move the ball by the amount. In this case I’d choose one dice as a roll of 1 or 2 would fall short but 3-6 would get it over the net. If you rolled two dice then 9 or above would take the ball out of the court. There’s no real skill except figuring out whether 1 or 2 dice maximises the odds of the ball staying in play.

It’s a fun little game and easy to code in C or any language.

BBC Basic with SDL

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

Back in my games programming days I never had a BBC micro, though I knew several people who did including one bloke who let people run their ROMs on his micro. Sneakily it made a copy of the ROM contents and saved it to disk. I remember wasting a lot of hours playing Elite on a Beeb back in 1984.

BBC BASIC for SDL 2.0 is a cross-platform implementation of the BBC BASIC programming language for Windows, Linux (x86), MacOS, Raspbian (Raspberry Pi), Android, iOS and Emscripten / WebAssembly by developer R.T. Russell. If you ever fancied writing BASIC programs and running them on a BBC Micro then you now can with this.

It is programmed in C (and I’ve added a link into the C code library) and you’ll find the multi-platform source on GitHub. A visit to the Complete BBC Games archive might also be in order!

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!