Phew... a few days since I don't blog anything about CRP. First reason, holidays are over, I'm back to "routine", and since university takes a lot of time (after all, engineerings are engineerings), I've reduced the amount of time that I spend working on CRP. Of course, I could work on it on weekends or in my free time, but I also want to enjoy my free time, without computers, just hagnging around, having a social life, running or whatever, you know. Of course, I'm not saying that I'm stopping, I'm still working on it. Less commits a day, according to my Git repository stats, but it's still moving.
Also, I don't blog because I'm not adding new features for now, instead I'm improoving the ones that the game already has.
For instance, I'm working on a more lightweight rendering system. At the moment CRP attempts to render every single tile of the city every single frame, even if those tiles can't be seen by the player. Right now, map is hard-coded to be 16x16, that makes 256 tiles to be rendered per frame, and about 75.000 tiles per second in my old Core 2 Duo computer that I use to develop my software (laptop keyboards are lame, long life to old-and-noisy desktop keyboards!!!). I increased the map dimensions to 256x256 tiles (65.536 tiles per frame) and the results were that FPS dropped from 200 FPS to about 2 FPS.
This improvement is linked to the city logic improvement. I'm splitting my city into regions. Instead of having a big, big map full of tiles that I call "city", I'm creating some little maps called "regions", and I'm considering now a city a set of regions. Those regions work independently ones from others, so instead of rendering cities, I can render regions, based on if they will be visible or not. To the user, those regions don't exists, and he sees the map as a single big city, just like it has always been. Even road connection will continue working between adjacent tiles from separate regions.
The game is also being ported to states. Right now there are no states and my game is just overriding Slick2D's BasicGame class. This is becoming so tight as the game keeps growing and growing, that I've already started to convert the game into a state based game. The earlier I do this, the less painful it will be. I've already created three states: one for the actual play, and other two for loading and saving the city. City is a shared resource that all the states can access to. At the moment those extra states aren't visible because loading and saving takes just a few miliseconds, but it should be visible as I add new features and change the saved game format.
After I complete all these improvements, I'll tag that code as version v0.0.3. However, it's most likely that I won't share that release as there are no new features that I consider people could enjoy. Plus, I worked last monday on a launcher that would replace current game deployment system. You'll have more details about the launcher after I polish and release it and talk about it on its own blog post, but just to give a sneak peek, the launcher will replace the user: it will automatically connect to a CDN that I'm using to host the game assets, and it will download, extract and link the game. So, next release won't be a Zip file that you have to manually download from my Dropbox account and extract on your desktop, but a link to the page where you can download the launcher. Period. Easy.
Also, this is probably the last pre-alpha release. The game is already getting a plot, a name (Drive To) and even a Facebook page. Once it's ready, you'll see Drive To v0.1, first alpha release of the game. No more sandboxed prototypes, let's make this thing real, bi*ch.
And, pretty much, that's it. This has been a long post after all. My English is not as clean as I would like to, even if I have a good knowledge of it, so I'll just hope that it's understable. You know, the longer you do things, more risk you have in failing them.
No comments:
Post a Comment