So after a single nights worth of work, I now have the ability to select individual faces from objects. I haven't implemented it in anything other than the 'BoxTrigger' but the way that it works now is fairly ideal. Each object itself can determine how it will report faces back during intersections. I just have it printing out which faces were hit but I will build a 'Face Shower Object' thingy tomorrow that will have wireframes around all of the faces. The great thing is, I have factored out a bit of the SelectionManager into the concept of a SelectionSet which holds all the information about the objects/faces/vertices that are currently selected which should be fairly reusable for selection groups if I ever decide to go down that route.
I should have the implementation finished up in the next sitting or two which will hopefully be soon. I am going to be using this to finish up the 6th step from my list in the previous posting [June 21, 2008] towards my goal of a simple test room. I will allow you to select a face and then a material can be applied to it. Internally, this will most likely break the object up by adding another child sub mesh on the fly to it (I will combine them when they share the same material) and then you can use the material browser to select a material to apply. This will actually go a long way towards creating the room. The face removal should be fairly straight forward once I get face selection finished. I also plan to add support for vertex selection as well which should also be fairly straight forward since I will provide a 'helper' interface that has things like 'checkVertexForClick' which will take a matrix, a vertex, and a 'vertex size' which will check to see if a box that gets projected into screen space where the vertex is would be hit by a particular mouse coordinate. Then it should simply be a matter of looping over the vertices and feeding them in to this helper class.
Once these two steps are done, the rest of it should be straight forward implementation things which just require me to have my butt in a chair for a while. All in all, things are going well. The editor is actually shaping up to be something useful. I might just get my work to review it [part of my contract with them] before I make an official release sometime. I will probably also end up taking suggestions and contributions from the community and integrating them into the editor when I get a chance. I still want control over this since I am using this for my own personal project but I will definitely integrate items when it makes sense to do so and release that back.
Wednesday, June 25, 2008
Saturday, June 21, 2008
Success
So it turns out that I actually code a lot more effectively if I have a specific set of tasks to complete. I created a step by step guide to have the basic features required to build a simple test map. The test map is nothing spectacular. It's basically got a box that's been scaled out and had a face cut out of it for a 'connection' to another room. The other room is the same thing of another box with a face cutout that is going to be snapped to the first one. Each box starts with it's normals facing out but I am going to need to invert those so that the walls face in. I am also going to have to be able to assign a texture to each wall. So that's pretty much it. I have a lot of that functionality in there but none of it is really completed. There are a few bugs with each thing but now that I've tasked out everything, I am going through 1 by 1 and making sure everything works as expected before moving on. It's really nice to have a goal to work towards and having something tangible come of it.
Here are the tasks that I've prepared in order to be able to do the test room. This is the order that I have been tackling them since yesterday so hopefully when I am finished, there won't be much else to do.
1. Clear the scene
2. Translate tool
3. Scale tool
4. Box placement
5. Simple normal manipulation [just reverse them for now]
6. Texture assignment [per face or per object]
7. Face removal from a box
8. Vertex snapping
9. Object snapping
10. Light placement [point light]
11. Sprite icons for lights
12. Color adjustment for lights
13. Player start placement
14. 'Trigger' volumes
15. Rotate tool
So I think that should more or less add the required functionality to be able to create the room I want. I think I am going to always sit down, plan out the creation of something, and break it down similarly in the future. It lets me know how long I'll be towards a target, keeps me focused on getting something useful accomplished, not just something cool, and it also gives me a specific feature to drive towards completing at any given time.
That being said, I sat down today and did some actual work. I managed to fix/implement the first 4 features of that today. Granted, almost all of the framework was there but I at least fixed some bugs and made the scale and translate tool function as they are supposed to.
As it stands now, I've given myself the weekends and 2 'work days' throughout the week to be spending on this. I also gave rough estimates for how long things will take. Based on that [which may be horribly inaccurate], it appears that I should have all of this done by mid August some time. As far as that is, I think I can pull it back into late July which will be nice.
As far as the editor is concerned, I won't be recreating Maya/Max at all but I will be allowing for simple face manipulation that will allow you to create a basic room, block off some sections with walls, and place ramps and things so you can have multiple levels. Anything more complicated than that and I'll have to allow you to import it as a mesh from your favorite modeling package. I will have to create a suite of tools to allow you to place objects easily and line things up nicely so that will probably be coming soon as one of the next few use cases.
Here are the tasks that I've prepared in order to be able to do the test room. This is the order that I have been tackling them since yesterday so hopefully when I am finished, there won't be much else to do.
1. Clear the scene
2. Translate tool
3. Scale tool
4. Box placement
5. Simple normal manipulation [just reverse them for now]
6. Texture assignment [per face or per object]
7. Face removal from a box
8. Vertex snapping
9. Object snapping
10. Light placement [point light]
11. Sprite icons for lights
12. Color adjustment for lights
13. Player start placement
14. 'Trigger' volumes
15. Rotate tool
So I think that should more or less add the required functionality to be able to create the room I want. I think I am going to always sit down, plan out the creation of something, and break it down similarly in the future. It lets me know how long I'll be towards a target, keeps me focused on getting something useful accomplished, not just something cool, and it also gives me a specific feature to drive towards completing at any given time.
That being said, I sat down today and did some actual work. I managed to fix/implement the first 4 features of that today. Granted, almost all of the framework was there but I at least fixed some bugs and made the scale and translate tool function as they are supposed to.
As it stands now, I've given myself the weekends and 2 'work days' throughout the week to be spending on this. I also gave rough estimates for how long things will take. Based on that [which may be horribly inaccurate], it appears that I should have all of this done by mid August some time. As far as that is, I think I can pull it back into late July which will be nice.
As far as the editor is concerned, I won't be recreating Maya/Max at all but I will be allowing for simple face manipulation that will allow you to create a basic room, block off some sections with walls, and place ramps and things so you can have multiple levels. Anything more complicated than that and I'll have to allow you to import it as a mesh from your favorite modeling package. I will have to create a suite of tools to allow you to place objects easily and line things up nicely so that will probably be coming soon as one of the next few use cases.
Scheduling
In my attempt to take a much more professional approach to the creation of my editor, I am actually using some scheduling software. It is called Hansoft and I am using the free license that they give to attempt to manage myself. I find that I am always wandering off the path towards actually getting something usable so in an effort to control that, I will become my own manager.
I just installed it and have been playing around with it for about an hour or so. It seems to support everything I will need: bugs, tasks, and scheduling. Hopefully I will be better at estimating how long features will take so I can be more committed to my release dates when I set them. Currently, I have too much of a 'when it is done' attitude and would like to correct that.
As an addition to this, I am also trying to come up with 'use cases' for the editor. I want to be able to build a test room as my first real milestone for the editor. In order to accomplish that, I am going to strip away all of the unfinished features, tuck them somewhere in a directory on my computer for later, and start fresh and actually finish a feature and flesh it out before I move on. That being said, the goals I have laid out for myself will mean that I can make a basic test map of 2 rooms [just simple cubes] that are snapped together with 2 lights inside as well as having 2 'volumes' inside that will be read in as triggers for the game engine whenever that gets completed. I have given a really rough schedule for this [I will go back and re-evaluate my estimates soon when I'm more rested] and it appears that I should be able to finish all of this by the end of August if I just work on the weekends and 2 days through out the work week. That being said, I am going away for vacation for 1 weekend in July so that will have to be taken into account. At least now I have a more realistic estimate as to how long it will take me which is always a good thing. It's humbling to know that what I want will take me 6 years but what I need will only take me 1 [as a metaphor, not in reality].
I'll probably post a schedule from time to time to show what I am working on, what's currently finished, and so that people can have more of an insight into my own work habits. I will post some more technical details about the tools I am using in an upcoming post.
I just installed it and have been playing around with it for about an hour or so. It seems to support everything I will need: bugs, tasks, and scheduling. Hopefully I will be better at estimating how long features will take so I can be more committed to my release dates when I set them. Currently, I have too much of a 'when it is done' attitude and would like to correct that.
As an addition to this, I am also trying to come up with 'use cases' for the editor. I want to be able to build a test room as my first real milestone for the editor. In order to accomplish that, I am going to strip away all of the unfinished features, tuck them somewhere in a directory on my computer for later, and start fresh and actually finish a feature and flesh it out before I move on. That being said, the goals I have laid out for myself will mean that I can make a basic test map of 2 rooms [just simple cubes] that are snapped together with 2 lights inside as well as having 2 'volumes' inside that will be read in as triggers for the game engine whenever that gets completed. I have given a really rough schedule for this [I will go back and re-evaluate my estimates soon when I'm more rested] and it appears that I should be able to finish all of this by the end of August if I just work on the weekends and 2 days through out the work week. That being said, I am going away for vacation for 1 weekend in July so that will have to be taken into account. At least now I have a more realistic estimate as to how long it will take me which is always a good thing. It's humbling to know that what I want will take me 6 years but what I need will only take me 1 [as a metaphor, not in reality].
I'll probably post a schedule from time to time to show what I am working on, what's currently finished, and so that people can have more of an insight into my own work habits. I will post some more technical details about the tools I am using in an upcoming post.
Saturday, May 10, 2008
Refactoring
I have been looking at my code lately and it's time for another refactor. I've noticed that almost all of my SceneObject types require transformations. There are only a select few that do not yet I have implemented the transformation system through the generic property/command system. This worked well at the start but as I implement more complex, non-primitive, types for the editor, I'm realizing that it can be a pain to re-implement the same functionality over and over again.
I am currently working on a BoxTrigger which is composed of a SceneNode and a wireframe box (technically it doesn't require the SceneNode but I need it for later). I want to be able to translate, rotate, and scale this object but in order to do that, I have to forward the methods on to the SceneNode. I'd have to write all sorts of code to handle the transformations again when I really shouldn't have to.
My proposed solution, after looking at Sinbads wxOgreMVC code, is to implement the transforms on the base SceneObject class and then declare a way for each derived type to receive a notification when the transform changes. This will simply allow me to add the 'position', 'scale', and 'orientation' properties to my class and everything else should work.
The tools will need a very small rewrite to handle this but that shouldn't take more than 10 minutes. In order to transform a SceneObject, the tool should first check to see if the any of the 3 properties above are present. If they are, then the associated methods should be relevant. For instance, the translate tool should see if the 'position' property is available. If it is, it can then call 'translate', 'setPosition', 'getWorldPosition', etc knowing that they are fully implemented.
When it comes time to save objects, the transform information may require special handling. I believe that the 'position' property should be all that is required to be written out.
I'm doing some testing at the BoxTrigger level before I implement this at the base level but so far, everything has worked accordingly. I believe this transition should make all future objects a lot easier to implement and work with. Considering that most of the editor objects are concerned with transformation information, having it available at the base level should be a major feature.
I am currently working on a BoxTrigger which is composed of a SceneNode and a wireframe box (technically it doesn't require the SceneNode but I need it for later). I want to be able to translate, rotate, and scale this object but in order to do that, I have to forward the methods on to the SceneNode. I'd have to write all sorts of code to handle the transformations again when I really shouldn't have to.
My proposed solution, after looking at Sinbads wxOgreMVC code, is to implement the transforms on the base SceneObject class and then declare a way for each derived type to receive a notification when the transform changes. This will simply allow me to add the 'position', 'scale', and 'orientation' properties to my class and everything else should work.
The tools will need a very small rewrite to handle this but that shouldn't take more than 10 minutes. In order to transform a SceneObject, the tool should first check to see if the any of the 3 properties above are present. If they are, then the associated methods should be relevant. For instance, the translate tool should see if the 'position' property is available. If it is, it can then call 'translate', 'setPosition', 'getWorldPosition', etc knowing that they are fully implemented.
When it comes time to save objects, the transform information may require special handling. I believe that the 'position' property should be all that is required to be written out.
I'm doing some testing at the BoxTrigger level before I implement this at the base level but so far, everything has worked accordingly. I believe this transition should make all future objects a lot easier to implement and work with. Considering that most of the editor objects are concerned with transformation information, having it available at the base level should be a major feature.
Thursday, April 24, 2008
A little too quiet
So it's been a few months since I last posted. I got busy with school and living in a house with 4 other people. Let's just say that there was a lot of Halo that happened. Unfortunately, that experience has come to a close. I wrote my last exam today and will be moving out on Sunday. I'll be in my new place with my fiance on Monday/Tuesday which will be our own place where we will stay for a few years. Eventually we're looking at getting a house. I also start my job again (game programmer) in a week and a half.
What this all means is that once the move is done, I will finally be able to work consistently on my projects again. The editor will start getting some much needed love and I am hoping to add a few things into the RTS game.
The main thing that I've been toying around with lately has been a visual scripting system. There are examples of this all over the place lately. The two that I first saw were the editor for the Crytek engine as well as the editor for the Unreal engine. Crytek calls their version FlowGraph with an example below.
I have tried both of the systems in a limited capacity and I just find that the Crytek version is easier to work with and a much nicer interface than Unreal's version. That being said, I haven't actually compared the capabilities of each but I haven't run into anything that I'd want to do that I couldn't in FlowGraph.
I've been experimenting with my own system and I seem to have come up with a reasonable solution. It's heavily based on the Crysis SDK but since I don't have actual source code for it all, I've had to do parts from scratch. I'm hoping that I will be able to implement this system into the RTS so that scripted sequences as well as some basic AI logic could be laid out with this tool.
There are a lot of possibilities that I have in my head for how this system could be used which I will explain in a future post. Needless to say, I will try to make this as powerful as possible so that I don't have to resort to the code-compile-wait-test-debug-wait-redo cycle that a lot of development gets stuck in. If I can chop out the compile part, that should save me a lot of time and at the same time will open up creation to many more people than just coders.
I'm also looking into toLua to expose a lot of the game to Lua so that I can write modules and some AI in lua without having to constantly recompile. At some point, I'd like to be able to define nodes in my visual logic system in Lua so that new functionality could be added on the fly without recompiling all the time.
There are a few other things on the burner right now but I am going to try and finish fixing the transform tools now that I've merged the 'tool' and 'gizmo' system into one system. This will make it a lot more consistent when a new piece of functionality is required.
And now. If you'll excuse me, I am going to get myself back into some coding.
What this all means is that once the move is done, I will finally be able to work consistently on my projects again. The editor will start getting some much needed love and I am hoping to add a few things into the RTS game.
The main thing that I've been toying around with lately has been a visual scripting system. There are examples of this all over the place lately. The two that I first saw were the editor for the Crytek engine as well as the editor for the Unreal engine. Crytek calls their version FlowGraph with an example below.
I have tried both of the systems in a limited capacity and I just find that the Crytek version is easier to work with and a much nicer interface than Unreal's version. That being said, I haven't actually compared the capabilities of each but I haven't run into anything that I'd want to do that I couldn't in FlowGraph.
I've been experimenting with my own system and I seem to have come up with a reasonable solution. It's heavily based on the Crysis SDK but since I don't have actual source code for it all, I've had to do parts from scratch. I'm hoping that I will be able to implement this system into the RTS so that scripted sequences as well as some basic AI logic could be laid out with this tool.
There are a lot of possibilities that I have in my head for how this system could be used which I will explain in a future post. Needless to say, I will try to make this as powerful as possible so that I don't have to resort to the code-compile-wait-test-debug-wait-redo cycle that a lot of development gets stuck in. If I can chop out the compile part, that should save me a lot of time and at the same time will open up creation to many more people than just coders.
I'm also looking into toLua to expose a lot of the game to Lua so that I can write modules and some AI in lua without having to constantly recompile. At some point, I'd like to be able to define nodes in my visual logic system in Lua so that new functionality could be added on the fly without recompiling all the time.
There are a few other things on the burner right now but I am going to try and finish fixing the transform tools now that I've merged the 'tool' and 'gizmo' system into one system. This will make it a lot more consistent when a new piece of functionality is required.
And now. If you'll excuse me, I am going to get myself back into some coding.
Friday, February 01, 2008
Deformations
Well I am now officially employed back in the game development world once again. I am back working for the same company that hired me for a co-op position last year. I'll be starting in May. So I'm excited about that. I'll still be continuing work on the editor as well as on my game so that shouldn't change.
As for the editor itself, I now have the concept of a 'mode' which will be a distinct state for the editor to be working in. This will help the plugins organize everything that they need in order for their particular 'mode' to work. For instance, the terrain editing mode will disable regular object selection so that you can only manipulate the terrain.
Each mode can have a custom tool window that is queried for, and managed by, the editor whenever that mode gets activated. You can see the terrain tool coming along in the video below, with the higher quality version available. It's tool window is shown in the lower left hand side of the screen which I use to change how I am manipulating the terrain.
View in High-Definition (Recommended)
Download Original (6.49 MB)
Intermediate Terrain Editing from Shawn Carroll on Vimeo.
As for the editor itself, I now have the concept of a 'mode' which will be a distinct state for the editor to be working in. This will help the plugins organize everything that they need in order for their particular 'mode' to work. For instance, the terrain editing mode will disable regular object selection so that you can only manipulate the terrain.
Each mode can have a custom tool window that is queried for, and managed by, the editor whenever that mode gets activated. You can see the terrain tool coming along in the video below, with the higher quality version available. It's tool window is shown in the lower left hand side of the screen which I use to change how I am manipulating the terrain.
View in High-Definition (Recommended)
Download Original (6.49 MB)
Intermediate Terrain Editing from Shawn Carroll on Vimeo.
Wednesday, January 16, 2008
Terrain Editing
Two new things:
1) I've started working on terrain editing inside of the editor. I think this will be one of the most used features other than direct object placement so I'd like to make sure it's possible to do. I have to come up with a 'mode' system that will allow the editor to reside in certain modes. That is, object placement will be one mode while terrain editing will be another. No two nodes can be active at the same time so that they can be sure that their settings won't be changed while they are on. The switching between modes can appear automatic or manual to the user. If you click on an object to place it, you'll automatically be kicked into the 'object placement' mode. On the other hand, you will have to manually hit an 'edit' button to go into terrain editing mode. It's up to the designer how each of these modes will be activated.
2) I am going to try and upload videos now showing off the editor in action. I find that videos show more than a single static screen shot can. I'll post the videos through Vimeo since it appears to offer the best quality. I'll post the embedded video directly on this blog with a link to the 'higher quality' one on the Vimeo site. The originally will also be available for download on the Vimeo site (bottom right) for each of my videos if you want to save them to your local computer.
And without much further wait, here is my first video showing off the ability to raise terrain in the editor. I used the amazing editable terrain manager which was not written by me for this. I wanted a proof of concept to make sure it would be doable. I have to add proper support but it's running inside of the editor and was able to be interfaced as a plugin which was all I wanted to confirm.
View in High-Definition (Recommended)
Download Original (9.79 MB)
1) I've started working on terrain editing inside of the editor. I think this will be one of the most used features other than direct object placement so I'd like to make sure it's possible to do. I have to come up with a 'mode' system that will allow the editor to reside in certain modes. That is, object placement will be one mode while terrain editing will be another. No two nodes can be active at the same time so that they can be sure that their settings won't be changed while they are on. The switching between modes can appear automatic or manual to the user. If you click on an object to place it, you'll automatically be kicked into the 'object placement' mode. On the other hand, you will have to manually hit an 'edit' button to go into terrain editing mode. It's up to the designer how each of these modes will be activated.
2) I am going to try and upload videos now showing off the editor in action. I find that videos show more than a single static screen shot can. I'll post the videos through Vimeo since it appears to offer the best quality. I'll post the embedded video directly on this blog with a link to the 'higher quality' one on the Vimeo site. The originally will also be available for download on the Vimeo site (bottom right) for each of my videos if you want to save them to your local computer.
And without much further wait, here is my first video showing off the ability to raise terrain in the editor. I used the amazing editable terrain manager which was not written by me for this. I wanted a proof of concept to make sure it would be doable. I have to add proper support but it's running inside of the editor and was able to be interfaced as a plugin which was all I wanted to confirm.
View in High-Definition (Recommended)
Download Original (9.79 MB)
Subscribe to:
Posts (Atom)