Yep.
1 Like
From a design standpoint does a 1x1 square really mean that much, what if you had the smallest plot 2x2, or even 3x3? Seems like a better balance of game paint detail and performance.
I considered settling with 2x2, but I don’t have to anymore.
What’s your algorithm for this? These two in the center look like they ought to be joined up.
3 Likes
I divide paintable surfaces of my map into smaller surfaces that are at most 8x8 in size:
To reduce part count, I just merge runs of the same color. Consecutive runs that occupy an entire row get merged vertically into thicker parts. This is done in O(n^2) time. Also, by dividing the paintable surfaces into smaller ~8x8 surfaces, I won’t have to update a whole lot of cells when a change occurs in a surface. .
Although this algorithm is inefficient in some cases (like the one you mentioned, creating 7 parts instead of 4 in the best case), it makes is easier to represent the data I send to each client whenever a surface changes.
For example, I have a surface that looks like this:
1122
2222
3331
1111
1111
Each number represents a palette Id (a character from 1-255,1 being unoccupied) which I send to the client. I can compress this by reserving the characters 1-32 to represent runs which are horizontal and 33-64 to represent runs which are vertical. (33 being one full row, 34 being two full rows, etc.) After compression, it would look like the following:
[2]1 [2]2 [33]2 [3]3 [1]1 [34]1
Which compresses 20 bytes down to 12 bytes (not including palette data). If I have a fully occupied surface (which is very common in my game):
2222
2222
2222
2222
2222
I can represent it simply as:
[37]2
In your example, if the parts were to merge optimally like this:
The algorithm would be too complex for my liking and it would be difficult to represent this easily.
EDIT: Hmm, now I’m wondering if I running my algorithm in both directions (horizontally and vertically) and choosing the result with the fewest parts is faster than what I have right now.
2 Likes
I see. What I do is:
- Indentify a start tile;
- Sweep horizontally as far as possible;
- Sweep that whole swept horizontal line vertically as far as possible.
Another thing you can do is to turn this into a covering problem rather than a packing problem: allow overlaps between merged tiles of the same color. If you consider a plus shape:
010
111
010
You can cover the 1 regions with two overlapping strips: one horizontal and one vertical. You might have z-fighting issues when it comes to rendering though.
2 Likes
Developing a new soccer game: APS (Advanced Professional Soccer).
Began working on main items such as animations and controls, along with the progress of a stadium:
https://i.gyazo.com/fcd27bd7ca0f4c1817aa9ed0813b4e97.mp4
https://i.gyazo.com/b77541253685a2dde8c0301786748393.mp4
Also tried the concept of 3d grass, but didn’t end so well:
Coming soon this Summer!
17 Likes
I recall you explaining this algorithm a while ago. I tried coming up with examples where my heuristic would defeat yours but I couldn’t come up with any. Any idea on the complexity of your algorithm? Any implementation I came up with requires some way of tracking whether or not a cell has already been merged (using sets).
As for covering instead of packlng, I can’t allow parts to overlap because of z-fighting (flickering parts).
Complexity will be a bit greater, and will take a little more memory, but probably worth the savings in parts.
Worth noting that, as you mentioned in relation to yours, if you’re willing to do a second pass over the data in the other direction (sweeping vertical first instead), you might well find a more optimal packing arrangement.
Feel free to continue on DMs!
1 Like
I think our animator is learning much more.
7 Likes
Thank you for working on this. I Tried working on a soccer game but never got around to finishing it cause my time was needed elsewhere.
I do hope you finish it!
1 Like
You work fast.
1 Like
It’s been an ambition of mine too! Thanks for the words of wisdom 
I got my monorails to work by removing the suspension component. I guess prismatic constraints really don’t like moderately heavy objects. The bogies are attached to the frame with BallSocketConstraints and I now have a new friend: AlignOrientation, because it doesn’t obey Newtons 3rd law by default, so I can force the train upright while allowing the bogies free travel around superelevated track, because too much force on the bogies on superelevated track makes the whole train do a front flip.
6 Likes
Put together a quick ‘security tools’ plugin using the new PluginGui feature. You can use it to execute code on the client as well as easily fire/invoke any remotes in the game.
Grab it here!
19 Likes
But this is just a mixamo mocap :\
1 Like