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