So long time no posty ... I gots me a job, yay! So busy, busy, busy!
Me and the Herriman team have been eager to work on a new project. Gaz has been concentrating on a few ideas on a long time theme, but we've decided to put that on the back burner for a number of reasons. We all still need to learn a lot so we're just going to experiment on a few ideas and see how they turn out.
All that I can say now is that it involves Monkey's .. possibly of the albino variety .. yes we are mad :) Should be a lot of fun
Sunday, 28 October 2007
Tuesday, 3 July 2007
IGN mentions Herriman: Under Pressure! and the XNA User Group
Even though Gaz has mentioned it on his blog I feel obliged to say that Herriman: Under Pressure! our winning XNA game has been mentioned on IGN: http://uk.xbox360.ign.com/articles/800/800923p1.html
The prestige is really great, especially as I read the site nearly every other day. Now if someone would notice and give me a job, that would be great!
The prestige is really great, especially as I read the site nearly every other day. Now if someone would notice and give me a job, that would be great!
Monday, 2 July 2007
Moved blog
Just to say that I've moved my blog from www.theblog.net (while I'm waiting for things to compile). Blogger is much more user friendly and has much less (no) broken links. Blogger also has more functionality as well, although my images aren't displaying correctly... I'll have to work on that bit.
Dan: Under Pressure!
I knew about the competition on the afternoon of the 5th June - so we had quite a few days of catching up to do. This started with a frantic brain storming session that outlined some of the foundations of the game, the game mechanics, the characters and the artistic direction, nearly all courtesy of Gaz, one of the artists on the project. The game mechanics were to later change as we saw and played the game in its development state.
The late start was compounded by the fact that I had only worked very minimally with both C# and the XNA framework, coming from a C++ background ... still I had some confidence that we could pull it off or at least enjoy trying to.
A day or to after the brain storming session we enlisted another artist who later came to focus on the level; its design and layout. Dave did a fantastic job on the level design, art wise and the position of the enemies and pickups. I started coding like a man possessed, starting with the animated sprite and pixel collision samples. During this time I learnt/remembered how to use C# and the XNA framework, simple things like using and iterating containers! I had some dodgy collision response for a while and I was panicking a little, as it all rested on it - in the end it works nearly 99% the time which is surprising!
Some days later we recruited a sound artist that made some great music tracks and started on some sound effects, unfortunately we didn't have quite enough time to incorporate them all (or time them correctly!).
I felt my productivity was on a all time high during the next 10/11 days, I was working at every opportunity (mmm.. caffeine) coding and learning more about the framework. The only thing that let it down was time wasted on unimportant things near the end, the pressure (pun intended) was taking its toll and my fingers/brain couldn't work any faster. Its very much against me to not test a piece of software and put good error handling code in, but there was no time for it. I would have also liked some extensive gameplay testing so we could tweak all the numbers as well as the character behaviours.
There's a few obvious bugs in the final version, mostly to do with sound, at the moment the sound API seems very bizarre, especially working with the XACT tool. Another thing that I'm not happy with is the horrible performance (particularly at load time) and horrid memory usage, things I have since fixed surely to everyone's chagrin.
Most important though, I have really enjoyed working on the project and gained many things from it. I think C# and development with XNA definitely allows for an ease and speed improvement in the development process, I've enjoyed using them and I'll definitely use them again.
The team did some sterling work on getting a playable, nice looking game within that time frame and I want to thank them all for there hard work; it would have been nothing without them. I'd also like to say I was amazed by some of the sound and art entries - I felt we were spoilt for choice.
I've been working on correcting/collecting all the bugs, introducing a few optimisations, and incorporating all the artwork from Gaz that never made it in. You can try out the game here: http://www.divshare.com/download/1117858-df0
You'll need the .NET framework and Microsoft XNA Framework Redistributable to run the game. Enjoy!
If you have any problems see this post.
The late start was compounded by the fact that I had only worked very minimally with both C# and the XNA framework, coming from a C++ background ... still I had some confidence that we could pull it off or at least enjoy trying to.
A day or to after the brain storming session we enlisted another artist who later came to focus on the level; its design and layout. Dave did a fantastic job on the level design, art wise and the position of the enemies and pickups. I started coding like a man possessed, starting with the animated sprite and pixel collision samples. During this time I learnt/remembered how to use C# and the XNA framework, simple things like using and iterating containers! I had some dodgy collision response for a while and I was panicking a little, as it all rested on it - in the end it works nearly 99% the time which is surprising!
Some days later we recruited a sound artist that made some great music tracks and started on some sound effects, unfortunately we didn't have quite enough time to incorporate them all (or time them correctly!).
I felt my productivity was on a all time high during the next 10/11 days, I was working at every opportunity (mmm.. caffeine) coding and learning more about the framework. The only thing that let it down was time wasted on unimportant things near the end, the pressure (pun intended) was taking its toll and my fingers/brain couldn't work any faster. Its very much against me to not test a piece of software and put good error handling code in, but there was no time for it. I would have also liked some extensive gameplay testing so we could tweak all the numbers as well as the character behaviours.
There's a few obvious bugs in the final version, mostly to do with sound, at the moment the sound API seems very bizarre, especially working with the XACT tool. Another thing that I'm not happy with is the horrible performance (particularly at load time) and horrid memory usage, things I have since fixed surely to everyone's chagrin.
Most important though, I have really enjoyed working on the project and gained many things from it. I think C# and development with XNA definitely allows for an ease and speed improvement in the development process, I've enjoyed using them and I'll definitely use them again.
The team did some sterling work on getting a playable, nice looking game within that time frame and I want to thank them all for there hard work; it would have been nothing without them. I'd also like to say I was amazed by some of the sound and art entries - I felt we were spoilt for choice.
I've been working on correcting/collecting all the bugs, introducing a few optimisations, and incorporating all the artwork from Gaz that never made it in. You can try out the game here: http://www.divshare.com/download/1117858-df0
You'll need the .NET framework and Microsoft XNA Framework Redistributable to run the game. Enjoy!
If you have any problems see this post.
Friday, 29 June 2007
Win of the XNA user group competition, best overall game!
I've just heard the news that our team has won the best overall game category for the XNA UK user group, which is excellent, excellent news! In the next few days I shall try and detail the time in development, which resulted from the 11 days that we had available from hearing about the competition. This is just a brief post but I would like to thank the team who really pulled together for Herriman, thanks guys!
I'd also like to thank the hosts of the competition; the UK XNA user group and of course Nescafe.... for now I'm going to celebrate and let it sink in!
Wednesday, 30 May 2007
New Project - Ion Core
As usual its been a while since I've updated this blog, I'd like to take the opportunity to talk about my latest project; Ion Core. As well as the few tons of report that accompanied it, Ion Core was developed for my Final Year Project at Uni which I've recently finished and waiting for my results. I am really happy with the game and have gained a lot of good feedback. I am currently in the process of improving the game; first ironing out the small bugs or inconsistencies then new features will start to be added. Hopefully I will describe some of the new features here. You can read about Ion Core here.
I should probably mention my previous C++ game project; 'CastleWall'. Although software wise it was going fairly well in my spare time on my work placement I feel the game design has hit a brick wall. As a first project I think it was a bit to much to manage especially with the unfamiliar and unexplored game dynamics. I have learnt that you've got to start with a firm idea, usually described in a design document which to expand on in order to make a good game. Although I am proud of the progress in the game I feel abandoning is the best thing to do because I can work on more sure and feasible projects. I feel at the end of the day it was a good test bed for exploring some game components and features of the Ogre3D engine.
View More photos
I should probably mention my previous C++ game project; 'CastleWall'. Although software wise it was going fairly well in my spare time on my work placement I feel the game design has hit a brick wall. As a first project I think it was a bit to much to manage especially with the unfamiliar and unexplored game dynamics. I have learnt that you've got to start with a firm idea, usually described in a design document which to expand on in order to make a good game. Although I am proud of the progress in the game I feel abandoning is the best thing to do because I can work on more sure and feasible projects. I feel at the end of the day it was a good test bed for exploring some game components and features of the Ogre3D engine.
View More photos
Tuesday, 16 May 2006
"CastleWall" 0.2 progress
So its been a while since I've updated me ood blog, especially on my c++ projects front - which I really should do, as not only does it help me show off ;) which everyone has to do a little of now and again.. it helps me keep track of my own progress and solidify it in my mind. Here's a biiig update to make up for it.
I've been working on what I've been calling 'CastleWall 0.2', though I feel the iteration should be a little higher, which shows I'm not setting any milestones for myself, oh well I'm learning it all for the first time.
So what have I done? Well I've got two castle's made up, with full opal/ODE physics. Its a lot of bricks, so I had to make them larger and fewer, and they had to be box primitives unfortunately as ODE doesn't support trimesh-trimesh collision, which was a bit of a blow when I found out.. The primitive shapes do anything for any semblance of realism as you might imagine, I plan to try using a random selection of materials to add more variation and/or some offset mapping to see if that helps. The good part is that all the bricks are loaded from a .scene(xml) file from blender and a method just adds physical attributes to the mesh used. This means that all sorts of structures can be made, and characters placed within Ogre. Though I'd like to add scripting to pick up the object names in Blender for use without re-compiling
Performance is still low when certain parts of the castle's get struck and the collisions get complex, I'm going to have to work on this part. I've made the current player's castle static geometry and that helps tremendously, its when a big proportion of the castle 'bricks' have a force acting on them that causes the slow performance problems, perhaps a good solution would be to limit the amount of objects that can be physically effected for each major collision, such as cannonball striking.
I decided to go for a multi-speculuar bump mapping shader, which I admit I from the Ogre sample, I really want to learn how to write shaders, but I'm concentrating on C++ and general game programming and anyway, why re-invent the wheel? The performance difference doesn't seem to be that bad either between that and a more basic material.
I've got terrain with a splatted texture, not PLSM2 as when I first tried it I couldn't for the life of me get it to run, though the latest version works a treat. I don't think it would be an advantage as my test level is very small anyway.
I've also added a skybox of rolling green hills and somewhat blended the terrain into in, which I'm quite proud of, I just have to alter the terrain to round at the edges in the correct way to look like it is completely another hill no different from the skybox ones.
Another feature (its not a bug, honest!) I'm proud of so far is when the current players turn is up, an animation track, takes the camera to the other player, I bit like Battlefield I've noticed though without all the post-effects (can't wait to dig into the Ogre compositor framework!)
I've also managed to integrate/modify a class so that player names can be displayed above players heads, I've made it so they appear central out visible at a sensible height to be read at a distance, its a pity I'm still using the Ogre Head, which is the biggest sore thumb of the artwork at the moment. I'm hopefully going to take a bit of time out to model some reasonable looking wizards.
I've also made use of the GameState manager to create a menu state after getting through a lot of my own mistakes. This has just a ocean, skybox and working menu items for New Game and Exit Game. I'd like to get some in-game options in there at some point too. The ocean needs and big island of rolling hills that I can fly to and around, I think that would look super cool. I'd like a water shader in at some point, one that will work on my ancient temporary Nvidia Tnt2 (ATI 9600 finally melted).
Theres also a feature in their to build, that is create shapes (currently based on tetris shapes) that can be moved and rotated on all axis via a menu and then made physical. These will be surrounded by swish magical effects with particles.
I should mention that I've managed to implement these features thus far: a simple sound manager in via Audiere, physics, a working CEGUI interface, particles, scripting, OIS input, a process manager and a game state manager. So I guess I shouldn't be too hard on myself with my progress. As most things though its turning out to be more of an undertaking than I thought. Though I've been learning lots of OOP and C++ and things about game programming, so its been very useful. I think my brain would have rotted at work by now if i had not started this project.
If any of you are interested out there, check back with any updates I hope to add soon
Check below for some screenies!
(Don't take these as an example of Ogre's real graphical prowess!)
More Pictures
I've been working on what I've been calling 'CastleWall 0.2', though I feel the iteration should be a little higher, which shows I'm not setting any milestones for myself, oh well I'm learning it all for the first time.
So what have I done? Well I've got two castle's made up, with full opal/ODE physics. Its a lot of bricks, so I had to make them larger and fewer, and they had to be box primitives unfortunately as ODE doesn't support trimesh-trimesh collision, which was a bit of a blow when I found out.. The primitive shapes do anything for any semblance of realism as you might imagine, I plan to try using a random selection of materials to add more variation and/or some offset mapping to see if that helps. The good part is that all the bricks are loaded from a .scene(xml) file from blender and a method just adds physical attributes to the mesh used. This means that all sorts of structures can be made, and characters placed within Ogre. Though I'd like to add scripting to pick up the object names in Blender for use without re-compiling
Performance is still low when certain parts of the castle's get struck and the collisions get complex, I'm going to have to work on this part. I've made the current player's castle static geometry and that helps tremendously, its when a big proportion of the castle 'bricks' have a force acting on them that causes the slow performance problems, perhaps a good solution would be to limit the amount of objects that can be physically effected for each major collision, such as cannonball striking.
I decided to go for a multi-speculuar bump mapping shader, which I admit I from the Ogre sample, I really want to learn how to write shaders, but I'm concentrating on C++ and general game programming and anyway, why re-invent the wheel? The performance difference doesn't seem to be that bad either between that and a more basic material.
I've got terrain with a splatted texture, not PLSM2 as when I first tried it I couldn't for the life of me get it to run, though the latest version works a treat. I don't think it would be an advantage as my test level is very small anyway.
I've also added a skybox of rolling green hills and somewhat blended the terrain into in, which I'm quite proud of, I just have to alter the terrain to round at the edges in the correct way to look like it is completely another hill no different from the skybox ones.
Another feature (its not a bug, honest!) I'm proud of so far is when the current players turn is up, an animation track, takes the camera to the other player, I bit like Battlefield I've noticed though without all the post-effects (can't wait to dig into the Ogre compositor framework!)
I've also managed to integrate/modify a class so that player names can be displayed above players heads, I've made it so they appear central out visible at a sensible height to be read at a distance, its a pity I'm still using the Ogre Head, which is the biggest sore thumb of the artwork at the moment. I'm hopefully going to take a bit of time out to model some reasonable looking wizards.
I've also made use of the GameState manager to create a menu state after getting through a lot of my own mistakes. This has just a ocean, skybox and working menu items for New Game and Exit Game. I'd like to get some in-game options in there at some point too. The ocean needs and big island of rolling hills that I can fly to and around, I think that would look super cool. I'd like a water shader in at some point, one that will work on my ancient temporary Nvidia Tnt2 (ATI 9600 finally melted).
Theres also a feature in their to build, that is create shapes (currently based on tetris shapes) that can be moved and rotated on all axis via a menu and then made physical. These will be surrounded by swish magical effects with particles.
I should mention that I've managed to implement these features thus far: a simple sound manager in via Audiere, physics, a working CEGUI interface, particles, scripting, OIS input, a process manager and a game state manager. So I guess I shouldn't be too hard on myself with my progress. As most things though its turning out to be more of an undertaking than I thought. Though I've been learning lots of OOP and C++ and things about game programming, so its been very useful. I think my brain would have rotted at work by now if i had not started this project.
If any of you are interested out there, check back with any updates I hope to add soon
Check below for some screenies!
(Don't take these as an example of Ogre's real graphical prowess!)
More Pictures
Subscribe to:
Posts (Atom)
