Some changes were made to the resource cache as based on Mike McShaffry's "Game Coding Complete 3rd Ed.", an excellent games programming book may I add. The resource cache is now much more flexible and allows it to maintain things like D3D Textures for sprites. These changes were done to facilitate the introduction of the sound component which seems to be coming along nicely.
I am currently planning to support 3 audio types, uncompressed WAV, OGG and MP3. My plan is to stream music and large audio files straight from the harddrive. How this will work in the context of the resource cache remains to be seen. One option is to leave music files seperate from the resource cache, although I'm not too keen on this. The only other option is to somehow stream the music from the compressed zip that makes up the resource files. This seems like a difficult job however, since I'll essentially have to decompress the audio twice, one from the zip and secondly from Mp3 or whatever format into raw PCM data that can then be used by the underlying audio API.
The sound will be done on windows using XAudio2. DirectSound seems to be one the way out now and XAudio2 is also cross-compatible with the X-Box 360 which is a bonus If I want to port it (meaning I can leave most of the audio code intact). I haven't decided on the API's for other platforms yet, but I'll cross that bridge when I come to it.
Wednesday, 30 September 2009
Sunday, 20 September 2009
Basic Main Menu in place
I've implemented a pretty simple main menu with some buttons on it. None of the buttons are hooked up yet so that'll probably be the next task. The main menu is accessed after the user passes the splash screen. Text/Graphics should be added to these screens. I'll probably add some sort of disclaimer/GNU notice on the splash and the title on the main menu. For the background I want to play a video, this will probably be a video of me playing the game when I get the game/video components implemented.
Thursday, 17 September 2009
User interface coming along
Development recently has been focused on the user interface. This effected several changes in other systems like the renderer and platform also. I really want to get on with the fun part (developing the actual game) but as I've mentioned my approach is to have as many other components in place as possible first. It shouldn't really matter what order you write your code in though, if your design is modular and clean.
Developing a user interface is easy whilst developing a good user interface is very hard. With the user interface for PhysTank (as with most games) easy is taken over functional. A fully fledged UI API would contain a richly featured widget system, incorporating buttons, sliders, dialog boxes etc no dissimilar to the java swing libraries, developed entirely in a blackbox fashion and probably farmed out to a seperate library. There are C++ API's that exist which contain this and deciding whether to use one of these or roll your own is often a tough choice. For PhysTank the UI doesn't have to be particularly complex, I probably won't be using that many floating dialog boxes or slider controls, so where appropriate will fashion my own thrown together widgets. In a game that does require a more complex UI I would definitely recommend using an API like GTK. Using common API's like this rather than rolling your own will not only save you lots of time but since most UI API's are designed around making sure users have a certain degree of familiarity you won't be confusing your players with weird and wonderful designs. I will probably be using one of these API's when it comes to writing the level editor.
The User Interface still has a long way to come, and I probably won't polish it off until (very) late in development, but as long as there's something in place that gives the player reasonable feedback about what's going on in the game it'll do. Next up on my check list is to implement a basic main menu for the game, also further down the line colour schemes. One problem I'm having is deciding how screen elements (pictures, text etc.) should be placed and scaled on screen. If the user ups the resolution from 800x600 to 1024x768 for example, or higher, then icons and text will appear too small on the screen. In order to fix this these things have to be scaled dynamically based on some "ideal" resolution (i.e if the ideal resolution was 800x600 then on a 1024x768 display that would be a scale factor of 1.28 for the on screen elements). Doing this in an elegant manner isn't easy, and I may just have to resort to having the renderer scale things automatically and all positions given in the range 0-1 and maybe implement scaling functions for text (GetFontSizeScaled() for example).
Developing a user interface is easy whilst developing a good user interface is very hard. With the user interface for PhysTank (as with most games) easy is taken over functional. A fully fledged UI API would contain a richly featured widget system, incorporating buttons, sliders, dialog boxes etc no dissimilar to the java swing libraries, developed entirely in a blackbox fashion and probably farmed out to a seperate library. There are C++ API's that exist which contain this and deciding whether to use one of these or roll your own is often a tough choice. For PhysTank the UI doesn't have to be particularly complex, I probably won't be using that many floating dialog boxes or slider controls, so where appropriate will fashion my own thrown together widgets. In a game that does require a more complex UI I would definitely recommend using an API like GTK. Using common API's like this rather than rolling your own will not only save you lots of time but since most UI API's are designed around making sure users have a certain degree of familiarity you won't be confusing your players with weird and wonderful designs. I will probably be using one of these API's when it comes to writing the level editor.
The User Interface still has a long way to come, and I probably won't polish it off until (very) late in development, but as long as there's something in place that gives the player reasonable feedback about what's going on in the game it'll do. Next up on my check list is to implement a basic main menu for the game, also further down the line colour schemes. One problem I'm having is deciding how screen elements (pictures, text etc.) should be placed and scaled on screen. If the user ups the resolution from 800x600 to 1024x768 for example, or higher, then icons and text will appear too small on the screen. In order to fix this these things have to be scaled dynamically based on some "ideal" resolution (i.e if the ideal resolution was 800x600 then on a 1024x768 display that would be a scale factor of 1.28 for the on screen elements). Doing this in an elegant manner isn't easy, and I may just have to resort to having the renderer scale things automatically and all positions given in the range 0-1 and maybe implement scaling functions for text (GetFontSizeScaled() for example).
Sunday, 13 September 2009
Changes to the physics system.
I've changed the Physics component to expose more the underlying Box2D implementation. The reason for doing this is that I didn't see much point in building a complete wrapper only to act as a relay to Box2D function calls and restrict functionality available to the game. Due to this the Physics class has become more of a helper class, defining functions which will make future code look cleaner and easy to understand, such as functions to create physics bodies and shapes rather than having shape and body definitions all over the place.
The other changes include adding an AbstractCollideable and AbstractCollisionHandler to the Physics component. Game entities will be able to inherit from AbstractCollideable and be notified of when a collision occurs between them and another body/shape. The other type of collision handler, AbstractCollisionHandler, can be registered in order to receive global collision notifications. This would be useful for the sound system for example, which could implement this class to play sounds when a collision occurs.
As is often the case when using third-party code, finding the right implementation in your code can be somewhat of a nightmare. Your natural instinct is to encapsulate the third party code in your own set of classes which masks its use to the rest of your application logic. The problem with this is that the used code can often be quite large and have a fairly complex interface, so unless you want to spend a great deal of time encapsulating every small function call you're probably going to end up masking some of the used library's functionality.
The alternative to is present the third-party code directly to your application. The problem with this is that it very much ties it to your game, so if you find a better solution to the problem down the line, then replacing the system can be quite a long drawn out and loborious task. It's extremely difficult to create a "one-size-fits-all" interface class for systems with complex interfaces. It's very rarely you'll find a perfect solution to this problem. In PhysTank you can see both approaches, with the Renderer I've very much gone down the route of masking functionality in favour of portability and modularity, where with the Physics component I'm tieing the Physics API being used to my game. The difference is that the Physics API should be portable between various platforms since it itself has been written platform-independent, where as there a good chance the rendering code can't be (especially in the case of Direct3D).
I am not entirely happy with the approach but as is often the case with Game Development, trade-offs are part and parcel.
The other changes include adding an AbstractCollideable and AbstractCollisionHandler to the Physics component. Game entities will be able to inherit from AbstractCollideable and be notified of when a collision occurs between them and another body/shape. The other type of collision handler, AbstractCollisionHandler, can be registered in order to receive global collision notifications. This would be useful for the sound system for example, which could implement this class to play sounds when a collision occurs.
As is often the case when using third-party code, finding the right implementation in your code can be somewhat of a nightmare. Your natural instinct is to encapsulate the third party code in your own set of classes which masks its use to the rest of your application logic. The problem with this is that the used code can often be quite large and have a fairly complex interface, so unless you want to spend a great deal of time encapsulating every small function call you're probably going to end up masking some of the used library's functionality.
The alternative to is present the third-party code directly to your application. The problem with this is that it very much ties it to your game, so if you find a better solution to the problem down the line, then replacing the system can be quite a long drawn out and loborious task. It's extremely difficult to create a "one-size-fits-all" interface class for systems with complex interfaces. It's very rarely you'll find a perfect solution to this problem. In PhysTank you can see both approaches, with the Renderer I've very much gone down the route of masking functionality in favour of portability and modularity, where with the Physics component I'm tieing the Physics API being used to my game. The difference is that the Physics API should be portable between various platforms since it itself has been written platform-independent, where as there a good chance the rendering code can't be (especially in the case of Direct3D).
I am not entirely happy with the approach but as is often the case with Game Development, trade-offs are part and parcel.
Thursday, 10 September 2009
Help
I should mention that I'm always looking for help, coding, asset creation etc. If you're interested in working on a fun project either e-mail me or leave a comment and we'll work out giving your repository access.
I really should work on the design documentation so everyone has a better idea of what the game actually involves.
I really should work on the design documentation so everyone has a better idea of what the game actually involves.
PhysTank with Physics!
A basic physics component has been semi-implemented using Box2D. I still need to complete the interface and make sure everything is working as it should. Next I will probably move onto sound, I want to complete the tertiary components so I know what I'm working with when developing the game itself. The next step after that will probably be to allow users/developers to manipulate INI/XML files in order to change application settings. This will include things like choosing which renderer to use (only Direct3D at present), display resolution, setting AF(Anisotropic Filtering) on the loaded textures and MSAA (Multi-Sampling Anti-Aliasing) to make the line drawing seem smoother as well as run speed etc.
A good tip: Use the interface design pattern and use lots of them, I can't stress how useful a good interface class can be. By interface I mean an abstract class which contains nothing but pure virtual functions that you inherit from. The reason for doing this, for the renderer for example, is that it provides a common interface that lets you switch out various components. For example at some point I'll be writing an OpenGL renderer for PhysTank that I should just be able to plug-in without having to change any interactions between the UI and the Renderer. Even if you don't think you're going to need one, for example if your game is only ever going to have one renderer, I'd still recommend doing it because it makes you think about the interface to components you're creating.
All too often there's a temptation to use the D3DX extension classes for example in areas of code outside of the platform or renderer, i.e. in your main game code. D3DX provides perfectly good Matrix and Vector classes right? Along with an entire set of easy to use functions. Resist using these things in your game code at all cost. If you don't feel like writing your own vector or matrix class (although you probably should), at least use what are called wrappers which hide the underlying implementation as a D3DX class (or if you're really lazy use typedefs, i.e. typedef D3DXMatrix Matrix4x4). Then if at some point down the road someone offers to port your game to a UNIX OS they won't have to tare their hair out looking through file after file attempting to replace every D3DX call and instantiation, they can simply re-write the vector and matrix classes.
Keeping platform dependent code out of your main game code keeps things looking cleaner and easier to understand too, it also makes you more diligent against lazy programming.
A good tip: Use the interface design pattern and use lots of them, I can't stress how useful a good interface class can be. By interface I mean an abstract class which contains nothing but pure virtual functions that you inherit from. The reason for doing this, for the renderer for example, is that it provides a common interface that lets you switch out various components. For example at some point I'll be writing an OpenGL renderer for PhysTank that I should just be able to plug-in without having to change any interactions between the UI and the Renderer. Even if you don't think you're going to need one, for example if your game is only ever going to have one renderer, I'd still recommend doing it because it makes you think about the interface to components you're creating.
All too often there's a temptation to use the D3DX extension classes for example in areas of code outside of the platform or renderer, i.e. in your main game code. D3DX provides perfectly good Matrix and Vector classes right? Along with an entire set of easy to use functions. Resist using these things in your game code at all cost. If you don't feel like writing your own vector or matrix class (although you probably should), at least use what are called wrappers which hide the underlying implementation as a D3DX class (or if you're really lazy use typedefs, i.e. typedef D3DXMatrix Matrix4x4). Then if at some point down the road someone offers to port your game to a UNIX OS they won't have to tare their hair out looking through file after file attempting to replace every D3DX call and instantiation, they can simply re-write the vector and matrix classes.
Keeping platform dependent code out of your main game code keeps things looking cleaner and easier to understand too, it also makes you more diligent against lazy programming.
Monday, 7 September 2009
Phystank Update
PhysTank is coming along nicely, resource cache, renderer and the game engine are in place, also work has began on the user-interface and game components. Next up physics (which I will use a 3rd party library for, like Box2D) and a bit further down the road sound. Since the game will be rendered entirely using lines I won't have to mess around for hours in photoshop, although some nice user-interface graphics would be nice.
Tuesday, 1 September 2009
New Project Started - Phystank
Phystank is a two-dimensional puzzle game involving physics. The player will be forced to confront, as well as puzzles, a whole host of different enemy types. The game will also come with a pre-packaged editor.
Subscribe to:
Posts (Atom)