They aren’t engine limitations, they are the basic limitations of any game like this, every game has loading screens between regions even single player ones, if you’re transitioning between areas something has to load, so yeah it kind of is a feature at this point, there is no game on this scale that wouldn’t require you to load in to a new area, so yeah
if that what the correct definition, then missions, ships, even anoms and sigs are instances.
IMO you mean “instantiated on demand”, that is one copy is generated each time someone wants one.
And to be fair, even abyssal deadspace isn’t a true “instance” as they all happen inside specific systems in the game, the SDE will even list all the known triglavian systems and constellations, they are basically just missions within a system
The pocket is instantiated, just as the missions pocket are .
However if someone wants to access your mission pocket he wont be generated a new one (so they are not instantiated on demand)
(my b, they are actually instantiated on demand, however they are not isolated instances)
This thread has seemed to derail from two points OP made in regards to current release trends in EVE to semantics about what an “instance” is.
To bring things back on track, OP made two points:
High paying solo activities, such as Abyssal sites, are pushing people away from player-player interaction which OP believes to be bad for an MMO to do.
An emphasis on providing players with rewards, which often expire or are permanently affixed to one character, for simple tasks like logging in are providing little long term content.
I definitely agree with the second point. Giving out items and skill points for logging in or subscribing seems like a desperate attempt at attracting players.
For the first it isn’t a problem limited to EVE as OP points out. All MMOs seem to have a trend of providing lots of solo activities where players can ignore everyone else on the server. This might be due to a trend that new players aren’t into the “old school” way of playing online and EVE is just trying to adapt to changing player wants. It’s definitely a more difficult issue to pin down.
2 Likes
This is the standard definition of instanced understood by developers world wide. That lay people don’t understand doesn’t change anything.
Missions are not instanced, you’ve never had a stranger show up in the area you were missioning? One copy of that space. Ships are not even places so they don’t count at all.
2 Likes
No, wrong. Abyss is 100% instanced, they may happen in the same systems but they are COPIES, which is the key word.
1 Like
as a dev, no this is not.
An instance is an element that conforms to a pattern/blueprint/deterministic algorithm with fixed parameters.
For example, if I have a cooking book, containing recipes, and I bake 4 cakes, each of those cakes is an instance of the “cake” recipe (in this case the recipes actually tells HOW to instantiate rather than WHAT to instantiate, but we can assume the process of building is deterministic enough to allow each production to be called a “cake” as long as the recipe is applied correctly)
Another example, if I have a car design, it is an instance of the “design” meta-design, and can be used to create “cars” (in that case the process of creation is not provided with the blueprint - only the structural state is provided)
The term of “instantiated” is opposed to “shared” (or in dev “singleton” concept ) . For example, the code of a library(eg file library, or network access library) is shared among the processes that use that library(so that there is no duplication of the code in the memory), but each process instantiate its own access to that library (to avoid one process modifying the access of another).
In the same way, a program can be considered a generator, with its instances being the processes. Also the code of a program is (part of…) the model to generate this program, so a program is (partially) an instance of the code.
Since we are talking a bout game environment, and since the game IS an instance of the code that models it, everything inside the game is an instance of the code/template that define it. Of course it’s not worth mentioning (it’s always true so why even talk about that ?) even the system Jita is an instance of the template used for it.
The only other meaning of 'instantiate" that makes sense here is “instantiated on demand”, that is a new instance is created when someone wants it.
so yes, mission pockets are instances of the mission pocket templates, and ship (and modules etc) are instances of the template in the code.
1 Like
It is like talking to a brick wall. He just doesn’t get it.
1 Like
Anderson
Maybe I’m just being picky, but I’ve never liked the template metaphor, especially the “cake recipe” style.
It’s not obvious to non-developers that in IT, the instance is (effectively **) an actual copy of the “template” (the non-static parts of the class), with some modifications done after copying. It’s not quite the same as the relationship between a recipe and a cake made using the recipe.
Anyway I prefer a “photocopier-style” metaphor: the copies can be independently used in different ways, modified, and destroyed after they’re created.
( ** Of course some parts of the original are used by all the copies, but that can’t be explained briefly )
lol, outted for not knowing your profession.
I don’t usually agree with Salt, but I think he’s correct in this case.
Instance is an IT technical term . As used in MMO gaming, it could be the whole game, but it’s normally a smallish part, usually (but not necessarily) at a specific location in the “singleton” game server.
Note that location doesn’t mean a lot to a game developer. Development-wise, teleporting is much easier than e.g. collision testing
Similarly instanced content isn’t really at its nominal location. A new isolated piece of the game is dynamically created, and the gamer(s) are teleported in. When they’re done they’re teleported back to a location in the main game.
Hu, no ?
If you copy a model you still have a model. So no, an instance of a class is not a copy of that class. Unless you have meta-modeling access in the language.
The point is that if you copy a recipe you have two recipes, not a recipe and a cake.
If you copy e.g. a file on an SSD “disk” you have two copies of the file.
My post wasn’t about the underlying accuracy of what you were saying. I just prefer a simpler metaphor.
Your post was just wrong.
Instances are NOT copies of the model.
A copy is a copy, and an instance is an instance.
in cpp, an instance of a class is just a pointer towards a structure, whose virtual pointer is set to that class’ virtual pointer. instanciating a class is only allocating space for that class size, settings its virtual pointer, and calling the correct method to construct it. There is no copy .
a template is a model that is used as a base for other models, ie it is copied and enriched. example, if a minimal mission model contains a beacon, then it can be enriched with a rat , a stargate, etc to generate other model, each one being able to generate instances for a specific mission.
but the copy is never an instance(again, unless acces to meta modeling in the model).
Anderson
I sense we’re discussing exactly how much (if any) of the executable code in the “original” is actually copied, as opposed to the data and data “containers”.
This isn’t the place.
Especially in a “fat client” game like EVE, where the graphics and a lot of the code are local, rather than on the server 
So is this thread an instance where a topic deviated from its original intent? 
4 Likes
don’t we see a pattern here ?
Hate to break it to you, but, it isn’t, it may “feel” like it, but thats because you can’t actually get between what is essentially the deadspace pockets in that system, its quite an ingenius way to solve a number of issues, means not having to really handle any different types of load, it means you can just spin up a single system that handles, for example, every single “instance” of a tier 3 thermal abyssal pocket and just scatter them far enough apart that they don’t overlap, which is easy, while disabling local and the directional scanner, players are then left none the wiser and you already have a known stable system for handling entry in to and out of deadspace pockets
Its smart use of tech you already have with enough minor changes to make it feel otherwise, systems are for all intents and puposes infinite in size as they are just a bunch of XYZ coordinates so its trivial to scatter people far enough apart, you also lock the grid size to prevent the overview from giving the trick away
I mean its pretty simple when you look at it from a purely technical point of view ignoring the smoke and mirrors
If that is what you want to believe that’s cool.
I’m at work and 5 other engineers are lolling you.
1 Like