3 years ago
F1 24 Game Ideas
Hi, Below is a list of game ideas for F1 24. It’s probably too late to be giving the developers ideas for F1 23, because they’re three quarters of the way through developing the game (because of ...
Hello everyone, how you doing mates?
So, if I got this right the rumour has it that Mr Greco is leaving the handling department not exactly EA. Right?
Maybe he's got a promotion? Read last week that the WRC series is coming to EA this year, including a mode "where you create your own rally car". Quite familiar, isn't? If EA didn't get this guy to coordinate both game series than they would be quite stupid.
Also concerning (but somewhat refreshing to be honest) is the part of the rumour that states a engine change. I understand very little of engines and etc but to me it's clear that the current engine has reached its limit - I mean, the game looks great but done properly this engine change can open some new possibilities.
Cheers,
Dan
@dancrodriguesMiss you, pal.
Regarding Greco, that's a good and hopeful take. I'd take it!
Now with engines... Engines are huge. A game engine gives you the tools to build the game and provides the framework to run the application.
Say you want to build a simple Pong game, but with air drag in it. It's all up to you as a dev to use the tools the game engine provides to program it, and it can be as simple as clicking and dragging in a visual programming straightforward language or to literally code it all out in a manner that the engine can interpret and execute it properly.
Depending on how good of a job you did, this revamped Pong can consume, say, 50MB of RAM. But maybe the engine wasn't very friendly, and you ended up with a badly coded application that inefficiently gulps down anything from 50 to 500MB of RAM when the drag gets strong.
Maybe you're knowledgeable enough to program it reasonably well on engine A and engine B both, but the frameworks engine A provide are miles better than those of engine B and the same game consumes way less computing resources on the former – leaving more room to implement other features, perhaps?
We often associate a game engine to something akin to an Instagram filter, making a game look this or that way. But it impacts everything, really. From physics to AI to sound and image fidelity.
What do I know about Frostbite? Shamefully little. I do know the reported horror story that BioWare went through with it back when they were working on Anthem.
@mariohomoh wrote:@dancrodriguesMiss you, pal.
Regarding Greco, that's a good and hopeful take. I'd take it!
Now with engines... Engines are huge. A game engine gives you the tools to build the game and provides the framework to run the application.
Say you want to build a simple Pong game, but with air drag in it. It's all up to you as a dev to use the tools the game engine provides to program it, and it can be as simple as clicking and dragging in a visual programming straightforward language or to literally code it all out in a manner that the engine can interpret and execute it properly.
Depending on how good of a job you did, this revamped Pong can consume, say, 50MB of RAM. But maybe the engine wasn't very friendly, and you ended up with a badly coded application that inefficiently gulps down anything from 50 to 500MB of RAM when the drag gets strong.
Maybe you're knowledgeable enough to program it reasonably well on engine A and engine B both, but the frameworks engine A provide are miles better than those of engine B and the same game consumes way less computing resources on the former – leaving more room to implement other features, perhaps?
We often associate a game engine to something akin to an Instagram filter, making a game look this or that way. But it impacts everything, really. From physics to AI to sound and image fidelity.
What do I know about Frostbite? Shamefully little. I do know the reported horror story that BioWare went through with it back when they were working on Anthem.
Very good explanation.