Project BoardGASM (Graffiti Royale Board GAme State Manager)

The Graffiti Royale GAme State Manager idea is now Project BoardGASM.
So far I created a C# basis with a general object manager, and simple construction of Players (with names, id/player#, color attributes set).

When logging in, I test the character to make sure they’re less than the total number of allowed characters in game and if not, sorry, lobby’s full.

I had fun making 3 different ways to create a list of players… I Have a 4th way to try (which will be just as non-useful as the 2nd method below)

1st Used a method that created each player as a new object then added them individually. :

p1(“name”, “color”) …; AddPlayer(p1);

2nd Using varargs, I passed them in at once using an array.  For a simple setup purpose this isn’t bad, but if I were to use a server system for an online method I’d be logging in one at a time, not an array, so this was a mild waste, but I did learn how to do it which was what my goal was.

AddPlayers(p1, p2, p3, p4);

3rd Used the actual method I’ll probably end up using by directly passing in the data (after sanitizing, natch) offered for Player name and color choice, as entered in a field/selected from a menu.  The “player number” at this point is just determined by ordinality of login.  That could change, but for now good enough.

AddPlayer(“name”, “color”).

The 4th method would be a blend of 2 and 3 (and hence, why I said non-useful).  Basically instead of AddPlayers(p1, p2, p3, p4), it’d be something like AddPlayers(“Name1”, “Color1”, “Name2”, “Color2”, “Name3”, “Color3”, “Name4”, “Color4”)

I decided it would be fun to do this little bit in multiple languages and decided Python would be the next one.  So I got the first method up already.  It was less headbashy in some ways (once I got the actual python tools installed in vscode – I could do it in WSL/nano/vim(blech), but VSCode did it quite well).  I did see an interesting terminal editor that has UI and themes that’s more like Sublime/VSCode, but for the commandline, so I hope to try that if it’s workable in WSL).

But while Python was less headbashy it’d been a while since I did anything in it more complex than a simple script.  So I had to relearn how classes were made, and moreso, remembering how to deal with implicit typing (since most of my coding’s been with explicit type declarations)  Well, it was slightly brainjiggering.  And I haven’t done much using “var” in C#.

It did occur to me, however, that my earliest programming experiences were based on implicitly typed languages.  BASIC and Logo (At least IIRC, the Logo we used (Color Logo) didn’t have any explicit type system)).

I guess I’ll work on finishing the python bit and creating maybe a simple JSON file to parse for feeding in as player data so I can use that with all the different implementations I use (instead of hardcoding the test values/fake players in the main code).  Good practice to get into, me thinks.

Oh – I also spent a lot of time trying to get get github going in VS.  First time using Github, had used Bitbucket, GoogleCode and one other thing before that.  And always with hg, not git.
I saw VS have git integration and was like NICE!  But getting the first thing setup because it wouldn’t let me merge due to some “future”state crap.  Even though the solution was to pull, apparently.  It wouldn’t let me.  I ended up just downloading the git Windows client and that worked like a charm.

If anyone’s curious.  Here’s the github for it…

Windows 10 Creator’s Update and more

My afternoon consisted of a few hours of downtime on the PC while I installed the Creators update.  My understanding is that the console was 16 colors only, and Creators update would expand that.  It’s a shallow reason, but I was bored, so…..  I did it.

After finding a .bashrc file I used (not sure if I’m sold on it, so I’ll prolly end up tweaking it), I did see the increased color depth with a script test.

I have to say though, man, it wasn’t as easy or obvious to find an answer on HOW to enable it as I would have expected it to be.  There were hints here and there.  But one of the bigger issues are old results that are either not relevant or references to the current situation are speculation (e.g. “in the future they’ll have 24 bit color.  We don’t know anything about it yet, but stay tuned!”) (hyperbole firmly intended).

Regardless.  I got to use that downtime to actually clean my room finally.  How amazingly productive I can be when the computer is off.

So I had that .bashrc file copied.  I was slightly foolish as I didn’t actually read the full script.  Now, nothing nefarious was afoot, but the dude who posted it remapped “nano” to vim.

So I decided I’d pathname launch it.  /usr/bin/nano.

No dice.  OK, so I “which nano”.

/bin/nano

Sweet.  Then I thought.  “which nano” returns “/bin/nano”.
What if I treat it as a variable to be parsed by the command line?

So instead of typing “/bin/nano” which is what I was going to do, I thought

What if I type:

$(which nano)

Would it treat it as me calling the reference “/bin/nano”?

BOOM YES IT DID!

So like – it *shouldn’t* come as a surprise, it makes logical sense, but oft-times things don’t come together as you may expect.  The fact this did means it was a pleasant surprise that the thing actually worked the way I had assumed.

It was just a happy tech moment/playfulness/discovery moment in a world where tech seems so maddening at times for many reasons (Working in the telecom field has given me a whole new appreciation for system complexity, let me say that.  Even more than programming has.)

Graffiti Royale: Game state history/log/tracking

Hello, old neglected friend, how are you?
I’ve been doing various creative project outside game design lately, primarily art and music (did someone say Volca FM?)
But have been wanting to get back in the swing of game design.  So I let background threads run in my brain, instead of conscious attention to it (that’s one of those things that can backfire, I find, trying TOO hard to figure things out).

One of the fundamental issues I had with the design was how to keep track of who placed what tile where.

My initial thought was a personal paper pad with the city grid laid out, and grids to stamp a color on the graiffiti spots you’ve placed a piece, the game would provide a set of colored markers to dot the location.  But then I thought that seemed wasteful, and it requires everyone to have one more thing to manage, and it’s unwieldy.

Then for some reason it hit me: there’s a 5×5 grid of locations – A-E rows and 1-5 columns.  Why not have tokens in each row and column, labeled as such.  Say I played on D-2, I would take the D token and the 2 token, and place it on my Sketch Pad replacing the piece I took from the pad and thus keeping a record of where that piece was played.

Note: NOT the paper pad above, but a separate mat where players’ graffiti tiles are placed as their hand.

However, that seems like it could be problematic.  Originally it seemed simpl, but you run into the issue of resource management.  That is, there are 6 potential locations that could be taken up in each main build spot (D2.a1, D2.a2, D2.b1, D2.b2, D2.c1, D2.c2).  There’s 25 (5×5) locations so that would add up to 150 tiles required to ensure that if everyone played their tiles.

However – each player only has 12 small tiles, 4 medium and 2 large so 6 players (max) 6×18 =  96, still a hefty chunk, really.  I could make 4 player game which would make 72.

I’d have to think of the math on this more through the day.  It may actually end up being cheaper to print pads and use pens LOL.  Hopefully once I get my caffeine my brain’ll be ready to tackle this challenge.