Search the Community
Showing results for tags 'optimization'.
Found 3 results
Good day to all. Many were faced with friezes and a severe FPS drop during large-scale battles. There is an idea how to optimize the game for such battles. I will describe the essence of the idea, and my version of its implementation. The idea has 2 directions: at the player computer level and at the server level. The essence of the idea at player computer level: Create a special mode in the game settings called "Large-scale Battle Mode". Including this option, the game automatically adjusts to the most optimized settings for such battles, as well as disables some packet transfers (which will reduce the load on the server). However, in this mode, the maximum range of rendering ships is necessarily preserved. The essence of the idea at Server Level: Create a special mode that is activated when there is a huge crowd of people in one place, limiting the bandwidth per player, or rather, receiving and transmitting in this mode only the most critical packages for battles. So that the player does not appear discomfort and lags. How to do it? I have an idea. How to implement the "Large-scale battle mode.": Perform zero tests. Create a separate test client that is zero (there’s almost nothing in it, just a few kilometers of a flat surface without textures), and zero characters (who don’t even have animations and textures in the first stages of the tests). Recruit community testers. It is enough to publish information about this on the forum and in the Steam blog under the slogan "We need a lot of testers to work on optimization" and a large number of people will gather. I am more than sure of this. Assign tests for specific dates and times, which is determined by community voting (For maximum presence and stress test). I already did this once.) Believe me, the community is only happy to participate in such tests in order to help developers. You do not put the players in an uncomfortable position with this act, but on the contrary will win their respect and foster their interest. The essence of the tests is to check how the game behaves and its code (on the player and server side) (some developers also connect to the test like regular players to see what happens with their own eyes) during a large cluster of players in one place at zero conditions. Ideally, the game should work smoothly and without problems. In this case, it is necessary to gradually expand the zero client option, by slightly moving it closer to the game version. If suddenly, when adding one of the parts of the game and server messages during the tests, the players started lags or even strong lags - note what exactly these lags caused, disable and continue tests with other parts of the game. Thus, gradually revealing all problem modules of the game. After that, try to optimize as much as possible each module of the game individually, as well as decide which game modules and packet exchange with the server can be disabled in large-scale battle mode. You won’t believe it, but in one game with a large crowd of people, it turned out that simple sounds exert a tremendous load on the game client. The server was not loaded at all, however, among players, the frame rate dropped to 1 stable. The sound of walking, shooting, jumping and so on from each player created an enormous load on the game client. Therefore, the cause of the load during the accumulation of players can be anything. From the trivial problems of the game client to the ultra-high network load on the server. Atlas is a great game in which players are able to entertain themselves by creating their own plot. Each has its own unique story. If you find the key to optimizing it, then it will be very difficult to find a game better.) P.S. when you be able to create an effective “Large-scale Battle Mode”, I recommend adding an option (checkmark) for players to automatically turn on this mode, when the FPS has strongly sank for a minute, which is initially turned on by default.
Hey, i will put some simple suggestion here to increase server performance and allow to finish ships and bases with more useable details. I think these should go into Phase 1 or soon after. So we would need the following build parts added to the game (this can be expanded as seen fit, since buildparts are stored in the local client and should not effect server performance, depending on potential engine limitations): Floor and walls for ships and bases with the following sizes (tiles) -> 2x2, 3x3, 4x4, 1x2, 1x3, 1x4 When Building for example a 8x8 ceiling or deck, it doesnt make sense to fill it with 64 single tiles, that all have their own collision, health, links, weight, color and so on when you could do the same with 4 (4x4) tiles that would greatly reduce the server lag generated buy ships and bases in general. Sails with climbable rigging, and ladder parts with the size -> 1x2, 1x3, 1x4 This will remove the need to put ladders on sails and reduce the needed parts for ladders on the ship. Again saving alot of parts for building a ship. Foundations with sizes -> 2x2, 3x3, 4x4, 1x2, 1x3, 1x4 Foundations with more height (best scaleable when placing) -> from 1 to 20 This will greatly reduce the parts needed to build the foundation of your buildings and ports saving alot of items to reduce server load generated by land bases. There is no need for new visuals just merge the smaller part into bigger blocks so they will fit smoothly with the smaller ones. Other usefull changes: Smaller crafting stations that prevent some unnecessary large buildings where one doesnt want to build one. Clientside visuals that fill the gap between a ships hull and a placed wall. Larger XL sails for the galleon. It does not only look better having three sails of appropriate size, it will also reduce server load needed for calculating speed, position and stuff compared to having six sails instead. -> This will allow to build the same ships with fewer parts so we can complete them and not just build empty hulls to meet the item limit. In the future it allows us to put more interactive objects and stuff on ships to allow building them into a mobile base to live on the sea and offer more gameplay, rp and social value. -> Same for land bases there often goes an incredible amount of parts into building foundations and basic walls and ceilings that can be greatly reduced. So there is more room for building more fancy stuff and keeping server lag low at the same time. -> With the decreased server load it should be easier to add more details to ships like more sail types and sail locations like fore and aft sails. Cabin details like windows, balconies, interactive objects to outfit your ship. Damage visuals for planks and other stuff that helps to locate where you need to repair and judge the condition of your ship in an intuitive way. Or a more realistic way of handling the water line and sinking of ships. And many more things like seen among the other suggestions. Happy sailing, arrrrr!
OK not sure if this is posted already or even possible but hear me out. A server manager that shuts down grids not in use that way you can have a huge map on your local machine and still be able to play with just you or a few friends. Now this idea becomes less effective the more people you have. Basically have it set up that once all the grids are loaded they get put in "hibernation" (like suspended in ram or a paging file) and they stay that way until the server manager "pings" that grid which would bring it out of "hibernation" (the paging file) and resume the grid like normal. Now for example say you select a free port to spawn on, well when you click spawn the server manager would ping that grid and wake it up for you to use. Another example could be that once a player gets close to one or 2 grid walls then the server manager pings those grids and wakes them up so they are ready for you to pass over them by the time you get to the wall. And when the server sees that a gird is empty and no players are around it then it can close those grids. And the same situation could work for sleeping. Once you log out it checks the grid and surrounding grids and if all is good it will hibernate until needed.