Yesterday I did some work on the engine and added some functionality.
The first one is 'BlockingVolumes' it's now possible to add blocking volumes to the scene, this can be used to efficiently create collisions for high poly scenery where trianglemesh collision might wreck the performance.
Finally added the character controller from BEPU Physics library. Out of the box it can: Walk, turn (look), jump, step (onto stairs and other objects) much like you would expect :P Luckily a camera toggle type was already implemented, so it's now possible to toggle between play mode (= camera fixed to player view) and edit mode (camera in free roam) very easily.
I did some work with custom Sunburn Lights. First off, a candle light. So far it's a fairly basis class that will simulate a lit candle. I hope to include this in a video tomorrow.
On Tuesday, my school will kick-off a new project. We might be required to use Unity instead of XNA. This would pretty much ruin a lot of my plans (to use this engine for my school projects) While Unity is really not a bad tool, I do prefer to stay with XNA. If I do not get permission to use XNA, that does not mean the end of the engine development. However, I will have to cut down on the time I can spend developing it. I just hope they will allows use to keep using XNA (That's what they've been teaching us the last couple of months anyway) If they don't, I'll have to rethink my plans.
On a brighter note, there are some cool ideas to be announced in the near future... It involves Synapse Gaming (creators of Sunburn) and should really help XNA developers with their awesome ideas. I'm not sure how much I can say about it, as it's still only a concept. Hopefully I can give you more information, soon ;)
Sunday, 31 January 2010
Sunday, 24 January 2010
Editor Update: Physics Rotation
Just a quick video update. Implemented rotation of Dynamic and Static actors in editmode. For now, rotation is done using the Arrow-keys. This will soon be changed (most likely using a rotation gizmo)
Tuesday, 19 January 2010
First footage: Edit/Play feature demo
I've put together a short video, demonstrating the first iteration of the Edit/Play feature. There is yet a lot(!) of coding and design to be done on this feature, but I have a clear vision of what it should look like within a few months of development. Uploaded the first video footage. I hope you enjoy watching! :)
Saturday, 16 January 2010
Creating your game while playing!
It's 4:30 in the morning and I've just finished a good chunck of engine work. Some progress has been made on the console (XNA Console Component) and support for switching 'modes' while playing the game.
The concept: The idea is to allow quick access to any editing tool while playing the game. This may have some pitfalls, but for the purpose of the engine (concept prototyping and school projects) it should be fine. To quickly gain access to these tools, you only need to open the console and type 'editmode' and the editor will change its ControlScheme, Camera and load all editor tools. The gameplay will be pauzed and all AI, physics etc. will not be updated while in editor mode. To continue playing, all you do is enter 'playmode' and gameplay will continue with all changes in effect.
This concept should greatly reduce developing time and will allows other teammates to build levels and tweak values without coding knowledge.
If you have any questions, please leave your comment below...
The concept: The idea is to allow quick access to any editing tool while playing the game. This may have some pitfalls, but for the purpose of the engine (concept prototyping and school projects) it should be fine. To quickly gain access to these tools, you only need to open the console and type 'editmode' and the editor will change its ControlScheme, Camera and load all editor tools. The gameplay will be pauzed and all AI, physics etc. will not be updated while in editor mode. To continue playing, all you do is enter 'playmode' and gameplay will continue with all changes in effect.
This concept should greatly reduce developing time and will allows other teammates to build levels and tweak values without coding knowledge.
If you have any questions, please leave your comment below...
Tuesday, 12 January 2010
First BEPU Integration Steps...
Just a small update this time...
Added some BEPU (Physics) functionality. 'StaticMeshActor' used as the static ground mesh in the video. 'DynamicMeshActor' the movable boxes. And of course the vehicle that can be driven around. Currently BEPU is not a priority milestone for the engine, messing around with physics is always fun however :)
The vehicle is a great starting point to demonstrate XML tweaking in a live scenario. All I have to do is convert all hardcoded values (like grip, torque etc.) into variables and add some XML functionality to the VehicleActor class. I hope to have a video about it by the end of the week. For now, I'll leave you with this:
Added some BEPU (Physics) functionality. 'StaticMeshActor' used as the static ground mesh in the video. 'DynamicMeshActor' the movable boxes. And of course the vehicle that can be driven around. Currently BEPU is not a priority milestone for the engine, messing around with physics is always fun however :)
The vehicle is a great starting point to demonstrate XML tweaking in a live scenario. All I have to do is convert all hardcoded values (like grip, torque etc.) into variables and add some XML functionality to the VehicleActor class. I hope to have a video about it by the end of the week. For now, I'll leave you with this:
Saturday, 9 January 2010
Tweaking variables using XML (Part 2)
In my previous post I talked about the method I'll be using to tweak values in runtime. Today, I created some code to demonstrate this method. It's an iterative process, so improvements will follow.
In the provided sample the method is explained using a Vehicle class, with two instances of that class. the static 'FrictionDef' variable will declare the value that every instance of the class should use. a private 'frictionDef' variable will allow an instance to set this static value using the XMLSerializer. You as a developer can manually change the value of 'frictionDef' in the XML file (called 'SuperCar.xml' in this sample) and reload the file to set all instances to the new assigned values in the xml file. You can use this method to quickly change values in runtime on PC. For Xbox, the 'XNA console component' could help us out setting values in the xml file (of course, you will need a 'chatpad' to properly use the console on Xbox) so other solutions are still being explored. I've yet to implement this feature into the engine so I'll save it for a later blog entry.
For PC developers: keeping this type of gameplay specific data in easily readable XML format, will allow for easy cheating by players. You might want to consider running it through the content pipeline (as binary) when you're done tweaking. Alternatively, you might simply remove the whole code used to tweak, and assign the values to the variables in your source code. Doing so, will still safe you a lot of time compared to rebuilding your project for every slightly changed variable while tweaking your game.
Some articles of interest:
Shawn Hargreaves Blog: MotoGP Tweakables
Luminance: Changing constants at runtime
Link to sample code:
XML Tweaking Sample
Video
In the provided sample the method is explained using a Vehicle class, with two instances of that class. the static 'FrictionDef' variable will declare the value that every instance of the class should use. a private 'frictionDef' variable will allow an instance to set this static value using the XMLSerializer. You as a developer can manually change the value of 'frictionDef' in the XML file (called 'SuperCar.xml' in this sample) and reload the file to set all instances to the new assigned values in the xml file. You can use this method to quickly change values in runtime on PC. For Xbox, the 'XNA console component' could help us out setting values in the xml file (of course, you will need a 'chatpad' to properly use the console on Xbox) so other solutions are still being explored. I've yet to implement this feature into the engine so I'll save it for a later blog entry.
For PC developers: keeping this type of gameplay specific data in easily readable XML format, will allow for easy cheating by players. You might want to consider running it through the content pipeline (as binary) when you're done tweaking. Alternatively, you might simply remove the whole code used to tweak, and assign the values to the variables in your source code. Doing so, will still safe you a lot of time compared to rebuilding your project for every slightly changed variable while tweaking your game.
Some articles of interest:
Shawn Hargreaves Blog: MotoGP Tweakables
Luminance: Changing constants at runtime
Link to sample code:
XML Tweaking Sample
Video
Tweaking variables using XML
A few months ago, I was tasked to tweak a car to behave like an actual vehicle (using XNA). Nothing close to a simulator, but a task like this can take up weeks of your time if you don't have proper tools. I did not have proper tools...
With a fresh project coming up (got till about April to work on the engine, before I can put it to use for another school project) I can take some time to develop tools like the one mentioned before. I've no current plans to develop these tools for a wide audience, this makes it somewhat easier to code them. I do of course release snippets and full source when applicable. Most of my current code works, but is not qualified to be released without a proper cleanup. Releasing something to a wide audience of programmers without fully debugging or tweaking your code is not in anyone's best interest.
Like a lot of other previous posts, this one will be cut into two parts. The first part I will talk about a possible method that you can implement into your project/engine when trying to save time tweaking. The next part will show an example (with snippets etc.) using this method.
If you've ever made a game before, you will know how much time fine-tuning or tweaking any object in your game can consume of your total development cycle. To help reducing the amount of time spend building and rebuilding your game with only slight changes in your character's run speed, you need a tool. I use XML to help save time. It's still a work in progress, but tests have shown good results so far. I'll explain the concept below...
Every class that uses constant values that should not change during runtime (i.e. default run speed or friction in a spring) can be tweaked using this XML method. The tweakable value is not a 'const' as this would not allow us to change its value in runtime. Instead we will use a 'public static', which holds the value that is used for every instance of the class. to Get/Set this value with XML (explained in more detail in the second part) we will need a 'private (non-static)' value.
public static float FrictionDef;
private float frictionDef
{
get { return FrictionDef; }
set { FrictionDef = value; }
}
In its current implementation you will have to manually open the XML file created for the class (one XML file for every class that uses tweakables) in a text-editor and change the value to anything you'd like in runtime, saving the file and reloading it using a simple key command in-game will load your new values to the 'public static' variables. Any instance will now use the new values and you get direct feedback on any changes made.
I will go more in-depth of the coding required to achieve this in part two. And provide a video with the implementation in effect (if time permits)
With a fresh project coming up (got till about April to work on the engine, before I can put it to use for another school project) I can take some time to develop tools like the one mentioned before. I've no current plans to develop these tools for a wide audience, this makes it somewhat easier to code them. I do of course release snippets and full source when applicable. Most of my current code works, but is not qualified to be released without a proper cleanup. Releasing something to a wide audience of programmers without fully debugging or tweaking your code is not in anyone's best interest.
Like a lot of other previous posts, this one will be cut into two parts. The first part I will talk about a possible method that you can implement into your project/engine when trying to save time tweaking. The next part will show an example (with snippets etc.) using this method.
If you've ever made a game before, you will know how much time fine-tuning or tweaking any object in your game can consume of your total development cycle. To help reducing the amount of time spend building and rebuilding your game with only slight changes in your character's run speed, you need a tool. I use XML to help save time. It's still a work in progress, but tests have shown good results so far. I'll explain the concept below...
Every class that uses constant values that should not change during runtime (i.e. default run speed or friction in a spring) can be tweaked using this XML method. The tweakable value is not a 'const' as this would not allow us to change its value in runtime. Instead we will use a 'public static', which holds the value that is used for every instance of the class. to Get/Set this value with XML (explained in more detail in the second part) we will need a 'private (non-static)' value.
public static float FrictionDef;
private float frictionDef
{
get { return FrictionDef; }
set { FrictionDef = value; }
}
In its current implementation you will have to manually open the XML file created for the class (one XML file for every class that uses tweakables) in a text-editor and change the value to anything you'd like in runtime, saving the file and reloading it using a simple key command in-game will load your new values to the 'public static' variables. Any instance will now use the new values and you get direct feedback on any changes made.
I will go more in-depth of the coding required to achieve this in part two. And provide a video with the implementation in effect (if time permits)
Subscribe to:
Posts (Atom)