No announcement yet.

Designing scalable systems [IMPORTANT]

  • Filter
  • Time
  • Show
Clear All
new posts

    Designing scalable systems [IMPORTANT]

    1 - Designing scalable systems "project" ?
    - (Structure)
    - (Code) (Example in spanish)

    2 - Also ask, if there is any way to always be updated with the code with the version. I understand that when a version is updated it may be incompatible with the new one, but is there a compatibility system that can support all the work of an earlier version? For example, imagine that I am using version 4.21, but within a month version 4.22 or even 4.3 / 4.4 / 4.5 is released ... There is some way (programmable as artificial intelligence) for the code to update and not be incompatible with the new versions?

    Sorry for my English.
    Last edited by Drakgoku; 01-03-2019, 11:18 PM.

    It depends on what you mean by scalable
    As far as updating to a newer version, the engine will try to update what it can if something changes, but sometimes something is removed, and you may have to go through the project and find an alternate way of doing something.
    However, you should try to avoid updating if you can, only update to a newer version if there's some significant feature that you need, otherwise it's too much of a problem to deal with.


      Fortnite is always updated with the engine to the latest version. How do they do that?


        For Fortnite, them updating the engine is the same as working on the game, many of the changes they make are due to their needs of Fortnite. In that case, they still go through the process everyone else goes through when updating to a new version of the engine, some things will break and require extra work to get working again. They're better positioned to do it though because they have more knowledge of the changes between versions and can be prepared to adjust to changes.


          I am a Java EE programmer, I could advise what would be the best way to start a project with unreal engine (I have knowledge to link it to databases, flow graph, c ++ and other languages) to have it updated as the current version of unreal engine?

          I understand that when you modify something from an api to improve the version, you have to refactor code from our project, but if it is done with a scalable design (Designing scalable systems), it should not cost me much to change those updates.

          That is to say, I can not get stuck in 4.1 or 4.2, I need to make a project "upgradeable" in every way.

          What do you recommend for good practices like fortnite?

          By the way, theme of the team. I am quite competitive and I would like to do it alone. I understand that it is not the best and practically impossible way, but I have notions of all fields and I think that something could be created. That's because I need a project that does not require refactoring "all the code in each version". "Could someone make a blueprint that separates the native code from future development?"
          Last edited by Drakgoku; 01-04-2019, 01:20 PM.


            It's not like refactoring code to fix errors, some things simply won't be there anymore. Or in the case of Blueprints some things may be different enough that the editor can't adjust it to the new way things are done. In some cases, something might function but work in a different way than before that you don't like. Or references and settings might reset, or a bug may simply cause something not to work. Every game has to deal with these kinds of issues and typically they avoid it by sticking with one version of the engine unless there's a feature they really want.


              "It's not like refactoring code to fix errors"
              I know, but I repeat again if you do "scalable systems", you will not care about the unreal code if it is updated or not, the code that will matter is the native C ++ (and here we are talking about another level).

              Version c++:
              ISO/IEC 14882:2017
              if the c ++ code is updated, then yes you have to think about whether to refactor or not.

              Is there someone from the maintenance team or development team that is programming Fortnite to comment on this issue?

              Last edited by Drakgoku; 01-05-2019, 12:06 PM.


                Really nobody knows anything about the issue?
                Last edited by Drakgoku; 01-07-2019, 03:09 PM.


                  Hello, to illustrate a little, I have made an imaginary sketch to be able to understand what I am saying. Surely it could be done better, but it is to make an idea. In case it can not be done, I would also like to know it.

                  Last edited by Drakgoku; 01-09-2019, 11:47 PM.


                    Originally posted by Drakgoku View Post
                    Hello, to illustrate a little, I have made an imaginary sketch to be able to understand what I am saying. Surely it could be done better, but it is to make an idea. In case it can not be done, I would also like to know it.

                    You seem to be looking for a silver bullet. I can assure you, there is none.

                    Having been in software engineering for quite some time now, no application/game will ever be totally future proof. A giant portion of software will use frameworks and/or libraries. Frameworks and libraries receive updates, most of the time regularly. These updates range from security vulnerability patches to enhancements to bug fixes. The key challenge to software engineering is you do not know what bugs you will have in the future. Thus, things change.

                    UE4 is no different. It is MUCH better to work with an engine that is receiving consistent updates than trying to work with a dead / abandoned one. If you don't particularly need anything an update has to offer, feel free to pass on it. However, bear in mind that with every update you opt out of, you add more technical debt for the scenario that you do indeed wish to update. You can do some work here and there by keeping up with the UE4 versions, or you can put it off and do a giant lump of work at once by updating multiple minor versions.

                    Follow best practices and prepare to put in a good amount of work to keep up on updates, if you do choose to update. That's the best you can do.

                    There is no "best DB for games". Logging in, for example, is EXTREMELY different than attempting to stream data in real time. Generally speaking, a good architecture would be to build an API for logging in, microtransactions, and other fairly time-insensitive activities. That should be ENTIRELY separate from your game's activities, which could realistically use a DB, or not. It depends entirely on your game's needs. MMOs, for example, are a tremendous amount more heavy on the data side than, say, an FPS. Yet a minor hitch in an FPS can mean a world of a difference for players.

                    Put in the time. That's all I can definitively say. Figure things out, get a feel for what is best practice, and try to plan ahead as much as possible without giving yourself analysis paralysis. As a lead engineer of a very large SaaS solution, I can promise you, successful software of ANY sort is not easy. I work in ~5 different programming languages on the daily, all with multiple different frameworks working together in a microservice architecture. We update the frameworks fairly regularly, and every single time it is a beast. There are ALWAYS deprecations, and there are always new ways to do things.

                    Progress is not your enemy, stagnation is. Learn to embrace the new features and changes and get excited about the shiny new releases. Otherwise, a new hobby may be in order.
                    Last edited by One Mode Only; 01-11-2019, 01:18 AM.