Jump to content

SwineDK

Members
  • Posts

    22
  • Joined

Posts posted by SwineDK

  1. 1 minute ago, Matt115 said:

    I can and i can't agree :  i was watching talk of some devs of one studio - they had a problem with some functions like realistic looking plants - in sequel they decide to use another engine and it was easier .  Well ofc decisions are important but for example - old engines of serious sam support 100 enemies per time , in cod zombie you could have 32 zombie one time but in cod bocw you can have more of them etc .  In l4d2 they used so tricks with shaders to make a new variants without bugs and 30 fps. But now it have generate more variants . I think about something like - okay we have a zombie girl -  put 20 head , 10 types of hairs , 10 t- shirts ( + 20 colours) ,10 pants , 5 shoes , 4 backpacks -  8 000 000 combinations + random dirt and blood + diffrent wound . Some head can be reused and hairs , shoes can be used for zombie shop owner and casual , backpack can have student or zombie survivor 

    Regarding graphics, you are absolutely right that this is highly dependent, out of the box, on the engine. But if you have very skilled graphics artists and utilize physics based rendering and setup shaders to make it look realistic, then you can get realistic graphics with the same result in Unreal and Unity.

    This is related to how the engines talk to graphics cards on a "low level" and what features of the graphics cards, that the engines choose to utilize. But in regards to Unreal and Unity, there's not much difference if you have skilled developers.

     

    It is definitely possible to do what you want with all the different types of heads, hair, clothing, body-parts and all that.. But somebody have to make all these parts first and make sure that they look good. This is very time consuming and needs some artists to work full time on for many months. And it also requires coding the generator to build these zombies as well as quite a lot of networking code to make it work in multiplayer games.

     

    So it might be a great project for the next game for The Fun Pimps :)

  2. 9 minutes ago, Matt115 said:

    Well but there a chance that your another game will be on UE5? And more theoretical question : Random Character Generator similar to L4D2 woudn't works on Unity but do you think it could work on UE5? Well ofc i don't suggest to change engine only for that but it could be good step forward in 7DTD 2 . In l4d1 one base zombie have 64 variants, updated 320 but L4D1 Common Infected Overhaul    created by Skessler make a system allowing have 286.720 variants of single type of zombie. And this diffrence can be see easly. I know 7dtd don't need so much variants but even 100 could be rly good. Well make a sandbox on Source 2 could be impossible  ( gmod is more static that 7dtd or conan)

     

    @Matt115 it really doesn't depend as much on the engine as it depends on the actual development and decisions of the game developers.

    Game engines can give a lot of advantages in supplying a lot of utilities and some "shortcuts", that the developer can choose to use or not.

    If the game engine doesn't support a specific feature, it can always be added by the developers, either through plugins or by writing the code themselves.

     

    This is also very true for a "random character generator". It is a concept that is independent of game engine, but will of course need to be written in the programming language for the game engine.

    And if the developers are more used to C# instead of C++, then it would be more suited to use Unity or Godot.

    In the end, it's better to use the engine that the developers feel is better suited for the project rather than choosing an engine, where a new programming language needs to be learned.

  3. 12 minutes ago, Kalex said:

     The tethering I am talking about is when you are running a client-host game (LAN) if the client tries to go too far from the host's character, it will rubberband them back into range of the host because of the way the game engine loads sectors based on x distance from the host only and not by x distance from each player on the server. Dedicated servers do not have this problem only the peer-to-peer games.

    That seems like a per-game issue.
    I haven't used Unreal, but pretty much any chunk loading system, independant of game engine, is usually developed by the game developers themselves.. I could be wrong about Unreal having a built-in system, but It would be weird if they had it build-in by default and set it up to center around the host instead of the local player, which would be the easier task.. at least in my mind, having built a couple of them..

     

    Edit: for multiplayer games, it would not be a big issue for the clients to request a chunk far away from the host, that the host is managing physics and state for. It's pretty much just a bunch of numbers and some math calculations here and there.

    The biggest issue as I see it, are the floating point calculations, since the farther away from 0 you get with floating points, the more imprecise they get. But that can be fixed by some virtual movements of chunks.

  4. 32 minutes ago, faatal said:

    We pool a lot of stuff, but you often get spikes anyway. Even changing parent from the pool to another owner can cause spikes.

     

    Instantiating after the first time is typically cheaper, since Unity keeps resources around, so instantiate is often not that bad.

     

    Unity 2020.3 LTS released today and in testing so far has been working great and in general, due to optimizing, the game is running quite well now.


    Yeah, it can be quite tricky with Unity to get great performance. 

    We will be looking forward to help testing the game, when the Unity 2020.3 LTS is implemented. I read previously that you didn't have to do a lot of recoding for it, so I guess we can expect it for A20?

    We are a lot of eager beavers for that update 🤪

    Do inform us if you need us to test something before the EXP build, hehe..

  5. 58 minutes ago, ZombieHorde said:

    Maybe don't keep instantiating the zombies then? Like never dispose of them in the first place. Just have them die/time out and turn invisible but the object is still there in the background, ai turned off, If there is a volume that needs more zombies then what are already instantiated then just create one or two, not the the full pack again and again.

     

    Let me guess: not that simple in Unity?

    Oh it's pretty easy as such. It requires some coding, but it's not rocketsurgery for a basic version that adds objects as needed, but otherwise retains the objects disabled, when they are not needed.

     

    But while you save some CPU, it requires some more RAM. at the moment. So it's important to analyze gains vs. cost, also in cost of development time.

  6. On 3/9/2021 at 9:24 PM, faatal said:

    It is not about distance or rendering or scripts. All those GameObjects and their components are expensive to create, which means lag spikes. It need further analysis to find all the slow parts and find solutions for each.

    Yeah, instantiate is really expensive. I guess that you are pooling all kind of objects, not just zombies, to minimize instantiation while playing.

     

    I've read that the Unity c# job system could allow for thousands of objects while having great performance - I have no real experience with huge games like 7 Days to die, so I couldn't say if it would work for this though..

     

    I guess that it could of course also be a huge task to implement, especially since it won't give a huge economic gain 😀

×
×
  • Create New...