This F# Area property also illustrates something powerful gained: pattern matching on a discriminated union. While logic with pattern matching is very powerful, F# discriminated unions have another use, as regular enumerations on a finite set.

Games require human input. Games that do not require human input are simulations.

At the heart of every game is a way of acquiring the player’s input. So most games have the concept of a game loop. A game loop keeps the game running by continuously checking for user input, drawing to the screen, and updating state internally.

From there I created “component systems” which is fancy terminology for wrapping a dictionary: a way for me to access components by their EntityId efficiently. Do note that the coloring on the following code snippet is thrown off by the single quote in the generic type ‘T

This inherits from ComponentSystem, and tacks on some extra functionality. I can now easily check for entities that are positioned inside a rectangle. A good spatial system would do that efficiently except I’m more concerned with correctness right now.

This has side effects, the list of components is constantly changing with removal and insertions. But the side effects are limited in that I’m never updating the component’s value directly. the only way for it to be updated, is for that entire component associated with that Entity to be replaced.

Even with this compromise, record immutability has some fantastic possibilities. I can pass those component records in messages with wild abandon. Indeed, I’ve been doing so and that is next week’s topic.

Entities and components are linked together only by the entity’s ID. Certainly a far departure from Object-Oriented convention. But does this remind you of anything?

Relational databases are fond of using an integer as a primary key to make nice foreign key. So the entity and components above could look like this
This has a couple benefits:

Composition of behavior through whether an entity has a component(s) or not.

No longer have to maintain giant object hierarchies

Systems can operate on isolated information. Example: Field-of-view, collision detection, and spatial operations in general should only need to operate on a collection of PositionComponents. They don’t care what other components an entity may have.

Serialization is much easier. This is important when loading or saving game state, sending game state over network, and logging.

There are other benefits as well, but those will become apparent over time and examples. Of course there are drawbacks too, but those will become apparent with time as well.

Boom! That wasn’t so bad. We can just override whatever behavior whenever we want.

Let’s add a few more monsters to make this game really unique:

class PoisonIvy: DungeonMonster
{publicoverridevoid Move(Direction direction)...//Does not allow move}class Mouse: DungeonMonster
{//Shouldn't be able to attack. Just moves around and stuff. }

Now this is getting to be a problem. PoisonIvy also can’t move. So I have the option of either copy-pasting code from EvilAppleThrowingTree’s Move function into PoisonIvy’s Move function which is stupid, or I could add another layer to the heirarchy.

I could keep going on and adding more monsters, but I’m trying to make the point that a dungeon monster can have many attributes. And a multitude of monsters means these attributes will be combined in many different ways. For example: I might just add a LightMold. A LightMold is a sentient fungus that cannot move, but it can cast spells.

Guess what? An egregious sin has happened for now I have to go back and override all the other monster’s CastSpell function to do nothing. I could have the base class DungeonMonster do nothing with spells, but then the problem of copy pasting spell casting logic to all classes that can cast spells appears (we haven’t even added evil wizards yet). Not to mention the fact that I just copy pasted the Mouse’s Attack function override.

In short, I’ve made a mess of everything.

Let’s rework this using composition. A dungeon monster is made up of behaviors. A behavior is how something acts.

Adding an attribute to DungeonMonster got a lot easier too. No more complex inheritance or copy-pasting logic. All logic is sitting in those behaviors. Combine the behaviors to make the logic how you wish.

This is not what I’m actually doing, but it is a great step forward. I’ve laid out the code above because that is actually how I arrived at my current solution. So join me next time when I explain my understanding of entities.

As it turns out, generating chunks in a continuous world is not the difficult part. The difficult part is keeping a continuous world. What happens when buildings are spread across multiple chunks? When pathfinding needs to go across unloaded chunks? When loaded entities are no longer in loaded chunks? How to continuously write/read chunks from files?

So I’ve replaced every instance where I’m operating on a collection of chunks, with an operation on a single level. The level structure has simplified from the chunk since there is now no difference between local coordinates and global coordinates.

After a month’s sojourn I have returned to my long term project with more knowledge. I’m replacing my Object-Oriented F# that looks like

namespace Morgemil.Maptype TileType =
| Void =0
| Land =1
| Water =2/// <summary>/// This defines a tile. Each tile instance will hold a reference to one of these as a base attribute./// </summary>type TileDefinition(id : int, name : string, description : string, blocksMovement : bool, blocksSight : bool, tileType : TileType)=/// <summary>/// Use this in file storage. When saving a chunk or map, use this ID./// </summary>member this.ID= id
/// <summary>/// A short name. eg: "Lush Grass"/// </summary>member this.Name= name
/// <summary>/// A long description. eg: "Beware the burning sand. Scorpions and asps make their home here."/// </summary>member this.Description= description
/// <summary>/// If true, this tile ALWAYS blocks ALL movement by ANYTHING./// </summary>member this.BlocksMovement= blocksMovement
/// <summary>/// If true, this tile ALWAYS blocks ALL Line-Of-Sight of ANYTHING./// </summary>member this.BlocksSight= blocksSight
/// <summary>/// The tile type determines some things like if they can breath or not./// </summary>member this.Type= tileType
/// <summary>/// A default, minimal definition. Could be used as the edge of the map blackness?/// </summary>staticmember Default = TileDefinition(0, "Empty", "", true, true, TileType.Void)staticmember IsDefault(tile : TileDefinition)=(tile.ID= TileDefinition.Default.ID)

with something that looks a bit more F#-ish.

namespace Morgemil.Maptype TileType =
| Void =0
| Land =1
| Water =2/// This defines a tile. Each tile instance will hold a reference to one of these as a base attribute.type TileDefinition ={///Use this in file storage. When saving a chunk or map, use this ID.
Id : int/// A short name. eg: "Lush Grass"
Name : string///A long description. eg: "Beware the burning sand. Scorpions and asps make their home here."
Description : string///If true, this tile ALWAYS blocks ALL movement by ANYTHING.
BlocksMovement : bool///If true, this tile ALWAYS blocks ALL Line-Of-Sight of ANYTHING.
BlocksSight : bool///The tile type determines some things like if they can breath or not.
TileType : TileType }/// <summary>/// A default, minimal definition. Could be used as the edge of the map blackness?/// </summary>staticmember Default ={ Id =0
Name ="Empty"
Description =""
BlocksMovement =true
BlocksSight =true
TileType = TileType.Void}staticmember IsDefault(tile : TileDefinition)=(tile.Id= TileDefinition.Default.Id)

I think this is a lot more concise and removes unnecessary encapsulation.

Here is another example of something I’ve learned. I have a test project that I script odd things in to test out concepts with and I’ve had this “Walkabout” class that I use to test movement from a console window window. It was defined as this

For now, whether it is good design or not, the position is included in a “Person” definition. So the only thing I wanted to change on that player was the Position, but I was having to pass everything which was a pain. Then I found the context of the “with” keyword with Record Types.

I’m finally getting around to my original goal of Dto Generation. I could probably have skipped everything that came before but that’s too late now.

Yesterday in my searches I discovered something new and wondrous Code Generation and T4 Text Templates. This seems to be exactly what I am looking for. Since my requirements are for run-time text generation, I’m following this guide verbatim. I’ve thrown the new new text templates into a new folder for clarity.

I am the audience and I am making this application for my own use. I believe that software benefits greatly when the developers are users too. When the developer are primary users, then the software may benefit even more so since there is then an instantaneous user feedback loop.

This post is finally going to deal with DTO generation I hope. We’ll see. The lead picture on this post shows what the project looks like right now. Not much there right now.

The easiest way to start off getting column information from the DB I know of is GetSchema. And supplying the name of one of these SQL Server Schema Collections. My DBs are fairly small, so this approach should be within reason for now.

By default, I’m putting immutable objects under the “Messages” category as a matter of principle. Not because I necessarily know that I will use them as a message. Here is the DataColumnMessage, the behemoth that it is