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.
Sunday, March 31, 2013
Garbage Collector is garbage
Whenever you are playing around with OpenGL and LWJGL in Java, say LibGDX, Slick2D or pure LWJGL, please keep this in mind: Java Garbage Collector is NOT your friend. There are a few reasons that make it suck for games. One of them is 'the moment' it chooses to start working. If Java garbage collector is messing around during our main loop, it may cause it to take longer to complete each cycle, causing our game to lose FPS.
There's another reason to hate Java garbage collector: it doesn't work with video RAM. Whenever you load a texture on LWJGL or any LWJGL-based library, actual image data is loaded as a pixmap on video RAM. OpenGL stores graphical data on video RAM so that your graphics card can access faster to it.
However, video RAM is not the VM heap. That means that Java Garbage Collector won't free your textures -you must do that manually, by using the appropiate method depending on the platform you are using, dispose() or destroy(). If you don't release your textures, you will end with memory leaks and your will require a lot of memory: this might not be a problem at all on desktop platforms, but if you are planning to release a mobile phone game, you should be aware of this.
Remember to destroy your textures once you aren't using them. Doing some image = null is not enough: as I said, that won't remove your pixmap data on video RAM. Plus, if you remove all the references to your texture, it's over: you won't be able to destroy the pixmap and that memory bank used by your pixmap becomes lost and wasted until you close the game.
Aside note: make sure to destroy textures that you aren't using. Sometimes pixmaps get shared across multiple texture or image objects. Consider the following example in Slick2D: you load an Image, then you create a SpriteSheet, and then you use an Image array to reference three sprites. You are using five objects here, your original image, your spritesheet and three references to some subimages of your original image. However, they all will be sharing the same pixmap on video RAM. If you destroy that pixmap, you destroy the pixmap for all of them. So, if you are using a spritesheet, a tileset, a bitmap/AngelCode font, be careful on deleting pixmaps.
There's another reason to hate Java garbage collector: it doesn't work with video RAM. Whenever you load a texture on LWJGL or any LWJGL-based library, actual image data is loaded as a pixmap on video RAM. OpenGL stores graphical data on video RAM so that your graphics card can access faster to it.
However, video RAM is not the VM heap. That means that Java Garbage Collector won't free your textures -you must do that manually, by using the appropiate method depending on the platform you are using, dispose() or destroy(). If you don't release your textures, you will end with memory leaks and your will require a lot of memory: this might not be a problem at all on desktop platforms, but if you are planning to release a mobile phone game, you should be aware of this.
Remember to destroy your textures once you aren't using them. Doing some image = null is not enough: as I said, that won't remove your pixmap data on video RAM. Plus, if you remove all the references to your texture, it's over: you won't be able to destroy the pixmap and that memory bank used by your pixmap becomes lost and wasted until you close the game.
Aside note: make sure to destroy textures that you aren't using. Sometimes pixmaps get shared across multiple texture or image objects. Consider the following example in Slick2D: you load an Image, then you create a SpriteSheet, and then you use an Image array to reference three sprites. You are using five objects here, your original image, your spritesheet and three references to some subimages of your original image. However, they all will be sharing the same pixmap on video RAM. If you destroy that pixmap, you destroy the pixmap for all of them. So, if you are using a spritesheet, a tileset, a bitmap/AngelCode font, be careful on deleting pixmaps.
Saturday, March 30, 2013
City Road Prototype Pre-Alpha 0.0.2
Yay, second release! :-). Screenshot first.
So, v0.0.2. This prototype is growing and I've already got a few ideas on what to do with this code after this prototype is finished... won't talk about them right now, they are better protected in my head right now ;-).
Changelog:
Here's the download link (multiplatform, Zip, 3,3 MB). As usual, I don't expect many people reading this but if you do and you download the game, I would appreciate any feedback, any thoughts or any bug report, write a comment below or tweet me at @danirod93 and I'll read it.
So, v0.0.2. This prototype is growing and I've already got a few ideas on what to do with this code after this prototype is finished... won't talk about them right now, they are better protected in my head right now ;-).
Changelog:
- Widescreen. YAY! (don't know how does that affects my game)
- Isometric map. YAY! (awesome 2.5D graphics)
- Panning. You can right-click the screen and drag to move along the map. At the moment there's nothing interesting to see here as the map for now is fixed at 16x16 tiles.
- Tiles render darker if mouse is over them. That makes easier to understand that you CAN click (and drag) to create roads.
- As I said in my previous post, car has been removed. Priority issues: better to work on finishing and improving a feature before starting working on another. Car will be back soon, with a better AI.
Here's the download link (multiplatform, Zip, 3,3 MB). As usual, I don't expect many people reading this but if you do and you download the game, I would appreciate any feedback, any thoughts or any bug report, write a comment below or tweet me at @danirod93 and I'll read it.
Isometric engine
No more orthogonal maps, CRP has gone isometric!
This isometric map looks a thousand times better than my old orthogonal map. Just compare this screenshot above with the one from the previous post. v0.0.1 city was plain 2D, like if you were flying above the city and you looked straight down. Now, my city has got depth, and you can see that some roads are nearer to you than others.
This has some advantages as I may add more features later. For instance, say that I want to add buildings. If I had to render buildings using my old orthogonal system from 0.0.1, you would see buildings from above, so you would see some squares. Using this isometric engine, you would see buildings as 3D boxes, giving the game a better look.
Plus, I've improved my grass texture as you can see. Grass textures are quite easy to do with any advanced image editor like GIMP or Photoshop, just fill your sprite with a solid green color, and then add some noise to make pixels randomly brighter and darker.
However, isometric maps need more processing than orthogonal maps. For instance, I had to remove the road designer, so right now you cannot add or remove road tiles by clicking them. I have to rewrite that feature from scratch. The technical reason behind that is that detecting which tile is the mouse at was easier on v0.0.1: tileX = mouseX / tileWidth, tileY = mouseY / tileHeight. However, things are now harder to do.
 |
| City Road Prototype has gone isometric! |
 |
| Old 2D orthogonal map from v0.0.1 |
This has some advantages as I may add more features later. For instance, say that I want to add buildings. If I had to render buildings using my old orthogonal system from 0.0.1, you would see buildings from above, so you would see some squares. Using this isometric engine, you would see buildings as 3D boxes, giving the game a better look.
Plus, I've improved my grass texture as you can see. Grass textures are quite easy to do with any advanced image editor like GIMP or Photoshop, just fill your sprite with a solid green color, and then add some noise to make pixels randomly brighter and darker.
However, isometric maps need more processing than orthogonal maps. For instance, I had to remove the road designer, so right now you cannot add or remove road tiles by clicking them. I have to rewrite that feature from scratch. The technical reason behind that is that detecting which tile is the mouse at was easier on v0.0.1: tileX = mouseX / tileWidth, tileY = mouseY / tileHeight. However, things are now harder to do.
Thursday, March 28, 2013
City Road Prototype
During this week I've been working on another game prototype in Slick2D. At the end of this post I will provide you download links to what I've done. Here's a little nice screenshot:
What you see here is called City Road Prototype.
This demo creates some green terrain (grass?). Player can draw streets by clicking and dragging the terrain, that will place road tiles. Game engine will automaticly make those road tiles look like streets and intersections if there are nearby road tiles.
There's also a car, that little red dot you see on the left. Game will randomly spawn a car if there's no one. Car IA is at the moment really dumb: they will only attempt to move forward; if the road ends, they will turn somewhere else to keep moving forward. It's dumb because sometimes they turn back doing a 180º turn, which is actually dangerous (at least in real life). Should check that so that they better turn left or right when possible.
Although I've been doing a lot of prototypes on the last months, this one is attracting me a lot. I usually let my prototypes rot as soon as they bore me. I just HOPE that this does not happens this time. Here is a download link to v0.0.1 (Zip, 3.4 MB). It's multiplatform and it has already been configured to work like a charm on any operating system out there so you should not have any issues. Just download and extract. If you are using Windows, double click the JAR file or run BAT file if you are having issues. Mac, Linux and Solaris users can run SH file.
I don't expect many people reading this blog post but if by some reason you read this and you decide to download my demo, please give me feedback about any issues you could have so that I can fix them on future alpha releases.
What you see here is called City Road Prototype.
This demo creates some green terrain (grass?). Player can draw streets by clicking and dragging the terrain, that will place road tiles. Game engine will automaticly make those road tiles look like streets and intersections if there are nearby road tiles.
There's also a car, that little red dot you see on the left. Game will randomly spawn a car if there's no one. Car IA is at the moment really dumb: they will only attempt to move forward; if the road ends, they will turn somewhere else to keep moving forward. It's dumb because sometimes they turn back doing a 180º turn, which is actually dangerous (at least in real life). Should check that so that they better turn left or right when possible.
Although I've been doing a lot of prototypes on the last months, this one is attracting me a lot. I usually let my prototypes rot as soon as they bore me. I just HOPE that this does not happens this time. Here is a download link to v0.0.1 (Zip, 3.4 MB). It's multiplatform and it has already been configured to work like a charm on any operating system out there so you should not have any issues. Just download and extract. If you are using Windows, double click the JAR file or run BAT file if you are having issues. Mac, Linux and Solaris users can run SH file.
I don't expect many people reading this blog post but if by some reason you read this and you decide to download my demo, please give me feedback about any issues you could have so that I can fix them on future alpha releases.
Subscribe to:
Posts (Atom)