go-man API
Learning go-lang & writing a game
Why?
 By day: I am architect/developer hacking
at Java based api’s
 By night: Still harboring a passion for
video games ...
Fusion
Why not combine both pursuits to retain a
level of interest?
Goals:-
 Better understanding of go-lang
 Maybe and ...
Dissecting the game
 Broke the idea of “pac-man” down to a
series of API calls.
 Create game
 Add player(s)
 Move play...
Concurrency
 Lightbulb moment!
 Multiple players in same game =
concurrency
Parallelism
 Multiple games in single server =
parallelism
Caveats
 Probably not the best way to do this
 First golang code I’ve developed
 Highly inefficient
 Websockets would’...
Starting the game
HTTP POST request to create a new game with
following parms:-
 Game name
 Max number of GoMen
 Max nu...
Add players to game
HTTP PUT request to add a player to a
game with parms:-
 Game id
 Player name
 Player type (GoMan/G...
Time up
If wait time expires, game server adds
remaining players as CPU controlled players.
Creates new golang process for...
Game States
“new” – just created
“waiting” – waiting for players to join
“playing” – game active
“over” – all GoMan player...
Power Pills
If a player eats a power pill a separate
golang process is submitted that waits for
duration of pill. At end o...
Game Client
Originally I started developing a separate
client in go-lang.
Stopped development of this because I
wanted peo...
Game Client - technology
 HTML5 + JavaScript
 Twitter bootstrap
 HTML5 canvas
 Ajax calls to RESTful API
Game Client - features
 List games
 Create new game
 Join existing game
 Play game
Game Server
Server implements MVC pattern:
Models = game board + players
View = JSON representation of game state
Controll...
Game Server - technology
 Standalone golang executable or
 Google app engine app
Uses:
 Gorillamux (for http routing)
...
Game Server – lessons learned
Things I learned during development:-
Started using filesystem as simple datastore for
games...
Game Server – logic
 All game logic resides on server. Game
state / player state etc.
 Game clients are completely dumb....
Game Server – concurrency
 Game controller writes PlayerMove
requests to a single channel (one per
game)
 This prevents ...
Game Server – concurrent requests
move me
Game
request
channel
Players can be either remote web players
or local CPU contr...
Game Server – concurrent responses
Players receive a new instance of the
Game board after their move
Bad move
Game Server – stats
golang is FAST!
 Normal game 1 goman & 4 goghosts runs
in browser @ 60fps
 5 x 60 (300) requests per...
Game Models - GameBoard
type GameBoard struct {
Id string
Name string
PillsRemaining int
Players map[string]*Player
MaxGoM...
Game Models - Player
type Player struct {
Location Point
Id string
Type PlayerType
State PlayerState
Name string
cpuContro...
Game Models - GameState
const (
NewGame GameState = "new"
WaitingForPlayers = "waiting"
PlayingGame = "playing"
GameWon = ...
Game Models - PlayerState
const (
Alive PlayerState = "alive"
Dying = "dying"
Dead = "dead"
Spawning = "spawning"
)
Game Models - PlayerMove
Request interface
type PlayerMove struct {
GameId string
PlayerToMove Player
ResponseChannel chan...
ASCII Client
HTML5 Canvas Client
Demo
Client: http://go-man-client.herokuapp.com/
(Hosted as simple static site)
Source: https://github.com/telecoda/go-man...
About me
robbaines@gmail.com
@telecoda
Upcoming SlideShare
Loading in …5
×

go-man API

4,453 views

Published on

Learning go-lang and writing a multi player API based game

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
4,453
On SlideShare
0
From Embeds
0
Number of Embeds
3,270
Actions
Shares
0
Downloads
17
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

go-man API

  1. 1. go-man API Learning go-lang & writing a game
  2. 2. Why?  By day: I am architect/developer hacking at Java based api’s  By night: Still harboring a passion for video games and regularly write small games to try out new tech on my daily commute (rarely finish them…)
  3. 3. Fusion Why not combine both pursuits to retain a level of interest? Goals:-  Better understanding of go-lang  Maybe and actual finished skunkworks project?
  4. 4. Dissecting the game  Broke the idea of “pac-man” down to a series of API calls.  Create game  Add player(s)  Move players  Repeat to fade
  5. 5. Concurrency  Lightbulb moment!  Multiple players in same game = concurrency
  6. 6. Parallelism  Multiple games in single server = parallelism
  7. 7. Caveats  Probably not the best way to do this  First golang code I’ve developed  Highly inefficient  Websockets would’ve been MUCH better  BUT, it’s fun to try it
  8. 8. Starting the game HTTP POST request to create a new game with following parms:-  Game name  Max number of GoMen  Max number of GoGhosts  Time to wait for players What happens?  Creates new game on server  Creates golang process waiting for timeout to start game.  Creates a single channel to listen for player updates
  9. 9. Add players to game HTTP PUT request to add a player to a game with parms:-  Game id  Player name  Player type (GoMan/GoGhost) If total players reached game will begin otherwise game waits for players
  10. 10. Time up If wait time expires, game server adds remaining players as CPU controlled players. Creates new golang process for each missing player Dumb AI: Wait for ¼ second. Pick random number between 0-3 Send move request to game channel repeat…
  11. 11. Game States “new” – just created “waiting” – waiting for players to join “playing” – game active “over” – all GoMan players have died “won” – all pills eaten
  12. 12. Power Pills If a player eats a power pill a separate golang process is submitted that waits for duration of pill. At end of timer game reverts to normal.
  13. 13. Game Client Originally I started developing a separate client in go-lang. Stopped development of this because I wanted people to try the game easily on the web. Switched to JavaScript based client as this was the most likely client to consume the API.
  14. 14. Game Client - technology  HTML5 + JavaScript  Twitter bootstrap  HTML5 canvas  Ajax calls to RESTful API
  15. 15. Game Client - features  List games  Create new game  Join existing game  Play game
  16. 16. Game Server Server implements MVC pattern: Models = game board + players View = JSON representation of game state Controller = RESTful API calls to perform CRUD on a game instance.
  17. 17. Game Server - technology  Standalone golang executable or  Google app engine app Uses:  Gorillamux (for http routing)  Game state stored in memory
  18. 18. Game Server – lessons learned Things I learned during development:- Started using filesystem as simple datastore for games. Got tired of serialisation / deserialisation and realised it was unnecessary for my simple demo. Originally modeled board cells as a 2d byte array. But these force client to have to deal with Base64 encoded binary data (nasty). Changed definition to a 2d array of “runes” for an easier life. BoardCells [][]rune
  19. 19. Game Server – logic  All game logic resides on server. Game state / player state etc.  Game clients are completely dumb.  Weakness in API is that players are not authenticated so they could easily fake each others moves by using the other player’s GUID.
  20. 20. Game Server – concurrency  Game controller writes PlayerMove requests to a single channel (one per game)  This prevents concurrent updates to same board (two players eaten same pill etc.)  PlayerMove request includes a unique response channel, to return response back to original requester
  21. 21. Game Server – concurrent requests move me Game request channel Players can be either remote web players or local CPU controlled players on server
  22. 22. Game Server – concurrent responses Players receive a new instance of the Game board after their move Bad move
  23. 23. Game Server – stats golang is FAST!  Normal game 1 goman & 4 goghosts runs in browser @ 60fps  5 x 60 (300) requests per second. Average 3k per response. 1MB per sec traffic.  Running locally it is handled with ease 80+ players in a single game  DO NOT PLAY ON MOBILE PHONE WITH DATA CONTRACT!!!
  24. 24. Game Models - GameBoard type GameBoard struct { Id string Name string PillsRemaining int Players map[string]*Player MaxGoMenAllowed int MaxGoGhostsAllowed int WaitForPlayersSeconds int State GameState PowerPillsActive int CreatedTime time.Time LastUpdatedTime time.Time GameStartTime time.Time BoardCells [][]rune }
  25. 25. Game Models - Player type Player struct { Location Point Id string Type PlayerType State PlayerState Name string cpuControlled bool Score int Lives int }
  26. 26. Game Models - GameState const ( NewGame GameState = "new" WaitingForPlayers = "waiting" PlayingGame = "playing" GameWon = "won" GameOver = "over" )
  27. 27. Game Models - PlayerState const ( Alive PlayerState = "alive" Dying = "dying" Dead = "dead" Spawning = "spawning" )
  28. 28. Game Models - PlayerMove Request interface type PlayerMove struct { GameId string PlayerToMove Player ResponseChannel chan (PlayerMoveResponse) } Response interface type PlayerMoveResponse struct { Board GameBoard Error error } Response written back to channel passed in request
  29. 29. ASCII Client
  30. 30. HTML5 Canvas Client
  31. 31. Demo Client: http://go-man-client.herokuapp.com/ (Hosted as simple static site) Source: https://github.com/telecoda/go-man-javascript-client API: http://go-man-app.appspot.com (Hosted on single GAE instance) Source: https://github.com/telecoda/go-man-app Wiki: https://github.com/telecoda/go-man-app/wiki
  32. 32. About me robbaines@gmail.com @telecoda

×