Friday Posts Delayed

I am not sure if I mentioned it in passing, but I was studying fore and passed a test back in November.  That was the easy one since it was the one for my major.  Unfortunately, I need to take another test which is more of an overview including a subject I have not taken in a decade and a subject I have never taken.  This means I will be devoting quite a bit of time until the test in early March to studying those holes in my knowledge.  But with all of this time newly devoted to studying and still needing to work, I am going to have nearly no time left to do any modeling work during the week.  Because of this, I am going to stop posting Friday nights/Saturday mornings.  It is not like I have been making Friday posts regularly for some time and the ones I do are mostly excuses about overtime or something came up, et c.  I am hoping to get some modeling done over the coming weekends while taking a break from studying, but as fate would dictate, most of my overtime is now over the weekends.  I am going to continue chugging along slowly but surely and hope that things come together real soon.

Hopefully with a focused post one night a week, I can get this project back on tracks.  I am going to add a list of projects for the game as well as side projects I am doing to the page eventually, just to keep track of what I am doing for everyone else.  Until next post,

~gunnah

Hidden Progress

Just as the post name states, I have nothing to actually show for this post.  Perhaps later in the week I will have more pretty pictures of tutorials I completed.  Well, I suppose the place to start is where I left off last post: the high-detail, low-poly plane.  One of the biggest problems I am having with the second part, I finished the first already, is I want to use a completely different set of software than the tutorial.  Though I have tried the image editing software the tutorial uses, the price tag is very high, so I found a free alternative.  However, not everything lines up perfectly, and I can say you do get what you pay for in this circumstance.  That being said, I am going to continue with the free image editing software for the time being until I can actually afford the pricey alternative   Another problem I found was the tutorial does not use UDK like I though but rather Unity, something I hope never to have to touch.  So when I get to it, I will try to export it to UDK.

Now that looks like I did not do much, and that would be fairly truthful, at least for that tutorial.  What I did do was get familiar with the new 3D modeling software, which is much like the debate I am having over which image editing software to use.  Though in this debate the new, free software actually has a few advantages over the old software.  One of the big ones is that the software will generate a UV map and while this does not sound like much, that is actually quite nice compared to making one in the old software.  Note that while I have not actually unwrapped a UV on one of my models, I watched two tutorials on how to do so and practiced on a cube.  One little annoyance I have is that scaled geometry keeps the UV points relative to their position before scaling.  That may sound weird but here is what I mean: Say you have a cube and unwrap it, you would get the normal t shape.  But let us say you did not unwrap it and instead scaled the Y and Z dimensions by one quarter and the X by three, leading to something that would be like a 6" by 6" by 6' piece of lumber (I was trying to make a pallet and that was to be the middle beams).  I was expecting the unwrap to produce four rectangles and two square, but what ended up happening is the UV map for the cube was generated.  With a bit of work, I manage to determine it was the scaling that did that, since moving the vertices to the same locations unwrapped in the proper form.

One of the bug advantages, since the new 3D modeling software is open source, the interface to export to other software is very open.  So exporting to UDK only required a small python script.  I watched several tutorials on how to move models from the 3D modeler to UDK so they would have the proper material, collision boxes and light maps.  This just means that if I do decide on UDK, moving the models to it would be very easy, at least that is what it looked like.  I will probably make my final decision about what software I am using at the same time, buying whatever licenses at that time.  Currently I am looking into several engines, though I only have two installed at the moment, a few image editing software since I am not sure I completely like the free one I just started using, and a few 3D modeling programs, but mostly the two I have been suing, trying to decide if it is worth putting that much into the project or to just use the free alternative.  Well, probably nothing definitive on those choices any time soon, so until the end of the week,
~gunnah

Work in Progress: Well Scene Animation (Part IV)

The hand before bending

So I managed to catch the animation project back up to where it was before I needed to reformat my computer.  So that only puts me about three weeks behind schedule from where I was.  The pictures attached in this post are the progression of making the hand to putting it into the project.  Most of the hand was already saved luckily, so I just needed to make the two long bones which are actually in the arm.  Once that was done, I set each bone in a child-parent relationship to the others so when certain bones are moved, other dependent bones follow.  Once the bone hierarchy was in place, any moving bones pivot point needed to be altered (that is three points in each finger as well as one point for the wrist with that bone being the parent of all the other bones in the hand).  Then I just had to bend the fingers into place and move it so the lantern looks to be held up by the hand.  Then the lantern needed to be scaled down so that it looked the proper size in the screen.  Finally, the hand and lantern were grouped and mirrored on the other side of the well, keeping the thumbs pointing the right direction.

The hand with the lantern not scaled down

So this leaves only a few things left to model in the foreground for this animation project.  I would like three or four stepping stones, a figurehead perched on something coming out of the wall behind the well (the perch would serve as a fountain), a few more of the tangled weeds with one growing up the wall and then some last minute detail work (chips and the like out of the stone so it does not look so perfect).  Once that is done, the easy part is going to be background work, I hope.  As I mentioned, one dead tree and one willow should be enough to keep the mood going and make he background interesting looking without drawing too much attention or taking too much time.  Once all of the modeling is done, texturing should not be that bad on most objects, since most are small or in the background where less detail is required.  Then all moving parts need to be rigged so that the animation can show the movements of the various objects.  If I get real inspired, I will probably look for sound and some HDRI of a forest under a moonlit night.

Hand with scaled lantern

Now, as for the tank game project itself, I have not stopped thinking about it, life has just gotten busy.  I still am thinking of ways to add detail to the base models.  I am thinking about learning another modeling program and doing some of the tanks inside that program.  Not because I do not like what I am using, just so I am more versatile.  This means I will probably do several small tutorials so I get used to the UI.  I do not really need to learn to model again, unless I move into some kind of sculpting programs since those behave differently from what I have experienced, though trying to stay low polygon count would really rule those out.  My goal is still to get the main underground roadways done, a set of tracks for my motor-pool showpiece and then work on some of the more individual roadway pieces.  I believe I already stated I wanted to make a few pipe sets to add some quick detail.  Once those are set up, I can worry about some of the other details scattered around the map as well as what various projectiles and mines are going to look like.

The hands holding the lanterns in the well scene

Now, as for my research this weekend.  I think I did a fairly decent job of getting a large sample size of images from an up-coming online game with expected to support a large number of players at once.  What I have found, and this is by no means a final survey since I only glanced at a sixth if that of the screen-shots, is many of the low polygon tricks I have read actually can work.  Most of the detail comes from the textures with, in some cases a very rough, shape being defined by the model itself.  This makes me feel decent about my work because my modeling skills are about there, but now I need to work on my image editing skills.  My problem is I really never advanced beyond paint with that whole line of programs, so many of the techniques to make various effects are going to take me a while to make since I will need to look each one up as I need it.  Another concept I have seen is making a high polygon model with a low detail texture and with the renderings make a highly detailed texture which can ne applied to a low polygon model.  Well, I think that is more than enough for now, have a good week,
~gunnah

Small steps forward

Sorry this is very late.  I have continued my work on getting the repeatable pieces done for my map.  To the right is the T-intersection and below is the 90-degree turn.  The 45-degree turn is modeled, I just have not textured it yet.  Once the is finished I will move onto the walls, which will be a little more numerous, as most pieces will need multiple walls around it.  Once those are made I can move onto the ceiling which will finish most tile-able parts.  After that I will probably make a light - more as a placeholder than a finished product, letting me get back to it later when I can make a few different ones so it will not be as monotonous looking.  Once the halls are in place, I will build the custom rooms in the same manner - floors, walls, ceiling - and then the basement of the level will be almost done.  What will be needed is a ramp or two, I am thinking two different widths, and then just small materials to make the level more interesting, but those can wait.

As far as the engine discussion goes, I have decided on a test for UDK.  If I can build the demo, than it is my choice of engine and I will get the license.  But this is still a little while away.  What I did do over the last week was check how I could import the objects and materials, and after a bit of work I have found it is not that bad.  Once I am happy with how the level is built, I will move onto making the moving models - tanks, missiles, mines, satellites, et c. - and then making four textures, one for each team, for each.  Once all of those are finished, it will just be a matter of programming the demo.  Now of course, I made that sound as easy as possible and the demo is probably a decent way off still.  I am unsure if I will add small details to the map or just leave it as empty hallways, I am tempted to do the latter to keep construction time down and save something for the actual release.

So again, sorry for the late post, I hope this makes the direction I am moving in clear.  A lot of modeling and texturing in the coming posts, though I am hoping they level pieces at least go together fast.  The other pieces, the non-permanent tanks and missiles, will probably have more detail and take a bit longer to finish.  My post tomorrow will probably be early since my shift at work changed for next week.  Until then,
~gunnah

What I need to make a demo

Well, first off, sorry I missed Friday's post; I know, I am a terrible person.  Secondly, next Friday, I am not sure if  there will be a real early post or if I am going to miss that one also.  I am busy Friday night and most of Saturday, no where near my computer, so it is likely I will miss that one unless I got quite a bit done a feel it is enough to warrant the early post.  Now, with that out of  the way, I will start talking about the game and how I am hoping it will move along.  Currently I am finishing up the four base models from Tanarus: the chameleon, lightning, mag rider and devastator/vanguard (the models are near identical looking beyond the texturing).  I am hoping to turn each model into two versions, much more detailed than the basic model.  One tank, probably the mag rider or chameleon whichever is more intricate, will need only one model since I am planning seven tanks at release, each with slightly varied stats.

So with the vehicles discussed, we need a level to use the vehicles on: and I am thinking the one which will go together the quickest will be the military base.  Because a majority of the base will be segments of hallway underneath the surface, I am hoping to get away with two dozen of so varying pieces underground.  Once those are finished, I will probably make three or four pipe sets to add a little variation into the halls and finish the underground section with a few chambers.  Above ground will be fairly sparse.  I am planning outside of the base for each team, six entrance ports which will lead to reconnaissance points as well as a fairly large central building leading to the central reconnaissance point.  Beyond that, I am thinking that there will be four installations (north, south, east and west on the map).  East and west will be shorter sides and hold only two reconnaissance points.  North and south will be larger installations and hold three reconnaissance points.  Note the map will be rectangular with twenty-one total reconnaissance points.

Now the only thing left to do is go over the opening screen again, but since I feel that I already have described it previously in enough detail.  That covers everything I need to do for the demo.  Since I am probably going to try to get the demo out with the least amount of coding, I may ignore the opening screens as well as the multiplayer functionality, just letting users go around and blow up pre-spawned or re-spawning enemy tanks.  How long will it take me to finish all of this?  That is a good question, my guess would be several months, mostly because I am finding it hard to get time to work on this project on top of school and work.

Now, on to my 3D art which I have ignored thus far into the post.  I made an ArmaLite AR-15 assault rifle over the weekend.  I could have worked on some of the previous projects or started to think about how to move forward, but I wanted to do something I would get some enjoyment out of and which would be done quickly.  Each picture is just a re-skin of the others and all of them use the built in materials provided by the 3D modeling program.  I would really love to see this in a demo since each og the paints is metallic, even though it is hard to see from these pictures, and the way the light catches them, particularly off of the gold plating, would be fun to look at - I had to settle for rotating the gun and then redrawing the scene.

Well, sorry for the long post, but I think this is the first time in a long while I had some kind of direction as to what I need to do to get something playable released.  Well, until next time, again I will only post early Friday if I have done something useful, not a filler post,
~~gunnah

Some direction

Well it may be a little while before I get much else done.  Hopefully I can start making small progress in various minor aspects of the game, but that depends more on how life decides to play and it does not always play fair.  Probably the quickest topic I want to discuss is my progress with the Source engine.  In short, not much.  They way the tutorials for the engine recommend setting it up involves setting up the source control early on and I just have not had time to sit through and set up all of the preliminary work (I have been looking to check the engines as quick as possible and this may take a little more time than I was hoping).  So in short I have not done much, but I have read through how to set up the engine and when I get some time I may get around to actually going through and getting it up and running.

Another quick note is that I have added a new column on the 3D art page for small items I want to make.  Some of them were described in the previous post, like the garbage and recycling cans.  I have been looking around and have a few other ides, but I am not sure when I will get around to making a long list of things which should get done (There will never be such a thing as a complete list, but there are numerous things which I would eventually like to make for the suburbia map).

Finally when I was describing the levels I would like to make (I will save you the work of looking, it is in this post) I talked about different maps.  I know I have had tunnel vision on the Suburbia map but that is because at the moment it is the most detailed of the map and the one with which I would like to make the demo.  After a bit of thinking I have thought of the fourth map I wanted but could not think of at that time, a Top-Secret Base. The uniqueness of this map is the overall layout.  The cargo hold I am thinking will be entirely exposed.  The suburbs will be mostly exposed except for a few exceptions (Parking Deck and Mall in the middle of the map). The castle will also be mostly exposed but have a little more enclosure (I am thinking it might be fun to have a map with a different scaling, so on this map the tanks would be scaled models and the castle extend out as though it were the size of a large town).  The Top-Secret Base on the other hand I am thinking will be about half enclosed with a large subterranean area including the central point.

That about covers everything I wanted to get out there, hopefully Friday I have something more to show.
~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

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

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

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

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

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

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

Change of Plans

Well, I am glad I was playing with those other programs before I tried to make something as complicated as my tank shooting game. While I really like python and think it has great potential, I have found some of the drawbacks. Before I go into those, I would like to mention some of the highlights of the language since it is quite convenient in many respects. Probably the nicest aspect compared to Java and C is that python has duck-typing. The file i/o is a breeze compared with all the buffers some other languages use; and the networking with need to use sockets and other complexities was also nice. Now for my complaints: problems with class instancing and initializing data. While writing the GEDcom converter, I allowed for a person to have multiple later in life families by setting that type of family to be stored as an array. While running the program, I found that while I meant the array to be per individual, I was creating a global array where each person was adding to the array. Another aspect I could not work out is why most of my parsing code worked fine while one check did not return the right data, but I am going to say that was on my end and not blame python for that. So that was my big complaint, the array not working as I had wanted it too, and I know it has something to do with the odd way python works with classes, but that is for another time, hopefully in a future version this is remedied. My other complaint is that python insists that when defining members of a class they be initialized, which is fine since I understand the need to know how much space to allocate. But python does not support multiple constructors, which makes it hard to have a blank class place holder in the definition and then create a class with some variable. I know this is nitpicking but I really found this to be a hassle (I have been using Java for years which is why I am used to multiple constructors).

So where does that leave me? With a big choice, what language to try to do this project in next? My main choices were C and Java. Java has its advantages in a built in method of creating a graphical interface, but I have never really liked the way it looked. So I looked for graphics engines, and found one I think I like. It is called Ogre, and I believe it runs code written in C++. Not quite one of my two choices, but it will work well enough if this engine does what I am hoping it will. This is going to involve a lot of work before I even start on the main project, since Ogre comes with a ton of predefined classes. So far I have made it through the first two basic tutorials, slightly cheating on the second since I did not find a black ninja in the dark a very fun thing to look at (as it turned out, I needed to move the mesh file to render the ninja which I would not find out looking at a black screen). Currently I am using a Pentium 4 computer running Ubuntu 10.10 to do all of the programming work, but if it becomes too much for that computer - the ninja with three lights casting a shadow, though it was the most complex shadow, had it between 8 and 18 frames per second - I may need to move over to my main computer, which is Windows which I was avoiding since I do not really like the setup of Visual Basic, as odd as it sounds I like the basic text editor.

And now a bit about the game:
I was going over what I have posted so far in my head earlier today and realized I missed a very big part of the game play experience. Every tank is electrically powered and has a certain bettery life (it can be slightly expanded but I will get into that more when I expound on the different modules). While near the base and friendly reconnaissance points the battery charges until it is full. Outside of those areas, the battery begins to drain, with a Warning state (75% movement speed) at 25% and a Critical State (50% movement speed) at 10%. These two altered states keep the battery alive slightly longer, and I may include an option on the tank customization page to override these states which would drain the battery at a constant rate, but once the tank looses all battery power it stops. The tank does not loose weaponry, but cannot move the turret, so as long as the opponent moves out of the line of fire, the stationary tank is sunk.

Disconnects and logging off each leave the tank on the field for 10 seconds. During this time the tank is vulnerable to enemy attacks, so watch where you are when you log out, best done inside the base.

One final bit is the recharge rate of the base and reconnaissance points. These are not unlimited, but rather start with 100 slots. For each module refilled (mostly mines, missiles and other one-use modules) the point looses 1 slot. For bases slots will regenerate every 15 to 30 seconds depending on how testing works out - players entering and respawning will each eat some of the slots, so this will need to be a fairly quick regeneration. Reconnaissance point will like be on the order of a minute of so depending again on testing feedback.

Vacation Over

I will start this post off with why it has been about two weeks since I last posted. I ended up going to Canada for a few days which means factoring in packing and unpacking takes a week out of that time. Besides this trip, I have also been designing another program. Before I do my tank shooting game, I am looking to make two programs, which I will discuss now:
* A Family History Website Maker. This program takes a GEDCOM and converts it into a series of HTML files. For those of you out there who do not know, GEDCOM is a file format (usually using the extension .ged) which was developed by the Church of Latter Day Saints and which has become a standard for storage of genealogical information from programs. This obviously does not look run or sound like an online tank shooting game. My goal with this program is to review syntax for my chosen language, work with varying amounts of file input and output and eventually build a basic graphical user interface. With the experience from this I will have most of the concepts for the program on the server side, as well as the client side.
* The second program is a small instant messenger. The goal is to have it handle a small group of basic tasks such as the instant messenger process itself and file transfer, as well as problems like disconnections and time outs. Again the hope is this program will have a slightly more complicated graphical user interface. This will familiarize myself with how to get the server program talking with the client program.
Once these two programs are complete, I will begin work on programming the tank shooting program. The hope is that by then, everything is already laid out and the preparations will make the actual programming go much smoother. The language I have chosen for all three programs is python, because of how friendly the language is, especially in the areas of file i/o, GUIs and internet protocols.

Basic Tank Stats
Each tank will be given a rating in each of three categories: armor, modules and speed. All tanks will have a total of thirty points to spread between the stats, described a little later in this post. A score in any stat of a 10 is about average with zero being near useless and thirty being overkill in an particular stat. I am thinking of releasing ten tanks at beta launch and cutting out the three absurd tanks once I feel the game is balanced. The most balanced tank has a ten in each stat. Tanks which slightly favor one stat will have a points spread of about 14/8/8 while those tank which strongly favor one stat will be 20/5/5. The final three which will likely be removed will have a spread of 28/1/1. A score of zero does not mean the tank does not have anything in that stat, for example a tank will always have armor, it is just a scale of how much. For this reason, On top of each stat, there should be six global variables, two for each stat. The first is the scaling factor - how many points of armor do you get for each point the tank has in the stat for example. The second is the base case - if my tank has no points in armor, how much damage can it take? These will be decided during the beta testing once this program is more of a finished product. The following is a brief description of each stat:
* Speed: dictates both top speed and acceleration. Top speed is linear while acceleration increases greater than linear.
* Armor: how much damage can the tank take and how fast does the health recover. The amount of health increases greater than linear while health recover increases less than linear.
* Modules: many many compartments does the tank have for equipment. Modules also dictates how large the tank is, since to have more compartments the tank needs to be larger. The overall size increases less than linear while the number of modules is linear.

In the above, I am not sure how clear it is described, so here is what I meant by linear, greater/less than linear. Linear is basically the same here as in math with the generic formula x = base + (stat * scaler). A stat which has an attribute increasing greater than linear means the attribute grows faster than a linear plot or when plotted the second derivative would be positive in a more mathematical sense. Increasing lesser than linear is the opposite of greater than.

I hope this explanation is not too confusing, next time I will probably go into what modules will be available.
~gunnah

The Match Laid Out

In the last post, I went over what I hoped the menu system would work like, this time around I am going to hopefully go over more of the actual game. Once a game is selected from the menu or via a friend, the tank selection screen will come up. For now I will not go over details since I am still working out what I want in terms of number of available tanks and modules to customize the tanks once set. Next post will probably cover modules and give a few screen captures of some tank ideas. Once this is finished and the "Join Game" button is hit, the very basic commands for the game will be W/A/S/D (turret up, left, down, right), up, left, down, right arrow keys (increase trust, turn left, decrease thrust, turn right) and space bar (fire auxiliary weapon). All other keys will be based upon how the tank is setup. The following sections describe each type of match which will hopefully be available.

Open
This is an nonobjective based map. The main goal is to kill enemies or capture the flag which in turn earns the killer/captor points towards their rank. This is the most like the original Tanarus game. A kill or capture will earn a bounty, not sure how bounty will be calculated yet. Captures are special since each member of the capturing team gets a kill on each member of the team which lost their flag. This will be discussed in greater detail under capture the flag. Additional ways to earn points in open include taking reconnaissance points or destroying enemy satellites, neither will net that many points but will be worth something for the help it grants the team. Game is four teams of six members.

Death Match
Very similar to open, but a greater emphasis is placed on the killing of enemies. I am not sure but I may remove flags and reconnaissance points and purposely place these on very small maps. Overall goal with these is matches is to get new players more used to the controls without as much worry about other in game situations. Game is four teams of six members with a set timer to limit match.

Capture the Flag
Much like Death Match, this is a dumbed-down version of Open where the main focus is on flag captures. Reconnaissance points may or may not factor into these like Death Match. Again the main goal is to teach new players how to work as a team for flag captures in the Open maps. When a flag is captured, each player bounty on the captured team is set for each player on the capturing team, and any bonuses are added. This bounty sum is them multiplied by number of people on the captured team over the number of people on the capturing team (if teams are even the multiplier is one, more people on the capturing team means the capture is worth less then if there are more people on the captured team). Each member of the capturing team then has the bounty added to their score, a kill for each member of the captured team. Members of the captured team get a death for each member of the capturing team and once the capturing team gets their bounty, the bounties are readjusted for the multiple deaths. Unsure, game may be two or four teams of six members with a set timer to limit match.

King of the Hill
Unlike Death Match/Capture the Flag, this is a match in its own right. In addition to the ways to earn points in open, points are also awarded for spending a set amount of time in the area designated as top of the hill. Unsure, game may be two or four teams of six members with a set timer to limit match.

Duel
For those willing to go one on one, duel eliminates flags and reconnaissance points, but has a kill count, ending when one player reaches the target number of kills. The map is very small and intended to be a very quick match. Points earned based on difference of combatant ranks and overall score to be finalized after much testing.

Challenge Match
This is a special form of open match where the tank selection screen is bypassed. Each player of this has the exact same setup. Going to the base and reconnaissance points in game does not open the ability to swap equipment like the option would be in a normal open match.

Now that I have described each of the main types of matches, some more may be added, I would also like to mention how matches may be selected. Each type of match may be limited in one of three ways: rank, bracket or open. Rank means that only people of a specific rank, beginner is a very good example of this, may enter the match. A bracketed match is reserved for those of slightly higher ranks, coupling several close ranks. An open match is one in which any player may enter, without needing to reach any set rank. In bracketed and open, killing a higher rank player nets a bonus multiplier, whereas killing a lower ranked player hurts the multiplier.

In a later post I will go over the exacts of terrain, roads, fluids and other map based obstacles. This brief description of game play will focus more on team oriented objects. One a fresh map, each team has a base with a set number (I am unsure if I will make it six or ten) satellites. Outside the base are numerous neutral reconnaissance points. Above the neutral reconnaissance points are neutral satellites which can be shot down. On this now open point, if the player has added the module to call over a satellite, that team may now capture the reconnaissance point. All tanks are given an energy bar, which recharges when in home territory and decreases when in enemy territory. By adding these points, the home territory can be expanded. A similar process can be used to take an enemy reconnaissance point. If a tank runs out of energy, it is no longer able to move, leaving it stationary, but still may rotate the turret and fire weapons with a penalty to the ability to move. In the discussion about modules, this energy gains and losses will be discussed more fully but it would be remiss to not touch on the subject while discussing game play.

Besides energy, each tank is equipped with armor, which can be augmented with shields. Once all of the armor has been destroyed, ever if shields remain, the tank is destroyed, the kill is rewarded, and the destroyed tank is returned fully healed and equipped back in the base after a respawn countdown. To view the current players, kills and deaths in this match and bounties, the tab key will probably be bound. Once a player is done, they can choose to leave the map, probably an option after pressing the escape key. At this point a timer begins and once the timer hits zero the player is removed from the map, be advised while the timer is going the player is completely vulnerable.

While this post probably touched on too many subjects an dis too long, I think it give a good idea as to how match selection will work. Game play will fill in as more of the detail about different topics come to light. In no particular order the next few posts will describe: Map Terrain, Modules, Server/Client Programming, and Tank Ideas.
~gunnah

New Direction

So I have decided to give this blog yet another try, third time is the charm or something like that. Well, my overall goal is to document the progress I am making on my newest project. Not really sure what to call it yet, then again, I do not really have much done. Without beating around the bush anymore, I am just going to give the basics:

The Inspiration:
A few days ago, me and a friend from high school started talking about a game we played online around the turn of the millennium. It was a 3D online tank shooting game called Tanarus, which we would waste countless hours on after getting home from school. That was until it became pay to play and neither of us had a credit card or could convince our parents. So time lapses, and I check on it every once in a while and the only real change is I become a poor college student who cannot really afford the $10 a month plus the time to play the game. As it turns out, the game has been offline now for a little over a year, after a thirteen year run which I would consider a success for any online game.

The Project:
While not wanting to tamper with anyone's rights, even though the game is offline, I would like to create a game with a similar play style. All of the code/models are going to be made by me, though it will be clear from where I draw my inspiration. I hope they, like I, consider imitation the highest form of flattery. Most of the models will be fairly square with lots of sharp angles, this is not because I am not learning the modeling software, but because I want to preserve some of the nostalgia I hope to eventually create.

Project Details:
The following is a very rough breakdown of what I will need to do before the game even begins:

• Game opens to a log in screen which sends the username and password to the server and can either send the client to a log in fail page where the user can try again or go to the server select screen.
• The server select screen is the main page for the game. A list of news/updates should appear on the one side. A link to option page(s) on the bottom. The tutorial and/or practice campaigns should also be a link on the bottom. A link to the user stats page should also appear on the bottom. Finally, counter to the news/updates should appear a list of all games currently going on, listing the match type, the map, and number of friends/people playing on each of the four teams.
• Option page(s) should include any video and audio options, as well as an option to re-key the game and credits.
• The tutorial and/or practice maps will be run solely from the client-side and include basic information on how the game works.
• The user page includes any stats which may be of interest, primarily the kill/death ratio, hit percentage for each ammo type, most used tank, kills, assists, points (used towards ranking), points in each match type and a list of friends the user has made, and an input field to add another friend. Clicking on a friends name will send you to their stat page, with a special table row that will be labeled status showing the match they are currently in, in the color of the team they are on. Clicking on that will join you to that game on their team, with a popup appearing if their team is full with a link to join teams which are not full, or an error that the match has no open slots.
• Possibly included above or below the news/updates is a ranking list for overall and match type by kills, points, kill/death ratio as well as maybe a drop down list to limit to only users of a certain rank.
• Finally, the table of matches. The arrows at the head of the match column will sort by alphabetical (-), increasing rank (^) and decreasing rank (v). Additionally there are four symbols above the team breakdowns: (^) for most people in a map, (v) least people in a map, (F) friends in a map (sorted by which has the most friends), and (All/Limit). This final button does not sort but chooses whether to display only those available to your rank (Limit, which is the default), or all of the maps (All). Clicking on match will join you to the team with the fewest number of players, whereas clicking on the team column in the team breakdown section will join you to a specific team.

More details of actual game play will be given at a later date, as this post is getting too long as it is.

~gunnah