Wednesday, December 28, 2016

Haskell Game Development (Part 03)

Basic Servers

Terminology

Previously our Contract type was agreements from the perspective of the player to the game or us.
We are going to add two more layers in between.

Servers act on behalf of the game to fulfill the agreements in a particular way.

Simple Example: Walking Simulator

Let's start with a server for our game. The simplest server is one that can't remember anything and just does actions in lock step with what the client wants. 

Tuesday, December 27, 2016

Haskell Game Development (Part 02)

Executable Design Docs with Free Monads

What is a design doc?

See Tim Ryan's The Anatomy of a Design Document for something that is complete, human readable, and more elaborate than the essential definition we are going to cover here.

For our purposes in making an executable design document, we need the properties:
  1. Acts as a contract between us and the player
  2. Is simple enough to avoid redundancies
  3. If it makes a reference to something outside of itself, we must define it
Let's break each of these down with an example before we move onto quiqs.


Haskell Game Development (Part 01)

Please follow me in a small series I use to procrastinate working on my academic thesis work.

Motivation

Many times, when starting a game project, we get lost in the weeds. Specifically, projects grow beyond scope because we get side tract implementing how  the game is supposed to behave and not enough time exhausting what the game is supposed to be.

In practice, this could look like spending too much time on your OO-style or actor style heirarchies and interactions, and not enough time on paper with your design documents.

But wouldn't it be nice if you could turn your design documents directly into code? I'm not talking UML style, where there is still this fuzzy sense of abstraction and things are nominal only. I'm talking about defining the bare minimum and setting up how the game is played in essence being a complete view of your game.

Sunday, April 17, 2016

The intermediate Developer [Elixir and Metaprogramming]

Shameless plug: I religiously listen to Johnny Winn's Podcast "The Elixir Fountain" because he is really good at holding an engaging conversation with Elixirists, Erlangers, and FPers from a variety of background and relating to them and their programming from all the major prospectives I care about (hobby, entrepreneur, corporate, and (sometimes) academic).

One topic he brings up a lot with seasoned developers is when a language gets intermediate developers-- I notice this comes up from people with a .NET background for reasons I intend to hit below the break. I'd like to share my thoughts as a social computing group leader (academia). Note that this is a small subset of the possible interpretations of this and isn't something I am supporting via science (no IRB here), just casual observations on what this could mean.


Friday, January 8, 2016

[Intermission part 2] Elixir Service mock up

So I have had two ideas recently that I was using writing them up as a reward for doing more strenuous make up work.

Friday, December 4, 2015

[Intermission] Libraries and DSLs that should exist

Here is a small intermission from elixir game dsl for some other elixir/erlang applications I think would be nice.

They pretty much break down from the following meta desires:
- Elixir as an OS
- Elixir as a desktop application language
- Elixir on Hardware

Saturday, November 28, 2015

Elixir Game Design #3: Data Pt. 2 - Pong

Suppose the following user story

A game designer wants to make a simple pong clone. Pong has four entities: the world, the player paddle, the ball, and the enemy paddle. The world is made up of the current score: {player, enemy}, and the size of the rectangular field (width x length). The player paddle, the ball, and the enemy paddle all have a position that must be within the rectangular field. the ball is moved by simulating simple physics, the player paddle is moved by some input controller, and the enemy moves by some sort of AI.