Monday, April 29, 2013
Not dead, but frozen
I've decided to interrupt CRP development. I'm not saying "drop", I'm saying interrupt. This is, zip all the source code and the Git repository folder and take it away from my main hard drive so that it's not there making my computer slow.
Why I'm interrupting CRP development? Let's take this seriously. Adding some classes around a prototype is not making a game. This kind of things really need some kind of design and plan before even turning on the computer. The idea and the gameplay behind CRP is nice, so I'll try to maintain that ideas as better as I can, but right now there's nothing to do, on the computer.
Same can be said for all those "projects" that are in my hard drive. They are going to be zipped and taked away. Then, I won't do anything for a month. Actually, during May I have got all my finals on my university so I think it's a really clever idea. And after that, I will probably reset and start from scratch, trying to design, and then develop, one of those minigames that I planned a few months ago as a summer project. Probably that puzzle-ball game that I considered during the month of february. I don't know. And indeed, for now, I don't want to know.
Saturday, April 20, 2013
Some old, old, projects
Just wanted to show you some old projects that I did, or that I attempted to do. Some of them succeded, some of them failed. Let's go from the oldest to the newest.
My development style it's not so good compared on what they always teach you. You are supposed to have an idea, then create some kind of story, then sketch some ideas and design some concepts on a paper, and once you are ready start coding slowly, but I still prefer to start coding some prototype whenever an idea reaches my mind, even if it's not cooked yet. It's a time-waster way and a bad practice, but I'll continue on that for a while.
I recently took down the videos because the code actually have some design flaws that I don't want to show (specially if your videos are called "educative"), but I still keep the source code in my computer and I'm even thinking on correcting those design flaws and continue the development as a standalone game.
Here's an screenshot from the original video (I can't link to the video because I switched it to "private" when I detected those flaws, and YouTube wouldn't let you watch it), as uploaded to my YouTube channel on August 13th.
I remember having the idea about a casual game that mixed concepts taken from games such as Advance Wars (for the war) or League of Legends (for the team organization), while looking totally 8-bit and retro, as if it was a NES-era game.
The idea really looked better in my mind, as I just remember that I left the development in less than 2 days since starting designing the system (not coding, but sketching some characters, thinking about some UML diagrams, etc).
My development style it's not so good compared on what they always teach you. You are supposed to have an idea, then create some kind of story, then sketch some ideas and design some concepts on a paper, and once you are ready start coding slowly, but I still prefer to start coding some prototype whenever an idea reaches my mind, even if it's not cooked yet. It's a time-waster way and a bad practice, but I'll continue on that for a while.
Alien Chase (July 2012 - [frozen but active])
This goes first because, 1) it's the first project that I did, and, 2) it's the first project that I successfully finished. Alien Chase was developed as part of a educative YouTube screencast series that I recorded last year about Slick2D.I recently took down the videos because the code actually have some design flaws that I don't want to show (specially if your videos are called "educative"), but I still keep the source code in my computer and I'm even thinking on correcting those design flaws and continue the development as a standalone game.
Here's an screenshot from the original video (I can't link to the video because I switched it to "private" when I detected those flaws, and YouTube wouldn't let you watch it), as uploaded to my YouTube channel on August 13th.
 |
| Alien Chase, v0.0.9 (Source: YouTube) |
Pixel World War (July 2012 - July 2012)
I don't hold any source code about this nor any screenshots, so I can just tell you some little things about this.I remember having the idea about a casual game that mixed concepts taken from games such as Advance Wars (for the war) or League of Legends (for the team organization), while looking totally 8-bit and retro, as if it was a NES-era game.
The idea really looked better in my mind, as I just remember that I left the development in less than 2 days since starting designing the system (not coding, but sketching some characters, thinking about some UML diagrams, etc).
Solar (January 2013 - January 2013)
Let's go to 2013. Solar was an idea that I had in January 2013. Some kind of game that involved "big, randomly generated terrains", robots, spacial stations, and so. Just like Pixel World War, the game looked way better in my mind. I had the time to upload some videoshots to YouTube, but the project really didn't passed the 0.0.2 version.
Like Pixel World War, the idea was cool, but I didn't liked my first prototypes, so project dropped quickly.
Drive To (a.k.a. CRP) (March 2013 - [on development])
And then you get to Drive To (or City Road Prototype). It's active and I'm definitely not dropping it. I have stopped working a lot on it because the story behind the game still looks too fragile, but the game will continue its development.
Thursday, April 4, 2013
Game prototype current status
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.
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.
Subscribe to:
Posts (Atom)