Yes, it's been way too long since anything was posted on the blog, but the amount of blog activity is generally inversely proportional to how intensely I'm working on the game!
I'm pleased to report that a closed alpha testing session is currently taking place, which should help iron out any system-related issues. Things are looking good so far for the main game engine being stable over a variety of hardware configurations.
After a few iterations of testing and improvement there will be a general alpha release posted on this blog, so watch this space!
Showing posts with label brainworm software. Show all posts
Showing posts with label brainworm software. Show all posts
Sunday, 30 October 2011
Sunday, 14 August 2011
Back from holidays!
The last month has been a little slow on development as I've had a couple of weeks of holiday, leaving me feeling refreshed and possibly even a little tanned.
The most important recent update is that scripted animated objects are now up and running properly. This means that doors (and any other environment object) may be animated by script strings, meaning that proper game interaction is now possible to generate, such as the player's craft needing to move to a specific location within the world and activate an object (which then executes the script) in order to open the door. These scripted objects are properly integrated into the physics engine, such that they impart appropriate force to any dynamic objects they collide with during their animations.
Now, the primary focus is on further development of the AI algorithms for the swarm, such that they can spot the player's ship and attack appropriately, including chasing them through the environment and performing proper route-finding. The basic navigation node structure is already complete and searchable, the main weakness is the lowest-level control i.e. correctly navigating between nodes without going out of bounds and colliding with the world.
I'm currently holding off creating a new video for a while until there are enough visible differences to make the recent updates apparent. Also, I had it pointed out to me recently that in all the videos so far I've been playing the game really badly (purposefully), mainly to show off collision particle effects etc., but I'll make sure on the next one to actually fly around normally!
The most important recent update is that scripted animated objects are now up and running properly. This means that doors (and any other environment object) may be animated by script strings, meaning that proper game interaction is now possible to generate, such as the player's craft needing to move to a specific location within the world and activate an object (which then executes the script) in order to open the door. These scripted objects are properly integrated into the physics engine, such that they impart appropriate force to any dynamic objects they collide with during their animations.
Now, the primary focus is on further development of the AI algorithms for the swarm, such that they can spot the player's ship and attack appropriately, including chasing them through the environment and performing proper route-finding. The basic navigation node structure is already complete and searchable, the main weakness is the lowest-level control i.e. correctly navigating between nodes without going out of bounds and colliding with the world.
I'm currently holding off creating a new video for a while until there are enough visible differences to make the recent updates apparent. Also, I had it pointed out to me recently that in all the videos so far I've been playing the game really badly (purposefully), mainly to show off collision particle effects etc., but I'll make sure on the next one to actually fly around normally!
Sunday, 10 July 2011
Token post!
OK, I say I'll do more regular updates and then immediately fail to post anything for a week. Welcome to OppositeLand, population me.
Work is still ongoing, worry ye not, with the focus on improving the scripting system and I/O for the more complex objects within the world map. Also, within the main asset management system there's now an overall object dictionary that handles everything from physics objects to particle fountains, allowing them to be spawned easily in a unified way.
So yes, at the moment it's all core engine work, but this is all necessary (except for a few sidetracks) in order to achieve my current main goal of scriptable game objects.
Work is still ongoing, worry ye not, with the focus on improving the scripting system and I/O for the more complex objects within the world map. Also, within the main asset management system there's now an overall object dictionary that handles everything from physics objects to particle fountains, allowing them to be spawned easily in a unified way.
So yes, at the moment it's all core engine work, but this is all necessary (except for a few sidetracks) in order to achieve my current main goal of scriptable game objects.
Thursday, 30 June 2011
The start of a series of shorter updates.
Up until now I've tended to try and get out one decent-length blog post a week during development, but I think I may change that pattern to trying to post something short today to give a quick snapshot of what I'm working on at any given point.
The main thing I'm up to at the moment is working on the world scripting - my primary goal is to create an animated door that can open/close based on interaction with a world object. I've already gotten the main scripting up and running, such that interacting with a destroyed ship will update the amount of resources you have, give you a new ship component or start a given bit of narrative, but this push towards having a properly dynamic environment will make a lot of difference.
The custom scripting language and the asset management system are tightly integrated. Here's an example of the current scripting that is implemented and working:
"$Timer #3.0 $ZoneResource1 #OFF"
The $ prefix is used to reference an asset that exists in the global asset management framework, and the # is used to indicate a constant value. In this case, there is a special asset called 'Timer' that allows scripts to be called with a specific delay; the #3.0 indicates that the delay should be 3 seconds, and the rest of the parameters '$ZoneResource1 #OFF' are the script to execute once the timer period has completed. ZoneResource1 is another interaction zone, and the #OFF value indicates that it should be rendered inactive after the call. If the last two parameters were replaced by 'script:ExampleScript', the asset management system would check to see if the ExampleScript asset were already in memory and, if not, load it in from a specific default directory.
[Foreseeing potential questions on this issue]
Why didn't I use Python? Because BOLLOCKS, that's why.
Of course, any time you try to do X in development, you tend to find yourself doing Y, Z and occasionally α to support getting X to work, as well as tidying up other bits that you come across while doing Y and Z. As a result, the damage callback system has been given a bit of an overhaul in the last day or so.
Right now, I'm working on an object factory so that a wide variety of different object types may be simply loaded, allowing enemy spawners, physics objects, debris, animated objects etc. to be loaded by the same framework. This will then mean that dynamic components (such as the opening/closing door) will be automatically created and assigned to the right list, and then may be scripted (after a wee bit of work on animation).
[Edit: OK, so that didn't turn out to be so short].
The main thing I'm up to at the moment is working on the world scripting - my primary goal is to create an animated door that can open/close based on interaction with a world object. I've already gotten the main scripting up and running, such that interacting with a destroyed ship will update the amount of resources you have, give you a new ship component or start a given bit of narrative, but this push towards having a properly dynamic environment will make a lot of difference.
The custom scripting language and the asset management system are tightly integrated. Here's an example of the current scripting that is implemented and working:
"$Timer #3.0 $ZoneResource1 #OFF"
The $ prefix is used to reference an asset that exists in the global asset management framework, and the # is used to indicate a constant value. In this case, there is a special asset called 'Timer' that allows scripts to be called with a specific delay; the #3.0 indicates that the delay should be 3 seconds, and the rest of the parameters '$ZoneResource1 #OFF' are the script to execute once the timer period has completed. ZoneResource1 is another interaction zone, and the #OFF value indicates that it should be rendered inactive after the call. If the last two parameters were replaced by 'script:ExampleScript', the asset management system would check to see if the ExampleScript asset were already in memory and, if not, load it in from a specific default directory.
[Foreseeing potential questions on this issue]
Why didn't I use Python? Because BOLLOCKS, that's why.
Of course, any time you try to do X in development, you tend to find yourself doing Y, Z and occasionally α to support getting X to work, as well as tidying up other bits that you come across while doing Y and Z. As a result, the damage callback system has been given a bit of an overhaul in the last day or so.
Right now, I'm working on an object factory so that a wide variety of different object types may be simply loaded, allowing enemy spawners, physics objects, debris, animated objects etc. to be loaded by the same framework. This will then mean that dynamic components (such as the opening/closing door) will be automatically created and assigned to the right list, and then may be scripted (after a wee bit of work on animation).
[Edit: OK, so that didn't turn out to be so short].
Tuesday, 14 June 2011
Because banging can be fun, can't it?
OK, the title is a reference to this video (RIP Roy Skelton), which is marginally justified due to this post including physical collisions between convex objects.
Since the last post quite a few significant updates have been made, which are best expressed through the medium of bullet points.
Since the last post quite a few significant updates have been made, which are best expressed through the medium of bullet points.
- The convex object collision detection/physics is working well (huzzah!)
- Springs (currently massless) have been implemented in the physics engine, which will form the basis of the tractor beam with Juggernaut.
- The damage and destruction framework has been significantly upgraded to include penetration levels for both laser and projectile weapons. For example, in the video you will see that the laser weapon immediately terminates upon hitting the debris, but passes through several Scourge enemies before terminating. A larger penetration factor for a weapon will improve its effectiveness against multiple enemies, but not against single tougher enemies.
- Each object can now have a convex collision shape associated with it that will be intersected with by laser + arc weaponry. This replaces the bounding-circle based object/object collision.
- Upgrades the asset management framework that allows resource files containing multiple asset types to be loaded in transparently. Dull, but very handy ;)
Sunday, 5 June 2011
Environmental decoration: instanced cilia
As well as all the ongoing work on the physics engine (the convex polygon routines now work except in a couple of extreme cases that I'm fixing), I've taken a little time out to make things more pretty. In this case, I've added some animated 'cilia' that will be used to add dynamic motion to some of the infested areas. The initial version of this is shown in the video below, although I've already updated the actual graphics to add a small bright tip to each strand, stopping it from just looking like grass.
Although there may be thousands of cilia on-screen at any one time, all the work is done by the GPU using immutable buffers. A specialised vertex shader adds the sinusoidal animation based on a time value supplied via a shader variable, as well as adding a small size variation. Also, rather than manually defining the position/angle of each cilia in a level (which would be quite memory-hungry), areas of cilia are just defined by a straight line with a normal.
To further improve the effect, cilia further away from the camera have their colour dimmed in order to provide a depth cue.
Although there may be thousands of cilia on-screen at any one time, all the work is done by the GPU using immutable buffers. A specialised vertex shader adds the sinusoidal animation based on a time value supplied via a shader variable, as well as adding a small size variation. Also, rather than manually defining the position/angle of each cilia in a level (which would be quite memory-hungry), areas of cilia are just defined by a straight line with a normal.
To further improve the effect, cilia further away from the camera have their colour dimmed in order to provide a depth cue.
Monday, 2 May 2011
The ship editor in action:
This video demonstrates the initial drag/drop ship editor interface in action. It shows that each ship component has a number of slots that can be used to attach either other structural components or weapons.
This video starts after the two wing elements and one of the engines have already been added (due to FRAPS time restrictions) - you then see the addition of a couple of power generators, which provide increased power recharge rate and power maximum (which is consumed by firing weapons), a missile launcher and a couple of standard energy cannons.
The angle of any of these components may be changed by dragging with the right mouse button, so you can create rear-facing/side facing weaponry as desired. As development progresses, there will also be computer-controlled turrets that will auto-target enemies.
This video starts after the two wing elements and one of the engines have already been added (due to FRAPS time restrictions) - you then see the addition of a couple of power generators, which provide increased power recharge rate and power maximum (which is consumed by firing weapons), a missile launcher and a couple of standard energy cannons.
The angle of any of these components may be changed by dragging with the right mouse button, so you can create rear-facing/side facing weaponry as desired. As development progresses, there will also be computer-controlled turrets that will auto-target enemies.
Juggernaut Ship Editor Demo Video from Darren Myatt on Vimeo.
Sunday, 1 May 2011
Time for reflection...
OK, while I'm putting off a bit of particularly annoying refactoring, I thought it may be a good time to post a quick reflection on how far Juggernaut (and I) have come so far.
I quit my previous job (as a technical consultant at a defence subcontractor) on the very first day back this year, because I simply couldn't do it any more. Monetarily it was a pretty good job, which is how I can now afford to do this, but I got no satisfaction from it and the pressure nearly drove me crazy.
I'd been working on the code that became the Juggernaut engine for about a year in my spare time (including long periods of nothing) before then: it initially started out as the engine for a 3D game named Super Robot Harpsichord which, who knows, may one day still get made. However, it quickly became clear that attempting to create a full 3D game on my own was completely infeasible in terms of art assets, at which point I came up with the basic idea for Juggernaut, although it has evolved a lot since the initial conception.
So, after fully leaving my last job on the 5th February, I have been working on Juggernaut (more than) full time. It is still quite ambitious (something warned of by MrMacguffin), but I am trying to keep to deadlines, and progress has been rapid.
My original plan was to make a first demo in May, and I think I'm still reasonably on target for that, although it's now going to be the end of May. It's certainly going to be an alpha release rather than a beta, but hopefully it should demonstrate enough of the concepts of the full game to get people interested.
I quit my previous job (as a technical consultant at a defence subcontractor) on the very first day back this year, because I simply couldn't do it any more. Monetarily it was a pretty good job, which is how I can now afford to do this, but I got no satisfaction from it and the pressure nearly drove me crazy.
I'd been working on the code that became the Juggernaut engine for about a year in my spare time (including long periods of nothing) before then: it initially started out as the engine for a 3D game named Super Robot Harpsichord which, who knows, may one day still get made. However, it quickly became clear that attempting to create a full 3D game on my own was completely infeasible in terms of art assets, at which point I came up with the basic idea for Juggernaut, although it has evolved a lot since the initial conception.
 |
| The Super Robot Harpsichord graphic engine at the time when work was stopped. Notice how everything has the same texture, a constraint that I quickly removed when creating Juggernaut! The red spheres are a large number of test bullets that bounce around the scene. |
My original plan was to make a first demo in May, and I think I'm still reasonably on target for that, although it's now going to be the end of May. It's certainly going to be an alpha release rather than a beta, but hopefully it should demonstrate enough of the concepts of the full game to get people interested.
The first high quality Alpha video!
Yes, it's finally here, I've managed to make a video that doesn't look like arse! Alas, the free version of FRAPS only allows clips of 30 seconds, and this video doesn't necessarily show off anything to the best effect, and the sound is knackered, but it's at least a start. Now that I'm confident it produces good results, I'll upgrade so that I can record full videos.
The video demonstrates the laser weapons and the force-applying missiles with space-warping effect. There's also going to be a graphical explosion effect for the missiles, but that hasn't been implemented yet.
Also, note that the Scourge aren't bothering to attack the player in this video as the AI is just set to do a patrol loop. In the actual game they'll turn and start following/attacking the player once spotted.
Juggernaut Alpha Demo 1 from Darren Myatt on Vimeo.
The video demonstrates the laser weapons and the force-applying missiles with space-warping effect. There's also going to be a graphical explosion effect for the missiles, but that hasn't been implemented yet.
Also, note that the Scourge aren't bothering to attack the player in this video as the AI is just set to do a patrol loop. In the actual game they'll turn and start following/attacking the player once spotted.
Juggernaut Alpha Demo 1 from Darren Myatt on Vimeo.
Saturday, 30 April 2011
Juggernaut Development Update.
My new keyboard arrived today that should help streamline the development of Juggernaut:
It'll be so much easier having the 1 key to the right of the 0, unlike standard keyboards. Also, the air-cooling will definitely reduce the level of key-melting that I usually experience.
It'll be so much easier having the 1 key to the right of the 0, unlike standard keyboards. Also, the air-cooling will definitely reduce the level of key-melting that I usually experience.
Post-Easter update
Since the 15th I have been exploring the vast and desolate wastelands of the North of England (while visiting my family over Easter), and only returned to Guildford a couple of days ago. Now, after going to the Reading Beer Festival yesterday I'm ready to start work properly again.
This is not to say that I haven't been working over the couple of weeks: things have actually come quite far. Before now, the main thing missing from the Juggernaut engine is any proper collision physics: rather than the player's ship bouncing off walls and taking damage (as you'd expect), damage was just applied while the ship was colliding with the main environment. This was just a temporary, but obviously incomplete, solution.
However, the advantage of being back in the North was that I only had my laptop with me, which lacks DirectX 10 hardware, and as a result there was no way that I could work on the main game engine. This forced me to do the necessary research in order to be able to implement a decent rigid body physics engine, which means that not only will the ship react well when colliding with walls, but it leaves a lot of room for interesting physics-based challenges, including pulling things around using a tractor beam. I'm currently just doing the refactoring necessary to integrate the physics engine with the main game engine, but in a few days I'm confident that this last major aspect of the game will be working well.
After that, it will be full steam ahead towards the creation of the first demo!
This is not to say that I haven't been working over the couple of weeks: things have actually come quite far. Before now, the main thing missing from the Juggernaut engine is any proper collision physics: rather than the player's ship bouncing off walls and taking damage (as you'd expect), damage was just applied while the ship was colliding with the main environment. This was just a temporary, but obviously incomplete, solution.
However, the advantage of being back in the North was that I only had my laptop with me, which lacks DirectX 10 hardware, and as a result there was no way that I could work on the main game engine. This forced me to do the necessary research in order to be able to implement a decent rigid body physics engine, which means that not only will the ship react well when colliding with walls, but it leaves a lot of room for interesting physics-based challenges, including pulling things around using a tractor beam. I'm currently just doing the refactoring necessary to integrate the physics engine with the main game engine, but in a few days I'm confident that this last major aspect of the game will be working well.
After that, it will be full steam ahead towards the creation of the first demo!
Subscribe to:
Posts (Atom)