Working back on the C Sharp version of the “BoardGASM” thing.  I am now at the point where I have player and pawn generation.  Today I created the Die class and a list of Die named Dice.  No rolling functionality yet.

The dice in Graffiti Royale are based on a concept I had of increasing danger.  Ascending a 5 color spectrum (Red, Orange, Yellow, Green, Blue), each die in the series would have a single pip increase.
This means, Red has 1 face with a pip, and 5 with no pips. Orange has 2 faces with a pip and 4 with no pips.  Yellow, 3 with and 3 without, etc…
I’m attaching an image to this post to show what I mean.

To use one has some sort of increasing value that is indicated by a color.  This color corresponds to the dice taken.  You grab each dice from ROYGB in order until you have the dice pool to roll based upon the level of the color you’re dealing with.

In the case of Graffiti Royale, that means a “danger level” that both increases danger (A red would be a low level visibility area (alley, say) and blue is high level (billboard)).
So I had to create pool of five six-sided die.
I had hoped to be able to create something like an array of arrays structurally to define/instantiate them:

{{1, 0, 0 ,0 ,0 ,0}

{1, 1, 1, 1, 1, 0}}

And I’m sure there’s a way to do that, but I just ended up making an array of 6 bools (1 for each die face), and then a list of 6 (one for each dice), with a constructor that takes the dice color and a list of 6 bools for the values.  Actually I could just ignore the 6th, now that I think about it, since unless I added a purple die at some point, I’m not really using it.  There’s always a chance of failure (or in our case success, since we DO NOT want to have a “hit” (e.g. be seen by someone)).

So, I did that today.

I’m also working on a personal project to share with 4 friends for a 4 player multiplayer asteroids type game.

In the process of that (I got to basic thrust acceleration and screenwrapping — the screenwrap code I just ganked from Black Module’s Youtube Tutorial…

And the thrust code, was just part of the sample code on Unity’s site for motion and joystick input modified for my needs).

Why reinvent the wheel, ferrealz.

While doing that, I decided to fuck around a bit on making a Graffiti Royale project in Unity and laid out a basic board (not the same board I have laid out physically with my original prototype), but one that’s a bit more balanced in distribution of difficulty levels.

I have that all laid out, and I am in the process of making players pawns.

I think I’ll try to merge my unity game with my BoardGASM code.  This is going to be some major refactoring, but hopefully if I’ve separated concerns well enough (since my logic is all just in C# 7.x (or earlier, I’m not sure what the most newest feature I’m using is, really). I should (hopefully) be able to use that as the sort of server and logic end of things, and the base mechanic/UI/interaction with the game code, can be done in Unity and I’ll (hopefully) be able to make a nice little system for passing state message between server and client (haha, and here, I should probably read more but I’ll work on that when I actually deal with the server/client side of things – right now I’m building the scaffolding from each end, and once they’re ready, I’ll work on the interconnect between them.

Grafitti Royale & F# & More

Well, last week, return to the cold weather, recovering from the cold and a sore back for the first part of the week and finally getting to a warmer day today, and wanting to get back “in the swing” as it were, I asked my roomies if they wanted to play a game or two.

We played Flag Dash, designed by one of Madison’s native talents.  It was a decent game once we got the general rules down, though I think having to wait to play does change the board a bit so it’s hard to have a perfect plan in motion.  Though I won, so I’m not complaining 😉

One issue I had is the general wordiness of the rule book (I should talk, right?) I’d kinda skim-read it a couple times, sat down and read most of it the other and my roomie read as we went along and I guided questions about specifics I remembered.  There were still details we weren’t sure of, but for the most part it worked.

I agree with my roomie that instead of player colors the team colors should have been used.  I suppose a “hat” could have been placed on for the colors of the players.

Anyways, then we played 7 Wonders and I lost as expected.  It’s been ages, but was fun to dig it out again.  I forgot how much I love it.

Then I wanted to show off the basic concept of Graffiti Royale to them, so I dug out the board, the small tiles I cut out (finally the right size!) Only one set, but it was just to give a basic idea of what I was thinking.  Showed them how the artist/worker placement would work, the basic “market” the layout of the tiles, the scoring concept, the penalties for getting “busted” and the Infamy for the one who was most busted showing that conflict and drive to punish your enemy, but not so much as to drive them to receiving benefits.

I actually had a good feel for it, and feel a lot more inspired on this than Quartiles, which I feel guilty about not doing more on.  So I should really get my ass to focus on that again.  It’s really just needing to get a few more powers that are simple to use but unique, and I’m struggling to find some ideas. Probably need to brainstorm.

The last bit is F#.  I’ve not programmed in a while and I’m curious about trying a functional language.  I’ve done very minimal “Hello World” type stuff in the Racket interpreter, for example.  Or Haskell.  And since I have used C# and know a very little of some of the concept of the CLI (Common Language Infrastructure – not the Command Line Interface), that it might be fun to try F#.

Further since F# seems somewhat lightweight/scripty, I though it’d be nice to use it with a code editor instead of Visual Studio.  There’s a plugin for Atom/VSCode called Ionide, so I tried to install that and after struggling to get it working, found a page on MS’s site that explained the setup better.  Ionide’s instructions already assume you know how to setup F# projects and such.

So, as with any language I’ve used apart from Basic, Turbo-Pascal and Logo, dealing with tooling setup and understanding that is the most pain in the ass of all of it.

Unlike Python and Java, dealing w/path variables was fairly painless (though part of that is how Win10 does the path now, with a nice UI that splits the paths into a list, instead of the string of ‘;’ delimited paths).

But what threw me for a loop was the Project Setup.  I couldn’t just say open an F# file and try to compile it (in Code) or run it in an interpreter, it kept giving me errors about something not being found, so I installed/uninstalled packages (Paket & Fake), nothing.  Finally I hit that MS website post with the instructions and setup a full project and BAM!  It compiled.

I know the FSI can run a script, so I should probably just invoke it that way if I want fast scripting/testing.  But goddamned, I really was hoping VS Code/ionide could give that experience without having to build a whole project infrastructure.

Paint the Town: Designing for Physical Resource Use & Current Status/Progress

So I started to finally work on creating goal cards for Paint the Town.  My initial vision was to give goals regarding the locations of graffiti.  However, that’s quite limited.  Even though there are a lot of possible combinations, I want to keep the goals as thematic as possible.  I went to a graffiti dictionary and found some terms that can be used with some of the locations and created a few (I think I have 11 goals at this point).  I don’t have the rewards for these goals (I do for a few such as “Good Cop, One Donut” which requires players to graffiti the police station & the donut shop, and the reward is a “donut token” which let’s them move the cop (by placing the donut token at a location) thus increasing difficulty of the location the cop is at… Think of it sort of like the Robber mechanic in Catan, but different effects).

So my next goal is to do things like… figure out what other aspects I can do.  One is “slash” and the other is “massacre”. Slash will let you cover a piece already played with a smaller piece, but at the cost of reputation.  Massacre is the opposite, you can paint over a smaller piece with a larger piece.  If you do so, you can obtain the “restoration truck” (the truck lets you remove graffiti – say of your opponents).  I’m not sure I’m going to use these exactly like that, but it’s a basic concept to play with.

I’m thinking dealing with color combinations is another possibility – either colors of the graffiti or colors of the locations (each location has a color representing a “danger” level, picture the terror threat color coding, only it’s for visibility.  A dark shadowy area is only a red, but a tall tower is blue, for example (using ROYGB as the hierarchy).

Another interesting concept I’m working with is finding the best solution towards keeping track of who placed the graffiti.  I believe I’ve posted previously about my debate on whether players should have unique tiles or a shared pool.  I’ve decided to go with a shared pool.  My solution to this was originally a marker of some sort for each graffiti placed indicating who placed it, but that can add up to a LOT of pieces (in theory 25 locations times 6 graffiti pieces per location (times 6 players)).  I mean that would be the ridiculous max.  of course you’d pare it down to actual useable likely placements.  But even then, that’s still a lot of cardboard wasted.  My idea was to then use something akin to Roll Through the Ages’ paper tablet.

Basically a sheet of paper where each player notates what they played and where (initial or colored marker/pencil or something).  Haven’t fully thought through how to do this, but mocked up the paper templates for it at least to test.  The one issue I have with it is overwriting .  Is the pad a collective thing that players pass around on their turns and mark when they play?  Does each player have their own sheet?  I picture the first scenario more likely.  The problem with that (or any, really) is how do you indicate an overwritten piece in that scenario?  I suppose you could note it as a marginal note or something.  Initially I wasn’t going to have any overwriting, but thematically it makes sense to use it, because it does happen IRL and it would allow players to “attack” each other in different ways.

But more than that, the other issue I had was how to keep track of progress on a piece.  If you have a large piece, it can take more than one turn to complete painting it. My initial vision was to have the tiles themselves have a back that had a grid with the number of spaces required to play.  Players would place the piece upside down and then each turn move across the piece, and upon hitting the end flipping the piece over displaying the graffiti tile face up as if it has been completed.  This is a potential solution but that requires extra printing and thus ink/resources for each tile which adds up.  So my next concept is doing it on the board itself.  Each location would have a turn track along with the grid required to place the piece.  Simply place the piece face up and then move along the turn track until it’s complete (there’s more to this than just taking turns – rolling the danger dice for being caught and moving back if so, and ultimately possibly going to jail if you can’t move back on the turn track any more).  This would only require painting the turn track once for each location 25, instead of 108 times on each piece (and the positioning on the reverse side of the piece that would require).  Thinking more, I think I could just forsake that and have players basically move along each segment on a piece (or perhaps a faint/light grid over the graffiti itself to indicate total moves, I dunno).

Either way it’s interesting to think about the issue in terms of efficiency of resource production and how to reduce costs and components required to make a game.  It’s not something I’ve thought much of before because it’s not something I’ve dealt with (being my only previous game was a card game and the biggest issue with that would be minimizing total number of cards).

I don’t think it’s a huge issue (say, printing an image with a grid vs printing an image without a grid in the locations is still printing an image and in theory wouldn’t matter, since you’re using ink either way) — but if I did a tile vs location thing, that would definitely increase cost & complexity compared to just on the board and it’s that little type of thing that can add up.  I think in some ways I like that idea better, because it places it on the piece and gives it more of … tactile sense?  Like this particular piece has this many moves…  In terms of “game feel” it feels more natural and invokes an embodiment in the world more so than just an external track you use to count.  The… I can’t think of the term here, but maybe thinking of it as a mental affordance in design where you FEEL as if your action on the board is analogical to the thing you’d be doing in real life (that is taking turns to paint and moving along the piece itself is analogous to moving along the piece as you paint it on a wall in real life).

If you had the time and money and polish that would definitely be a better game design choice, IMO.  But if you are trying to conserve and make the design simple, removing that complexity in production is important, even if it ultimately costs you a little feeling in game design.

It really shouldn’t be a problem, though.  Players can and should be able to imagine/figure out moving along an invisible track (or a faint grid/track outline over the graffiti).  I’d prefer not putting a grid over the graffiti so the art itself can be clearly seen.  Eh, whatever… It’s a nitpicky detail at that point, I think.