Please switch the engine now before its too late..

[Hazed]

uh oh guys we have a comp science degree here

 

that is such a blanket degree that you may as well have told me "i know how to use microsoft products"

 

can you go more in-depth? did you spend more time on software programming? hardware optimization? tech support?

 

you can't just copy and paste the code for a game built around one engine and expect it to stick on a new engine, that's now how it works! why do you think it takes big box developers YEARS to develop a new engine and then release a major IP title with it? why don't they just "port" their latest entry into the new engine?

 

and fyi as you're a college graduate you should know pretty well that wikipedia is NOT a reliable source for anything, and as such you can't even use it as a cite-able source for coursework

 

you did know that, right? because if you didn't i'd have a hard time believing you actually went to college

 

here you go http://link.springer.com/chapter/10.1007/978-1-4302-4900-9_1

 

didn't think you could afford going into actual sources.. but if I were you i'd start there.. the intro stuff

 

It is not rocket science.. were dealing with virtual game assets.. all that stuff can easily be reworked into a new engine with time being the only constraint.

[Malastare]

here is a quick wiki on "porting" a game which is exactly what switching to a new engine entails

 

http://en.wikipedia.org/wiki/Porting

 

Ha ha ha ha ha ha ha.... haaah ha ... ha..

 

Are you serious? You think that changing engines is called "porting"?

 

Ha ha ha.

 

Ha.

 

Sorry, OP, but it's hard to see how you can understand so little about what you're talking about, and the mistakes you're making because of that are just laughable now. The reason why porting a game between operating systems (such as, porting an XBox game to run on Windows) works is because the game engine doesn't change. You still don't seem to even grasp what a game engine is, but that's not shocking because you don't seem to fully understand what coding is, either. And now that just baffles me.

 

seriously?

So taking assets from a game and "porting" or "copying and pasting" them to another base or "ENGINE" is not the same thing?

 

NO.

 

Not at all. Why would you ever think it was? Why would you think that you'd just be able to paste resources optimized for the Hero Engine into Frostbite? They use completely different APIs, completely different object models, completely different service architectures...

 

Its funny because I am probably the only one here with an actual computer science degree LMAO

 

I weep for my profession. I've been a professional developer for 12 years. When I was a sophomore in university we learned about porting code and my professors specifically showed examples of why porting code between OSes was easier that switching application code on one OS to a different framework on another. This is seriously basic software engineering stuff. In my LAN class, we talked about the difficulty of converting code from one network framework to another. Porting Berkeley Sockets code on UNIX to Berkeley Sockets code on Win32 is easy, but converting it to native WinSock code is costly. Trying to convert it to Java NIO is barely worthwhile.

 

So for future reference what c/p to another engine entails

 

c/p visual assets

c/p audio assets

c/p scripts.. if that does not work then you rewrite scripts accordingly.. although the scripting was most likely done in Python so its probably NOT an issue to c/p that as well.

 

Wow.

 

Just wow.

 

You still don't understand anything about game coding. You think the bulk of this game is run by Python scripts? Seriously? You must be trolling. Or lying about having any code experience, because that's just so embarrassingly wrong that I don't know where to start.

 

SWTOR is not run by a bunch of Python scripts. That's... just no. Take a look at the binary. Take a look at the process. Watch the API calls. It's a native DX/Win32 app coded in C/C++. The game has many pixel shaders. I guarantee you those are not written in Python.

 

Just... I don't even know where to go with this. It's like trying to refute someone who has just claimed that cars are fueled by applesauce.

[MillionsKNives]

man i went to a ****** college

 

they didn't have it structured the way you're talking about... that's what i get for going to a catholic school

 

At least yours probably had some women. My year hit a record high ratio of women at 30% across all majors. CS had like 2 graduating females.

[Hazed]

Ha ha ha ha ha ha ha.... haaah ha ... ha..

 

Are you serious? You think that changing engines is called "porting"?

 

Ha ha ha.

 

Ha.

 

Sorry, OP, but it's hard to see how you can understand so little about what you're talking about, and the mistakes you're making because of that are just laughable now. The reason why porting a game between operating systems (such as, porting an XBox game to run on Windows) works is because the game engine doesn't change. You still don't seem to even grasp what a game engine is, but that's not shocking because you don't seem to fully understand what coding is, either. And now that just baffles me.

 

 

 

NO.

 

Not at all. Why would you ever think it was? Why would you think that you'd just be able to paste resources optimized for the Hero Engine into Frostbite? They use completely different APIs, completely different object models, completely different service architectures...

 

 

 

I weep for my profession. I've been a professional developer for 12 years. When I was a sophomore in university we learned about porting code and my professors specifically showed examples of why porting code between OSes was easier that switching application code on one OS to a different framework on another. This is seriously basic software engineering stuff. In my LAN class, we talked about the difficulty of converting code from one network framework to another. Porting Berkeley Sockets code on UNIX to Berkeley Sockets code on Win32 is easy, but converting it to native WinSock code is costly. Trying to convert it to Java NIO is barely worthwhile.

 

 

 

Wow.

 

Just wow.

 

You still don't understand anything about game coding. You think the bulk of this game is run by Python scripts? Seriously? You must be trolling. Or lying about having any code experience, because that's just so embarrassingly wrong that I don't know where to start.

 

SWTOR is not run by a bunch of Python scripts. That's... just no. Take a look at the binary. Take a look at the process. Watch the API calls. It's a native DX/Win32 app coded in C/C++. The game has many pixel shaders. I guarantee you those are not written in Python.

 

Just... I don't even know where to go with this. It's like trying to refute someone who has just claimed that cars are fueled by applesauce.

 

so tell me how these guys can do a whole game from the ground up in 2 years?

https://robertsspaceindustries.com/

 

now once you wrapped your head around that get back to me about what can't and can be done.

[Eilan_Sorn]

here you go http://link.springer.com/chapter/10.1007/978-1-4302-4900-9_1

 

didn't think you could afford going into actual sources.. but if I were you i'd start there.. the intro stuff

 

It is not rocket science.. were dealing with virtual game assets.. all that stuff can easily be reworked into a new engine with time being the only constraint.

 

i think you're deliberately ignoring the five or six people in the thread who actually know what they're talking about

 

i didn't take my degree in computer science, i opted for business and language, so i don't count myself in that number...

 

but there are more to games than assets and engines! as SEVERAL people have now already said! you can't just dump the assets and code into a new engine and call it good! there is a reason they build games around engines and not the other way around!

[Malastare]

here you go http://link.springer.com/chapter/10.1007/978-1-4302-4900-9_1

 

didn't think you could afford going into actual sources.. but if I were you i'd start there.. the intro stuff.

 

Ha ha ha ha....

 

You think that a point-and-click adventure game is a reasonable analogy? Hah.... Sorry, I'm going to go tell the engineers at Toyota that they suck at their job because I read a book named "Build Your First Bike".

[MillionsKNives]

Just... I don't even know where to go with this. It's like trying to refute someone who has just claimed that cars are fueled by applesauce.

 

Apples come from trees and trees release carbon dioxide when burned. Gasoline also releases carbon dioxide when burned. They're the same thing!

[Hazed]

heres more

 

python to c++

 

or c++ to python

 

not difficult

 

http://stackoverflow.com/questions/4650243/convert-python-program-to-c-c-code

 

what makes it hard for EA is they outsourced almost EVERYTHING.

 

 

Keep drinking the kool-aid bro

[MillionsKNives]

so tell me how these guys can do a whole game from the ground up in 2 years?

https://robertsspaceindustries.com/

 

now once you wrapped your head around that get back to me about what can't and can be done.

 

You realize that they haven't finished the game yet right?

[Hazed]

You realize that they haven't finished the game yet right?

 

dogfighting alpha begins in a few months bro

 

and client (hanger module) is already up

[MillionsKNives]

dogfighting alpha begins in a few months bro

 

and client (hanger module) is already up

 

It's pre-alpha bro.

[Hazed]

It's pre-alpha bro.

 

They have been working on it less than a year though

[Malastare]

so tell me how these guys can do a whole game from the ground up in 2 years?

 

Have they? They started work in 2011. It's late 2013... and there's no game. They hope to have a short single-player campaign by early 2014, with a persistent universe sometime in early 2015.

 

now once you wrapped your head around that get back to me about what can't and can be done.

 

What does one have to do with the other? The whole point people are trying to get across to you is that "changing the engine" == "rewriting the game". You, laughably, think that some intern can do it. If you honestly do have a degree in computer science, then I'll be depressed for the rest of the day. My university program had classes specifically designed to teach us how silly that sort of notion was and you would not have been able to pass the class or get a degree with that sort of naive understanding of software.

 

You know what, you like websites, try this one:

 

Your First HSL Script

 

That is the primer to the very simplest part of the Hero Engine, the great-uncle of SWTOR's engine. Note how the script is not Python. Note how its specific to the engine and cannot be used in other engines. Now, realize that its just doing some simple UI stuff. It is able to interact with a game. This sort of thing is how they script up quest progression. Yay, fine. But you're not going to use it to draw objects on the screen. You can just request that the engine do it. That's the way scripts like these work. They are the quick-n-dirty ways of plumbing engine API calls together. If Bioware wants to add some new quest behavior --such as the macrobinoculars activities-- that functionality needs to be coded into the engine. You might be able to use a script to create a new Dye Module, but the code that knows how to use the data from that object to change how a model is textured comes from the engine.

 

And then there is the whole idea of all the optimizations they've added. The animation-granularity-by-distance thing was an engine fix. Support for MegaServers? That was the engine. Server selectors? Appearance designer? Achievements? Reputation? 4-man arena framework? All of those needed to have code added to the engine.

 

See, the engine is not just a vehicle that the game rides on. The engine is the vital organs of the game.

[MillionsKNives]

They have been working on it less than a year though

 

Two years. They began work on it for a year before the kickstarter even began. The campaign began last October.

[Malastare]

python to c++

 

or c++ to python

 

not difficult

 

http://stackoverflow.com/questions/4650243/convert-python-program-to-c-c-code

 

Oh god. You just don't get it.

 

It's not the language that presents the greatest barrier. It's the API. How could you seriously make it though a CS degree program without understanding these basic things.

 

Do you seriously think that the language defines the capabilities of a piece of code? If I write a game with the Gamebryo engine and extend it with Python scripts, converting those Python scripts to C will get me absolutely nowhere if I want to switch to a different engine. Those Python scripts are targeting a Gamebryo API, and structured to be loaded and executed by Gamebryo. Even if you have Source (engine) plugins in C, those same C plugins can't be used in another engine that uses C plugins. Even more to the point: In most cases, the graphical and even audio assets can't be simply copied from one engine to another.

[Hazed]

Oh god. You just don't get it.

 

It's not the language that presents the greatest barrier. It's the API. How could you seriously make it though a CS degree program without understanding these basic things.

 

Do you seriously think that the language defines the capabilities of a piece of code? If I write a game with the Gamebryo engine and extend it with Python scripts, converting those Python scripts to C will get me absolutely nowhere if I want to switch to a different engine. Those Python scripts are targeting a Gamebryo API, and structured to be loaded and executed by Gamebryo. Even if you have Source (engine) plugins in C, those same C plugins can't be used in another engine that uses C plugins. Even more to the point: In most cases, the graphical and even audio assets can't be simply copied from one engine to another.

 

Are you even reading what your saying?

[Malastare]

Are you even reading what your saying?

 

Yes. Are you?

[Andryah]

Are you even reading what your saying?

 

Now you are just being ironic.

[Hazed]

Yes. Are you?

 

 

Yes, but I am starting to understand what is going on here.

 

You must live in a parallel universe, one in which writing code is for shamans and has more to do with magic than actually writing lines of code.

 

At the end of the day its only lines of code that tell other lines of code what to do.. so I can understand your position that this is somehow a mystical environment that is impossible for people to comprehend.

 

Even then,

 

it can still be done.. get enough wizards to conjure up lines of code and then reform those lines of code onto a new framework for the code so it doesn't have the drawback that the current framework has.

 

 

broken down even simpler

 

write 0101010111010111010101111010101110101010101010101010101 over and over till you get it.

 

You aren't splicing atoms BRO

[DOHboy]

Oh god. You just don't get it.

 

It's not the language that presents the greatest barrier. It's the API. How could you seriously make it though a CS degree program without understanding these basic things.

 

Do you seriously think that the language defines the capabilities of a piece of code? If I write a game with the Gamebryo engine and extend it with Python scripts, converting those Python scripts to C will get me absolutely nowhere if I want to switch to a different engine. Those Python scripts are targeting a Gamebryo API, and structured to be loaded and executed by Gamebryo. Even if you have Source (engine) plugins in C, those same C plugins can't be used in another engine that uses C plugins. Even more to the point: In most cases, the graphical and even audio assets can't be simply copied from one engine to another.

 

SLOC is SLOC. going from an one api to the next is simple as ( int) unsigned <variable>. nothing possible go wrong there

 

why you mad bro?

 

at least we got passed copy and past and are now on porting. who cares if we have to rewire entire classes, change prototypes is actually the easy part. when you start getting into multiple indirection, function pointers, and OOP that can get pretty interesting pretty fast.

 

OP probably took nothing but java classes googled everything and turned it in. Actual programming probably been lost.

[Malastare]

You must live in a parallel universe, one in which writing code is for shamans and has more to do with magic than actually writing lines of code.

 

I'm starting to believe that you don't have any significant, professional experience with code. In looking over your other comments, I get a strong feeling of academic experience without a practical application. It's like you've only ever worked on small-scale applications, or you've only worked on filling in some gap that was pre-defined. Maybe you're just not in the software industry. I've met a number of brilliant network engineers or hardware designers who just don't understand the first thing about software development. Or maybe they just forgot it.

 

Code is code, yes, but language and bits and stacks don't define what that code is capable of. In the end, code is capable only of what its interfaces allow it to do. Even kernel code is subject to the restrictions of the hardware interfaces it runs on. Your

 

Imagine I write a HSL script in SWTOR to set up the scoring behavior for a new Warzone. Now, imagine that Bioware decides to replace the game engine (as impractical and nonsensical as that is) with Frostbite. That HSL script cannot be used in Frostbite. It cannot be converted for use in Frostbite. There is no wrapper or facade that will let Frostbite load up that HSL script. The issue, at a very basic level, is interfaces. The SWTOREngine exposes a very specific API to HSL scripts. Scripts are allowed to access that API, and the loading of those scripts assumes that the conventions and restrictions of the API will be respected. Would Frostbite toss errors if it ran the HSL script? No. Trick question, though, because Frostbite doesn't even know what HSL is. Frostbite can't load the script. If it did load the script, it wouldn't know what to do with it, because it doesn't use (or even know) SWTOREngine's API. The HSL script would be referencing objects and routines that don't exist. In fact, the HSL script wouldn't even know where to load itself, because it is built around a client/server data model which isn't even defined by Frostbite.

 

Anyway. I'm off to go refactor some code for a large-scale service. I'll let the world decide which of us knows what we're talking about: The guy who is describing the concepts behind APIs and porting code, or the guy who can't seem to even express his ideas in proper technical terms.

[Akrian]

OP, you seem to like binary so here is some BCD, with a special message inside just for you if you can decode it. If you have problems I might give you a hint later.

 

0100 0100 0110 1001 0110 0101 0010 1100 0010 0000 0110 1001 0110 1110 0010 0000 0110 0001 0010 0000 0110 0110 0110 1001 0111 0010 0110 0101 0010 0001 0010 0001 0010 0001.

[ninjonxb]

Imagine I write a HSL script in SWTOR to set up the scoring behavior for a new Warzone. Now, imagine that Bioware decides to replace the game engine (as impractical and nonsensical as that is) with Frostbite. That HSL script cannot be used in Frostbite. It cannot be converted for use in Frostbite. There is no wrapper or facade that will let Frostbite load up that HSL script. The issue, at a very basic level, is interfaces. The SWTOREngine exposes a very specific API to HSL scripts. Scripts are allowed to access that API, and the loading of those scripts assumes that the conventions and restrictions of the API will be respected. Would Frostbite toss errors if it ran the HSL script? No. Trick question, though, because Frostbite doesn't even know what HSL is. Frostbite can't load the script. If it did load the script, it wouldn't know what to do with it, because it doesn't use (or even know) SWTOREngine's API. The HSL script would be referencing objects and routines that don't exist. In fact, the HSL script wouldn't even know where to load itself, because it is built around a client/server data model which isn't even defined by Frostbite.

 

I find this very fitting for what you are doing right now http://devopsreactions.tumblr.com/post/62797205545/whenever-i-find-an-old-legacy-code-bug

I feel for you, we are currently in the process of transitioning our entire ACS backend to ruby...

[ninjonxb]

OP, you seem to like binary so here is some BCD, with a special message inside just for you if you can decode it. If you have problems I might give you a hint later.

 

I just got some weird looks at work. I burst out laughing with that one ... not sure why

[DOHboy]

OP, you seem to like binary so here is some BCD, with a special message inside just for you if you can decode it. If you have problems I might give you a hint later.

 

0100 0100 0110 1001 0110 0101 0010 1100 0010 0000 0110 1001 0110 1110 0010 0000 0110 0001 0010 0000 0110 0110 0110 1001 0111 0010 0110 0101 0010 0001 0010 0001 0010 0001.

 

Ummm thats not BCD... Binary Coded Decimal uses 4 bits to represent numbers 0-9 so 4 bits per digit.

 

so assume you are talking ASCII

which at this point might be a bit harsh upon translation