Sunday, October 25, 2015
inside out
I'm coding again after one year of paralysis, and I feel like I've been respawn. Lots of bash scripts, the servers side will have to do a very few things but very quickly and cleverly. I might translate the scripts into python, but for now the shell is simply perfect, I can see almost in realtime what I'm doing. I'm also thinking of buying some aws courses, it could be useful since I'm still thinking to place the game in amazon cloud.
This resurrection is certainly due to the removal of a major source of depression, a crappy job, which has devastated my life in the last year and a half. During all this time I felt so oppressed that I wan't able to produce literally anything, despite many attempts to artificially revive my inspiration; now the long night is over, and I automatically came back to the project without any artificial input, as if it was the most natural thing in the world.
This resurrection is certainly due to the removal of a major source of depression, a crappy job, which has devastated my life in the last year and a half. During all this time I felt so oppressed that I wan't able to produce literally anything, despite many attempts to artificially revive my inspiration; now the long night is over, and I automatically came back to the project without any artificial input, as if it was the most natural thing in the world.
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.
Wednesday, October 14, 2015
The Decipherment of Linear B
To admit difficulties is always difficult, I'm no exception. I'm making no progresses with C#, in spite of a serious attempt. I think the reason is the OO approach and/or the syntax, which I find incredibly obscure.
So, another difficult admission, I'm probing Unreal Engine's blueprints, as they are supposed to be similar to quest3d's building blocks, and maybe they'll help me to grasp OO way of development.
Also, I'm actually considering that my project is clearly divided in two sections: a frontend, which is the client, that can be written with almost any middleware, and the more challenging backend. This is the real core of the program, being an online game.
The challenge lies in the fact that I must account for potentially many games at once, and I must find a way to run them all. A sort of time division multiplexing, by which every game is allotted one round of calculations and then another match is loaded, does not seem promising. But also, a 1:1 ratio of one backend running for each match is not practical. This in the end will heavily modify the mechanics of the game.
By the way, with these latest news, the game is no more vapourware and is now officially fantasyware.
So, another difficult admission, I'm probing Unreal Engine's blueprints, as they are supposed to be similar to quest3d's building blocks, and maybe they'll help me to grasp OO way of development.
Also, I'm actually considering that my project is clearly divided in two sections: a frontend, which is the client, that can be written with almost any middleware, and the more challenging backend. This is the real core of the program, being an online game.
The challenge lies in the fact that I must account for potentially many games at once, and I must find a way to run them all. A sort of time division multiplexing, by which every game is allotted one round of calculations and then another match is loaded, does not seem promising. But also, a 1:1 ratio of one backend running for each match is not practical. This in the end will heavily modify the mechanics of the game.
By the way, with these latest news, the game is no more vapourware and is now officially fantasyware.
Sunday, October 04, 2015
Umlaut
I'm learning very slowly. I've found a very good course on udemy, but I can't dedicate it too much time every day.
In the meantime I'm trying to build a small gravity game, it's useful to learn about instancing. The final result should be a bunch of spheres revolving and colliding via Newton's laws, but without using any kind of physics engine.
Obviously the biggest problem is to find all the different functions, my only reference is quest3d functions so I must translate my previous knowledge into this completely new way of doing things.
In the meantime I'm trying to build a small gravity game, it's useful to learn about instancing. The final result should be a bunch of spheres revolving and colliding via Newton's laws, but without using any kind of physics engine.
Obviously the biggest problem is to find all the different functions, my only reference is quest3d functions so I must translate my previous knowledge into this completely new way of doing things.
