Work-in-Progress: Courthouse (modeling continued)

I had three viable topics for this post.  Since it is he end of the year, I could do a recap of the previous year and  what I want to do with this project in the coming year.  I thought that was a much better topic for the first post of the year.  The other was some of the other engines I have looked at, but I am deciding to wait and see if I try any more and do them all in one post instead of spread out.  So this leaves me with my third topic, the Courthouse Work-in-Progress I showed last post.

To the left is the courthouse from last post but with some major additions.  The model now has 4200 faces, about twice what it had previously.  Most of my complaints were addressed since last time with a few exceptions.  The star in the circle in the eave is still made out of polygons but will eventually be made into a texture when I get that far.  For the moment it is serving a a  placeholder and may even be put back if I do not like how the textureing looks, but for the moment that is a few faces I can cut from the final project.  The flagpole is missing a flag.  The final change I wrote I would want was the base of the columns.  In the close-up version, the base just looks a little odd in comparison with the way the rest of the model flowed, but that was only the entryway, and an incomplete entryway at that.  Looking at the project as a whole, at least in terms of actual modeling, the bases seem to fit in very nicely

This images is from a much better vantage point, making it easier to see a little more of the detail.  Since last time I finished to molding and added it completely around the building as well as a special set of bricks on each side-edge of the building.  This just left the void to be filled by windows.  Originally I wrote that I wanted two different kinds of windows.  I was expecting one small and one large, but after looking at the project as it was turning out with the large windows duplicated where the smaller ones were going, I decided that the large windows looked nicer.  Tat pretty much fills out the bottom section of the building with a couple of blank planes set up to fill in the gaps between the windows.  Next came the roof, which started as a plane and then altered to give a nice size lip, but not enough to obscure any of the detail in the clock-tower.  The clock-tower was the final addition to the project to make it just a little more interesting to look at.

This is the back of the building from the opposite side the other two images were taken.  I took this mostly to show how I staggered the windows a bits.  This about shows where the project currently stands, I could have made it more intricate, but this side is not the side likely to be viewed, and that would have just increased the polygon count even higher.  For a building this size, while the count is not great, I would say I am not disappointed in how it turned out and I cannot really find a face that is unneeded.  So with the modeling basically finished, there are a few details which may get changed as the project moves forward but they are only minor details, it is time to bring the model into the next phase: texturing.  This process make take quite some time, so do not be surprised if another building is modeled in between now and when this building is textured.

If I get some free time, I am going to go through the pages and clean them up a little with recent changes to the project.  Have a happy New Year,
~gunnah

Work in Progress: The Courthouse

I could easily go over what features I like about Ogre and which I like about UDK and which I would like to see and which I find annoying.  I have gone over this already pretty much as far as I want to, so unless a new contender pops up I am not going to say much more besides small status updates about what I am learning in which engine.  This week was nothing, I forgot about Friday night's post since I was real rushed with Christmas Eve being the next day.  On the up side, since I will not be talking about engines and the like for a little while, I will focus more on the game art, which at least looks like more progress than just saying this or that was programmed, I promise.Another thing I did not notice is that many 3D objects are not modeled in a sitting or two but spread out over the course of months, so I will be doing a series of work-in-progress updates.

To the left is my current piece I am making for the game, the courthouse entrance way.  Obviously I am missing most of the building, but this will be the focal point of the building so I wanted to give it my attention before moving onto the rest of the building.  My goal is to make it as low poly as possible, but since this will be a unique building, and I may want to reuse some or all of it in other projects eventually, I am giving it some extra polygons (polygon face count is currently about 2100 for just the entryway).  Now this is more of a status report than a final release and much of this model may change between now and the model which I will include in the game.

Going from top to bottom I am going to give some of my own critiques of what I would like to change or aspects which may be altered.  I am fairly happy with the scales on the top of the building and because in no game I can really think of the player could get close enough to tell me which polygons are out of position, I think it is fine.  Next is the parallelogram roof.  During texturing the circle in the middle will likely be turned into a texture to save on faces.  There is a star in the middle but the star is very hard to see since there is very little way to light it and cause shadows.  Along the bottom edge, I would like to make a molding which I could possibly reuse as the roof's molding.  The columns are fine, but base just do not seem right to me, they may look better once everything around hem gets filled in, but they just do not seem right to me.  I am fairly pleased with the decorations above the doors and the flagpole and holder on the wall, though obviously I am going to need to add a flag.  As for the doors themselves, they need handles of some form.  The stairs may need a little beveling so they are not quite as straight and a handrail in the middle to break up the long straight lines going across the stairs may also help the scene.  Finally on the base of the entry way, on both sides I want to make a high molding which I will then use throughout the base of the building to mark out the perimeter.

Now onto what still needs to be designed.  Two kinds of windows.  I want a large and a small kind of window, which will be spread around the building to take up most of the wall space.  At the corners I want to make a nice decorative piece so all of the detail is not focused at one point.  The molding at the roof and around the base have already been discussed but would be the last elements to build the lower walls.  On the roof I would like to put in a clock tower.  This will involve another smaller window, the clock piece itself and a molding separating the building from the dome.  Then once all of this is modeled, texturing can begin

Until next time,
~gunnah

Taking this decision slow

While I would really like to just breeze through this decision and go this or that is going to be my engine, my mind is made up and I am done with all of this discussion, that is not going to happen.  Moving from an open source to a licensed proprietary engine has both advantages and draw backs and I will probably be looking over several other engines before I decide on a final choice.  One of the big problems is with Ad Sense links listed, despite not being really generating revenue, I would be required to get a license since it is considered an alternate form of income from my product (I read and re-read most of the legal and business pages to make sure I am not going to get in trouble with anything).  Since I do not really have the money for the license at the moment, buying it and declaring the Unreal Development Kit my engine is not really an option.  Also, I would like to make sure that the UDK is exactly what I want before I spend money on it.  So I will probably check out a few other FPS and 3D engines to see what they are like and work from there.

In the meantime, I am going to keep working with the UDK.  Most because if I do choose it as my engine, to be able to jump right into programming will make the project advance quicker.  Also, while I cannot afford the license, as long as I am using the engine as an educational tool and not making any profit off of it, I can use it without a license.  One of my biggest problems with Ogre was how poorly worded some of the tutorials were.  UDK hosts hours on end of tutorial videos showing exactly how to do what.  One of the biggest problems I had with run-time errors was changing names of strings which Ogre needs in a particular format, but were not commented or explained as being necessary how they were presented.  While I would like to keep playing in code, the UDK is not distributed with its source, so I do not need to worry about these strings.  Now, UDK offers a built-in coding area, but this is nothing like what I would need access to in order to replicate the problem from Ogre.  One other plus with UDK is having a built-in level designer and not need to worry about the DotSceneParser, which gave me so much trouble a month ago.

While not a very comprehensive comparison, I am just listing some of my observations where UDK seems easier to use than Ogre.  Of course, UDK being in a GUI and not several thousand lines of code does help with coding problems, so I guess the adage you get what you pay for may have some validity.  Most likely I am just going to keep on fooling around with UDK for the next few weeks, then look for another engine to try out, or take some time and go 3D modeling to reappraise the project.
~gunnah

A big decision arises

While I had more or less figured out what I was going to do for the weapon system in the tutorial I had been working on, I am not sure if I am advancing in Ogre any further.  I had been talking to a few friends whose major deals with networking and computer programming, and they told me Ogre was not the best way to go.  While I have not completely given up on Ogre, I do have a few issues.  Te biggest advantage of Ogre is it is open source, so anyone can go in and really customize any aspect of the engine.  Other things I like about Ogre are the speed of compiling, my familiarity with the conventions used in programming and the relative ease to change levels using the DotSceneParser, one it is working.  But Ogre is a 3D engine, and every other aspect of the game needs its own engine: sound, networking, physics, and GUI.

So the recommendation to me was move over to the Unreal Development Kit, the free for non-commercial use version of the Unreal Engine.  Since I have not made a cent off of this game yet I am not real worried , though if I ever make any money off of people clicking on the Ad Sense links on the side of the page or I ever get a donation page up I will definitely need to go over their legal requirements to see if I need a license, though I am thinking it is only if I am actually selling the game.  That is my only big worry right now since the UDK has the financial stipulation, another problem I have is the engine is not open source.and with the UDK I do not even have access to the engine (they allow access to the pre-built binaries for free).  Right now those are my big complaints, though I am not real worried about them.  I cannot really comment on how it is to program or design a level or anything since I am still making it through a lot of the introductory documentation.  Though having all of the aspects integrated into the engine does seem like it would be easier.

So, I do not have much to show for the previous week, and probably will not have much for the weekend since I think most of my free-time will be spent reading the UDK documentation.  I will probably make the decision n whether to switch or not once I have read most of the documentation, made a level and imported a mesh or two.  My guess is in about I week I will decide if using the UDK would be advantageous for my project, because this is big and something I do not want to rush.
~gunnah

A little bit of a stall

So I was working on the next tutorial which is adding a weapon system.  The basics are fairly simple, a database class to hold all of the pointers weapons and the individual weapon classes (all extending the Weapon base class).  This looked to be an easy tutorial finished in an afternoon, until I got to the end of the tutorial where the lists and arrays are actually implemented.  At that point none of the generic classes the tutorial used worked properly and instead of reading like they were suppose to making life easy, they all came up as an error-type.  Now it was not the way I made them, I actually at one point copied the code straight from the tutorial source (the tutorial itself does not give the generic types, I had a similar problem during one of the earlier tutorials also) and it still did not work.  So right now I am deciding how best to handle this section of code and if it is worth while to actually implement my own list type.

Not much was done from a planning or art perspective on the game, I was fairly tired and the coding problems just made it difficult to think of what to do next on anything else related to the project.  The one thing I did manage to do was run the Intermediate Tutorial 3 as a stress test for client side program.  I took the number of tens of thousands of faces and plotted that versus the number of frames per second I was getting and found that I got the equation: faces in thousands equals the constant 2027.7 divided by the frame rate to the power of 0.809.  The r-squared value, which is an indicator for how closely the points match-up with the line was 0.9939 on a scale from 0 to 1, with most real world experiments lucky to get a reading of about a 0.9.  What this means is that I can say with a decent confidence the game should run decently on a decent computer with between 100 and 125 thousand faces on the screen (for me that was between 30 and 40 frames per second, PAL frame rate is only 24 fps, with animation being either 12 or 6 fps; most games are targeted to run at about 20 fps).  This will give a little leeway for computers which are not as good as mine while still giving me an overall target to plan with.

So, for next time I am hoping to have the Weapon system all reworked and be ready to move onward through the tutorials.
~gunnah

Finally made some progress

While the last month and a half may seem like I have little to show for it, I have learned a great deal about 3D modeling.  Not that I really want that as my excuse, but it is how I explain it to myself, so that is about all I can say about it.  Life really has been harsh the last month and a half, so hopefully it starts to ease up a bit.  As far as programming goes, the last month or so has been a complete washout, basically being stuck at the same point for he entire time, but that has now changed!

Tutorial 2: Loading a Scene has caused me nothing but pains sine I started it.  As I commented last post, I had almost finished it for that post, at that point my errors laid outside the coding.  As it turns out, having required files in the same folder as the other project files is not good enough for Visual Studios, you actually need to bring the files into the project inside the program.  It took a bunch of thinking to get that one, so this is as much a note to myself as a warning to others.  Once I solved that trick, I was almost home free.  As it turns out, the strings of names given in the program need to match the XML file, but that was nothing to correct.  So I am done with that, unfortunately, all it does is display a corner of the static map, so it is really nothing to look at.

Now onto the next tutorial, Adding the Player.  The part of this one which took the longest was adding all of the minor changes to the parser allowing items to be parsed right into the game engine instead of a secondary scene manager.  Overall this tutorial went very smoothly without too much new material learner.  Though I did find out what kind of shooter this tutorial was making: a fixed shooter - think Space Invaders or Centipede - with a little better graphics than those old arcade games.  I know it is not the perfect match for what I am doing, but it covers most of the basics, which can then just be applied to three dimensions from the two already programmed.

The final tutorial I finished was more of a bathroom reading material type of exercise than an actual tutorial.  It was called Populating the Level but was really just a collection of links to sites which offer free or cheap low polygon count models.  I am most likely just going to use the models the tutorial does to finish the tutorial as quick as possible, being a month and a half late already from where I wanted to be, and then make my own low polygon models for the game.  To be honest, besides the pains of making sure the Credits page is one of the first done, I would also feel a little weird using someone else's materials.

On a programming side note, I also wrote my first pair of server/client programs.  I know all they do is send the string "Hello, World!" from one panel to another on my Linux-box, but I under stood 80% of the code use to make them.  There was a few functions which I did not quite grasp but the text outside of the program said that what I did not understand was okay since the author had not gone over the code previously.

The last thing I would like to discuss is a redefined timetable (I know I go over this every post, but this one should hold unless something really goes wrong with my program of Life).  For now I would like to say that the Shooter tutorial should be finished for the post just before Christmas.  The Advanced Framework should be done for the last post of this year.  Once those are done, I can begin actually coding on the game, which I am going to say early to mid January on the Progress page (I know that was originally early November, but I hit a speed bump), possibly using some of the starting coding to make the proof of concept I want to do.  Well this post is too long now, so I will stop here, hopefully more good results for the end of the weekend,
~gunnah

Short and Sweet

I guess the best way to sum up the weekend was average.  I did get some done, have a lot which I should be getting done.  So let us start off with the programming.  I went through and redid the first tutorial, got it to compile and that means I was back to where I was before in terms of what I had that would function.  Unfortunately the first tutorial is how to make a black screen, not the most impressive piece.  Next up was retrying the second tutorial, again.  This time I decided I would stick with the tutorial and use the TinyXML files.  I got the entire code finished, ironed out all of the coding problems, but there is a little snag.  When trying to make the object file (not really sure why Visual Studios makes that file but it does and it gets cranky when everything is not lined up right) I am getting a hand full of linking errors which I need to work through.  Hopefully once these errors are solved, the program will load up the XML file and I can move on with the tutorial.

That about sums up the programming end, now onto the 3D modeling.  My primary goal is eventually to make all five of the original tanks and then alter them beyond recognition.  Okay, maybe not that much, but I do wish to use them as a base for my tanks.  Working from a set of images, I did start that.  I decided to work on one of the odder looking tanks, the Mag Rider.  While I still need to tweak the proportions so they align with what I am looking for in my game, I have the basic shape mapped out in a surprisingly few number of faces.  Of course, once I get the proportions, I can start making changes, though the changes will probably wait until I have all five of the bases finished.  I will probably use the more traditional bodied Vanguard and Devastator as the base for multiple tanks and the more uniquely bodied tanks as the base for just a singular tank.

I also will probably need to do a stress test or two to find out what kind of polygon count I am looking for in a scene.  From what I have been reading it is almost down to the program what kind of polygon limits are required.  My hope is to just get a base line and move from there.
~gunnah

A new month

Since this is the first post of a new month, I figured I would use it to plan what I would like done during the month.  While the last two months had some high points, I feel the programming end has been stalled for some time now.  So my top priority is to get the 3D shooter tutorial back to where it was before I destroyed it, then continue to build.  If all goes well, I will have that project done fairly quickly.  Once that is done, I want to piece through the Advanced Framework tutorial at which point I will be done with tutorials.

My secondary concern is getting some models ready to use in the game.  I have decided I will begin with the five original tanks from Tanarus and build them into something new.  After looking at the models carefully, I realized the majority of the detailing was in the texturing - a neat trick to make fairly detailed tanks using only 50 or so polygons.  Right now I just want a base model to use as a place-keeper.  Once the tanks are ready, which should not take that long, I will finish up the level map.  Neither the tanks nor level map have that big of a rush since neither will be utilized before I finish the Advanced Framework tutorial.  Once I finish the level map, I can start working on itemizing all of the building and objects I will need for the map, but this is still some distance off in the future.

Finally are my goals with my 3D modeling.  The biggest goal is learning how to texture my models.  While a decent model is a great place to start, even a mediocre model can be saved with a good texturing job.  After all, almost all of the detail in the original tanks were in the texturing.  I would also like to start finishing some of my open projects, but there is almost no rush on that happening.

Just a little note: after working on a few models and seeing where difficult portions lie, like getting the right roundness while preserving a poly count, you do begin to see it in video games.  Not so much in CG scenes or movies since those are entirely rendered and do not have poly constraints like games.  Well, until next time,
~gunnah

A little more about my level design

Okay, so life strikes down another post in its prime.  I had a fairly busy weekend with little time to play in front of my monitor.  So the programming I was hoping to have done will likely wait until the next post at the end of the week.  As modeling goes, you can see the lack of pictures, so nothing major happened in that department either this weekend.  What I did do is pick up a few tips about level design.  Of course their was for a humanoid walking in an Action/Adventure or RPG style game and I am looking to make a multiplexer FPS, it did give some good tips.

The biggest tip it gave was to block out the scene before adding little decorative bits.  While another plan it to make all the little decorative bits then compile them into a level, I think this blocking out and seeing what needs to be made system works best for a single person project.  Once I finish blocking the entire level out, I will include a list of buildings I need on the "3d Modeling" page.  The map is going to be very varied in terms of terrain from city to small forest.  My hope is to keep a large number of the buildings fairly generic in structure, for example only use six or eight generic buildings in the city-scape in addition to the few unique pieces.  Then closer to release, create several additional textures for each building to vary them.

Now, onto more game background.  I needed to pick a unit to work in and normally it would be meters, but they have the same problem as yards.  Both work well under certain applications, but to keep fairly whole numbers, which is my goal for the moment, feet work better.  The map I am working on will be a 1000 foot square.  I divided the map into 9 regions (4 300-by-300 regions at the corners, 4 300-by-400 regions at the edges and a 400-by-400 region in the middle)and then decided what generally I want to add where.  The northwest will be more sparse with more trees and larger houses while the southeast will be a suburban zone.  This leaves a central band which I want to make more built up like a city.

So I started laying out the building for my city when I realized while the main avenues are twenty feet across, I was adding alleys between buildings which were narrower.  This could pose a possible problem if some tanks are larger than the alleyway (giving some tanks an advantage over others) or worse all tanks were wider since that would reduce the playable area (these alleys are similar to capillaries in the human body, while they do not take up much space, because of the amount of them, they provide a significant surface area).  Luckily most alleys should be about 15 foot across (I am assuming in buildings I mark as 30 by 30 for example will omly be 20 by 20, but will include the sidewalk in front, dumpster on the side and anything else in the five foot buffer area around) and most tanks should be under 12 foot wide.  I was doing some background work finding dimensions of large vehicles like SUVs as well as tanks.  I found a small tank is slightly larger than a large SUV, so my smallest tank will likely be about the size of a large SUV.  Width is likely eight to twelve feet, height is seven to nine feet, and length is the big variable at between eighteen and twenty-five feet.  None of these are set in stone, but the level I am working on now is being designed wit the upper values listed in mind.

While not really much to talk about, I hope this gives some insight into my thought of what are going into the level and tank design.  Hopefully more concrete progress in the next post,

~gunnah

A little distraction

Look a picture!  Actually it is not that impressive since I cannot think of when I would need a meat grinder in a video game outside of a scene in a deli or supermarket.  But if the need ever arose, I do have the perfect item for it.  Actually, in my opinion, it looks a little cartoon-y, and could probably be helped with a better background, I am still learning how to best frame items.  I mostly made it because I wanted something to show and it had been a while since my last picture.  I had been working on the mech, but the process of UV mapping over twenty thousand faces is going to take some time.  Also I have started on a second 3D modeling program, just picking up the basics, but the more I learn the more marketable this all may become.  My problem with the new program is it is a lot more artsy than the one I had been using and low poly is more or less non-existent in that program, but it is capable of rendering extremely photo-realistic images.  So the trade-off is while completely unusable for the game I am making, it may prove useful in future exploits.

Now, on to what should be my main focus.  Since the Shoo 'Em Up tutorial was in utter chaos from trying various ways of merging the two systems together, I am in the process of restarting the tutorials.  This was the easiest option since I only got to the second tutorial.  So no progress there really, outside of making a whole new project to repeat what I thought I had done but royally messed up.  But there is a bright spot, not in the previous bits but in the fact I continues with the network programming book and made a program which returned the IP address of a given website.  That may not sound like much, and actually the program was not very intense, but what was key was that I completely understood the entire program.  The next couple of programs in the book are a server and a client so that should be fun to get together.

Finally, a small change has been made to the Progress page changing when I think I will start coding the actual game from late November to mid December.  I am trying to be honest, but life has a way of making a liar out of me.  So I hope for a little forward progress next time.
~gunnah

Slow but steady

Well maybe not so steady.  Actually progress seems to be made in bursts, but neither of those are the point.  Okay, so as mentioned in the last post, I was finally trying to mesh the XML into something that would play nice.  I started by seeing if I could convert the tinyXML code to RapidXML, which I quickly found was not going to work.  As previously mentioned none of the attributes line up.  RapidXML seems better to create a scene from scratch while tinyXML seems better suited for file overlays.  RapidXML creates the scene directly through Ogre while tinyXML does a memory allocation and then passes the spot in memory.  So that was plan A, onto plan B: use the tinyXML function inside the RapidXML file.  In theory this could work.  The premise was that as long as the RpidXML passed the same data to the terrain parsing function that tinyXML did, it should not matter the implementation, as long as the function handled the same task.  It did not, eventually driving me nuts with linker errors.  So then I decided to take the previous idea and expand it.  I removed the RapidXML code from the program and added the tinyXML code in, so it should have behaved like the tutorial.  What did I get, more linker errors.  Funny thing was I had already fixed some of the more annoying ones when implementing RapidXML and really did not feel like figuring out how to do it again.  Currently I am in the process of deciding whether to start over from scratch or try to salvage their code.  On an up note, this should be handled by the next post, of course the only thing the code should do is display a corner of the terrain, but something is always good.

As far as 3D modeling, not much was done.  I have been fairly tired from the past few weeks which have been draining.  I only added a few details to the mecha I have been working on, so it is still not done enough to start the texturing part of the tutorial.  I got a little further with the low poly house, but like the mecha it is not close to being done.  I have another model finished and would show it off, but again ti needs to be textured.  I am also hoping to expand the Weighted Companion Cube picture from earlier into a full scene, but that is on the back burner for the time being.  A new page has been added which lists all of my 3D modeling projects I am working on or have on pause.  Later on I will possibly add the finished images, though I am really hoping to get a website devoted to my 3D artwork (I already have the site and it is not doing much right now, I just need to get around to converting it).

So, hopefully with more to show at the end of the week, I will end this post here.
~gunnah

Questioning how it is this time of week already

While I have full faith in all of my electronics, especially since they all say the same day and I do not think anyone would go through the trouble of changing all of my electronics to be a day or two fast for a practical joke, it must be time to review the previous week.  I made a little bit of progress in a few of the 3D modeling tutorials I have been working on, though nothing real concrete to show.  I really do not want to show off something which is not finished do, for now at least, I have no pictures to show.  Hopefully I can scrap something together since pictures give me something nice to show.

Since there was nothing to show with modeling, I am moving on to the programming aspect.  Again there was nothing show off, which I was really hoping to have out at this time.  Life has kept me fairly busy, so much so I lost a day somewhere in the last week.  The plus is, while I did not really make any forward progress with the #D shooter tutorial, I did open Visual Studios.  This may not sound like a lot but I have not really had the head to open that program in a few weeks.  So I began to look over my XML problem before seeing just how much of a pain it is going to be.  While most of the sections are compatible between TinyXML and RapidXML, or at least the environment and camera sections, the terrain is another story.  Not only does the XML parser I am using read it a completely different way, the option do not line up at all (I mean I do not think one of the names is the same).  What does this mean?  I need to go into the tutorial's XML parser, figure out where it sends the various bits of data, find the equivalent in the other parser and then format the data so the new parser can read it.  I may try a level design program and see if that helps next week if I cannot crack this problem this weekend.

Hopefully more to come over the next few weeks as life settles down a bit, at least I am hoping life does.

~gunnah

What I have picked up so far

Again not much done in the tutorials, still need to find the line that is causing the XML to freeze up.  Hopefully the tutorial will fly after that.  Either way I am going to need to learn how to use the parser since I chose to use the one in the Advanced Framework rather than the one used in the tutorial.

And now on to the 3D modeling work.  As you can tell by the lack of pictures I did not finish anything.  Currently I am working on two tutorials, the mech mentioned in the previous post and a added a cartoonish haunted house.  Neither of these are great experience for modeling objects in video games since both look to be fairly high poly count, but many of the techniques should be applicable.  I have just started the house tutorial but it is more for a standard FPS than the one I am making.  Here is what I mean by that: In a normal FPS you can go in and out of buildings, and the use of creating buildings with wall thickness has a purpose.  Since this game revolves around a tank played character, most buildings will be shells like the low poly apartment tutorial I read.  I am not saying none of the buildings will be open, but those will be the exception not the rule.

Now the mech is coming along real well.  I hit a point where I need to alter the mech in such a way as to add detail.  This will probably take quite a bit of time as I toy around with various detail adding additions.  Once that is done, there is a small bit on how to texture and I think rig the mech so it is pose-able.  But that is not my focus at the moment.  I am going to go over a few things I have learned in the tutorial.  Probably the biggest is work in halves, the duplicate the half with a modifier to get the mirrored half.  Build the general shape and then fill in details based on how much they add, so larger detail first more minute detail last.  Once all of the detailing is done, insert a ton of edges.  Since most mech-type objects are metal and metal is straight and my tanks are unlikely to be an exception, at any point where the metal bends, add lines on both sides of the crease.  This will keep the line shaprer when the object is smoothed, keeping an edge desired to be sharp clean while allowing other areas to be rounded.  A final trick is to build the model by section, grouping the sections and then using layers to help control what you do and do not want to see or work on.

So while I do not have much done this time around, next time should have a few pretty pictures.  The haunted houes should be done, the low poly house I mentioned a while back should be finished and the mech should be well on its way, though that may or may not be finished.  I also have one big project I am working on, which I mentioned earlier, but that may still take a while to finish.  Hopefully my time frees up towards the end of the week, though this week will again be tough for any forward progress on Ogre tutorials.

Small update

While I did learn a lot this week, almost none of it was related to this game.  Probably the biggest thing I learned was how tiring it is to sit in pretty much one spot for about six hours, I really never would have thought that it would be so draining.  I also continued to learn how to paint a room as well as starting to learn how to put it a floor (I have already done a few tile rooms but this room is these interlocking wood rectangles).  With any luck most of what is keeping me from this project will calm down.

I made a small change to the Progress page reflecting my inability to make forward progress on this game changing the date from mid to late November since as hard as it is to believe it is pretty much mid November.  There is not much left for me to do hopefully once I straighten the problem with the XML file out and with any luck I will be through those fairly quick and start to wrap up the Advanced Framework.  But I am getting ahead of myself again.

I was hoping to have some artwork done for this post.  Most of the earlier project I have I have not touched, like the low poly house, though I did try to go back and re-texture the tank.  That did not work out so far, but I am getting closer with the texturing.  The major project I was working on has been placed on the back-burner also, though I will probably get back to that one around the end of the month.  What has been absorbing my attention are a small series of tutorials I found.  Again, I do not plan on finishing all of them, but I find them very interesting.  The main problem is the are high poly, which will probably mean slow rendering.  I started watching a tutorial to make a dragon, then moved onto a landscape and a boat, and while all were interesting, and contained some good ideas, they were not real relevant to this project.  I did find a mech which I have started and was hoping to have done for this post, but it is taking me a real long time to move through the tutorial.  If nothing else it will make a pretty picture for the end of the weekend post.

Well, I have said enough about nothing so I will ed it here,
~gunnah

New Labels

So I added a label or two to each of the previous posts based on the material included.  Unfortunately that is all I finished.  Life has kept me very preoccupied, and while I would loved to have done more, by the time I can play on my computer, I am very tired.  With any luck I may find a little time to figure out where that XML went wrong this week, but another possibility is I will not really have any free time until sometime next week.

Now for a brief description of each label.
* 3D art: Any of the 3D images I made, game related or not.  This was the easiest to add since if the post included an image I pretty much added this label.
* Game Layout: Any post related to a discussion on how the various layouts will work is included under this label.
* Log Layout: These are posts dealing with how I present information in this log.
* Modules: Posts related to the various in-game items I plan to include.
* Planning: A generic label for future additions to the game.
* Tangent: Posts which deal with things related to the game but not really the game itself.
* Tutorials: Any posts which related the working through of a tutorial.

Hopefully the next post has a little more substance than this post.
~gunnah

End of Another Week

Not much to show, not for being lazy or anything like that, it is just that life has caught up.  Right now I am painting and putting a floor into a room.  This eats a lot of time and leaves me fairly drained.  I am still stuck with my XML problem so little has been done to move forward with the tutorials for Ogre itself.  This is mostly because it is going to take quite a bit of work to go through the parsing code to find which line of the XML file is causing the lockup.

Now to get around to my 3D artwork.  After reading a bit on the difference between low polygon counts and high polygon counts, of course the line between the two is fairly ill-defined, I have decided to start thinking over the first few maps I would like to include when the game is launched.  One of the maps is a suburbia level, of course it will not follow logic very well (fences will do nothing most likely, pools can take a tank running into them and houses will be able to take a direct missile hit) but it is more an off map than it is one of the main maps.  The main maps are more likely to be just textures with natural bunkers like hills, but I have not really given these much thought yet.  As for the artwork on these, I have finished one house, but it is lacking most of its materials, so I will get around to showing it later.

To the right is a completed model with materials properly applied.  It is the weighted companion cube from the Portal series (this model is from the first one if I got it right).  I claim no credit for its invention, creation or any other rights own by Valve.  But I did figured it would be an easy model with some color differential, use of some interesting tools (like bevel and Boolean intersection).  The other reason I chose it is because it is fairly well-known and unlike the house or other projects I am working on, would need to be a lot closer to what the original image(s) looked like, kind of a test to see how well I could reproduce an item.  I am likely to add more to this image to create more of a full scene, but hat is for later (probably when I get around to beating Portal 2).

Well, besides a building or two, I am unlikely to get much done this weekend since painting is fairly tiring work.  Of course I would love to stumble on what is making the tutorial lockup in that XML file (I feel I am likely to fly through the tutorial after that point).  Well, until next time,
~gunnah

Very Fast Weekend

Okay, so I did not get anything done this weekend.  Monday is the day I normally do most of the work for my after the weekend post and being Halloween, I needed to be somewhere besides my computer.  That being said, welcome to November, hopefully I will be able to move quickly through the few remaining tutorials I have remaining and have something to actually show by the middle of this month.  I have recently picked up a couple of books to read for this game, one on Game Development and another on Network Programming.  I do not expect to be done with these books before I have proof of concept out, but I will hopefully try to apply some of the information into the final project.

Okay, the program will divide into 3 programs: the client-side, the server-side and the game.  I will go over each of them in enough detail to give an idea of what their main responsibilities are.

Server-side
This handles getting information from files on the server and providing relevant information from the requesting programs.
To the client it handles the log-in and sends most of the out-of-game pages (news, stats, friends).  It is also responsible for relaying open game servers to the client.
To the game server it sends the user's information when the user joins.  During the game it takes data from the game server for the user (death, kill, assist, point, or whatever is being tracked) and updates the user's global information.

Game-server
This is responsible for most of the game like keeping user positions, missile positions, user stats, and any other useful information.
As previously mentioned, from the server-side it receives the user information and it sends the key information that occurs during a game session.
To the client it sends updates on positions and the user's stats.  From the client it receives most of the information to handle the game.

Client-side
This is mostly responsible for rendering the game environment for the user.  It also performs minor checks which I do not think are game breaking, but most of the major inputs are handled by the game-server.  Most of the interactions have already been described.  While I could argue fewer calculations makes the game less intense to run, this is mostly for game security.  I am learning lessons from the past and hoping to correct a few mistakes that were made in he game I am modeling this game off of.

Hopefully over the course of the week I can crack what is causing the problem with the 3D shot 'em up tutorial and get the ball moving on that again.
~gunnah

Two Steps forward

No pictures this time around, I did very little with my 3D modeling projects while trying to get through as much of the tutorials as possible.  With that noted, I finished the Mad Marx tutorials.  What was the biggest thing to take away from them?  try to keep your code in nice easy workable files instead of a long single file.  Each tutorial was suppose to have its own file, which would have simplified the coding a little,. but a lot of the program was reused in other tutorials, so I ended up with the tutorials split into four files.  The first was making an Ogre program from scratch and did not require their headers, so it was alone.  Then 2 through 6, 7 & 8 and 9 &10 were each split into their own executable.  None of them were that much to look at, and they did almost nothing so I am not going to upload them.  So the only tutorial left is the Advanced Framework in the In-Depth Tutorials.  I plan on making this the last tutorial I do, molding it into a base for my technical demonstration which will serve as a base for the game itself.

Now there are a series of tutorials off of the Ogre website.  I mentioned earlier the Artis series of tutorials is mostly missing, but there is a 3D shoot 'em up tutorial, which is divided into ten tutorials.  The first tutorial is setting up the application.  Nothing real new, so it went together fairly quickly.  This tutorial builds on itself so I am not going to post each tutorial, but I may, when I finish and if I feel it is acceptable, post the end-product.  That decision will come at a latter point.  So with the first tutorial done, I moved onto the second tutorial.  Tutorial 2 is level creation (add something to the blank scene seems to be the second level most of the time and this followed the trend).  The code itself was fairly small unlike most of the other level creation tutorials.  This tutorial uses DotSceneLoader header which allows for most of the scene code to go into an external XML file.I had two choices with the DotSceneLoader and since I am trying to learn as much as possible, I went with what was probably the harder option.  The tutorial uses TinyXml which is a little more bulky than the RapidXml recommended on the Wiki.  Either should behave the same to the program (and they do, same line of code would be used with either) but I am having a problem with the format of the XML level, for some reason it does not like the terrain section (the program runs fine when terrain is removed but fails to load when terrain is included.  So I did take two large steps forward finishing Mad Marx and starting the Shoot 'Em Up tutorials, but I have had to take a step back while trying to figure out how to write the XML file so the program will run instead of freezing.
~gunnah

Recovery

So I spent most of the weekend recovering from the cold I had last week.  This means I did not get much done with anything.  My 3D modeling got distracted by a small part of a small part of my big project and I just did not get much else done.  That said, this gave me time to update my Progress page which I will describe below. Other additions for the near future may be an images page where I put all of the images throughout the blog into a single section, though I may hold off for a little while and split it in three sections.  3D modeling tutorials would cover images I have done for the different tutorials and modeling work which is unrelated to the game.  Concept art would include any Ogre screenshots, original 3D modeling for the game, and anything else I think should be set aside in this page.  The final page would be a game preview page which would include images from any project which will be built into the game as well as models which will be used in the game.

Okay now for the changes to the Progress page.  Tutorial completion is set properly.  A note about getting the numbers wrong has been removed since the completion has been correct for about two weeks.  Artis tutorials have been removed.  Though I did not do any tutorials this weekend, I did go through o see what was remaining.  After actually going into the Artis tutorials, I found mot were only tables of contents to be added later.  A new section has been added for small projects not handled under the tutorials.  The tank movement demonstration has been described in an earlier post and I am not going to go over that again.  Also note I moved the start date from early to mid November.  While the two technical demonstrations will become part of the game, actual work on the full game will not begin until later.  So while much of what I do in early November will be foundations for the game, I am not considering the work on the game to begin before the two projects are finished.

Now to go over what I want the Proof of Concept to entail.  Upon opening the executable, the game should initialize and then open up the log-in screen.  For the concept the log-in screen will just have a button to move on to the actual game if the right username is put in, else it displays a failed log-in screen much like I want the actual game to do.  Once in the game, I want to be able to go to at least two of the menu screens and have the bring actual information up, the rest should say under construction.  Hitting the escape key should bring up a menu after passing the log-in screen.  Here I hope to set up a few working options, put mostly this is a place holder for the future menus.  Also in the menus is am option to exit the game which should be the only way to terminate the program.  I do not want to make it impossible to leave but I also do not want it to be possible to exit the game accidentally.  The final aspect I want to add to this is when one goes to where the game should start, it brings up the aforementioned tank movement demonstration.
~gunnah

There is a plus

I am going to start off by saying I did not get anymore more of the tutorials done. I caught a cold somehow and it has made my brain not want to do much. The plus is I think I was a little ahead of how far I thought I would be, so I do not think I am that far behind. Hopefully in the coming week I will have most of the tutorials finished, though that is on the assumption I get over this cold (it is really only drowsiness, congestion and headache, but the headache makes too much thinking a problem).

Now that I have gotten what I did not do over the week out of the way, I can get to what I have done over the week. While unable to concentrate on code, working on 3D modeling does not hurt my head as much. (It would be the errors that would hurt my head since many are written in such a way that there is no clear you missed this or that is spelled wronged, you know, useful messages.) As noted in the previous posts, one of my big problems was getting the images to actually render properly. As you can see by the hookah to the left, I think I figured my problem out. My big problem was I was missing the background image (I did not realize one was needed as either an HDRI or created through the program itself), along with a lack of practice texturing different materials. That was one reason I decided to redo the hookah (the first time did not come out as nice, plus I accidentally deleted it) which has glass, metal and ceramic.

While I did a few other tutorials, the only one I finished was the sprocket to the left. It did show how to use the bevel function, but outside of that, it was just shiny looking and complete. Besides these two finished items, I have two items waiting to be rendered - the tank from last post and an airplane which is giving me a hard time because of how I want it rendered. Additionally I have 2 or 3 items waiting to be made and one large-scale project waiting to wrapped up and rendered. When I finish this large-scale project, I will probably devote a post to it since there will be quite a few images and that will detract from anything I have to say about any other topic.

So, where does that leave me, a few 3D modeling projects to finish up before I start work on 3D models for the game. A few more tutorials before I start work on the game. I also want to make the technical demonstration mentioned in the previous post and a proof of concept type program that has most of the basic aspects of the game in place without being actually fully functional. Once all of this is done, I hope to start work on getting the game actually moving towards something playable.

~gunnah

A fairly slow weekend

While I did very well in my opinion last week, over the weekend I did not do so much. This is mostly because I am working on honing my 3D modeling skills. As noted in previous posts, I am doing 3D modeling tutorials but they are not arranged in any sort of structure to number them, and even if they were numbered, I would be unlikely to do them like I am the Ogre tutorials since I am only looking to learn a small subset of modeling skills.

So I decided to make a tank model over the weekend. Probably the most noticeable difference is the higher degree of intricacy in this tank as those I have previously included in screenshots of programs. Another thing to note is this one has, though fairly poor in my opinion, coloration. So my rendering work still has quite a bit to be desired, other than that I am quite pleased with how it turned out (I am unsure, but I think it is an M48 Patton, even though it was found on a search for the M4 Sherman).

Depending how inspired I feel, I have been thinking about using the above tank as a character for a camera test (similar to the In-Depth tutorial but this one would be a little different). My plans are to include a 1st person and chase camera. I am implementing the chase camera as a way to see how the tank responds to various commands. 1st person should look down the barrel of the tank. The arrow keys should move the tank on the terrain. A and D keys should rotate the turret between -180 and 180 degrees. W and S keys should raise and lower the turret (a little experimentation will decide what angles look realistic). Note these are the same controls that will be used in the game. If I make this, I will consider it a technical demonstration for the game.

Well, I think that is enough ranting for nothing being actually done.

~gunnah

The Long and Short

While I could go on for a while about all I have done over the week, my hope is to keep this post fairly short. The biggest news is I finished the penultimate In-Depth tutorial, which had to do with changing the camera. My only complaint with it is the 3rd person camera does not follow like I think it should. Also to prevent unexpected behavior, I needed to overwrite one of the example functions, not a big deal but that is not in the tutorial and is the only thing that makes the tutorial worth playing with. I am hoping to getting around to fixing it sometime over the next few weeks (should only require changing the camera to update based on character position) and I will post it online since it can be fun.

Now for the next sets of tutorials. I went back and started redoing the Mad Marx tutorials. I have been able to work through the original error I got and have about half of the Mad Marx tutorials finished. Unfortunately the tutorial window has reached a point where I need a fresh window to see what is going on and I have not felt like making the new file. Hopefully these will be finished in the course of the next week, but it is doubtful they will get posted online. So far the best lesson from their actual execution (I read the tutorials a while ago) is why to use header files.

Okay, last topic for this post, my work with 3D modeling. Notice no picture, means I did not finish anything worth sharing. Of course this does not mean I did not learn anything. Probably the biggest lesson is that human heads are very complex to model. The other is how to use two complimentary images at right angles to each other to make a 3-dimensional image of the object, of course also learned is he farther from been at right angles to each the harder the 3D image is to make. With that said, I will probably have a cool picture done for next post (or the one after if the image takes longer than I am thinking it should).

Being I went over what I thought I would get done when least week, I am going to end the post here. Not real short, but fairly concise. I tried,

~gunnah

Just a couple more tutorials

Of course the tutorials remaining are most likely going to be fairly long, but there are only 16 more to go through. 9 of them are in the Mad Marx set of tutorials, which I am hoping to go through fairly quickly since I have read them already. But enough about the future, I will go over what I did over the weekend.

I will start with the 3D art. Notice the lack of picture, that is because I have yet to figure out how to properly render the frame. I was tempted to post the screen image from from the 3D modeling program or import it into a simple Ogre program and see if that worked, but I really just want to figure out how to properly render the image. I was working on a screwdriver which was supposed to have a translucent handle (a yellow handle for that matter, and all I got was opaque red, why I am not posting the image). Hopefully I can get that straightened out by the end of the week. I do have the logo for the log-in screen when I get around to coding it. I may release that when I get the page finished (of course no functionality, but a good technical demonstration nonetheless) but that will probably be a little ways off, right now my main focus is going through the tutorials for Ogre as quick as possible.

Now onto the actual meat of the post, what did I do in Ogre. To be honest not much. I did read through the entirety of the Practical Application tutorial, but had a hard time getting it to compile properly. While I will admit to failing with the tutorial, I did learn quite a few things from it. Probably the most important is the concept of how to construct an executable for distribution. Very few tutorials deal with what needs to be included with the executable if you want to distribute it and this tutorial was no exception. It did however go into good practices for how to manage resources needed by the executable. This involves keeping the executable in a central folder and all additional files needed for run-time in sub-directories. That and he fact that any file pointer, either hard-coded or in a configuration file should be a relative address from the executable since some people may not install or run the files from the same location that they were initially compiled.

The next tutorial was a lessen in linear algebra, a class I have not taken. It was informative, explaining how in order to prevent unexpected behavior, the best way for a camera to be stored is attached to 3 scene nodes. Each scene node handles one of the rotations (about the x, y or z). A good if not difficult read, it also went into how Ogre handles the quaternions (a four part variable holding the x, y, and z displacement of a vector from an origin and the degrees to rotate about said vector) and how some of the similar looking functions actually handle the quaternions.

Finally there was the simple first person camera tutorial. While very interesting, and I will need to implement something like it in my game, it was just a few code fragments from what I saw. Which brings us back to where the post started, what is coming down the pipeline. Probably the next post will have one more In-depth tutorial and whatever I can get done of the Mad Marx tutorials. Hopefully after a week or so the Mad Marx tutorials will be done and I can move onto the Artis tutorials. I am not sure how I am going to finish the tutorials, but it will come down to combing through the Advanced Ogre Framework and the Creating a shoot 'em up with Ogre 3D, hopefully all done by the end of the month.

This will mean that actual programming for the game should have the basic screens, though probably not most of the functionality by early to mid November. Of course that is if nothing slows down the current pace these tutorials are being finished.

~gunnah

Picture unrelated

Okay, tutorials completed during the week: 2. Not that impressive, but it is at my initial predicted rate, of course there is no coding in either of the two tutorials which is why it does not seem that impressive. But that is another story.

The first tutorial was another tutorial on resources and resource managers. This did not go over much new information but had a decent layout for how the resources actually flowed in a program from the declaration of the resource manager to the unloading at the termination of the program. It also handled how to create a new resource manager for data types not currently covered by Ogre like how to handle a text file. The second covered was near useless. Besides giving a little overview of the different buffers, it was just 4 C++ files. There is no real explanation or walk-through of what does what or why different lines are added, just a lot of code to go through.

While I could spoil the next post with a preview of the coming tutorials since I started the next two, but I will wait until I get through them to go over them. So I will go over good news instead, I finally got around to figuring out what had to be changed to get the tutorials to run, so the links should be added to the Progress page when I update it with how many tutorials are done.

Is this picture unrelated? I would say yes for the most part. Why am I showing it? I like how it turned out, but besides that, I also started to work on my 3D model skills by going through a tutorials I find online. I do have a site, but since it is mostly just links to other people's work, I am not going to follow it as I have those listed on the Ogre Wiki. So that is good news, I am only going to wait until I finish the tutorial on the Ogre wiki and not add another series of tutorials. Of course, I will probably be showing more and more of that work off, especially as more and more of the tutorials are just reading or when I first start coding since there will probably be little else to show off. So far I have learned quite a few tricks, as before I only knew vertex manipulation, like extrude and revolve on top of the animation and materials used in coloration.

So was it a productive week? More or less I think so. What is next? Hopefully a few more of the In-Depth tutorials.

~gunnah

A little bit of a slow weekend

I should clarify this a bit. It is not for a lack of effort the weekend was a little slow. The In-Depth tutorials take a lot of time to go through since they tend to be very dense with information. With that said I did manage to get through 2 of the In-Depth tutorials over the weekend, one on manual resource loading and the other on how Ogre manages resources. The management was interesting since it explained why the tutorials gloss over the fact that even on the simplest of tutorials, the whole resource configuration file is loaded into the program. Apparently, as long as the resource is not called to load, it is only a pointer to a space on the hard drive (at least how I more or less understand it). While neither of these are extremely useful, I plan on mostly using models rendered on a 3D modeling program and not making the objects by scratch, they did provide some insight into how Ogre works with the meshes and textures not previously covered.

Not to disappoint too much but the tutorials for next post look to be of a similar type, interesting, though not extremely useful. Of course, I say that now before I set out to do the program, I may find that I will need to refer to these when actually loading a custom resource type.

As for the file for some of the previous tutorials, I kind of forgot them. For me they are less important than moving on with the next set of tutorials. Hopefully I will remember them sometime in the next week.

~gunnah

Moving forward

Well, I managed to find a way to compile the programs which were giving me errors. So I went back and did the first Mad Marx tutorial. Finding the fix was more accidental while working on another project than it was trying to rework the Mad Marx tutorials, but I guess I will get around to them in the near future.

I also started the In-Depth tutorials, with my own version of the framework. My goal is to go over each of the other tutorials and try to find ways to add them to my current framework rather than making new cpp files for each tutorial and not have them be related. My hope is that by the end of these tutorials to have a framework which will handle almost everything I need. For starters, I was going through the Advanced Framework (the next In-Depth tutorial) and found a section of game-state coding which will be very useful (state 1 is the log-in screen, 2 is the main menu, 3-n are the different menu screens, and n+1 is the actual game once loaded). Besides this I need to go through, figure out what each item added deals with and whether the element would be relative to my project, in which case I will add it to my framework.

Once I finish all tutorial I will start the main work on the program but the framework I have been creating will likely serve as a platform from which I can build up the different elements of the game.

I did not forget about the uploads, I am hoping to get to them in the next post as I have been busy getting through this one.

~gunnah

The Enigma of Mad Marx

Well, I will start off by saying I did not get around to figuring out what is needed to host the Ogre examples, for now I would say I should get that done within the next week, but that depends o how I handle some of the other things I am fooling around with.

Now I tried to go through the Mad Marx tutorials like mentioned in the previous post, but I ran into trouble. At first I thought it was how I had set the project up as I started this project from scratch to get rid of some of the bulk accumulated in the previous sets of tutorials. So I went ahead and deleted those, closed out of the program and redid everything from scratch again with the same results. After several hours of looking around the internet and finding no one had a good answer on how to handle the link error, I decided what if I put their code in and tried to compile that. For all I knew I forgot some minor line here or there that was causing the whole program to go into convulsions, it would not be the first time. That is where I figured out they had the same problems compiling as I did. So I scrapped the project a second time and remade it again. This time after getting all of the properties set I loaded up the basic tutorial from the last tutorials and they worked fine. I again wrote the program out and got the error and then copied their code and got the error. At this point I decided I would just read the tutorials.

They are a fairly interesting take on how to build an Ogre program. One of the flaws I noticed was they took place entire in one function which made for a very cumbersome read by the end of the tutorials. It is a shame I could not work them out better while going through them to pick up some of the finer details since building an Ogre program from scratch is one of the first items I am going to need to do while making my program. I will most likely go back to my Linux box and try to write and compile them there. While much of the material was not new, it was presented in a different way. Plus, the best way to learn to program is to program. So that is why, while I have gone over the tutorials, they are not marked as completed on the Progress page.

In the mean while I am going to be moving on to the In-Depth Tutorials. Depending on how these work out, I may not need to go through the Mad Marx tutorials. The first In-Depth Tutorial covers how to build your own Ogre Framework, which was in one of the earlier tutorials, but not in as much detail. If these cover what I am hoping, they very well could be some of the first few tutorials I go back to when starting my program.

Well, next time I will probably know whether I am mark Mad Marx as finished or not and will hopefully have a few of the In-Depth tutorials finished.

~gunnah

Continued success

Well, I am really moving through the tutorials now. Bot sure how long I can keep at them at this rate, but at least this was a good pick up after loosing that time earlier in the month. I will start with the bad news, because of how much time I spent on the tutorials, I never got around to figuring out what I need to package with the Ogre executable to make it run, or if it can be run on other machines. That being said, I finished the four remaining Intermediate tutorials. So I will make a brief note of each of them along with any comments I have about how I can make them applicable.

So the next tutorial after last post was number four. This involved making a two-dimensional box on the screen and using the ray queries to figure out which models, if any, were inside the box. Not much but it does show off how to make a bounding box on multiple targets as well as making 2D images. This unfortunately will not greatly help my project, but it was fun nonetheless. When I get Tutorial 3 up I also hope to upload this just for fun. One thing to note is that this method checks to se

e if it hit by the bounding box which can lead to false positives and will need additional work to make sure when the program registers a hit, it is actually a hit.

The picture to the left is from the fifth tutorial. This dealt with static geometries and how to handle batches of objects that do not move. This may prove a little more useful when I get all of the scenery to add to the maps. O

verall the most interesting aspect was the tutorial was the use of RangeRandom. This little function takes two parameters a returns a number from the low to the high. Besides that, there really was not that much to say about this tutorial, which will probably not get uploaded since it does not have any real interactivity, though I was tempted to add a sky box and really finish off the effect.

Tutorial six was an odd one. I am not completely sure what use it has, other than bat signals. I had though about suing it as a cross hair for the guns, but from what it seems it is a highly inefficient system that would require a few tweaks just to get running. A simpler cross hair would be to just draw one with the GUI in the dead center of the screen. My other complaint about using it as a cross hair was how difficult it would be to see from a distance. This one is also not likely to get uploaded, but as you can see it does have an interesting effect.

Finally tutorial seven was handling textures and using a mini map. The mini map may be an interesting idea, but it would not a lot of work to be useful. They use it as something more for a single player game where you are trying to break in or out of somewhere and they want to show you the guard moving in the bottom corner of the screen. All this tutorial had was a green plane twirling, so it was not even worthy of a picture and is highly unlikely to get uploaded with the other few.

I think the reason these tutorials went so fast is they were introducing an advanced topic but there was only so much they could present on the topic before getting too highly detailed the tutorial would loose its value. Most were just a few functions and fairly quick to make. This leaves me in an odd spot. I have to decide if I am going to go with the Mad Marx or the In-Depth topics. My guess is Mad Marx, but it will probably depend on the amount of set up required.

Well, I think that about covers everything for this week. I added a progress page just to keep track of the different tutorials finished and left to be done. That is also where I am likely to put the spot for the tutorial executable links.

~gunnah

Progress!

Well it has been slow going the first half of September, but hopefully things will start moving again at a normal pace. As you can see to the left, I have managed to finish the preliminary satellite design. The overall look still needs a little work to smooth out some of the edges, but overall I am happy with this. In game, I would use a particle effect of some kind out of the four thrusters (all are visible, but only the very edge of the fourth) to give the illusion of it being held up and the effect increased during movement. Additionally I would like to add motion to two of the thrusters. The two side thrusters need to be able to tilt both forward and back, as well as in opposite directions for forward, backward, turn left and turn right. Also the gun needs to be able to rotate 360 degrees as well as point downward. A particle effect for the flash of the muzzle may be interesting to program in also. Finally, when this is colored, on the base of the gun you may notice an odd protrusion. This is a charging bar which will fire when fully green, setting the bar to red until the cool-down is finished. Most like the only main difference between satellites for the teams will be a logo displayed above the gun (not in the picture, just guessing).

The main goal of Tutorial 7 is to have CEGUI interface wit OGRE and go over some very basic controls in the GUI library. The biggest difficulties should have been compiling CEGUI and getting all of the linkers to point to the right spots. So last post, I explained how I got through Beginner Exercise 7 but was running into a few problems here and there. I found out that it was not loading the GUI because for some reason the dll files which I copied into the OGRE project folder were deleted (I may have done this when I was cleaning out the plugins since I started adding these before realizing the plugins.cfg file needed to be changed a little). After that the program worked like a charm and so that wraps up all of the OGRE Beginner tutorials, now onto the intermediate stuff.

I have already done Tutorial 1, check the 31st of last month for that summary, so it was on to the second tutorial. What held me up previously is that the main controls of these tutorials are handled by a GUI engine and not OGRE. Since I have only quite recently gotten the GUI engine and Ogre to interface, I have been unable to continue my tutorials until recently. Tutorial 2 handles finding a location in three dimensional space of a mouse click. A pre-made world is added at the start of the tutorial and then the GUI overlay is add on top of the OGRE layer. Finally a ray query is used it figure out following the ray from the camera if the click was over the ground and at what location it occurred. Another interesting feature added in the tutorial was a collision detection for the camera so the user can no longer go beneath the terrain. Tutorial 3 was a continuation (part 2 of 2) of the previous tutorial. The main goal in this tutorial was determining if there was something where the mouse was clicked. If there was nothing there, then a model is added to the map, if there was an object already present, then the user can move that object. The tutorial finished with an explanation of how masks work, explaining that masks up to 32 bits are supported by the CEGUI and OGRE combination, as well as a few bit functions.

Since pictures seem a little inadequate at this point, since it is no longer a landscape and objects, but actual user interaction which is now the goal, I am thinking of the best way to handle the sample. Most likely in the next post I will include a download link for the tutorial 3 executable. I am not including it in this post mostly because I am not completely sure that I know everything I need to pack with the executable. Hopefully I will have that figured out by next post.

~gunnah

Another short post

Last time I mentioned I got CEGUI and Ogre compiled and was hoping to get them to play nice in my last beginner's tutorial. While I am not getting the errors that most of the people seem to have had a problem with, since I compile both from source instead of, as a lot of people seem to do, use both SDKs. My problem is for some reason nothing is being generated. I know the project compiled fine before I started since I compiled the blank Ogre project, and everything was rewritten fine since I am getting a mouse pointer and no Ogre FPS box. But that is as far as I can get the project to go.

I thought everything was working fine, though I did notice the mouse pointer was the Window's default pointer. But after trying to add a button that says quit (not even the functionality, just the button), all I get is the black screen and pointer. After a small search I found out a file for a CEGUI log was suppose to be made which was not. So my guess is that something very early in the program is not behaving properly. Since this will involve making sure that every line added is doing what it is meant to do, this will probably be a fairly long and drawn out process. Since it make take a few days to solve, I decided to stop there for the moment to update this before stopping for the night.

If all goes well, the model for the satellite and this tutorial will be finished for the next post.

~gunnah

Good and Bad

Well, I am going to start out with the bad, no picture. Restoring everything after the reformat is taking a little longer then I had hoped, and I have not really gotten around to playing with my 3D modeler again. As for the techniques, they are still as much a mystery as last post since I did not have any time to see how to accomplish those goals (movement and painting). The model is almost done, I had been working on some ideas before I reformatted, but it does need a final touch or two before I feel it is how I want it, at least fr now. Hopefully in the future I get better at adding little parts to it to make it look that much better.

Now, on to the good news: in some ways I am further along then before I reformatted. After a bit of work, I got OGRE back up and running. Of course I got all the way to the end, when to compile the Tutorial Framework just to make sure it all worked and realized I forgot to compile the final OGRE project. So OGRE is back up and ready to use. Additionally, I managed to get CEGUI not only installed but compiled as well. I found out that last time when trying to get CEGUI to compile, I downloaded the wrong dependencies file. There are apparently two on the page for Visual Studios, and I overlooked the first link only seeing the second. Problem is the second only has one of the dependencies. So now I should be back on track and hopefully I have a few more tutorials done by the time I post next.

I could go into further additions to the game, but I am thinking I will talk more about the screen after log-in but before entering the game. In a much earlier post I have already described most of the functions that I want included into the page, these are summarized in the Game Overview page I created a week or so back. I believe in the earlier post I described the page as being two-dimensional. This description is what I remember the screen being like, which was nice, but while I want to make a similar game, the goal is only for similar, so this could be an area for change. So, this original layout is not what I am going to use, but how the new layout will function. After a bit of thought, a three-dimensional screen may be a different look, and after going beyond a certain point on the map, the desired screen would pop up with the options. The user would start in a depression in the center of the map. Each part of the page originally described would have its own ramp, with the areas between the ramps being fenced in. Above each ramp would be a sign for what screen the ramp will bring up, like Game, User, Friends, Options, News, et c. The two-dimensional screen for most of the will still be the same, though those that were initially built into the overview page now need their own pages, but that is a small task.

~gunnah

Warned it would be slow

Still in the process of getting everything back up and running after reformatting. I may have a new picture or two for the next post, but for now I did not really have time. While reformatting only takes a few seconds (the actual formatting of the disc), an hour if you count re-installing Windows, four if you count re-installing and updating; the process of getting everything back to where it was before it was so sadly removed takes a bit more time. None of the those times includes prepping the computer for the reboot (moving everything off the primary partition which is about to be wiped) or putting all the programs back into place. To be honest, if I were not applying for work, I would have not bothered reformatting yet since the only trace after I removed it was it diverted my google searches; but dealing with personal information is not worth the risk.

As for the project, Visual Studios and DirectX SDK are both in, OGRE is downloaded but not compiled, CMake and whichever GUI I choose is not downloaded. The 3D modeling program is up and running as well as the OGRE converter. The project will likely be moving again by the post after the next post.

As far as game mechanics goes, I think I am reaching a point where I need to advance both my knowledge or 3D modeling and OGRE before I can really add much to the game. I could go on about planned modules to add, which will probably be the next two posts if I get nothing else done. The need for OGRE is obvious, if I do not learn, it will not advance the project. What I am looking for now with the 3D modeler is a few aspects. Primarily, I would like to get a few items painted, even if the objects are only preliminary sketches. The other more interesting aspect of 3D modelling I would like to pick up in the next week or so is how to animate and then export that animation to OGRE. Getting both of those aspects of 3D programming down will leave the only task, that I know right now, as getting more insightful about how I want different items to look.

I know there was not much content, but hopefully more next time.

~gunnah

Slow Next Week or Two

There will be little programming work done in the next week or two as I prepare to reformat my computer. Yesterday it caught something nasty; so instead of finishing my satellite, I was trying to get rid of the virus in safe mode. This is one of the drawbacks to working on a Windows machine, but it is the only one I have that could do this programming.

Just as a side note to all that, I did add a Game Overview page to the blog detailing who the game should work once I get around to actually miking it. I may break it up further when I get around to it, having a page for the tanks and another page for modules, but that is another time.

~gunnah

A little rest

I know I have not done much with Ogre in a little better than a week, but I decided that I would take a small break. While I have no programming news to tell everyone, I did do a little bit of work on what the reconnaissance point would look like. The picture to the left is not set in stone, but should give an idea of what I am expecting it to look. The defining aspect of this building is that it needs to be tall enough to be seen from a bit of distance away. Each entry way should fit about a tank and a half across to give an idea of the large scale of the point. Secondly, since this is suppose to be a quick refueling station in many ways, access needs to be addressed. The four ramps should make the platform easy enough to get to while still balancing the final concern. Lastly, this is suppose to be almost a safe spot for the controlling team. Originally all I had going up the sides were very thin posts holding up the roof (which is necessary for condition 1). After a bit of thought, It seemed silly to let people drive to a raised position where they would be vulnerable to almost any form of attack.

With these considerations in mind, I have made this first release idea. The post shield the user from most enemy attacks while still keeping it open enough to allow easy access. The picture to the left is another angle of the same structure. Inside of a friendly reconnaissance point, the user may open a menu to swap or add equipment as well as recharging all spent munitions. This menu is also available at the base (so when you die or spawn for the first time) but with an option to change tank types which is not available in the field. This design is subject to change based on future inspiration or comments received.

Well, enough about that for a while, on to something a little different. How kills are decided is fairly easy, whatever damage was the damage to reduce the target's armor to less than or equal to 0 get awarded the kill. I have decided this would be a good post to better define who gets an assist. If the killer did greater than or equal to 75% of the damage, then no assist is awarded. If the killer did greater than or equal to 50% of the damage, then the player with the second most damage gets an assist. If a killer did the most damage and greater than or equal to 25% of the damage, then assists are awarded to the second and third place totals. If the killer was second, then first and third get assists while if the killer was third or lower, then the top two get assists. If the killer fails to get to 25% of the total damage then three assists are award two the top three players who did not get the kill. Note that offline players are skipped. Damage is recorded from the time since the armor was last at its full value (or since the last return to base or reconnaissance point, though the armor is more slowly repaired out of the base). While not a lot of points earned, assists get roughly 33% or the killers bounty, divided among the player with assists by the amount of damage done. (So a solo assist gets 33%; two or more assists get 33% * (damage of player) / (total damage dealt by all players earning an assist).) Hopefully this will decrease the harm done to people who keep have the targets stolen (you dealt a lot of damage and someone comes in a finishes them before you do, most likely you will get a decent amount of the assist points). That is about all for now, hopefully I will be more motivated in the coming week.

~gunnah