Cultcow EvaXephon / Yanderedev / Alex Mahan / Alexander Stuart Mahan / cannotgoogleme - Edgy weeaboo coomer with pedo tendencies and 15+ years internet history as a lolcow, now known as a disaster developer behind eternal debug build called "Yandere Simulator", confirmed groomer and dollfucker

The end of EvaXephon?


  • Total voters
    2,417
The prices for the merchandise are ridiculous
pricey 2.PNG
pricey 3.PNG
pricey.PNG
 
What the actual fuck? All this time, he didn't even know how to implement a save/load system? Not that I'm surprised, but that really is amazing. The Legend of Zelda had a save/load system in 1987, and he can't even do that in Unity today.


I'm surprised this didn't take longer to make.
It would have taken longer if that poor tiny build programmer wasn't the one to do it. Seriously this programmer needs a raise.
 
What the actual fuck? All this time, he didn't even know how to implement a save/load system? Not that I'm surprised, but that really is amazing. The Legend of Zelda had a save/load system in 1987, and he can't even do that in Unity today.

Unless he's making his own custom serialization/deserialization process (which is absolutely not necessary for 99% of all games) making a save/load "system" is entirely handled by external libraries. The only thing that a user has to do in Unity (or any modern development platform) is decide what serialization format they want (JSON, protobuf, XML, binary), map the object graphs and then handle their unloading/loading. This takes some time given the complexity of the object map, but given the fact that he already knows scene-to-scene persistent data that should remain then this is merely an extension of that persistence. Again, I do want to stress that the object map packing/unpacking can certainly take time, but it seems impossible that a game would be in development this long without even having a basic save/load option. This would indicate that he's either just been deliberately lazy about implementing it or that his data modeling and hierarchies are a complete and utter mess. In that case, sure, making a load/unload process would take a very long time.

All of that to say: there's nothing to "know" about saving or loading, other than some basic security risks involved with human readable formats. You either don't know which parts of your data need to persist or you do. The rest is purely basic integration.

Just to give you an idea how the libraries make this easy: this is all the code that's required to save persistent data and load it. XML is used here, but it's the same length for any common format. (Keep in mind, of course, that //PACK and //UNPACK are likely quite lengthy but nothing complicated)
//PACK DATA
// create a file to write to
string xmlFilePath = @"PERSISTENT\DATA\PATH\HERE";

FileStream xmlStream = File.Create(xmlFilePath);

XmlSerializer xs = new XmlSerializer(typeof(List<ObjectMap>));

//serialize the object graph to the stream
xs.Serialize(xmlStream, objectMap);

List<ObjectMap> loadedData = (List<ObjectMap>) xs.Deserialize(xmlLoad);
foreach (Data d in loadedData)
{
//UNPACK DATA
}
xmlLoad.Dispose();
 
Unless he's making his own custom serialization/deserialization process (which is absolutely not necessary for 99% of all games) making a save/load "system" is entirely handled by external libraries. The only thing that a user has to do in Unity (or any modern development platform) is decide what serialization format they want (JSON, protobuf, XML, binary), map the object graphs and then handle their unloading/loading. This takes some time given the complexity of the object map, but given the fact that he already knows scene-to-scene persistent data that should remain then this is merely an extension of that persistence. Again, I do want to stress that the object map packing/unpacking can certainly take time, but it seems impossible that a game would be in development this long without even having a basic save/load option. This would indicate that he's either just been deliberately lazy about implementing it or that his data modeling and hierarchies are a complete and utter mess. In that case, sure, making a load/unload process would take a very long time.

All of that to say: there's nothing to "know" about saving or loading, other than some basic security risks involved with human readable formats. You either don't know which parts of your data need to persist or you do. The rest is purely basic integration.

Just to give you an idea how the libraries make this easy: this is all the code that's required to save persistent data and load it. XML is used here, but it's the same length for any common format. (Keep in mind, of course, that //PACK and //UNPACK are likely quite lengthy but nothing complicated)
//PACK DATA
// create a file to write to
string xmlFilePath = @"PERSISTENT\DATA\PATH\HERE";

FileStream xmlStream = File.Create(xmlFilePath);

XmlSerializer xs = new XmlSerializer(typeof(List<ObjectMap>));

//serialize the object graph to the stream
xs.Serialize(xmlStream, objectMap);

List<ObjectMap> loadedData = (List<ObjectMap>) xs.Deserialize(xmlLoad);
foreach (Data d in loadedData)
{
//UNPACK DATA
}
xmlLoad.Dispose();
From what I've heard, the hardest part of the equation is encrypting the save files. You can just type "unity saving" into Google and be on your way.

That reminds me, does anyone who's been in the source files know if Yansim is Deltatimed?
 
  • Agree
Reactions: Chimneychan
From what I've heard, the hardest part of the equation is encrypting the save files. You can just type "unity saving" into Google and be on your way.

That reminds me, does anyone who's been in the source files know if Yansim is Deltatimed?

Encryption makes things slightly more difficult, but it's rarely necessary. If you're really concerned about users manipulating their save data then you either keep it binary (which will immediately remove anyone who doesn't understand memory editing from being able to do anything) or you can just do a server-side check if you do something like XML / JSON which overwrites anything that was changed since the last "legal" save. You can also encrypt binary and JSON, but the added steps are almost never worth the effort. Most games just don't really bother and keep it binary. If you're determined to break into a save file, you can break into a save file. Unless User A's edited save file can directly affect User B's experience (leaderboards might be a good example here), it's not worth the effort to encrypt a save file.
 
To be fair for Alex, the game is in such an early state (after 3½ years of work, heh) that it doesn't need the save feature yet. The other programmer probably did it because he is still being paid to work on the game, but Alex wouldn't let him implement any actual gameplay features, so he was left with boring technical stuff like saving.

At least that's the most generous plausible scenario.
 
I'm pretty sure you can report and take down his video for the "The Sims" track that he's using while trying to sell shit.

Is it really a surprise that he's completely unaware of things like these?

Regarding legal issues; I noticed something in one of this 2015 videos that could possibly lead him to getting sued in some way, but I'm not gonna say it as I don't want him to become aware of it.
 
I'm pretty sure you can report and take down his video for the "The Sims" track that he's using while trying to sell shit.
We can't, unless we represent EA. I know that sometimes Youtube acts retarded and doesn't bother verifying complainant's identity, but let's not stoop that low.

Regarding legal issues; I noticed something in one of this 2015 videos that could possibly lead him to getting sued in some way, but I'm not gonna say it as I don't want him to become aware of it.
Have you tried setting the wheels in motion?

Won't this be kinda useless? Y'know, since he's planning on changing the name of this fetish simulator?
Guess what? In a year we'll hear: "Just now! New Lovesick merchandise! Buy my stuff again!"
 
To be fair for Alex, the game is in such an early state (after 3½ years of work, heh) that it doesn't need the save feature yet. The other programmer probably did it because he is still being paid to work on the game, but Alex wouldn't let him implement any actual gameplay features, so he was left with boring technical stuff like saving.

At least that's the most generous plausible scenario.


Someone give that programmer some coffee or alcohol
 
Back