Modules 4: Other

Like last time, I am going to start off with what progress I have made. I already mentioned I only had one beginner tutorial left to finish, so I started on the Intermediate and was hoping to add MyGUI to this program, substituting that experience for the seventh tutorial on CEGUI. So after finishing the tutorial which should how to do basic animation, I started on the additional work. These started with small things like adding a new node and making the robot walk farther since the tutorial only gives two spots before idling. I did have a minor problem with the changing of idling to the death animation, for some reason instead of playing once, the animation looped, leaving the robot looking like he was a child's blow-up punching bag. Adding a key binding to add a new location was a little more involved since it required adding all of the key and mouse binding to override the defaults set up in the program. This part did error once, for some reason once the walking animation had finished and the robot was idling, it would crash when adding a new spot to walk. This is because it was clumsily coded and a fail-safe for an empty queue was not implemented, nothing real big. This pretty much finished what I was doing with that tutorial, so I moved on to adding MyGUI to this set of code, which should have been easy since most of the work was in adding the key and mouse bindings into the tutorial. I can add the class and even initialize it without a problem, but once I try to do anything with it I get an APPCRASH error about ms-singleton, for which I have not really found a cure. So my hope is to get CEGUI up and running sometime this week and finish that tutorial like it was suppose to be done. The GUI is a requirement for the second intermediate tutorial which is why I did not move on with the tutorials.

Now, on to more in game items. So far I have covered lasers, missiles and mines. Now I am going to cover some of the odder modules which can be added to the tank.

Shields are a default part of every tank, with a given strength in both the front and the rear of the tank. With the addition of a shield amplifier, which takes up a module, an additional layer of shielding may be added to the tank. This shielding has the same defensive value as the default shield, note that this is equivalent for all tanks since it it the armor value and not the shields that is higher and lower in some tanks (trying to worry about balancing before programming is a fun task). The main difference is how the shields can be applied. The shielding can be move in quarters between the front and the rear (meaning the back can range from 0.5, 0.75, ..., 1.5 to the front's values of 1.5, 1.25, ..., .5; note these always sum to two which is the value of two times the default shielding which is naturally 0.5 front to 0.5 back and these cannot be moved, even with the shield amplifier).

The Extra Battery takes two modules. This attachment to the tank doubles the amount of time that can be spent in enemy territory. Note that the second cell is considered off-line, and thus unaffected by any weapons which may have drained the first battery, until the first battery is dead. It is this added protection from battery destroying weaponry that makes the extra battery worthwhile.

Reconnaissance satellite communicator is an interesting use of modules. While unsure of exactly how many modules it will take up, this will probably be somewhere between 4 and 6. This can be just as destructive to the enemy team as any missile. While standing within range of a neutral reconnaissance point, this is a small circle but not requiring the player be directly on top of the point, this communicator can be activated. A satellite is drawn from the base to the neutral point as long as no other player from any team has a satellite already coming to the point. Satellites over the base are only at one quarter health and do not gain any while in transit. Once over the point, the satellite will slowly regain health. Once inside the safe zone (health > 90) the satellite will fire on enemies with bounties being split among the satellite's team if the satellite get the kill or assist. The satellite will stop attacking when its health is in the danger zone (health < 80) until it is back in the safe zone. Satellites over the base will attack regardless of the health level. When a satellite is destroyed there is a cool-down period the team must wait before the satellite is replaced. Please note this cool-down refers to how long until the number of satellites is back to full count, not how often the communicator can be used. Well played, several satellites can be called to a point if necessary. The total number of these satellites is two plus the number of reconnaissance points at maximum.

Communication satellite also requires a significant number of modules, 4 to 6 like the reconnaissance satellite, but for a different reason. The reconnaissance satellite always a new point to recharge batteries and weapons as well as offering a small amount of cover fire power. The communication satellite is an individualized satellite. It can be destroyed like the reconnaissance satellite, but the cool-down for the satellite to respawn is also personal. This means without two of these, one would need to wait until the timer finished (note this can be accelerated but not voided by waiting on a reconnaissance point) to get the satellite back. This satellite has much less health than the reconnaissance satellite but deals quite a bit more damage. This is meant as a weaker alternate to missiles, which can be drawn to full at any reconnaissance point, but with a more continuous rate of damage. The satellite is not targeting, and will attack the first enemy target in range until the enemy is out of range, then it moves closest to furthest. The animation should have the satellite pointing down until an enemy is in range, the the satellite should align to fire. When idle the satellite moves over the calling player randomly, drawn towards directly overhead.

Well this is the first part of those miscellaneous modules, more to come next time if I do not get CEGUI up and working to finish tat last beginner tutorial and the next intermediate tutorial.

~gunnah

And now back to modules, Modules 3: Mines

Well it is time to describe what I did and did not do with the OGRE Engine since last time. (Keep in mind this is the shorter of the half-weeks and the last post was late.) As it turns out there are two Basic Tutorials remaining after last post, and me being who I am jumped straight to the end and finished Tutorial 8 without much difficulty. This was mostly since this tutorial did not require any additional downloads or adding to the libraries I have already created. Tutorial 8 is about multiple viewports which is not really relevant to what I want to make, except maybe with the guided missile and then that may only be changing the camera not the whole viewport. This would be useful if, for example, I was allowing a co-op or multiplayer option from a single computer. Since this is not going to be an option I did not delve very deep, I did want to see what Tutorial 7 was about, but another example I will give in single player: when the screen split and the user character is on one half and the head guard/boss/target is shown moving around an office or whatever on the other, that would be another two viewport scenario, but again irrelevant to what I am doing.

So after doing Tutorial 8, I went back to 7 which is setting up a GUI. I did not realize this, but OGRE handles only 3-dimensional rendering and is not well equipped for handling 2-dimensional screens. Because of this lacking on the part of OGRE an additional interfacing is needed. Tutorial 7 is how to set up CEGUI, but after working with it for a little while I decided it is not what I want. My goal is to keep the game as light, in terms of what comes packaged with it, as possible and CEGUI has a lot of dependencies. So after a quick search, I came across MyGUI, which took forever to set up because I completely missed something. With the newest versions of both OGRE and MyGUI, while making MyGUI in CMake, it is necessary to add to variables to the list (OGRE_SOURCE and OGRE_BUILD) which I was hesitant to do since I do not really understand what CMake does and how it works. Unfortunately, I need to set up a new tutorial application so that I can run MyGUI in OGRE. Hopefully next time I have a little ore to show of this. Also next time I am hoping to have started the intermediate tutorials.

Okay, now onto what I had been meaning to get back to, the modules on the tank. In previous post I have covered most projectile type modules, so now I will cover the final type of weapons: mines. Unlike missiles and lasers which form moving entities which will either hit something or the edge of the map, mines can remain almost indefinitely. To prevent overloading the map with mines and possibly slowing the game down for all players, mines are weaker than projectile weapons. The in-game reason for this, since most people do not care about the logistical parts of the game, is that missiles and lasers require more skill since they can miss where a mine is a guaranteed hit. Mines do have a timer, and will be rendered inert after a fixed period of time (probably on the order of 5 or 10 minutes) or when the player exists the match (to prevent giving kills to players who are not playing). While missiles are handled by the middle set of letter keys, mines are handles by the lower set.

* Basic Mines: A fairly weak form of the weapon, these go off whenever a hostile goes directly over the mine, only type of mine that comes 2 to the module.

* VBM: A more powerful form of mine, while needing to have been driven over to detonate, produces damage in a blast radius. Comes one to the module.

* Motion Mine: When hostile motion is detected inside a detection radius is detected, the mine detonates producing a fairly large, though not quite as powerful as the VBM, blast radius of damage. Comes one to the module.

* Neutralizing Mine: These mines are triggered by being driven over and deal no real damage. These mines do greatly damage the shields and battery power of the tank which drove over the mine. A small electromagnetic pulse radiates out to hit any very close other targets in the vicinity. Comes one to the module.

* Command mine: This does slightly more damage as the Motion Mine also in a radius around the mine. The big difference is that only one of these can be placed at a time per player. The player can detonate the mine after it is deployed by hitting the deploy but again. Comes one to the module.

Hopefully I will have more progress to report next time, but if not (Hurricane and all the fun it brings) I will continue to expand on the last few types of modules shields and then accessories.

~gunnah

Ogre Beginner Tutorials 4-6

Well, it is a little later then I intended to post, I was hoping to makes this post in the early morning, but better late then never. The reason why is because the first two tutorials I started with after the last post only took a day combined. The picture left is from the fourth tutorial. Tutorials 4 and 5 are how Ogre handles inputs, unbuffered and buffered respectively. Unbuffered inputs look to see if a frame listener has been triggered since the last frame. This is very useful for commands like movement and any other continuous type of input, but requires an interesting way to get around input you only want to be triggered on/off, requiring a boolean be switched to determine if the key or button was in a previously pressed or released position.

Tutorial 5 handles this a little more gracefully. Buffered inputs have the frame listener call a pressed or released function for each input. This handles the toggles well and since it is calling the pressed function every frame, it handles continuous inputs fairly well also. A delayed reaction, much like what I would want the laser fire to act as, is also fairly simple since it just involves checking if the key is still pressed from a certain amount of time ago. This still required a variable to keep track, and probably a little more work to make sure it is not exploitable, but overall both types of input worked fairly well.

Tutorial 6 was not as kind. This tutorial is setting up an Ogre program from scratch and only using standard libraries to fill in the holes. The basic process is to create a Root object, define the resources and render system, and initialize resources. After that the key things to do next are create the scene, set up third party libraries and plugins, attach the frame listener and associated tasks, and set up the render loop. These can be completed in any order unlike the first four. What gave the biggest problem was for some reason when I tried to create the resource import system, which looked fairly easy, the program would crash, not knowing what to do with the zip files. So after trying to re-install the zip handling library, and re-installing Ogre from scratch, I was still getting the same error. Not sure what was different but after copying in their code and compiling the program worked fine. Only other hang up was on setting up the OIS input system, which for some reason did not like that I had not fully capitalized the word window, giving a runt time error.

So this only leaves one more Beginner tutorial ,then I can begin some of the more advanced work, but so far it seems, as long as I can get the actual programming down in C++, like this will be the probable graphics engine.

Slow Progress

So as I mentioned earlier, while working through the Ogre tutorials on my Linux computer I had to give up because of linker problems in Tutorial 3. Well a few days ago, I got back to the point I was at previously now on my Windows computer. Not only did I get it to compile and run, I managed to get through all of their recommended ways to fool around with the program. On a side note, if there are any misspelled textures, make sure to delete the dat file before trying to reload the program since it retains the file names from when it was created. The image to the left was the rendering in OpenGL. But back to the main point, I finished their tutorial and decided to alter it in my own way. What I decide is since I had fun making the mesh for the tank in the first tutorial, I would make my own mesh again. (I will admit I did not try a new mesh with Tutorial 2 because I wanted to make sure I could get Tutorial 3 to work properly.

So I go through all of the work to make a new 3D model, shown to the left. I still have not tried to add coloring and other effects to the model yet, I figured I would in the next few tutorials seeing how the engine played with different coloration patterns. But besides its fairly bland coloration, I would say the model came out fairly decently, I learned how to tell the modeler exactly how far to move the vertices instead of manually trying since that lead to odd shadow patterns in the first tutorial model. So after getting the model together and having a mesh generated, I added the few lines of code needed to add a mesh (a line to create the entity, a line to create the scene node and a line to attach the entity to the scene node), compile and still get nowhere. It was at this point I learned the trick about deleting the dat file since the land came up either black in DirectX or yellow and black striped in OpenGL. I would also like to note I added the code to add the ninja from the last project, directly copied from the tutorial and neither mesh will load.

This last picture s the rendering of the same code as the OpenGL above but in DirectX. I am not sure how the fog turned off.

Just one more note, a note is suppose to come up when the dat file is being created to warn about the loading period. While I am confident in the code I copied, I have not seen the warning up, and I have created that dat file quite a few times hoping that was what was giving the problem loading the new mesh.

Another Move

While I was enjoying the way I had my programming set up, I found a few key flaws. The biggest reason I needed to switch environments again was the limitations of the computer's hardware. My Linux machine was put together over spring break because I was bored out of spare parts lying around the house. I have hit a few problems with its computational power already, particularly when Ubuntu upgraded to its new graphics interface which the computer could not handle. So it was little surprise that I would reach a point the computer no longer could handle building this program; I was just not expecting to have graphics issues with tutorial 2. For those interested tutorial 2 is shadow creation with multiple light sources, and the computer would render the 3D space, just the frame rate was only 10 fps or so. The other, lesser, problem I had was linker errors I was getting on tutorial 3. The tutorials are written from a Windows environment perspective - not surprising since most people run Windows and those new to programming would prefer the ease of Visual Studio and the executable file, etc. - which does not help when a file key configuration file needs to be edited, and I am unsure if the change will corrupt the system. (I have changed files in Windows which completely wiped the system, so I am wary of changing configuration files in section reserved for key operating system files.)

So that all lead to me moving from my Linux machine to my Windows computer, which has much better specs. For those interested in getting OGRE, I will briefly describe what needed to be done to get it to install, note I am not going to give details given in the OGRE tutorial, but key points I need to remember if I need to setup the engine again from scratch, focusing on where I had the most trouble. For Windows, start by installing a copy of Visual Studios and an recent version of the DirectX SDK. From the OGRE site, download the source files, the dependencies and the tutorial framework. Extract the source to the desired location, then unzip the other two downloads into the root file. Set an environmental variable for OGRE to the root folder (where you told it to install) and restart the computer. Open up the dependencies with Visual Studios and build the solution. Download and install CMake, set the location to search to the root folder and the build folder to a new folder (I added a folder called build inside the root folder). Once this is done, a whole series of files will be in the build folder including a file open able by Visual Studios, which can then be built. If all goes well, everything to this point has compiled without problem, and OGRE source has been successfully compiled.

Now for the hard part, setting up an blank project. After adding the files from the tutorial framework folder, the OGRE tutorial on their website starts to set up several solution properties. This took a very long time to get right since they use a previous version of OGRE while making the walk-through. The biggest problem is to make sure the folder added to include dependencies is actually the intended folder, most of mine required adding "OgreMain" of something else to get to point in the right spot. I will admit I skipped the post-compile command since it was giving me trouble and look extraneous (so far it has been). If everything has gone well, inside the Visual Studio's project folder there will be an executable, which will bring up a mostly black screen, it took me nearly a day to work all the errors out, which is why I am spending so much time recording what I did.

So far I have completed most of the first tutorial, which is not really that big for me since I have already done it on my Linux computer. To make it more interesting, I decided to make my own mesh, albeit a very crude mesh, to play with in the tutorial. The following is an actual screenshot from my tutorial executable.

While it is not much to look at, take is completely done from scratch, starting with the 3D rendering, which was then converted to mesh and added to the tutorial, instead of the OGRE head they call for which I had already done. Well, that is enough for this time I think, this post may be the most helpful yet, especially if I ever need to re-install the OGRE engine on my Windows computer.

~gunnah