Sorry dont want to get too specific or get doxxed, its just interesting to me that a meatspace game designer doesn't REALLY know anything until an online version gets made. This designer in particular bragged in a blog post about how balanced this game was from his 400 game sample size. I get that in a day and its all stored in a db.

Of course one could argue online is not the same game as in person but still these results are very surprising.

I've found this to be true. I mean obviously there's poker, but, like, online Dominion is very cut throat, your opponents are often very efficient and have thought about the game, and much like in online poker, have played 10 or 100 times as many rounds as your average meatspace player. The harder a game is to set up physically the more this is true (for example, Small World 2 is a game I've only played online because managing all the dumb little tokens is infuriating)

What difference does symmetry really make in a game?

The token example, IMO, is Magic; the Gathering. The game is wildly asymmetric, utterly non-game-theory compatible, and by all mathematical measures, a terrible game. This doesn't stop it's popularity.

I think this whole conversation displays the impedance between tech and non-tech. Techies demand purity, moving parts, balance, etc. The average person just wants something easy to understand, a collector's item, brag about being a winner, and something they can play with their friends.

I have a question that I'm now confused more after researching.

Is it really appropriate to put a database in a docker image? I'm not talking about a large multi-VM swarm of databases, but a single database?

I read a long thread on HN on this topic. The only thing I can figure is that programmers aren't DBAs so they really can't communicate on this.

I've been examining another contract to possibly work on. I saw something like this:

I'm at a loss for words.

It probably depends how you're using it. If I want to spin up a container for a quick new feature test, having the DB inside the container would be pretty useful.

Its a crude way to make a game fun and fair. I'd like to see your evidence of mathematical measures of why MtG is "terrible".

By all accounts it is a great game and responsible for basically the entirety of the CCG genre.

https://en.wikipedia.org/wiki/Magic:...thering#Awards

Its just been critically acclaimed for two decades with a thriving professional and recreational scene. But I guess whatever bull**** math you're about to put forward totally will make sense.

I mean, give Player A, who never played before a $10,000 deck vs a professional with a stock 3 color deck and see who destroys who.

I'm not claiming I've played Magic a lot, but it should be glaringly obvious that it isn't a GTO game by any loose definition.

Why do you think a game needs to be GTO to be "good"?

Games with solvable GTO are among the most inane and boring games ever. I don't think you have the first clue about game design tbh.

I'm also not sure what the first example has to do with anything. That is like saying that I could create compositions in MOBAs where a bunch of casual players would crush professionals, providing an extreme and silly example doesn't prove your point moreso than illuminates your fundamental misunderstanding of the subject.

I should probably just avoid this tangent but...how are you using GTO here?

Game-theoretic optimal refers to strategy/method of play not to the game itself...

Sort of curious about the "meatspace game designer doesn't REALLY know anything" claims though maybe there are so few publishers that have an incentive to have enough expert play-testing that this is true enough.

lol

I would assume so. tic-tac-toe would be the best game ever in this new timeline.

I didn't wanna nit this one specific angle. But I could be wrong and he might mean something entirely different.

While we are on the topic, one if my friends brothers taught me to play magic and in that same game I pulled off a ridiculous combo where (essentially this should be correct) I put a planeswalker from board back to his hand and then got to pick it out of his hand and graveyard it permanently. He was using a brand new deck and I was using an older one from before planeswalkers, and the entire experience and especially that play, was super fun. When I made that combo of moves my friends brother was super pumped and hadn't even realized I had the cards to deal with the planeswalker on board. It made the game feel very thoughtful and deep. I still lost the game badly but it was great.

You are correct, I don't have the proper vocabulary to express what I'm trying to say here. The better word may be "fair."

For the record, this is said on a gambling forum.

That's the very problem. This isn't a silly or extreme example. In the game I would attend once in a while, we had a forbidden deck. We would only use it to teach someone. You'd be explaining the rules to the person while he kicks your ass before the deck is half-finished. The funny part was that the person who owned it couldn't use it at the local clubs because it wasn't powerful enough to play with.

Same thing for tournaments. People plop massive money down on cards and they have forbidden cards.

Deck-building is a major part of MtG strategy, but if...

1- You are playing Monopoly and by whatever strange rule, some person could start the game with $1 and another can start with $500k. No matter what the first player does, no matter how much dumb luck he has, he's going to lose. He simply can't win.

2- Phil Ivey is only allowed to have disconnected offsuits. You can only have pairs. You are going to clean his bank account out. He can't win.

3- Chess: white is one king, the rest is queens. Black is normal. I'd take out a grandmaster with those rules, and I'm horrible at chess, lol.

These would be fatal flaws of these games, and that's my point. Even if a GTO solution is or is not inherently solvable, there is still a deck -vs- deck where, no matter what each player does, one player is 95% guaranteed to win no matter how bad their luck is, no matter how bad their strategy is, etc.

You are taking this as a diktat that MtG is a terrible game. I'm claiming that, mathematically, it is terrible, and despite what would be a fatal flaw in nearly any game (no balance and wholly asymmetric), the game is still loved by millions. While we can go on and on about maintaining symmetry, it does well to understand the psychology of why people play, and if symmetry isn't the reason why, then that's pretty neat. It does well to look at asymmetric games that are successful. I'm claiming that over-analyzing symmetry isn't going to be the end-all to popularity. It is a tool, but perhaps a flimsier one than some would like to think.

And to be sure, totally solvable games are very popular popular, and your opinion of them doesn't matter one iota. Making them absolutely zero-sum wouldn't affect their popularity at all. If casinos offered b/e odds on all games (b/e on Roulette, for example), the LV strip wouldn't go lights-out because people stopped gambling.

Hopefully I cleared up what I meant here. It's more like, can the game be distilled into a strategy that is within a certain tolerance, where one player doesn't always have an insurmountable advantage no matter how poorly they play. I'm going in reverse, starting at some approximation of GTO and working backwards.

If 2 players are playing Magic and they have the same exact deck, then it would stand that the more skilled player will win over, idk, 100 games or whatever. This isn't how Magic works.

And once again... I'm expressing that Magic is a good game, regardless of my own personal opinion of it.

I'm kind of on the fence about this one. I get the argument if I don't think too much about it, but you still have to build a database from scratch.

You already have a db built. It is (hopefully) properly configured with connections, speed optimizations, etc. Why do this over and over again for a docker image when all you have to do is add a schema or new database to what you already have?

Similarly, since you are already configured to take connections, you can load in mock data, etc. Why does it make sense to change ports and other params in your loading scripts, app, etc?

I'm not trying to be combative here, just genuinely curious if I'm missing something.

You can run a container with disk volumes mounted from outside. You can also bake in config files etc to the image. Using disk volumes makes it essentially non portable though. We use db containers for dev and testing only

Sent from my Nexus 5X using Tapatalk

I have no idea. Just saying that as a developer, I want the minimum amount of setup possible to get back to a known state after I've messed up what I am developing. If there are better ways to achieve this than putting the DB in a container, then that works too.

The main argument for using containers in dev and test is that you can create an environment that is very nearly exactly the same as prod, without developers having to install database servers or having dedicated dev servers set up somewhere. In your docker-compose file you can set up the linkages between them so that they can communicate properly.

And you can swap different ones in and out - I might have already mentioned it before but I can switch between a database that reads from volumes mounted in my dev dir, or a database that is created from scratch every time I start it. I can do this without restarting or changing anything else, everything just works.

We have a half dozen dev docker configs for different purposes - some even use the literal docker image for everything that is used in prod (barring containers that are not run in prod like the DB images). We have other configs that run debug webservers (code auto-reloaded on changes, etc). Again, switching from one to the other is just a matter of a single docker-compose command.

Getting stuff set up for docker is a pain, and learning to use it well is a bit of a pain (I have seen many terribly set up docker work flows), but once you have it going it makes the process of developing much simpler, imo.

Ok, fair enough. I haven't done much study on Docker. It reminds me a lot of GNU Screen. I'm guessing that isn't a good mental connection, but if the global configs available like that, I can see why it makes sense. While Screen has global understanding, it doesn't, as far as I know, have a local-to-remote deploy. Screen also defaults to localhost and there's no need to be concerned with ports, etc. I should really look into Docker again just so I can be more intelligent about this comparison.

I was more asking about using it in prod as opposed to dev or testing, and specifically, a single-db instance. I don't know enough about multi-node database clusters to have an opinion either way.

I found this thread. It's a lot to read, but a lot of interesting debate. I think a lot the cross-talk is that people are talking about different techs, clusters, and even container technologies.

https://news.ycombinator.com/item?id=13582757

Docker has nothing to do with screen or anything like it. It's like a set of connected virtual machines that can be composed quickly and easily

daveT, you really have no clue how competitive mtg works, do you? The problem you mentioned, i.e. one player beating another player simply because he has more expensive cards, doesn't exist.

Everyone that participates in competitive mtg has access to the same pool of cards. That's just the price of taking part in the game. It's not cheap, but its not as expensive as some other hobbies.

Is League of Legends "mathematically horrible" because you have to buy a decent PC to play it?

I've read that if you're going to run a db in docker you should only run the single db container on a host. Something to do with the container scheduler messing with db performance. So if you plan to run the db container alongside other containers then maybe don't do that.

My point isn't about competitive. My point is that Magic is inherently asymmetrical. I'm using it as one example (among many, mind you) that symmetry is not a major element in game-making.

Of course, the rules in a tourney are going to be more "fair," but the vast majority of players are casual living room players, and that's the perspective I'm taking.

My understanding from setting up some docker containers is that you have no idea when a docker container is going to go away so you don't want any state on it. A production database seems to be the last thing you would want hosted on a platform that has no permanence.

Containers are temporary, Volumes are "forever". Or should be. I think docker in prod is kind of weird no matter what