513 réponses à ce sujet

[hoorayforicecream]

Fast Jimmy wrote...

Cool enough things in theory, but I'd be a lot more excited to see if the engine upgrades let us walk through a city of NPCs who are all interactable, can move about on their own and have their own activities, rather than just standing in place for seven years. Or a way to approach situations outside of A) combat or a dialogue wheel Auto-win. Stealth options or warfare gameplay (since we are in the middle of a war and possibly controlling a castle/fortress) would be nice. As would using magic outside of combat to solve problems/puzzles/quests, like creating an ice bridge instead of going through the valley and fighting hordes of mooks.

Those are the concepts and ideas I'd like to see an engine use. Not better cutscenes or more realistic grenades.

All of those are handled by gameplay, not engine.

[Fast Jimmy]

They are all elements of gameplay strongly influenced by the use and design of the engine.

[hoorayforicecream]

Fast Jimmy wrote...

They are all elements of gameplay strongly influenced by the use and design of the engine.

False.

[Maria Caliban]

I'm going to pull a quote from the Game Engine FAQ.

"Many term "engine" to mean the more specific hardware-oriented stuff, cutting out the gameplay system entirely from what's considered "engine". It will vary from place to place, but the generally accepted industry definition is "the stuff that is owned by programmers who really only have to talk to other programmers". Gameplay programmers and tools programmers spend a lot of time dealing with artists and designers, but engine programmers mostly just deal with other programmers."

[Fast Jimmy]

hoorayforicecream wrote...

Fast Jimmy wrote...

They are all elements of gameplay strongly influenced by the use and design of the engine.

False.

Having the gameplay element of having multiple NPCs walking around on the screen who could be in the state of a myriad of efferent animations, random dialogue banter and still remaining interactive by the PC has nothing to do with the engine? 

I think you are underplaying the significance of a game's engine in how it's final design comes to fruition. 

Modifié par Fast Jimmy, 04 novembre 2012 - 10:16 .

[hoorayforicecream]

Fast Jimmy wrote...

hoorayforicecream wrote...

Fast Jimmy wrote...

They are all elements of gameplay strongly influenced by the use and design of the engine.

False.

Having the gameplay element of having multiple NPCs walking around on the screen who could be in the state of a myriad of efferent animations, random dialogue banter and still remaining interactive by the PC has nothing to do with the engine? 

I think you are underplaying the significance of a game's engine in how it's final design comes to fruition. 

Correct. It has almost nothing to do with the engine. All of that is handled by data, which is parsed and dealt with by gameplay code. Only at the lowest level ("play an animation", "play a sound") does the engine get involved, and in that case nothing specific to that is done. NPCs talking and animating is the exact same underlying system as PCs attacking or casting spells or moving.

I've worked on analogous systems to every single thing you mention. I've built ambient NPCs. I've co-authored two different stealth systems. I've built dynamic pathing maps for NPCs, and I've built levels that require specific gating mechanisms to progress past. I've written scenarios and scripted level progression paths.

Unless you're reducing things to a pointless level like "it's all just code!", you have no leg to stand on. The engine does very little for any of the stuff you're talking about. I've been there. I've worked with the engine programmers about what it is I need from them to make stuff work. I've written most of the stuff myself. 

Most of what you're talking about wouldn't even involve a programmer at all, let alone engine work. Most of it is handled by designers, not programmers. Engine stuff is handled exclusively by programmers. Gameplay programmers serve as the buffer between designers + artists and the engine programmers. Unless it involves an engine programmer at some point, it doesn't involve anything on the engine level.

Modifié par hoorayforicecream, 04 novembre 2012 - 10:32 .

[Milan92]

Ivandra Ceruden wrote...

^ Watch out, we got a bad@ss here.

That was really immature, she is simply telling that she has experience with it and because of that probably knows it beter.

Modifié par Milan92, 04 novembre 2012 - 10:53 .

[John Epler]

Ivandra Ceruden wrote...

^ Watch out, we got a bad@ss here.

Unless you'd care to add something constructive to the thread, I strongly recommend recusing yourself. This is not the comments section on Yahoo.

[Maria Caliban]

Ivandra Ceruden wrote...

^ Watch out, we got a bad@ss here.

Average poster who has never worked on game talks about engine = fine.

Experienced game developer talks about engine = mock her.

Oh BSN, never change.

[Fast Jimmy]

hoorayforicecream wrote...

Correct. It has almost nothing to do with the engine. All of that is handled by data, which is parsed and dealt with by gameplay code. Only at the lowest level ("play an animation", "play a sound") does the engine get involved, and in that case nothing specific to that is done. NPCs talking and animating is the exact same underlying system as PCs attacking or casting spells or moving.

I've worked on analogous systems to every single thing you mention. I've built ambient NPCs. I've co-authored two different stealth systems. I've built dynamic pathing maps for NPCs, and I've built levels that require specific gating mechanisms to progress past. I've written scenarios and scripted level progression paths.

Unless you're reducing things to a pointless level like "it's all just code!", you have no leg to stand on. The engine does very little for any of the stuff you're talking about. I've been there. I've worked with the engine programmers about what it is I need from them to make stuff work. I've written most of the stuff myself. 

Most of what you're talking about wouldn't even involve a programmer at all, let alone engine work. Most of it is handled by designers, not programmers. Engine stuff is handled exclusively by programmers. Gameplay programmers serve as the buffer between designers + artists and the engine programmers. Unless it involves an engine programmer at some point, it doesn't involve anything on the engine level.

While I appreciate you listing your credentials, I think you are still oversimplifying things.

Changing engines is more than just the engine itself. All of the tools, software and techniques you had used on the previous engine are possibly of little to no help. Which isn't that big of a deal, when you are working with an engine that has previously been used to create similar games, as there would be tools already created to implement gameplay features already created. But if an engine has only been used to make shooters, chances are there hasn't been much work done to create tools for the engine that can help create the type of game you want.

As an allegory, imagine you are moving into a new house. But the new house has narrow doorways, doorways much more narrow than the house you are living in. None of your old furniture, appliances or other stuff can fit in the house, requiring you to buy all new stuff to replace it. You can make the case that the house design has nothing to do with you buying new furniture, but it doesn't negate the fact that you are having to start from scratch with more of your furntiure and large appliances just because the design of the house. 

In a similar way, moving to a new engine that has never been used to create an RPG would not let you take any of the tools or techniques you had previously developed with you, nor will there be any "on the shelves," so to speak, that could be used to springboard off from. Allan and others have already mentioned how the new engine doesn't have any tools or abilities to handle certain cutscenes or dialogue. That means it could be an uphill battle on the new engine, right from the start.

You obviously have more experience doing programming than I do. But I think you are also looking at things the way you want to see them, as well. 

Modifié par Fast Jimmy, 05 novembre 2012 - 01:54 .

[ObserverStatus]

I modded Fallout 3 once.

[hoorayforicecream]

Fast Jimmy wrote...

While I appreciate you listing your credentials, I think you are still oversimplifying things.

Changing engines is more than just the engine itself. All of the tools, software and techniques you had used on the previous engine are possibly of little to no help. Which isn't that big of a deal, when you are working with an engine that has previously been used to create similar games, as there would be tools already created to implement gameplay features already created. But if an engine has only been used to make shooters, chances are there hasn't been much work done to create tools for the engine that can help create the type of game you want.

Wrong. The engine does a lot to create the type of gameplay you want. Here's the general list of things the engine does:

- Renders things on screen
- Streams data from drive into memory
- Plays audio when told
- Plays animations on models when told
- Handles geometric collision
- Loads data from drive into the correct sections of memory for system access
- Handle the connection, transmission and processing of data of multiplayer data
- Handles physics applied to objects
- Handles lighting calculations
- Handles visualization adjustments, like field of view, depth of field, saturation, etc.

The ability to handle these sorts of tasks better than the previous engine is the primary reasoning behind engine changes. The sort of changes you're talking about are still gameplay changes, not engine ones. Just because there exists work to be done does not make them engine changes. It just makes them systems that gameplay needs to build (or rebuild, or port) because of an engine change. 

You obviously have more experience doing programming than I do. But I think you are also looking at things the way you want to see them, as well. 

You want to know what I've also done before that you probably haven't? I've worked on a project that changed engines mid-cycle. And I did something very similar to what you were talking about - I built a cinematic melee combat system where there didn't exist one before. But I didn't make any engine changes. There were certain things I built to ask the engine to do things for me, like "play this animation", and "check for collision within these parameters". But my system, and the AI state machine system on which it was based, was all gameplay. It wasn't engine work. It didn't fundamentally change the behavior of the hardware, or rendering, or networking, or physics, or sound, or input, or animation, or any of the host of low-level systems taken for granted. It just used those options afforded by those existing systems to work.

Which means you are still, as you have been, wrong. You might as well say "Well, kilogram has a different meaning to me". You could say it, but it would sound ridiculous.

[Fast Jimmy]

You still aren't making any sense.

In a similar way, moving to a new engine that has never been used to create an RPG would not let you take any of the tools or techniques you had previously developed with you, nor will there be any "on the shelves," so to speak, that could be used to springboard off from. Allan and others have already mentioned how the new engine doesn't have any tools or abilities to handle certain cutscenes or dialogue. That means it could be an uphill battle on the new engine, right from the start.

I've worked on a project that changed engines mid-cycle. And I did something very similar to what you were talking about - I built a cinematic melee combat system where there didn't exist one before. But I didn't make any engine changes. There were certain things I built to ask the engine to do things for me, like "play this animation", and "check for collision within these parameters". But my system, and the AI state machine system on which it was based, was all gameplay. It wasn't engine work.

How are these two statements incongruent? My concern is that moving to a new engine is going to cause them to have to reinvent the wheel, something you JUST said you had to do when you changed engines mid-development.

When we make a change mid-project in the business world, the cost benefit ratio is analyzed. Since obviously there is a cost being incurred to make this change, I am simply curious to ask what benefits it is bringing to the table. For you to imply I am saying you COULDN'T program an engine to do anything you want is not at all what I am arguing. I'm saying it will cause work, lose existing tools/techniques and eat time. Which is fine, if the engine change brings functionality to the table that is worth it.

So far, I've only heard comparisons and statements giving evaluations of Frostbite's graphical capabilities, but very little in what it provides in tools and support that could enrich (or even meet the already placed bar) of Bioware's RPG games.

Going back to the cost benefit ratio concept, I can see why EA sees value in it, as having all or most of their big development branches using the same engine has obvious bottom-line benefits. But I have yet to see anything mentioned about any underlying functionality that brings something to the table to what Bioware games do best. Not to say that there ISN'T anything the new engine does, but that is why I and others are asking the question.

And that is a question only a member of the Bioware development team, not you, can answer. Launching into a lecture on the specifics of software development when you can't answer the question with any real validity only makes you appear incredibly pedantic.

[hoorayforicecream]

Fast Jimmy wrote...

You still aren't making any sense.

How are these two statements incongruent? My concern is that moving to a new engine is going to cause them to have to reinvent the wheel, something you JUST said you had to do when you changed engines mid-development.

They aren't incongruent. You're moving the goalposts. Here is what you said originally:

Fast Jimmy wrote...

Cool enough things in theory, but I'd be a lot more excited to see if the engine upgrades let us walk through a city of NPCs who are all interactable, can move about on their own and have their own activities, rather than just standing in place for seven years. Or a way to approach situations outside of A) combat or a dialogue wheel Auto-win. Stealth options or warfare gameplay (since we are in the middle of a war and possibly controlling a castle/fortress) would be nice. As would using magic outside of combat to solve problems/puzzles/quests, like creating an ice bridge instead of going through the valley and fighting hordes of mooks.

Fast Jimmy wrote...
They are all elements of gameplay strongly influenced by the use and design of the engine.

Fast Jimmy wrote...
Having the gameplay element of having multiple NPCs walking around on the screen who could be in the state of a myriad of efferent animations, random dialogue banter and still remaining interactive by the PC has nothing to do with the engine? 

You seem to remain ignorant of the fundamental divide between gameplay and engine. The engine handles the nuts and bolts. It handles things like the actual act of rendering - deciding what pixel is what color, and filling that in. The actual movement of animation skeleton at a given time frame. The streaming of data into memory. The loading of assets. The calculations done on objects to make it behave as if they are swinging under the effects of inertia, gravity. 

None of the features you're talking about are engine-specific, or require any sort of work on the engine, because displaying things, playing animations, calculating lighting and physics, collision detection, all that sort of thing is a basic requirement of game development. You're almost guaranteed to need it no matter what sort of game you make.

But the sort of stuff you're talking about - even though it is work that's necessitated by an engine change, it is not actually engine related. It's just work to be done. It is done by gameplay. That the work is mandated by an engine change instead of by design doesn't make it engine-affiliated. It's still handled by the gameplay programmers, not the engine programmers.

You can usually figure out what sort of work it is by the title of the person who does it. That's how things tend to work - you hire somebody to do a specific job, and that person does it. The people who work on the engine are engine programmers. The people who work on gameplay elements are gameplay programmers. The people who work on tools are tools programmers. Those features you're talking about are all gameplay.  They're handled by gameplay.

For them to involve the engine, I would have to go to an engine programmer and say "Hey, the engine doesn't do this and I need it to do this." But the only question I need to ask in any of the examples you've given is "How do I make it do this?" because the engine already does it.

This is why I said those are handled by gameplay - because gameplay programmers are the ones who (will) create, maintain, and own those features. 

[Fast Jimmy]

You say I'm moving the goal posts, I say you are being overly obtuse to try and make an argument.

The previous Lyrium engine had tools and programming to handle all of the mechanics of DA games already created. The Frostbite 2 engine has none of them. So in order to accomplish many of the same basic tasks and functions in DA3, they will either need to create new software that works with new engine to do these things, or they will have to try and migrate this over to the new engine.

I don't care if who is doing the actual work are engine programmers, or gameplay programmers or members of the freaking Lollipop Guild... the work needs to be done, it will cost time and money and it wouldn't have to be done if they were not migrating to a new engine.


So again, I ask... does anyone from Bioware have any feedback on what Frostbite 2 brings to the table other than nicer graphics and a better bottom line for EA?

[axl99]

[Oh god the irony..]

Ahem.

For the past while the Bioware devs have been placing a gag order on themselves until they're damned ready to answer the above poster's question. Show not tell, they said. Chances are they're going to wait until they have a decent playable build to show everyone what they were able to do with their shiny new tech.

So keep your pants on sparky :\\. What's your rush?

Modifié par axl99, 05 novembre 2012 - 05:14 .

[hoorayforicecream]

Fast Jimmy wrote...

You say I'm moving the goal posts, I say you are being overly obtuse to try and make an argument.

You made a statement. It was wrong. I called you on it, and you refused to listen. Now you're just trying to pass it off as "it's all work that needs to be done anyway". So yeah, I'm making an argument because I happen to think that more people understanding what a game engine is and isn't would actually help them understand what sort of new features can be implemented because of the engine. I think that less overall ignorance is better than more. I think people would appreciate understanding the difference between something that's a gameplay feature and something that's an engine feature, especially when the thread topic is about the engine.

I guess we disagree on that.

[Fast Jimmy]

Yes, we do disagree. Your posts, while drenched with technical data, seem to also imply that an engine is an engine and any engine can be used to create any portion of the gameplay progrmming. While my ignorant, plebian posts still managed to point out that switching the engine mid-project (which, given that the game is set to come out a year from now, I would HOPE they are mid-project) would run the risk of losing lots of resources, time and functionality.

But I don't know what I'm talking about... so I'm going to quote a fellow BSN member's blog to try and express my concerns.

Fast Jimmy wrote...
Having the gameplay element of having multiple NPCs walking around on the screen who could be in the state of a myriad of efferent animations, random dialogue banter and still remaining interactive by the PC has nothing to do with the engine? 

Quote from blog...
Because different engines are good at different things. Some of them are optimized for displaying lots and lots of dudes on the screen at once (like the one Koei uses for their Dynasty Warriors games). The tradeoff is that the dudes aren't as well-detailed as they could be, but that doesn't matter because you don't often spend a lot of time looking at the dudes when you're mowing them down by the dozen. Other engines are great for things like great lighting and effects... but the tradeoff there is that you need a lot of fantastic artists to create the content that really takes advantage of that engine.

Hmmm. It seems based on that blog, an engine WOULD play a role in having multiple NPCs on screen at once in an ambient environment.

But I'm obviously wrong about the change in engine having a negative downstream effect in losing all progress made to date on a game, right?

Quote from blog...
The artists, designers, and producers are mostly creating assets in the meantime while waiting for the game to get up and running for them again. When a developer is working on a project, they have to decide whether the engine switch is worth it in the long run. The earlier the switch is made, the better, since they don't have to worry as much about possibly losing work. That's a pretty big topic in and of itself, and one that really affected one of the projects I worked on for its entire 2.5 year cycle.

Hmmm. I guess I may have had a valid point on that as well.

Now, hooray, before you criticize the ideas of this blogger, please know I don't know them that well, but from what I understand, they have over 10 years experience as a software engineer in the industry.



This thread is about the engine change to FB2, which is not to just talk engine specs, but also all of the impact said engine change would have. Including having to re-create all the tools and resources already created with the previous engine. So just because my requests for information dot have 100% to do with engine design and code, doesn't make them immaterial to the conversation at hand.

Modifié par Fast Jimmy, 05 novembre 2012 - 06:40 .

[hoorayforicecream]

Fast Jimmy wrote...

Yes, we do disagree. Your posts, while drenched with technical data, seem to also imply that an engine is an engine and any engine can be used to create any portion of the gameplay progrmming.

They can. Gameplay programming can generally be done with any engine, because it's invariably data driven and the things gameplay needs tend to be common across all engines. How well the engine performs those tasks determines whether the engine suits the needs of the gameplay. You can display as many NPCs as the system resources will allow with any given engine, and that includes the Hero, Unreal, Frostbite, Eclipse, Gamebryo, Unity, or an in-house one. They perform this task with different amounts of effectiveness, but that doesn't mean that the engine can't do it.

I'll just go ahead and snip your attempts at red herrings out.

Fast Jimmy wrote...
Having the gameplay element of having multiple NPCs walking around on the screen who could be in the state of a myriad of efferent animations, random dialogue banter and still remaining interactive by the PC has nothing to do with the engine? 

Quote from blog...
Because different engines are good at different things. Some of them are optimized for displaying lots and lots of dudes on the screen at once (like the one Koei uses for their Dynasty Warriors games). The tradeoff is that the dudes aren't as well-detailed as they could be, but that doesn't matter because you don't often spend a lot of time looking at the dudes when you're mowing them down by the dozen. Other engines are great for things like great lighting and effects... but the tradeoff there is that you need a lot of fantastic artists to create the content that really takes advantage of that engine.

Hmmm. It seems based on that blog, an engine WOULD play a role in having multiple NPCs on screen at once in an ambient environment.

The number of NPCs able to run at a solid frame rate at any given time would depend on the engine, yes. It also depends on system hardware limitations. The animation, random dialogue banter, and interactivity of the PC would not, which was what I assumed you cared more about and not the number of NPCs displayed on the screen at once. And even here, you moved the goalposts. Originally, you were talking about a city full of interactable NPCs, not how many one could fit on screen.

But I'm obviously wrong about the change in engine having a negative downstream effect in losing all progress made to date on a game, right?

I would totally concede if that was your original point. But it wasn't, which is why I said you are trying to move the goalposts. Allow me to quote you again, just so you remember:

Cool enough things in theory, but I'd be a lot more excited to see if the engine upgrades let us walk through a city of NPCs who are all interactable, can move about on their own and have their own activities, rather than just standing in place for seven years. Or a way to approach situations outside of A) combat or a dialogue wheel Auto-win. Stealth options or warfare gameplay (since we are in the middle of a war and possibly controlling a castle/fortress) would be nice. As would using magic outside of combat to solve problems/puzzles/quests, like creating an ice bridge instead of going through the valley and fighting hordes of mooks.

To which I replied: 

All of those are handled by gameplay, not engine.

They are. You're wrong. Stop spreading misinformation and trying to hide behind "BUT IT WILL TAKE PROGRAMMING TIME". I acknowledged that it will. That doesn't mean that you weren't wrong. You still are. It just means you're trying to deflect attention from it by attacking the strawman. I never said that it wouldn't take time or effort to create these gameplay systems. I never said that it wouldn't cause considerations. I said that the work that will need to be done is by gameplay, not by engine. The features you talked about would all be handled by gameplay, not by engine.

Stop attacking that strawman. It's taken enough abuse.

Modifié par hoorayforicecream, 05 novembre 2012 - 07:17 .

[Allan Schumacher]

So again, I ask... does anyone from Bioware have any feedback on what Frostbite 2 brings to the table other than nicer graphics and a better bottom line for EA?

I already stated that memory management and streaming are significantly improved.

It was a few posts before you stated that the only thing you had heard was improved graphics, just on the previous page.


While I'll agree with hoorayforicecream's initial response on the previous page (i.e. whether or not our game has NPCs that are all interactiable and can move around and do their own things) is less engine focused, the argument since then is starting to carry on.

By the technical description, hoorayforicecream is correct. Though even in my own posting I'll often use the word "engine" to include the baggage that comes with it (the current development tools) so in that regard, I've helped to obfuscate the issue too.

If your concern is "whoa, you're going to have to do a lot of work that you've already done" then yeah, that's valid.  But we don't just decide to switch engines without there being some level of benefit to them.  And yes, graphical fidelity IS also one of the benefits.  Much of that is effectively free, however (we can take a DA2 asset and plop it into Frostbite and it already looks better).

Modifié par Allan Schumacher, 05 novembre 2012 - 07:34 .

[Fast Jimmy]

You are right.


Switching to a new engine will eat up resources and time for DA3. I'm glad we can agree on that.

[Fast Jimmy]

Allan Schumacher wrote...

So again, I ask... does anyone from Bioware have any feedback on what Frostbite 2 brings to the table other than nicer graphics and a better bottom line for EA?

I already stated that memory management and streaming are significantly improved.

It was a few posts before you stated that the only thing you had heard was improved graphics, just on the previous page.


While I'll agree with hoorayforicecream's initial response on the previous page (i.e. whether or not our game has NPCs that are all interactiable and can move around and do their own things) is less engine focused, the argument since then is starting to carry on.
By the technical description, hoorayforicecream is correct. Though even in my own posting I'll often use the word "engine" to include the baggage that comes with it (the current development tools) so in that regard, I've helped to obfuscate the issue too.

If your concern is "whoa, you're going to have to do a lot of work that you've already done" then yeah, that's valid.  But we don't just decide to switch engines without there being some level of benefit to them.  And yes, graphical fidelity IS also one of the benefits.  Much of that is effectively free, however (we can take a DA2 asset and plop it into Frostbite and it already looks better).

Thanks Allan. This is, essentially, what I was looking for before I got sidetracked with jibes with hooray. Sorry I missed your original memory management comments, I saw similar statements on the first four pages bout graphics and FPS and then saw the same conversation going on with the page I made my first comment on, so I made the rroneous conclusion that nothing else was discussed. 

[Allan Schumacher]

Another big advantage of Frostbite (as opposed to some other engine) is also tech sharing.

The likelihood of us backporting changes to the Unreal Engine for Epic to license off to other people is pretty much zero. Backporting changes back to DICE happens regularly. The engine and tools is becoming more full featured because we collaborate directly with DICE as well as EA Canada.

Modifié par Allan Schumacher, 05 novembre 2012 - 07:55 .

[axl99]

Fast Jimmy: You owe horrayforicecream an apology.

Apologize.