CodingPosted by Marie Mon, April 30, 2012 12:40:09
In Star, I'm using three layers in order to create a feeling of 3D-depth in a 2D game:
* Front stars, moving fast and pulsating, large size
* Middle stars, moving fast, medium size
* Background stars, moving slow, small size
The depth feeling comes from the two last layers, when you see the "closer" (larger) stars moving past the "distant" (smaller) ones.
But lets talk and let me show you some code on the first one, the pulsating front stars. This layer if made up by three different textures, that each is transparent except for a few white painted stars.
I only show one of the three front star textures and once, and toggle which one is used, with a pause in between. When a texture is being used, I will gradually change the transparency to make a fade-in-fade-out pulsating effect.
I also move the layer to the left and paint it anew to the right as the side-scrolling game progresses.
Code sample from the pulsating stars:
CodingPosted by Marie Wed, April 25, 2012 22:54:24
A few days ago, I had a friend who is also an old demo coder over for code reviewing. I showed off the game and got some feedback.
One thing I had chosen earlier was to use a constant timebox for my game loop that updates coordinates and draws them. It would only draw if it had enough time left after update (about 5 ms) or at least every 5th loop. Each timebox was 20 ms. This kept the game on 50 FPS (1000 ms / 20 ms = 50).
However, what we noticed when looking closer was that the game had slight 'lag' feeling on the asteroids that moved forward. My friend mentioned that upon switching screen buffer (replacing the current image shown on screen with whatever new image has been drawn until then), in some graphic libraries that function delays and waits for the graphic card to draw. I figured that was the cause of the lag.
The problem was that the graphic card was set on updating the screen with 60 Hz (60 times per second) while the game only generated 50 FPS (50 images per second). That meant, that 10 times per second, the same screen was shown again, which the player experienced as "lag". It's also why first trailers of the game was even more laggy (it had even ANOTHER frame rate that was totally out of sync).
I've now changed the implementation completely by adding delta time in all update functions. The functions multiply the movement per millisecond by the number of millisecond elapsed since the last update.
The game flows great now, without lag, and will have the same speed no matter which computer or refresh rate is used. And I've learnt to choose delta time before time window next time.
CodingPosted by Marie Wed, April 25, 2012 22:19:22
I recently found a new solution for my resource management system:
The system asks the graphicsystem singleton to retrieve a pointer to a sprite by giving an enum as id. The underlying implementation relies on an X-macro (yes, I know they are blunt, pollute, hard to debug and overwrite stuff, but also most useful). By asking for an enum, it won't even compile unless a correct enum is given. Way better than using the other sprite info available (the sprite path url), that would show errors first when getting runtime exceptions.
Another advantage was that I could automate the resource loading. All resources specified in the X-macro will be loaded automatically by looping the enum. More info about the X macro solution I used can be found on DrDobbs website.
GeneralPosted by Marie Wed, April 25, 2012 21:25:46
I asked some colleagues to playtest my game in order to make sure:
- It has the same speed on their computers
- It doesn't crash nor miss some DLL library
What I did notice was that the Debug version works fine, but the Release has a problem in that 64-bit operating systems need the 64-bit version of some DLL's in order to work (the 32-bit version was not good enough). I haven't found any easy way to solve it yet. In most cases the operating system already has the right version, so for now I'm solving it by including the DLL's in the distribution along with some troubleshooting instructions.
Another thing that did happen however, was one of my colleagues, the graphics artist Lorenzo, wanting to improve my 'coder graphics' and offering to remake some textures. I happily accepted the offer and new gfx are in the works. So far, a new ship, logo and force field icons have been made. Great job by Lorenzo, who is now also included in the credits.
FeaturesPosted by Marie Wed, April 25, 2012 21:13:56
I've been working with Star on and off for a few months now.
It started with the gameplay mechanics. When I got something fun that I liked, I started to think and make a priority list of what I needed to add in order for the game to feel like a real game:
- Win/loose condition
- Make the asteroids rotate
I'ts all been implemented now.
The reason music had not been added before was because I wanted everything in the game to be a product of mine. After speaking to a friend who thought I should just copy everything that is not part of my skill in order to make the game as polished as possible, I changed my mind.
I finally found the music from hours of going through trance mixes on Youtube. My requirements was not to hear anyone singing as well as having different pace in each song. The higher the level in the game, the faster the stones move and the faster paced music will be played.
I've added the artists in the game's credits. Hopefully they won't mind, and if they do, I'll remove their work instantly. I hope they see it as a compliment and way to spread their music.
The graphics are at least made by me. I'm really proud of the backgrounds that I made with a few tips from Photoshop tutorials: