Sunday, October 18, 2015
python?
In the past days it became completely clear to me that I've been wasting my time. Instead of concentrating on the solutions I looked at cheap shortcuts, hoping that unity or unreal blueprints could in some way do the dirty job for me.
I always had the feeling it was the wrong way, but nevertheless I wanted to seriously try unity because it's the de facto standard in game industry. One quick consideration: I already have a tool which works pretty well, why should I bother at learning a new one?
Moreover it is now evident to me that I should not rely on any standard product for the server side, I should instead rely on custom scripts. The frontend client then can me made and remade in a thousand different forms. However the difficulty of this project is all on the backend side.
Basically I must find a way to quickly process all the units in a continuous terrain environment. I kept thinking at all the implications, it means that I have to process the movement of each single unit so that for all practical purposes they happen simultaneously.
So I have to divide each moment of each unit into small steps, and then execute all the small steps for all the units, then the second small step for all and so on. If the steps are small enough, and maybe if the units' order is randomly chosen at each step, it will ensure a very acceptable representation of a simultaneous movement. The complication is that different units have different speeds, so I'm still trying to find a proper number of steps, should they be calculated based on the fastest unit? That would mean that the slowest ones would require many useless steps, and this is all wasted cpu cycles. On the other side, if I calculate the optimal steps based on the slowest unit, the fastest ones would literally jump over too big a portion of continuous terrain, with the embarassing consequence of possibily avoiding obstacles if they're smaller than the "wavelength" of the unit.
In the middle of these problems lays the big question mark of which thing to use for this enormous loop: quest3d itself? the linux bash? a python script? this could be another headache but I can handle everything that is procedural.
I always had the feeling it was the wrong way, but nevertheless I wanted to seriously try unity because it's the de facto standard in game industry. One quick consideration: I already have a tool which works pretty well, why should I bother at learning a new one?
Moreover it is now evident to me that I should not rely on any standard product for the server side, I should instead rely on custom scripts. The frontend client then can me made and remade in a thousand different forms. However the difficulty of this project is all on the backend side.
Basically I must find a way to quickly process all the units in a continuous terrain environment. I kept thinking at all the implications, it means that I have to process the movement of each single unit so that for all practical purposes they happen simultaneously.
So I have to divide each moment of each unit into small steps, and then execute all the small steps for all the units, then the second small step for all and so on. If the steps are small enough, and maybe if the units' order is randomly chosen at each step, it will ensure a very acceptable representation of a simultaneous movement. The complication is that different units have different speeds, so I'm still trying to find a proper number of steps, should they be calculated based on the fastest unit? That would mean that the slowest ones would require many useless steps, and this is all wasted cpu cycles. On the other side, if I calculate the optimal steps based on the slowest unit, the fastest ones would literally jump over too big a portion of continuous terrain, with the embarassing consequence of possibily avoiding obstacles if they're smaller than the "wavelength" of the unit.
In the middle of these problems lays the big question mark of which thing to use for this enormous loop: quest3d itself? the linux bash? a python script? this could be another headache but I can handle everything that is procedural.
# posted by Marcus @ 9:41 PM 
