Boat Game

Actor System

I also wanted to build a more flexible actors system from what we had in our game projects. We currently use a base Actor class with one list of components for the update loop in our game projects. Here, I really wanted to apply some concepts I thought of during our game projects, but haven’t had the opportunity to implement until now:

• Separate lists for components that need to update and components that only hold data

  I noticed that we had a bunch of actors that only had data components in our game projects, but their components were still being iterated over in the update loop. Hundreds of static actors with data components (like meshes) that never needed to be updated were being iterated over every frame!

  After some template magic, I was able to create a system where components are split up into two lists. Components, which are included in the update loop, and containers which hold data. Both can be accessed via GetElement<T>(), but only components are iterated over in the update loop.

  This could be further improved by making separate lists for actors (like elements), but this was good enough for my use case.

• Central Actor management which allows for better control over the lifecycle of actors and easier access via ID

  Instead of having to manually keep track of actors in the “disposable” Game class, I decided to extend the Actor class with some static methods for creating, destroying, and getting actors by ID. The list is owned by the main Game object, while the Actor class manages it.

• Flag-style tags for components

  Instead of storing tags as a string list and keeping a separate manager for it, I wanted to have just an enum class with bit flags that can be set on actors. I think it’s pretty clever, and I’m especially proud of how this one turned out.

  c++

  Actor.hEngineusing ActorTagType = uint32_t;
   
  class Actor
  {
    public: click to expand 7 lines
   
    template<typename T>
    [[nodiscard]] bool HasFlags(const T someFlags) const
    {
      return (myFlags & static_cast<ActorTagType>(someFlags)) != 0;
    }
   
    private:
    ActorTagType myFlags;
  }
  ActorTags.hGame 
  enum class ActorTag : ActorTagType
  {
    None    = 0,
    Player  = 1 << 0,
    Local   = 1 << 1,
    Dock    = 1 << 2,
  };
   
  // Helpers for bitwise operations on ActorTag click to expand 9 lines
  constexpr ActorTagType operator|(const ActorTag aA, const ActorTag aB)
  {
    return static_cast<ActorTagType>(aA) | static_cast<ActorTagType>(aB);
  }
   
  constexpr ActorTagType operator|(const ActorTagType aA, const ActorTag aB)
  {
    return aA | static_cast<ActorTagType>(aB);
  }
   
  // The helpers allow us to do things like this:
  const bool isLocalPlayer = Actor::GetActor(id)->HasFlags(ActorTag::Player | ActorTag::Local);

  I would like to expand on this system in the future by making some kind of lookup feature where you can get all actors with certain tags.

Before building the actor system, I saw a video on YouTube by Pezzza’s Work called ”The magic container” where he talks about a vector alternative which keeps data contiguous in memory and allows for fast insertions and deletions while keeping consistent access via IDs. One downside is that it doesn’t keep things in order when iterating, but we should always assume that actors are in a random order anyway, so this isn’t really an issue. This container is most definitely overkill for this project, since we won’t have thousands of actors or performing a lot of insertions and deletions, but it sounded really interesting, so I implemented it.

Serializer

This time around, I really wanted to write a proper serializer, and I wanted to use compile-time reflection to make it as easy to use as possible. I discovered C++ concepts, and they are great for this kind of thing. They basically allow you to replace typename with a more specific requirement, which can be checked at compile time. I started off with two types: Trivial types and serializable types.

Trivial types was really exciting to implement, because it basically means “this thing can be directly copied with std::memcpy()”. I then set up serializable types, which checks if a type has Serialize() and Deserialize() methods that returns the right types.

These types can then be used to write a serializer by using template <TrivialType T> or template <SerializableType T>.

template <typename T>
concept TrivialType = std::is_trivially_copyable_v<T>;
 
template <typename T>
concept SerializableType = requires(const T& aPayload)
{
  { aPayload.Serialize() } -> std::convertible_to<std::vector<uint8_t>>;
};
 
template <typename T>
concept DeserializableType = requires(const std::vector<uint8_t>& aPayload)
{
  { T::Deserialize(aPayload) } -> std::same_as<T>;
};

Inputs

One of the main goals of this project was to send as little data as possible over the network. So for inputs, I was going to just use some flags in a byte, but where’s the fun in that? I decided to add controller support, which changes input data from a single byte of flags to two floats for the joystick axes. But two floats is 8 bytes, which is a lot for just input data. We don’t even get that much data from the controller itself!

After some thinking, I realized that I could use bit manipulation to pack the two floats into a single byte. You lose some precision, but it’s enough for boat inputs (0.13f per step).

Solution 1: Flagsenum class Input : uint8_t
{
  None      = 0,
  Forward   = 1 << 0,
  Backward  = 1 << 1,
  Left      = 1 << 2,
  Right     = 1 << 3,
};
 
// Diagonal input:
uint8_t currentInput = Input::Forward | Input::Left;
 
Solution 2: Packed Floats
Helper constants click to expand 3 lines
constexpr float InputPackFactor = 7.0f;
constexpr float InputUnpackFactor = 1.0f / InputPackFactor;
constexpr uint8_t InputNullValue = 119;
 
struct PackedInput
{
  PackedInput(const float aXInput, const float aYInput)
  {
    Input = static_cast<uint8_t>(QuantizeInput(aXInput) << 4 | QuantizeInput(aYInput));
  }
 
  [[nodiscard]] static uint8_t QuantizeInput(const float aValue)
  {
    const float remapped = aValue * InputPackFactor + InputPackFactor;
    const int rounded = static_cast<int>(remapped + 0.5f);
    return static_cast<uint8_t>(std::clamp(rounded, 0, static_cast<int>(InputPackFactor * 2.0f)));
  }
 
  [[nodiscard]] float GetXInputValue() const
  {
    return static_cast<float>(Input >> 4) * InputUnpackFactor - 1.0f;
  }
 
  [[nodiscard]] float GetYInputValue() const
  {
    return static_cast<float>(Input & 0x0F) * InputUnpackFactor - 1.0f;
  }
 
  uint8_t Input;
}
 
// Slight diagonal input:
uint8_t currentInput = PackedInput(0.5f, 0.5f).Input; // unpacks into (0.57f, 0.57f)

Server-authoritative simulation

Since I didn’t want to send a bunch of state data, I made the simulation server-authoritative, which means that the client really only sends events (like input changes) to the server, and both the client and the server run the same simulation. This comes with the added benefit of anti-cheat and client-side prediction!

There isn’t much more to say about this, but it ties nicely with the serializer and packed inputs I mentioned earlier. Here’s how the server handles client input messages:

case Net::MessageType::ClientInput:
{
  const PackedInput input = Net::DeserializePayload<PackedInput>(aMessage.Payload);
 
  const size_t socketClientIndex = std::distance(myClients.begin(), std::ranges::find(myClients, myRemoteEndpoint));
 
  const Net::PlayerId boatId = static_cast<Net::PlayerId>(socketClientIndex);
 
  if (const Actor* const actor = myWorld.GetActorByNetId(boatId))
  {
    MovementComponent* movementComponent = actor->GetElement<MovementComponent>();
    movementComponent->SetInput(input.GetXInputValue(), input.GetYInputValue());
    // Realization while writing this:
    // maybe `break` here actually,
    // since I don't think we should send inputs to clients if the server doesn't even have an actor for them.
  }
 
  const Net::ServerInput serverInput(boatId, input.Input);
 
  const std::vector<uint8_t> buffer = Net::Serialize({
    .Type = Net::MessageType::ServerInput,
    .Payload = Net::SerializePayload(serverInput)
    });
 
  NearbyBroadcast(boatId, buffer);
 
  break;
}

Grid-based culling

Now, to make sure we don’t send things like input events to clients that are on the other side of the world, I built a simple grid for our world (this will come in handy for procedural generation later on as well). Positions are hashed and used with an unordered map to keep track of which actors are in what grid cell.

I built a simple NearbyBroadcast() function that uses the grid to only send messages to clients that are within a range of the relevant actor. It uses a grid function to loop through nearby cells and gather clients that are within range, then the sockets are extracted from the server’s list using the actor IDs.

void Server::NearbyBroadcast(const Net::PlayerId aClientId, const std::vector<uint8_t>& aBuffer, const bool aExcludeSelf, const CellUnitWide anExtent)
{
	static std::vector<siv::ID> nearbyActors;
 
	const CellCoord clientCell = myWorld.GetNetActorCell(aClientId);
	myWorld.GetGrid().GetActorsInNeighborhood(clientCell, nearbyActors, anExtent);
 
	for (const siv::ID neighborActorId : nearbyActors)
	{
		const Net::PlayerId neighborId = myWorld.GetNetIdByActorId(neighborActorId);
 
		if (neighborId == Net::InvalidPlayer)
		{
			continue;
		}
 
		if (aExcludeSelf == true && neighborId == aClientId)
		{
			continue;
		}
 
		if (neighborId < myClients.size() && myClients[neighborId] != asio::ip::udp::endpoint())
		{
			SendBuffer(aBuffer, myClients[neighborId]);
		}
	}
}