The basic mechanics seem fairly simple and easy to extend to add features if needed.

The math/probability stuff can be visualized, and the game can calculate things for the player, if those turn out confusing or take attention away from the higher level strategy (like given a potential tile placement, the game can highlight the rows of tiles that would be captured, with different colors for different probabilities - like the furthest tiles might be red due to low probability, and closer ones could be greener). If its too random, you can throw in some guaranteed base value (like dont roll from 0-N, but start from a nonzero integer). And so on.

There are no fundamental issues with what you are proposing - its just implementation at this point (and that ultimately determines the outcome).

Your design document is just material to draw from during implementation - that is one reason it should be organized in minimal, somewhat independent fragments. Some of those might fit well together, but that synergy just becomes an additional fragment on top of the pile (and these can contradict each other in the design phase - theyre just possibilities) - it should not cause the whole thing to collapse into a single monolithic blob. Separating things out makes it easy to compress each one into less space, and analyzing and further developing each independently becomes easier (and maybe you find out one of them grows big enough to form the core of the game - hard to know which one ahead of time).

Like maybe it makes sense to explore the geometry of the hex based map (different areas, obstacles, environmental features...). Maybe its better to focus on how the tile edges interact, and use 90% of development on adding diversity there. Maybe managing your deck and playing quick becomes more important than winning individual matches due to the high level of uncertainty. Maybe keeping the gameplay simple and adding amazing audiovisual effects and story and whatnot is best. Same thing applies to every side mechanic you have considered - any one of them could turn out to be what actually matters (either while exploring it during design or exploring it during implementation/testing).

Like in the end, you might find that each tile is a complex universe of its own with all kinds of internal structure, and it turns out 3 tiles per player is enough (at a time). Like maybe players can just duplicate those carefully configured tiles to create the necessary complexity on the board. Maybe each tile can become a whole city, and that theme really locks in the direction of the game. Or maybe each tile cluster can represent the foot of some N-legged creature, and that gives another direction. So explore the aesthetic constraints as well if you need a guiding force for the rest of the game (the mechanics will then just naturally follow that).

If you keep things abstract (without aesthetic constraints), I feel like no design can naturally feel "complete", there really is no constraint to satisfy (other than quality of gameplay itself, which you cannot evaluate up front). With an aesthetic constraint (which can directly address implementation, like "make everything powers of 3"), being able to solve that challenge in itself makes the result feel "correct" (even if this is just an illusion - nothing says the result is guaranteed to be any better than some arbitrary abstract design generated by PRNG, apart from direct benefits of the aesthetic 'content' itself).

On 12/24/2017 at 5:52 PM, The_Con-Sept said:

I can only write walls of text.

A game designer needs to be able to write a wall, then to distill it down to 2 pages or 1 page or 1 paragraph or even 1 log line. You've achieved level 1. The goal of level 2 is to distill it down farther.

23 hours ago, Waterlimon said:

Snipped but read.

The math portion to find out whether or not a player can place a tile to see its outcome would be in the GUI and math side of things. But I kind of wanted to make it difficult for the player to just see that. In my experience I would always just go for the best outcome with the most possible points being the objective. However sometimes that can blind people to the weaknesses they invoke or create.

Where as they could have just placed a tile whose attacking power just flipped over several tiles in the late game but not realize that he left two tiles, not exactly adjacent one another, but in a fashion where the other player could place it into the cavity he created to make a corner move, and flip over double the amount of tiles the player was able to muster. Which is why I sort of wanted to leave that out. Having the player using the GUI to determine his next move solely on the purpose of capturing the most tiles in that turn could blind side them. I suffer from this myself in some games..

And on the same merit I do not want to create a dependency of the player to use the GUI to determine his next best move to avoid weakness. I would rather have the player taking into account his actions. We have too many games that hold players by the hand. In this game I don't want players feeling like they are being held by the hand of the AI to help them win the game. Then there is preventing cheaters from creating an AI that can play against other players. But that is a whole other category at this point.

As far as implementation, I wanted to have access to the source code of the original game, or confirmation from the creator of this game was not going to appear again. Or in development on a new platform other than the now dysfunctional PS Home. But I could not get any word from the creator what so ever. (It is like he had died, or just does not care.) I can only imagine how they created this game to begin with. BUT ON THE SAME NOTE. I am not completely clueless. And I am probably not 100% accurate, however with my experience creating objects in a 3D modeling program and compiling them into a game engine I do know the following: To keep things orderly in a low memory environment you do have to make things simple. Simple as in calling each and every vertex in a series of vertices to create an object as a hexadecimal value, or maybe even an INT. In order to group them you also need to define a new hexadecimal or int for them. Collision detection for the "gaps" in the engine we used could only accept INT's as a "group name" so if you wanted to create a gap that required you to clear 3 gaps in the skating game, you had to create that statement using ints to categorize them properly. So what I imagine how they created the original game was this: They had to code each and every hexagon's mapped face to have a script readily available to plug in the face's numerical attacking value properly into the token for it to execute correctly. Which means each and every face on the map has its own mathematical structure already inscribed in it. So that you would not need to create a matrix so to speak based on the space. As instead you would already have everything in place so the computer could just compute the end result, instead of using up memory to add a call function to figure out how many in every direction a tile can attack. While also just calling for the numeric values of the defending spaces to initiate a check of +, -, or Null. or even more simply, checking to see if the sum of attacking is < the current defending space. If it is less then it does not get flipped over. (However I keep thinking in my head that if a tile ties in attack and defensive power, a coin toss should show up to resolve the tie.) So I do not fear having to go inside of my map and labeling each and every face accordingly so its own inscribed math function can execute more quickly. But then there is the problem of the map itself. And as you were hinting at with "space" or "spaces." I have already had this argument in my head already.

When it comes to the map I do not want players heavily relying on CORNERS. As shown in the video of the Opening Post above you have a total of 14 tile spaces to play. Notice how players can not place a tile in the "Redded" out zone? That is a corner. Where a player could decide to put a tile's weakest sides into the corner to try and cement that tile's weaknesses away. I want to discourage that. And in order to do that I can simply implement a few lines of code that gives the player the feeling that he is going infinitely in a certain direction to place the first tile for the game to start. Simply by using warps, or re centering after a certain frame... or, allow the player to go infinitely go in any direction but once the tile is placed, it automatically sets it into the center of the map. That way they have to create their own "corners" using their tiles. And by having 18 tiles on each side, more than 2 corners could possibly show up in a match. (Which is why I finally brought this idea to the forum to talk about it more.)

So with that aside I also do not want to introduce "elemental weakness/advantage." Instead I was thinking in a different direction last week of changing something else for an attack strategy; thinking outside of the box of Multiplication, Division, Subtraction, and Addition. So I thought about INVERSE tiles. This could change the dynamic structure of the game with something so simple. Instead of Attack < Defense determining if the tile is to be flipped over, it switches that < to > in the checks. That way it becomes the lowest number is now the most powerful. Then the mathematical string also inverses the - in the equation to +. That way it adds the tiles defense to the attacking power until it reaches a tile that is lower than its attacking power.

Keeping that in mind I wanted to keep that as a very rare type of tile you can receive. An inverse tile could really ruin someone's day. I think that would be the most valuable tile in the game though as players would constantly be trying to create the highest amount of defense and generally not care for the low end.

And by keeping the decks randomized where you can only have 3 to 5 tiles in your hand it prevents players from stacking up against something like this.

And even while writing this very line I am already thinking of a third type of tile. A mirror tile. Where as it changes, or deflects, attacks in a different direction.

Even thinking about this it seems like I could easily create a sort of matrix that works like so: Each hexagonal space has its own predetermined function.Where as the attacking face gets plugged into the initial equation. The defending tile does the action while the attacking tile has to only worry about plugging in its data. So the defending tile would automatically take in the damage received, then send out the overflow into the corresponding opposite face as an attack. It just passes it along. then the next hexagonal tile takes the incoming damage and calculates it and passes on the overflow if there is any. If there is none, or the damage dealt is perfectly equal to the damage defended then the coin toss would appear for that tile. That is how I could write in the code so it can be properly managed by creating a matrix of matrix's.

And as you were saying when people place the tiles into the board I was thinking of having the world sort of pop up beneath it as you play. I thought about having the tiles act sort of like a decision, and that decision changes and molds the ground beneath it each and every time a tile acts upon that part of the land it would make something pop up. Just adding in a sort of background to the game instead of it looking so drab with nothing more than a 2D background to look at as a static image. That thought crossed my mind more than a few times. But being able to add or implement that into the game would take up resources and time to create. Because then I would have to map out everything on the board as well. What I was thinking was making the background seem like it is filled with nothing but water. And as you kept placing tiles into the ground it would slowly pop up islands... then there would be trees growing there. Then indigenous tribes of animals or people would take over the plane-scape. Each and every time. Just allow people to create little hexagonal plots of land that look different. Like Motifs.

But above all I already had the idea of the game's story like function work more like a mature, or even 18+ rated game (No nudity, just extremely mature seeing how most gamers are now middle aged and above.)

And I had the idea to have players choose an "Icon" not a "God" to represent themselves. And they would be voiced. Their only purpose is for the intro, and outcome. And maybe some back and forth banter between the two during gameplay on certain plays.

The number one "Icon" I have in mind is a Hyena character. Then I can only imagine a Zeus like character. Maybe a few women who are more dark/evil looking. Then maybe add in some ethnicity to the mix just to keep it entertaining to hear.

But even as far as story goes, even just the user's name they wish to be known by has importance to one side of this game. And that is LUCK. But that is explained in further detail in my txt file.

Seeing that this is going to be a more mature game, one to be taken with a considerable amount of intellect in mind, I don't want it to be "kid friendly."