| Tuesday, February 7, 2006 |
  Terrain So Far | 
Posted - 2/7/2006 11:00:11 AM | I've known for a while that I want to do something with tiles for the terrain. The requirements I have for the view are fairly simple. There's no skybox. The camera is always aimed at the ground and can rotate around, but its rotation along the x-axis is constrained. Units and buildings will not be to scale, so the terrain doesn't need to be either. The most important thing is that I know at any given time what type of terrain a unit is presently on. Also, going off of one edge of the map should cause the terrain to wrap around such that you can travel 'around the world' in any direction.
I've been playing around with different ideas on just how to implement the terrain tiles. What I'm working on presently, I started from Greg Snook's article in Game Programming Gems 2, "Simplified Terrain Using Interlocking Tiles". I didn't like the default implementation, so I've expanded on it a bit.
Given a heightmap, each pixel corresponds to one tile. Currently, a tile is a block of 5x5 vertices. The heightmap value is assigned to the center vertex. To avoid the Roller Coaster Tycoon look (squared tiles everywhere), the heights of the other vertices in the tile are interpolated between the current tile's height and the heights of its neighbors.
Thus far I've only got the basics implemented, in wireframe with no texturing. It didn't take long at all to get it up and running. What did take time is settling on an approach to use. I've gone through different tiled experiments, and even a half-hearted geomipmap implementation, to finally settle on this approach. I've got a bit more work to do on it before I finalize it. I need to implement the LOD part of it, which is very simple (the same vertex set is rendered at different detail levels by swapping out index buffers). I'll also need to add texturing. If I can get it to look and function the way it does in my head, this is the approach I'll go with.
I'm really anxious to get this done and move on to other parts of the renderer. The sooner I get all of the basic rendering implemented, the sooner I can start getting to the gameplay. I do enjoy doing graphics work, but my head is about to explode with gameplay ideas.
| |
| Thursday, February 2, 2006 |
| Of Prototypes and New Fonts | |
Posted - 2/2/2006 6:43:58 AM | Work has been pretty steady since my last entry. It was interrupted for 3 days for the Lunar New Year holiday as I had to head out of town to my in-laws' house. It's times like that I wish I had a laptop.
I knocked up a prototype of the web game idea I had using JSP and Servlets. My PHP voodoo is weak, so Java was the better option for a quick prototype. I was disappointed to find that the idea as it stands is not very interesting in implementation. I'm looking at ways to fix that. One of the things I'm considering is how much detail the player needs to manage each day. Ideally, not too much. Five or ten minutes is all it should take to play a turn. The real problem is how to make that five or ten minutes interesting enough that not only is it fun to issue the commands, but also that the player will come back each day anticipating the results of the previous turn. The prototype is missing that, as the choices after the first few turns just aren't interesting. This is one of those problems for solving on the bus or the subway between classes. I'm sure I'll come up with something.
Work on Game #1 has been sporadic while I fleshed out that web game prototype. I've toyed around with a few ideas for terrain rendering, but I've not yet settled on which approach to take. I've not done much beyond wireframe rendering, so until I get more work on textured terrain done I won't have a final decision. However, I did rip out and replace the font renderer.
I had originally been using Witchlord's BMFont tool, but when I decided to go with the RecordJar format and OpenRJ for all data files, I switched to MudgeFont. Converting the XML output to RecordJar format was very simple. There's a python script called 'mudgefontxmlto.py' in the package. It implements a few sample converters, so using that as a base it took less than 5 minutes to have a mudgefontxmktorj.py up and running. Even so, I wasn't totally happy with the output. I also decided using RecordJar for the font data wasn't the best idea. Then, today I happened upon Bitmap Font Builder by accident through someone's blog. I had used the tool once some years ago, but had forgotten about it. I actually like it better than both MudgeFont and BMFont, so I reimplemented the font system one last time. Finally, I'm satisified with the results and I'm not using the RecordJar format for fonts now.
I'm crossing my fingers that I'll have a preliminary implementation of a terrain renderer finished by the end of the weekend. I'm free all weekend, except maybe for some time out on Sunday to see a movie. Assuming no distractions, I should get a quite a bit done.
| |
|
| S | M | T | W | T | F | S | | | | 1 | | 3 | 4 | 5 | 6 | | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | | | | |
OPTIONS
Track this Journal
ARCHIVES
June, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
