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. Overengineering/Overthinking

So I tried to create an external state manager for my pawnlist, and had some issues, and realized it was, frankly, silly, to generate a complete pre-existing set of pawns for players to grab if only a fraction of those pawns will ever be used.

Why am I creating an entire structure to manage a pool that, once I dole out the contents, will be worthless?

My initial concern was whether or not a list of objects instantiated in a container/owner object would be on the heap or stack.

I have to admit, reviewing the results of my code, I’m still not quite sure what’s going on, so I guess I’ll have to read up more on the internals of Python’s approach to objects and also lists.

I’m less focused on theory/internals at this point and more on getting it to work (why do I worry that this is going to come back and bite me in the ass ;))

Anyways, after realizing that I should just generate the pawn objects “on the fly” when I create the character and append them to the list.  This saves on having an extraneous manager object.  I think this idea of a ‘game state manager’ to generate a sort of total state matrix is falling on itself.  In particular, when it comes up against the objects themselves.

The other thing I dislike about my approach or how its evolving is that this OO approach actually feels like it’s limiting my genericness.  I suppose since I am making this for a specific board game, and not a generic game state manager utility for any board game, that’s ok.

I feel a little too much like things are poking into other internals.  This idea of “player owns a list of pawns” feels worrisome to me.  How will these pawn objects ultimately feedback into the player object and is this going to lead to some really horrible spaghetti mess of object relations that’s going to be hell to disentangle at a future point.

Then I think – why am I coding this at all.  I should be printing and prototyping physical things with friends, this is supposed to be a board game after all!

Then I think – because I can.  Because I want to flex my brain on a project that isn’t disentangling the mess of virtual wiring that’s my day job.  I may feel as though I’m not as productive here, but once I get the foundation up and running I feel like this may make playtesting easier, and if I can work on abstracting things out from what I’ve learned, I maybe can create a good online testing framework for my boardgames that suits my purposes.

Point being here, I guess is that I was wasting so much time trying to shoehorn things into my own wrong way of thinking instead of letting the natural flow of the code dictate what needs to be done.  Part of that is me getting used to Pythonic ways of doing things.  Part of that is me just needing a better grounding on how to approach these issues.

I’m going to try to implement this new portion of my code into my C# base and see what differences rear their little heads.
I *feel* like I should be able to do what I did with Python in a shorter time (writing it in C#) due to more familiarity with C#.

I’m still torn on how to proceed though.  I like Python and C#.  But I know I want to make it web based, so JS/HTML/CSS is important.  So I’ll still ultimately need some web framework for the UI portion which means figuring out what the best way to go is.  Does any particular framework look like it suits what I want/need/know?

I’d really like to use C#, but hate that it’s basically windows only and traps you into the framework, AFAIK.
There is F# and Fable/Elmish…  But again – I’d really have to learn something new with that.  Even thought the syntax of F# appeals to me, I’m even more at a loss w/it than I am python.
Though now that I’ve got VS Code running python properly, maybe I can get Ionide finally setup and working.  Was being difficult previously, so I just gave up.

Rust support seems to work quite fine.  GAAAAAAAAAAH too many languages not enough time, I want to know them all!

Boardgasm.Py: builtin method overriding

So – tonight I had something that looked like:

During work today, I thought why am I making a whole second method that’s just a basic wrapper around another method?  If my intuition of Python is correct I should be able to override the method, and further, that it would be fairly trivial.

So I coded the following attempt:

Do you see the issue?  Infinite recursion.
Ok, so I’m calling the append method to the list, but the append method has to call itself to add, but then.  OK, I put it aside for a bit, and when I came back to it later, it occurred to me.

There maybe a way to call the list method by calling the list class itself without instantiating it into an object.
I don’t know why this occurred to me, but I thought you know it just seems like something Python would do…

So, I modified the above code to this:

So here, on the third line, I went from self.append(player) to list.append(self, player).

Instead of calling the custom append code (self.append) , I call the original unaltered append (which was the intended behavior all along of course).

When it worked, and I double and triple checked that it actually worked, it was one of those. Well FUCK YEAH moments.

When your intuition of what SHOULD happen and what DOES happen pleasantly aligns, and not only that, the WAY it  happens is different enough so you get to LEARN something in the process.  Now that is beautiful.  And when you see HOW it did what it did and understand it, it just.

I hate to use “elegant” because it’s overused as is, and sometimes misused.  But goddamned there is something elegant about this.

The fact I was able to logically assume a certain modus operandi w/Python and see that my assumption turned out correct and further more that it matches my perception of how something would be done in the language.

I’d say that’s pretty damn Pythonic in itself.

There’s always the particularities, and an any system you’ll run across such little pleasures that make you appreciate how something is done a certain way.