CRYENGINE | Forum

Hi. This post is a collection of all things that I have in mind about the engine. I think that I should give this feedback because in my opinion CryTek does a lot of good things, but also a lot of bad things. Before I start: I realize that the team is much smaller than other competitor engine teams.
All right.
Lets get started.

1. I guess that I don‘t need to mention it but the documentation is often times outdated. This makes it quite hard to find out how stuff works.

2. One of the most complex parts of a game is the player and AI. I‘m pretty happy that we get some good examples for player coding inside the game templates. But what would be really really needed now is an AI example game template. The AI system is barely documented (at least the C++ side) and people need to know how to setup stuff like MBT, Perception, Movement (already an example inside the Isometric Pathfinding Template), Factions, Stimuli, Path Following, Cover, AI Signals, Ragdollizing, etc. from C++ code. I guess that a simple Game Template could give us some nice insights inside the AI System. What I thought about was just an AI that can see/hear the player and/or other AI and then uses an MBT to follow him or do something... whatever. Just a simple example that uses some AI System functionality.

3. It seems as if the new EntityComponent system is pretty nice but it also has some problems. For example if you look at the engine‘s actor system or item system (and other systems), they all just accept the „old“ game object extensions. I guess that this should be fixed soon.

4. The default components are not that great. For example: the input component does not really read an action map. Or the MBT Component... here we have no way to set the MBT name from
Code. Other components have similar problems.

5. The legacy components inside the default components are not shown inside the sandbox editor when using a Game Template (e.g. the TagPoint is missing).

6. Games are now implemented as Plugins?! I guess that this one is a pretty bad idea. I really love the plugin system. It makes so much stuff much easier. But if we implement games (like seen in the templates) as plugins, then we loose all control over code like CGame or the startup file (where we could define a CVar whitelist and also the key for the encryption). So basically we loose control over the game code.

7. It seems as if we can‘t create anything like GameRules with the new EntityComponent system. Hope that this one will be done soon.

8. There are rumors that FlowGraph should be replaced with Schematyc in the future. I guess that this is a really bad idea. The point is that Schematyc is more like Unreal‘s blueprint system and FlowGraph is a tool for Game Design (like Unreal‘s level blueprint). Both concepts are pretty different.

9. Another thing would be that there is currently no easy way to create a FlowNode for an EntityComponent inside of C++. You know... these nodes that you get if you select an entity and then paste it into a FlowGraph. So basically the entity‘s node.

10. There is a lot of unclean C++ structure. For example a lot of game stuff is actually implemented inside the engine. For example the engine has functionality for weapons, items, inventory, etc. Would be better to migrate all of this into plugins.

11. Again the EntityComponents: A lot of FlowNodes just can‘t be used for them. E.g. all the actor nodes, weapon nodes, AI nodes, etc.

Hope that this was kind of useful feedback.
Again: you also do a lot of good stuff. Like I mentioned I think that the plugin system
In general is really awesome (only this „game as a plugin“ thing isn‘t that great). Also the EntityComponent system will be a really great thing as soon as it gets more support (e.g. ActorSystem, GameRules, FlowNodes for entities, etc.). Just wanted to mention it because all of my points that I‘ve made are negative.

- Jannis

Documentation is and has been in a poor state, even after they hired someone to work on it. I'm guessing that if you don't work with the engine more frequently/etc. it's harder to write documentation as it is. Maybe the Cry-HUNT team could pitch in?
Hard to answer questions a lot of the community don't ask t-t

Schematyc is bugged/broken, flowgraph is bugged/broken but it has more default nodes so people tend to use it instead, etc.
(Not my opinion, other artists frequently complain)

AFAIK, on current main branch, nothing has changed with regards to entity components.
They still use game object extensions, they still support old/out of date stuff, and they still haven't updated any of the templates.
So maybe by the end of next year, 2020.

That's not even counting on game rules/networking changes (e.g. entity classes and what not).
As an example, entity components don't work with action maps. They just don't get events, has to be a game object extension or you have to use extraActionListeners instead....

This is also taking into account that it took 2 versions (5.4 then 5.5) before entity components were actually usable to any real extent. They just have other priorities I guess.

They would need to do a lot of cleanup, and it's not on the roadmap so .-.

Unfortunate that the entity component system is still not complete. In an ideal world, you would replace core infrastructure with something that has the same functionality. Or at least prioritize cleaning it up/etc., been a while.

Thank you for taking the time to present us with the detailed feedback here. It goes a long way to help shape the engine and we don't just say that. We value all the feedback we get, negative and positive.
Entity Components are what we are aiming for, to expand end evolve. Currently we do provide legacy support for a lot of functionality but this is indeed something we hope to drop in future to focus on the new systems in CRYENGINE.

Regarding Flow Graph vs Schematyc, we have put a lot of effort into designing Schematyc in a way that provides feature-parity with Flow Graph. Ideally, there will be no more Flow Graph, games will be prototyped, designed and extended via the core systems such as Schematyc. Currently we are in a transition period between Flow Graph (GameSDK and other Legacy support) and Entity Components (Schematyc and other new systems). Since the plan is to engineer new systems, creating links between legacy systems means we will fall behind our targets for getting the new systems out.

This includes the Plugin Systems - feature parity is our priority and we want to allow this flexible system to be able to do all the things it needs to do. We can only say to be patient as we iron out the core and develop the new systems. Once the systems are ready, the Legacy systems will be dropped. We do not have any set time for this as development can vary greatly of course.

That said, if you can program C++, you can unlock all the features you need in either system, though of course if you want parts of both new and legacy systems then you will need to account for that.
In the end, we understand, and we are certain with each iteration of the engine, we will get closer to our goal of modernizing the engine in all the ways we possibly can.

Thank you for taking the time to present us with the detailed feedback here. It goes a long way to help shape the engine and we don't just say that. We value all the feedback we get, negative and positive.
Entity Components are what we are aiming for, to expand end evolve. Currently we do provide legacy support for a lot of functionality but this is indeed something we hope to drop in future to focus on the new systems in CRYENGINE.

Regarding Flow Graph vs Schematyc, we have put a lot of effort into designing Schematyc in a way that provides feature-parity with Flow Graph. Ideally, there will be no more Flow Graph, games will be prototyped, designed and extended via the core systems such as Schematyc. Currently we are in a transition period between Flow Graph (GameSDK and other Legacy support) and Entity Components (Schematyc and other new systems). Since the plan is to engineer new systems, creating links between legacy systems means we will fall behind our targets for getting the new systems out.

This includes the Plugin Systems - feature parity is our priority and we want to allow this flexible system to be able to do all the things it needs to do. We can only say to be patient as we iron out the core and develop the new systems. Once the systems are ready, the Legacy systems will be dropped. We do not have any set time for this as development can vary greatly of course.

That said, if you can program C++, you can unlock all the features you need in either system, though of course if you want parts of both new and legacy systems then you will need to account for that.
In the end, we understand, and we are certain with each iteration of the engine, we will get closer to our goal of modernizing the engine in all the ways we possibly can.

HI
Since GameSDK is so popular, Questions about the future of GameSDK>!
As seen in the roadmap. You try to keep GameSDK with the new animation system. This looks great!
In the future, legacy features will be destroyed, including Smart-Objects that will soon be forgotten.
The question is, does GameSDK survive or die with new features?

The ideal scenario is for GameSDK to be replaced by a more modern sample or samples. We still want to provide users with a package that lets them get into Game Dev straight away and start making their games. We don't have any specific details regarding this right now though. It is all part of a long term process to improve and modernize CRYENGINE in every way we can.