Hello, my name's Grapes and I'm a FairGame player of over 2 years, current run.
It's an unusual multiplayer incremental in that it doesn't have a market, which is generally the multiplayer feature in incremental games, and we've had a lot of markets. FairGame can be described as a race, or series of races in a round, which itself is part of a season; players climb ladders to reach the top and promote on to the next ladder until we reach the final ladder of the round, and promote off it to win. (Players receive points for how "well" they've done in each round; these points accrue over the course of a season but have no effect on gameplay across rounds aside from increasing the number of ladders in rounds.) Part of gameplay is the ability to "shoot" a player from the top of a ladder before they've promoted onto the next, requiring them to start that ladder over again. Shooting is done by gathering grapes from the base of each ladder, grapes produce vinegar which is both defensive and offensive. The game has a number of superficially simple mechanics that, together, ensure that each ladder is unique, and each round is different. Other players' actions can, and will, affect how you must tailor your own strategies for optimal, or sometimes merely adequate, play.
This isn't an advertisement, despite the link. If you've managed not to hear about the game, the link allows you to look at the game and see the mechanics I'm talking about.
Other multiplayer incrementals I've played have been resource gathering with crafting, and selling of either raw resource or crafted products, with the "NPC market" and a further, lesser-used, player market. I've played one game only, one about the tulip mania a few years back, that was an entirely player-generated market working with scarce resources, which was an unusual take on the market concept which is frequently overflowing with resources and highly unbalanced.
My thoughts from playing games of this nature is that building a community is key, it establishes a core of players that waxes and wanes but means that when new players enter the game there's somebody around to walk them through the early game, explain features and strategies, and communities will be the reason players return to your game when the initial wonder at your worldbuilding has worn off. A moderation team is fundamental part of your community; if you don't have them it'll turn into dross in no time so choose carefully (I say as a moderator of communities for decades).
Other thought on multiplayer incrementals is: please, no more markets. Think creatively about how your players can interact - conflict, support, shared goals. And get feedback from your playerbase, they'll let you know what isn't working.
The game was crashing. Not a lot, but about once a day the game would randomly just explode. No particular rhyme or reason to the stack trace or what was going on at the time. Just, boom!
We obviously can't ship that way. It was getting kinda late in the development cycle, enough that this made everyone nervous, and I was tasked with tracking the thing down. They said we hope you find it fast, but fast or slow, you have to find it because we don't really have a choice.
I spent about a week trying to see if it was related to any particular thing. I started disabling subsystems to track it down. No audio, wireframe graphics, simple test level, remove all equipment or controllers we don't need. Nope. At this stage you start having those tense conversations like "Maybe we don't NEED level 6.3" when fiddly bugs start to show up, but it was irrelevant, because nothing we could remove would solve it. I made some level of attempt to run back in the source control to see if I could binary-search to where it first showed up, but the game crashing isn't exactly unheard of and it was fiddly to even reproduce the thing in the first place. That was what made it so insanely slow to track down. No luck from any of this.
After several days, I understood that I wasn't in for a typical debugging session. What I decided on was to embark on making a build of the game that was byte-for-byte identical from run to run. No audio, no control input, constant RNG seed, track down anything that might make it deviate or anything time- or IO-dependent. That took about another week, but at the end, I had my build. Every byte of memory was the exact same from run to run; every address, every value. (This was a console game so this task was easier than it otherwise would have been.)
So we're two weeks in now. By dumb luck, I managed to replicate the bug almost immediately once I had the repeatable build. The morbidly simple level and setup that reproduced it quickly was: Start the repeatable build with a script running that would spawn the player in a bare room with a floating gun. The gun fires, killing the player. The player drops to the ground, and then the game crashes. Every time.
I got you now, you son of a bitch. Happy that the thing was trapped now, unable to flee into its stochastic wilderness, I began to live in an endless world of execution-style slayings.
What followed was actually the longest part. As I said, the crash had no real pattern, but I now had the ability to go backwards in time. I could control everything. I took any wrong-looking values from the memory at the time of the crash, and started setting watchpoints on their memory addresses. How had it gotten this way? What touched this piece of memory? The process of single-stepping through, as a single piece of memory was allocated, used, freed, and then reallocated, trying to understand it all and find the wrong bit, was intense.
My memory of the following couple of weeks is honestly a little fuzzy. I know I was able to track down, by single-stepping through every single place the offending memory value was touched, to definitively work out what value it was that had had an impossible value, how it had caused the crash, and every single place that value had been touched, until I arrived at the offending code. The problem was... the bug wasn't in the code I was looking at. It had had some weird impossible value in some of its data that had caused it to set up something else wrong.
Oh. Oh no. Do I have to do it again? By now I was three or four weeks in.
I did do it again. Like I say I don't remember clearly, but I remember that it took me about 6 weeks in total and I filled up the majority of one little notebook that I kept next to the computer to write notes in. Little hex addresses, stack traces, clues that I might need to flip back to later. No matter. After tracing back all the breakage, I finally arrived at the code that was actually causing it. Once I actually saw what was happening, it was easy to work out.
At some point, someone had added a cache for some expensive-to-compute data for actors in the world. The cache had a mapping of actors to cached-value matrices, and each actor had a single value that was a pointer to its cached value, or NULL if it had none. I think they were too big to store indefinitely? There was a little LRU cache. But, if an actor was destroyed, it wasn't removed from the cache. So its cached data would sit there in the LRU cache, like a little time bomb, until the thing expired, and then the last part of its removal from the cache would be... unsetting the pointer to cached data in the now-dead actor back to NULL. The actor's memory had already been freed, and so one int, somewhere at some random location in memory, would get set to 0. And once in a while, it would happen to be at a location where that would cause serious problems (usually leading quickly to a crash).
Hm... not sure it would have. Something simple like overwriting freed memory with an identifiable pattern wouldn't have helped, because by the time the crash happened, the actor's memory had been reallocated and was being used for something else.
This was on the Wii, which had some pretty bare-bones development tools, so it wouldn't have been real easy to try to use something like valgrind to do more sophisticated memory debugging or anything. It was basically single-threaded, too, BTW (I think audio and input were based on interrupt handlers), and I made it more so with the repeatable build.
Yeah. I was proud of myself. 😃 IDK how easy it is now with all these friendly toolkits, but back at that time and definitely for console development, there wasn't a lot of way around really knowing your shit. Even having a degree, it definitely helped, but even that wasn't really a full preparation for some of the difficult stuff I ran into. I wish CS prepared people better for real-world engineering; in particular I wish reading big codebases was more of the curriculum. I actually came out of school still with fairly bad working-with-production-code abilities.
Separate related story, I was disagreeing with my boss about whether to hire some guy. My boss said, but his code is really bad. I said, yeah but he's right out of school so it's to be expected. When I first graduated my code was really bad. My boss got sort of distant for a second while he was remembering, and then his face came alert again and he said, all animated, "Yeah! It was. It was terrible!" I said yeah, I know, then I learned what I was doing and it was better. It's just sort of how it works.
As a beginner myself I would recommend you installing portainer (a gui for docker) and if you need compose files I have them for all of my services on my GitHub.
You're confusing a container format (MKV) with a video codec (AV1)
MKV is just a container like a folder or zip file that contains the video stream (or streams, technically you can have multiple) which could be in H264, H265, AV1 etc etc, along with audio streams, subtitles and many other files that go along, like custom Fonts, Posters, etc etc.
As for the codec itself, AV1 done properly is a very good codec but to be visually lossless it isn't significantly better than a good H265 encode without doing painfully slow CPU encodes, rather than fast efficient GPU encodes. people that are compressing their entire libraries to AV1 are sacrificing a small amount of quality, and some people are more sensitive to its flaws than others. in my case I try to avoid re-encoding in general.
AV1 is also less supported on TVs and Media players, so you run into issues with some devices not playing them at all, or having to use CPU decoding.
So I still have my media in mostly untouched original formats, some of my old movie archives and things that aren't critical like daily shows are H265 encoded for a bit of space saving without risking compatibility issues. Most of my important media and movies are not re-encoded at all, if I rip a bluray I store the video stream that was on the disk untouched.
I think that CPU only supports up to 8GB RAM. Also the m2 is only for Wifi cards I think.
I have a somewhat similar ASUS board and it is quite ok otherwise, but don't expect wonders from that CPU.
A bit annoying will be that you need to either use one of the four SATA ports for the system drive, or find some way to boot from the PCIe 1x port. The similar ASUS board that I have does not support booting from NVMe drives though, so even if you added an adapter for this it probably wouldn't work (maybe if there is an BIOS update for it).
You could boot from a USB3 drive... not ideal but workable. Or add more SATA ports via an PCIe 1x extension card... but those might be hard to find, usually they require a longer (4x?) PCIe port.
P.S.: if you end up buying that board I can sell you 2x 4GB DDR3 SODIMMs that I have currently no use for :p
I just use informed delivery. It even can do something you couldn't just DIY: it tells me what's coming before it even arrives. Does it just tell you when you have mail?
That said: I just love things that are done simply because they can be done. Especially when they go hard like this. 😃
Yeah, all it does is tell me when something is obscuring one of the sensors. I figure anything that gers put in there which is small enough to fall in a way it covers neither isn't going to be important enough to worry about.
I am vaguely aware AusPost has some kind of service that might inform me of regular mail delivery, but anyone can put stuff in my mailbox not just AusPost. Plus this was a fun project, yeah.
Hi. I work at a conpany that makes digital card games.
Start by making the rules work. We generally use a callback implementation. We have a class that handles the game and enforces rules and dictates flow, classes that represent players, and then a rendering class.
The game will call relevant functions to prompt the players for an action, passing the game state with them. The players respond with what they want to do. The game calls the renderer to draw it out, and the renderer will then call the passed callback action. Repeat until the game is over.
When a human is involved then you just hook actions to buttons and pieces and clickable elements that the game catches and responds to if needed.
Really you can use any principle or design paradigm you want, but since you are making a "simple" turn based game just having it simple and well segmented is an easy way to keep a handle on it.
I've got a $50 USD 6500T with 25+ docker containers including jellyfin and it is amazing. It isn't the drive space you want but pure cli Linux is very lightweight.
incremental.social
Hot