I'd like to understand how the game "works" more

[AshlaBoga]

Back when when 2.5 was on the PTS, we got to see some level design. My communication with idnewton was very enlightening:

 

Wow, you guys really do use a super-freaky engine.... o.O

 

I don't know enough about video game engines to know if that map is unusual in any way. Can you elaborate?

 

The measuring tools are right on top of the max graphics world. In the second picture, the sphere volumes used to detect player proximity to the nodes is... irregular at best. Disturbingly reminiscent of the Pandemic engine from Star Wars Battlefront. All graphics, tools are hard to find and harder to use... it does match their description of the engine they've given in the past, specifically regarding a certain event (at this point I don't remember which it was, anymore). Their comment was something along the lines of "It's not just a simple switch to flip, it's vastly more complicated than that." And I remember thinking to myself, "But it should be a simple switch to flip."

 

Of course, it's entirely possible they turned on the full graphics just to give us a look at the engine parts that are actually within the world, as opposed to not having a wire-frame mode, lightning-only mode, unlit mode, etc.

 

You'd think there'd be turret spawn nodes, player spawn nodes, voice volumes (ie: "There's a ship NEAR THE B NODE"), etc. Path nodes probably wouldn't be there, because, well, there's no AI ships.

 

A bit busy this afternoon -- because, well, it's thanksgiving -- but I'll try to see if I can whip up a quick example of what I would consider a more 'ordinary' engine as seen behind the scenes.

 

Long day, decided to pull an example off the net rather than make my own, this time. I don't take credit for it, while it does look exceedingly amazin'-sauce. "Gray Matter" by Remus (http://www.remusbrailoiu.com)

 

 

In the engine I use, you have a lot of different view modes. Brush wireframe, poly wireframe, shader complexity, texture density, lighting-only, unlit, lit, and final (not really a view, just lit without the engine components).

 

It's rather complicated to go into detail about every single part, but some examples would include the apples (for whatever reason, they're apples) are AI pathing nodes, things like the bulb with the S are lights, the key-atop-the-audio-box icon at the far wall near the clock is an ambient sound source, etc. There are player spawns which look like joysticks (if you look really closely there's one in the hallway below at the far wall). Green wireframes are trigger volumes, to execute a command if you're A: inside the volume, or B: outside the volume (ie: you're within range to capture a turret, you open a door by being near it, etc.). Entirely possible to have more advanced commands related even to such a simple detector. ie: "once player enters it, do X", as opposed to simply "if player is inside, toggle X to 'on'. If outside, toggle off". Same for leaving it, same for being partially inside of it (but not entirely), etc. Probably by now you get the point.

 

Obviously each engine is going to have it's own way of showing player spawns, AI pathing, the nodes, the sound sources, the lights, and so on... There'll be even more diversity between the engines seeing as SWTOR uses an (old, I take it) MMO engine, whereas the one I showed here is an FPS one. That said, I still find it weird how the measuring tools are actually in the high-graphics display in the picture they showed. Of course that's possible in the engine I showed as well (as seen in the contrast between the 'Lit' and 'Final' pics), but what I mean is, if you're going to be showing engine elements, I'd think there'd be... more of them... A bunch of light sources, maybe some sounds, obviously no AI paths (because it's a pic of a PvP-only area) but you'd think there'd be turret spawn nodes.

 

Of course, we should also consider the possibility that they simply chose to show only the relevant engine elements.

 

(Again, thank you so much idnewton for all that neat info).

 

More recently I've seen people say that while the game engine can handle cross-server warzones,

their network infrastructure that can't.

 

I'm curious as to what that means.

 

Lastly, I know BW said that each robe and hood was individually coded and thus they would have to add a hood toggle on a case by case basis (making it almost a foregone conclusion that this will never happen), but I'm curious as to the differences in coding between being able to change a line or two of code and raise all hoods, or having to do it on a case by case basis.

 

I've played this game for about 21 hours a week for the last 2 years, yet I understand so very very little about how the game itself works. And I'd love to learn more:)

Edited January 8, 2014 by AshlaBoga

[tekhiun]

Only coding reason I can think of is that there is no parent class or if that there is one it doesn't contain the property for hood on/off ( most likely case imo ) . Either way it's really bad design at least they could have made one for all hooded robes. I struggle to believe that this is the reason though because this is like the first thing you learn in Object Oriented Design. Also does this mean that every helm has reference to every hooded robe in the game ? ***.

[Einobi]

More like there is no central software architecture design in the entire development. Everyone is doing their own coding in their own way. Where are the software architects? Where is the principal designer? Where are the quality controllers?

[Arkerus]

Personally I am very curious as to how the game "works" as well. Having spent time some time with open source engines, the HL engine and modern engines I know a thing or two. I know enough to be dangerous but not enough to know the true complexities.

 

Anything they share would be great for people like me.

 

One of the things that was so fascinating about the custom WoW engine was how simple it was. It was so simple the smallest things would break it. You could use all kinds of items and tricks to get inside unfinished sections or development areas. Heck, you could JUMP through the wall in some places.

 

Maybe simple is the wrong word. It sure as heck was easy to break.

Edited January 8, 2014 by Arkerus

[AshlaBoga]

Only coding reason I can think of is that there is no parent class or if that there is one it doesn't contain the property for hood on/off ( most likely case imo ).

Which is more likely, "no parent class" or "parent class doesn't contain the property for the hood"?

 

 

I struggle to believe that this is the reason though because this is like the first thing you learn in Object Oriented Design. Also does this mean that every helm has reference to every hooded robe in the game ? ***.

 

What does "every helm has reference to every hooded robe in the game" mean?

 

This is all new stuff for me.

[tekhiun]

Which is more likely, "no parent class" or "parent class doesn't contain the property for the hood"?

 

 

 

 

What does "every helm has reference to every hooded robe in the game" mean?

 

This is all new stuff for me.

 

Tbh I can't really tell which is more likely, but both are indicative of bad design. However I don't really know how things are done in this engine and it could very well be that the engine doesn't support this sort of thing , but then if it doesn't I have no idea why or how they chose to use it.

 

The basic principle is that if the parent class has this property , they only need to code the change once , however if it doesn't then they will have to alter the code for every single hooded robe in the game.

 

So what I mean by that is if a helm has to know if the robe has a hood or not , and you can't just ask the parent class, you would have to reference each robe individually , instead of just making a reference to the robe class .

 

 

Again I am just speculating here, so don't start quoting me around the forums:p

[Avicii]

I am not certain how their parent classes work it's kinda like the chairs works I makes sense that there's a chair parent class which all chairs would use. Why can you sit in your starships chair but not others? Because some one put a hack in that allows you to sit in it yet they can't apply to all chairs without breaking other things.

 

One thing to note is they have different Devs now and any programmer that was actual working experience knows a lot of people don't document their code or create documentation and reverse engineering others code can be a freaking pain in the ***. with a code base this large it can be extremely frustrating to do so.

 

OP if you are curious google Hero Engine and Object Oriented programming there is a wiki that details a lot of the under lying architecture and how it functions. Maybe without a back ground in CS it's confusing but you can google terms that are unclear or just start with object oriented programming and go from there.

 

One thing to note is they used a alpha version of gone engine I have heard, please correct me if I am wrong, and it is different then the finished product.

 

The poster calling them idiots is unfair without knowing what they did and why.

what we know is they had a lot of money invested in it and pressure to release and all Devs know what tends to occur when the pressures on people take short cuts that at the time get **** done but are a ***** in production to replace these areas or fix them. People wouldn't believe the mistakes I have found in people's DBs that supposed DBAs put in place or Devs create that should've went through DBAs.

 

But it's hard to judge them unless you are in the release cycle and know what choices were made. Although you can always slander them!

Edited January 8, 2014 by Avicii

[JattaGin]

One thing to note is they have different Devs now and any programmer that was actual working experience knows a lot of people don't document their code or create documentation and reverse engineering others code can be a freaking pain in the ***. with a code base this large it can be extremely frustrating to do so.

 

I don't really understand anything about game coding and engines. But when they changed the dev team I always had the feeling that the new devs sit in their chairs thinking all the time "what the h3ck did these guys do". And then we got so many new little bugs or old, already repaired bugs back into the game, which we users have a hard time understanding how it is possible. I always expected that the old crew did some unbelieveable tricks to fix bugs in unconventional ways and the new devs have to work hard to find out what they did, and re-program it in a believable way.

 

I remember one dev post which stated that they would love to fix the codex and are trying, but that it is super complicated. The code must be a mess. (Whatever this means.) Well, they have been fixing the codex during the last months. But slowly. And sometimes they just had to deactivate something instead of making it work. I guess that this would always be the last option for a dev: just deactive or delete something. So this says a lot.

 

I suspect that the code ist probably super terrible and messy and that is one reason why new content is mostly external (like a complete new planet or warzone etc.) which doesn't interfere (much) with the old code. And the cartel market code is extra coded as well. And it was coded by the new devs and they did it properly and that's why they can update it so often while the main game is not updated that much. This is my impression of the situation.

[DataBeaver]

I bet a part of the problem is that a lot of the game logic is actually contained in datafiles in some primitive scripting language. This means that bugs may be in the native code the interprets these scripts, in the tools used to make the scripts, or the scripts themselves. Furthermore, item scripts are often made by the same people who design the items, and they probably don't have a programming background.

 

I've done extensive reverse engineering on Anarchy Online's item data, and let me tell you, it's not a pretty sight. At last count there were 58 different operators for checking different things, some of which are unknown to me. In some cases there's more than one operator that seemingly check the same thing. The expressive power is seriously lacking. Base classes? Don't make me laugh. Copy-paste all the way. There are a few items which can be cycled through different stats or upgraded. This is implemented by a trigger that destroys the original item and spawns the next one. Naturally the trigger has to be duplicated in every item in the cycle.

 

On sites like torhead you can see some of SW:TOR's ability scripts. Unfortunately, those don't give me any reason to think SW:TOR would be any better than AO in this regard.

[branmakmuffin]

Regarding a hood toggle, there is obviously something in the code which says "lower the hood if the wearer is a Twi'lek."

[MillionsKNives]

Regarding a hood toggle, there is obviously something in the code which says "remove the hood if the wearer is a Twi'lek."

 

Fixed.

[AshlaBoga]

Regarding a hood toggle, there is obviously something in the code which says "lower the hood if the wearer is a Twi'lek."

 

I wish it was "lower hood," but on my Twi'lek's the hood is gone, not lowered.