I love this so much :D That reads like something I'd expect from ZA/UM, but it also thankfully alleviates most of the major issues I had with the game, which I've already talked about here on Lemmy. I really liked the game, but there was a lot of red flags point to it being just a quick corporate cash grab, where they decided to basically re-skin heir previous game based on with as low effort as possible, to quickly sell it and cash in on the Pokemon thing. It just smelled with corporate greed, and that they did not really cared about the game too much.
But assuming this screenshot is true, I'd say that it's clear that it wasn't development driven and pushed by corporate greed, but really just a few of guys trying their best.
As a craftopia player palworld definitely feels like a bit of a reskin, but one that gives players a lot of what they wanted (mainly being able to explore freely in multiplayer mode which is severely limited in craftopia).
One element palworld leaves out is being able to create your own automated processes (like automating a farm with a series of conveyer belts, chests, and various machines). They say they’re still planning to develop craftopia so I am pretty excited to get the elegance of the pal world pets (which craftopia had too, but not as shiny) and the fun of automating your own homestead instead of setting up prefab stations.
I guess I'm a little confused, because wasn't their previous game Craftopia? I'm fairly certain that game sold relatively well for an indie game, at least 25,000+ copies if you base it off the All Time Peak Players on Steam Charts. For a small team of just a few people, that's a decent chunk of money (I think it sold at $30 around launch, so roughly $750k for 25k copies sold before Steam takes its cut). Craftopia came out in 2020, so they're saying they've learned virtually nothing in 4 years, not counting the dev time Craftopia had?
I enjoy Palworld, I think it's a fun game that has a lot of potential, but I'm not sure I'm fully buying into some of these responses.
As a side note, a lot of Craftopia people complain they abandoned that game, but looking on Steam it shows several recent updates across the last year, with one even coming out just yesterday and a huge one in November 2023 and a new roadmap posted in December 2023. So, I'm not really sure where those players are coming from regarding that.
Regardless, I'm looking forward to what Palworld grows into, as I really do think they have something rather special here. It's got a lot of rough edges and a couple core design problems, but those can eventually be addressed with some hard work. Hopefully they use the massive cash influx they've achieved with their recent success and hire some competent, seasoned developers to come in and get their shit in order. I'm not holding my breath too much, though (remember when we thought Valheim devs would spend their game success lottery money to massively boost that game's content and polish?).
Agreed on both points - I am skeptical they are such "amateurs", and it also doesn't necessarily seem like a cash grab considering how Craftopia is faring. It does seem like there's way too much buzz currently going on however, it's hard to say what is true or what is just an outright lie... hoping to learn more and see how this progresses in a few months. Also hoping they stay dedicated to improving palworld more than the valheim devs did (meaning barely anything, thank god for the modding community there doing what little they can to keep the game alive).
Idk craftopia has a pretty committed fan base and combined with being free on gamepass I’m not surprised at the buzz. Very curious to know the gamepass player #’s compared to steam. I wouldn’t be surprised if microsoft has done some promotional stuff for free though (to promote gamepass).
It turns out that most info from the screenshot is false, there's a better article that's written by the actual developer linked in the updated post.
He did talk about them not having a budget plan, which was a fairly long part of the article, but can be summed up like this:.
Figuring out budget is too much additional work, and we want to focus on our game. Our budget plan is “as long as our account isn’t zero, and if it reaches zero, we can always just borrow more money, so we don’t need a budget
He also further down mentioned actual numbers of how much went into the development:
Judging from Craftopia's sales, it's [the budget] probably around 1 billion yen...
Because all those sales are gone.
He's right. These people are so fantastically wealthy, but it's not enough. They still need more, more more. And meanwhile, actual people, real human beings are going hungry, without heat, without a home. Not only do laid off employees suffer, but their families and their children too. All so that millionaires can continue promoting themselves to being billionaires and even more.
I don't know of anything realistically that can be done about it (in the short term at least). But it just needs to be shouted louder and louder until there's enough public sentiment that real change can start to happen. Greed needs to be shamed louder and louder. We know all the institutional power that the wealthiest people in the world have to suppress economic equality in every country and throughout the globe, but if our voices grow loud enough, eventually it will be too loud to ignore.
Excessive wealth and greed is a mark of shame. Let's just keep repeating it and hopefully we'll eventually have enough power to reverse it.
I think a compromise could be that developers would have to open source their games if they drop support, like entire support not just maintenance mode, so that the community can maintain them from then on. They could still have some sort of licensing to ensure the code isn't used for something else or the product used for profit (this would not include something like maintenance cost for online titles so that community ran servers could be paid for).
And then the developer goes out of business or gets bought by 15 other companies, with the rights to the game being so muddy it's not even funny anymore.
It's unfeasible. Not one serious publisher will let their game be open source for fear of reverse engineering, copycat games, using engines that a company has worked on for years, etc.
If users have to agree to every bullshit license terms then I'm sure companies can do so too when it comes to some open source license that would give them legal liabilities over those who breach those terms. This is not unfeasible at all, just has to be done on a legislative level that would enforces it. The EU has done quite a few regulations for the consumer so I don't think it is out of question. But I do think it is unlikely because video games are like an enigma to most politicians and still kinda stigmatized within older generations especially.
I can't really imagine how would this work in practice. While "I'm using industry standart AES encryption" may mean the cypher and the key itself will not be breakable, the bigger issue is how to get the 256b key from the player. Does he expect them to actually figure out and manually input 265b of data? That would be a pretty hefty game design challenge to make something like that possible.
I'm betting there's probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
The only A solution to keeping data from data-miners I can imagine would require just storing the key on the server - which could generally also be bypassed, since then you probably need a way to request the key, which could be data-mined and faked, so you're back at step one - how to validate requests for the key.
Or just make the secret puzzles so difficult, that they can't be brute-forced and the result really is 256b or more of data. Thinking about it, having specified 256 inputs you either have to make or are red-herrings that shouldn't be interacted with isn't really that much, but then the data-miner can just check the location of each one and filter out the inaccessible, and bruteforce the rest. And if all are accessible, it would make for a really difficult secret to discover properly.
I apologise as I know next to nothing about how this all works - so ELI5 please:
Based on what you explained here, could the game designed in theory put those 256 bits of key into 256 puzzles - with several hundred more puzzle pieces being red herrings?
But were you making the point the data miner could just then target the thing that accepts those puzzle pieces and reads the key from them?
Most of cyphers have some kind of decryption key, mostly between 256 to 4098 bits long. That means the (256 bit) key is 256 ones or zeroes (where order is important), so there's 2^256 combinations you have to try. To quote a stack overflow question about it:
You'd expect to find it after going through (on average) half of the keys, so average expected number of attempts would be 2^255. This is a Really Big Number. If every atom on earth (about 1.3 * 10^50 atoms) was a computer that could try ten billion keys a second, it would still take about 2.84 billion years.
But, remembering and imputing 256 ones or zeroes (or one number between 0-2^255, if you convert it from binary to decimal, which is around 78 digits) is really difficult and infeasible in practice. Due to that, when you want to encrypt something for example with a password that is easier to remember, you somehow have to generate the 256b key from the password, usually using a hash function. Because hash functions are designed to convert mostly any input into a 256b (or other size) bit keys, while making sure that the 256b are randomly distributed - so if you for example change one letter in the password, the hash will be absolutely random (but still the same for the same input), with no way to tell that it has anything in common with the hash of the previous password.
However, this introduces a problem - if for example you only used 4 digit PINs for the password, all anyone needs to do now is to 1) figure out how you generate the 256b encryption key from the PIN (which is usually doable by reverse-engineering the code), and 2) try every 4 digit combination, generate a key from it and then see if that key decrypts the data. That's only 6561 combinations, and can be done pretty quickly. So, by using the password that's limited to 4 digit PIN, even though you are using a 256b key for encryption, you have reduced the number of keys that can be valid - because there's only 6561 valid passwords, which only map to 6561 encryption keys out of the 2^256.
EDIT: I've realized that I've explained something you didn't ask for, I'll just keep it up for others, I didn't read your question properly, sorry about that :D
For the game development, assuming the author wants to use AES, it would mean that either there is some kind of "password", be it having to input a number, interact with game objects in certain order, or do some actions in order, out of which the key is generated. But then the answer has to be really complex (super-large number, or interacting with tens to hundreds of objects, or a long string), so the number of possible answers is large-enough that it can't be brute-forced - which would make for a really hard puzzle. Even if you for example required the player to input a text password of some kind, it could get frustrating, since it would have to be pretty long to not be bruteforcable.
The other solution I was thinking about is that you would have 256 objects or puzzles, where represents one "digit" in the key. If you solved the puzzle, the digit would flip to 1. However, it would be easy to check from code which puzzles are connected to the key - because that's what you are generating the key from. That would mean that unless you want the key to be all 1, some of the puzzles that are connected would have to be unreachable by the player (which can also be data-mined with some effort) or intended to NOT be solved, which does add more complexity and makes the puzzle even harder - those would be the red herrings.
could the game designed in theory put those 256 bits of key into 256 puzzles - with several hundred more puzzle pieces being red herrings?
Not exactly, because if you wanted to generate the key by solving 256 puzzles, it would mean that either the key is 256 ones, or each puzzle has a value - one or zero - it adds to the key. If that's the case, then you can simply take the values from the puzzle code and generate the key like that. Having more red herrings wouldn't help, because in code (which you can dissasemble and reverse-engineer with enough skill), there will have to be a function "UnlockSecret(key)", and probably something like "key = CreateKey()". And in the CreateKey function, you have to have only the puzzles that are not red herrings - otherwise the code has no way of knowing which puzzles to use for building the key. So a dataminer would just check the CreateKey function, and then check what exact puzzles are used for the key. That's why the only option in this case is to have a 256 puzzles, where each is either completed (1) or uncomplete(0), and out of the 256 puzzles, some are red herrings that should not be completed (and stay at 0), and some that should be - and those add 1s into the key.
However, now that I think about, just having some kind of a cypher puzzle which gets you a password of 10-20 characters (that's 10^29 options) would probably be enough. But then again - that's not that much fun, and it greatly limits what you can actually design.
Great explanation (including the pre-edit bit ha) - thank you!
When you say the cypher puzzle wouldn't be much fun - why not?
Surely you could have a set of puzzles through the game that each yield a keyword (seemingly plot relevant, but still pretty random when combined with the others) and the player has to combine all of them via clues in game in the correct order to yield the correct key. That doesn't sound unfun on the surface?
I'm betting there's probably something that generates the key from a vastly smaller player input, i.e what gameobjects you interacted with, in what order, or what did you press/place somwhere. But that also means that the entropy is probably in the bruteforcable range, and once you find the function that decrypts the secrets, it should be pretty easy to find the function that generates the key, and the inputs it takes.
When handling passwords, it is standard practice to use an intentionally costly (in CPU, memory, or both) algorithm to derive the encryption key from the password. Maybe the dev can reuse this? The resulting delay could easily be masked with some animation.
Most of the costly algortihms I know of are still reasonably fast, i.e you can try thousands of checks per second, so it would definitely help, but you would then still have to design a puzzle that has a large number od possible answers or combinations - which I still think really limits what you can create with it.
He could design a check/hash that would take a lot longer than common algs like bcrypt, but then theres a risk of someone reverse engineering it and simplyfiing it, or even finding a vulnerabilty that makes guessing the key easier. Because its suprisingly really difficult to make a hash that is matematically ok and doesnt have side-effects. Especially since crypto is dealling with some obscure advanced math, and some of the vulnerabilities in existing algorithms are pretty mind-blowing - especially since the more math you stack up, the more chances are there of you unknowingly using some kind of obscure math laws that can be used to simlplyfi or predict the results of your algorithm.
For a really bad and simple example (that kind of illustrates the point) from the top of my head, if i was just multipliing the input by 2 to get the key, and i did it 1000 times, it would mean that 1) the attacker could make it faster by multiplying it just once by 2^1000, and 2) the result would always be even, so now he knows he only has to bruteforce half of the keys, since it cannot be any odd key.
Ultimately you can configure these however you want. On my 5600X, I easily got one full execution of scrypt to last 34.6 seconds (--logN 27 -r 1 -p 1 in the example CLI), and one full execution of bcrypt to last 47.5 seconds (rounds=20 and the bcrypt Python library).
This kind of configuration (ok, not this long, but definitely around 1 second per execution) is very common in things like password managers or full disk encryption.
I am guessing it will just be sharded and hidden throughout the code in areas that get triggered as you play though the game.
The only real question is if it is quicker to find it in the code or to play though the game. IMO that is all a bit pointless as once it is cracked it will be cracked. All this does is maybe buy a few hours after launch (assuming the game files are not predownloaded before then) at best before all the info is available online. And now they have announced this quite a few will take it as a challenge and I doubt it will really slow anyone down.
In my worthless opinion, if the game is functioning as intended AND you get those sweet advertisements out there. It will probably sell pretty alright. Survivals are big right now.
Hi, Yeah as a survival games lover i am trying to make a game that you never saw on other survival games. For example, did you see any survival game with the cooking meet animations like that? İt is kot final result. İ will polish it. Thanks
Dont count on animations selling your game, my guy. It helps but its no bandaid for addictive gameplay. There could be no animation at all and if its fun I'll still play it. Make sure the mechanics bring about that feeling of completing tasks and advancing and it'll do fine.
My first game: A small dungeon-crawler style treasure hunter, written in JavaScript with Phaser 3. I'd like to note that those are not my assets, I only worked on this for two weeks and I also learned JavaScript and Phaser 3 in that time.
How has the actual process of developing your idea been different from your initial expectations and assumptions?
Do you have previous experience with a creative hobby/skill/profession (even if it's another sect of software development), and what challenges have you faced in the shifting of your creative paradigm? What's different?
Before I started, I already had some experience with python for simple scripts and Discord bots. I also watched a lot of tutorials for Godot, but I quickly lost interest in Godot because at the time I felt like I wasn't ready for stuff this complex. I also felt like Phaser3 isn't really beginner-friendly either, because of there not being a lot of ressources. The one's that exist are pretty meh. The official docs don't have examples or good explanations, and the official examples are confusing to navigate and it's hard to find what you need. In terms of JS, it was similar enough to python for me to understand the basics, so that was pretty okay.
Apart from that, I had a good amount of knowledge for GIMP and VSC to use them properly.
At the start I wanted to create a way different game, but I quickly realised that my idea was way too simple, and done already so many times that it's hard to do anything unique with it.
But after a few days of coding, it became easier and easier, because I realised how similar my ideas were to implement. Or it was the other way around, that I came up with ideas that I knew how to implement, idk.
TLDR: Didn't really have a plan, tried out different game ideas, and further developed ideas for the current game simultaneously while learning how to implement ideas.
Wouldn't this, along with the other numerous talks on ECS that were made before Unity copyrighted it, be enough to challenge the copyright and have it revoked? Or is that not how copyright works?
The patent wouldn't be for any ECS; it would have to be for a specific implementation. The post may match the implementation, and invalidate the patent, but just being an ECS wouldn't be enough.
Game Development
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.