Game Programming Patterns - State Management

This article was written in collaboration between myself, Daniel Ward, Finlay Brooker, Jimi Westerholm, and Igors Bogdanovs for an assignment. This is merely the hosting grounds!

All code examples are for C# with MonoGame. A .zip file is provided at the end of this article with a complete demonstration. The examples given in this article require a basic understanding of C#.

How do Typical Development Paradigms Fit?

When it comes to game development, it can be a bit harder for somebody who primarily focuses on application development to fully transfer their knowledge. With the inclusion of repeating logic centering around game loops, it may not come first nature to know how to write code that isn't so hopelessly bug-prone.

Consider a platformer. We implement a character that responds to user input. Push the jump button and she should jump...but remember that we need to handle only a single jump or we could spam the jump button and jump forever!

To deal with this, you could have a flag as an If statement that is unset when the player lands. But then we want to add more actions such as ducking and walking, and each time something gets added, we end up with total...

Hey, there's more! Click here to read the rest!

Ethical Considerations

incidentally, I took the sail image from Wikipedia Commons...hey, it's free-to-use!

It's just like Animal Crossing...what's the problem? But then we remember that this is an online game, so I'll have to turn my thinking around anyway...

Online Play

It's no secret that the bulk of the issues with online games can be attributed to players: moderation is subjective and good moderation is expensive; there will always be loopholes or uncooperative users, even if the game itself is completely morally sound, there will be at least 1 player to make it otherwise. It goes without saying that there needs to be a comprehensive and clear set of rules and a clear reporting system in-game.

The game isn't aimed at children, but being online, there will have to be some effort (or at the very least, a disclaimer) to prevent children from being able to create an account.

For some time while the game is in active development up until a stable release, I aim to collect usage statistics such as computational power, screen resolutions and time logged in through an opt-out scheme. I also plan to have an opt-in system that randomly takes screenshots of the game and uploads them to Imgur for...

Hey, there's more! Click here to read the rest!

Day 2: The Legend of the Usable UI Library

Finding the Solution to a Consistent Gripe

There are a lot of things to love with MonoGame (and by extension, C#). Interfacing is not one of them. By that, I mean, there is absolutely nothing that MonoGame provides to deal with it, you must make use of an interfacing library or roll your own code...except, there are actually very few interfacing libraries for C# and the ones that do exist are either needlessly complex or completely lacking (but odd design choices make them difficult to extend to your needs).

For some time, I found relative success with Squid, a blackbox library where you provide the rendering implementation and gave it inputs and it would take care of the logic, and it sortof worked, but I met 2 issues:

  1. The library wasn't actually very up-to-date and had some issues, and the developer behind it didn't seem to want to continue it
  2. Actually implementing UIs: all this time spent trying to come to an ideal solution meant that I had no real experience actually making a good game UI!

I thought hard about what I actually wanted in an interfacing library and came to the conclusion that I just wanted something that I could...

Hey, there's more! Click here to read the rest!

Day 1: Project Structure & Network Considerations

Let's Begin Development!

Like any old programming project, we have to start from actually...making a project! Now, because Unnamed will be an online game, we'll need more than one project. There are three projects in total:

  1. The client: effectively a view for taking data from the server and passing input back.
  2. The server: the thing that the game logic will actually run on, alongside storing player data and islands.
  3. The core: functionality that is shared between the client/server and can function interoperably so a client with different specifications could possibly be made at any time.

You can see that some stuff is done already: I write these things at the end of the day, you know!

The server is just a standard console application and the core will just be a library. The client itself is a DirectX MonoGame project for Windows. Both the client and server reference the core.

I've made it pretty clear in the past that I like using NodeJS, however, there are two reasons on why I've decided to not make both the client/server in NodeJS:

  1. I didn't want to spend too much time on database implementation; C# lets me just serialise an object and store it as a...
Hey, there's more! Click here to read the rest!