[Dev log] Yeti tamers [Art requested!]

[osmosisch]

A dangerous yeti has escaped from the monster zoo that you run. Better tranquilise it back into its cage before it can go on a rampage!

 

I'm making a digital version of a boardgame I've been working on over the past couple of months.

 

Because I have this week off from regular work to study, I'm not doing it in a game tool but using this opportunity to learn more javascript ecosystem stuff, like React, webpack, ES6.

 

Here's what I got so far:

 

As you can see I'm not much of an artist (and I'll have to redo the gorilla thing anyway) so any contribution in that field would be super welcome!

 

The code's over on github for anyone who wants to look along:

https://github.com/DanielReid/beast-tamers

 

A brief summary of the game mechanics:

- there's a team of zookeepers, each of whom has slightly different stats/abilities (move rate, tranq range, trang damage, health)

- each zookeeper gets two actions per round, which can each be one of [move, tranquilise, special]

- whenever the monster is tranquilised it gets angry, causing it to plan one more attack.

- the monster's next planned attack is visible so the player(s) know what to expect

- monster attacks happen at the end of the round sequentially (it's a queue)

- most monster attacks hit certain spaces on the board

- players have X rounds to inflict Y points of tranq or the monster enrages and goes off to destroy Gotham City of what have you

- players also lose if the whole team is knocked unconscious

 

I've got a a giant ape and a psychic cyber-bunny so far, but to go with the winter theme I'll be designing a new yeti monster for this jam.

[osmosisch]

Update:

 

- made a live-reload setup so that I don't need to manually rebuild when I update game code

- added Falcor to load the game data from the backend (because I wanted to know how that works)

- restructured the app to be more in line with React principles (data down, actions up)

- created backend data for one beast, one board, two classes (work in progress). 

 

So a lot of learning as far as framework stuff goes (this was a study week after all).

 

New code's up at the github.

 

Todo:

- integrate Flux for a sensible action / reaction pattern

- actual game logic

 

Reasonably satisfied, and a very enjoyable week. I'm dog tired now though.

[osmosisch]

Update: Got a mean flu (I suspect from being so tired), so past week has been mostly sleeping and drinking lots of fluids.

 

On the bright side, I felt well enough today to start work on this again. I'd been looking for a sensible pattern to integrate actions/logic into the app and Flux seemed the most natural fit. Integrating it took a bit of headscratching but I'm pretty happy with the current way updates/reloads should work as I understand them.

 

Again, code's up on github. Not much visually to see (although I did add coordinates to the hexes for visual debugging)

 

Board expanded by one column on each side to correspond to the real game.

 

Now to see whether I can get some actual gameplay in there before the jam ends :S

 

[osmosisch]

Update! Currently away on holidays at the in-laws in Poland, so I had some time to mess around.

Added:

- ability to select a player

- when selected, a player's movement range is higlighted

- players have limited actions per turn

- players can use their actions to either move or attack the monster (if they are in range)

- the turn counter advances when all players have used their actions

- the monster tracks the damage it receives.

Todo:

- figure out the best way to propagate information between stores in Flux. I think I need to set up a better event chain.

- add monster response attacks

- resolve these attacks (ie. damage players if they get hit)

- add win and loss states

- limit players' movement (they should not be able to pass through each other)

Update's up on github as always.