| Saturday, October 29, 2005 |
  Resisting Overkill | 
Posted - 10/29/2005 8:57:57 AM | The only 'real' programming job I've ever had was at a small startup one of my former English conversation students launched. I think he hired me to save money. My first order of business was to choose a server platform and technology to power our first project - a web app aimed to bring models, agencies, producers and wanna-be-models together in one community. At the time, considering our limited budget, it was a no-brainer: Linux + J2EE. I had some Java experience under my belt, but the whole web app thing was new to me.
I'll never forget that project because it was just insane. The feature set spiraled out of control as they kept adding features at every meeting we had. They built partnerships with other companies and required me to incorporate the partners' tech into our project. The front end was being designed by the web designer in isolation, and was changing on a daily basis. And all of this was supposed to be finished in 3 months. Additionally, they had two more projects lined up on contract that I was supposed to work on in tandem.
In the end they added two more coders to the team after I begged for help and we got the first version out the door in just over 6 months. I left after that. Too many nights sleeping in the office burned me out real quick. But the bug had bitten me and I continued to do J2EE work on contract out of my house for my former employers and other companies they put me in touch with.
One bad habit I picked up from all of that is 'future proofing'. People will tell you that making your software design future proof is a good thing. It's one of the core tenets of 'good OO design'. Being able to replace system components with better implementations, or to reimplement whole systems actoss new platforms when they become available without changing the client code, can potentially save you some headaches when you find you need to do those things.
Don't get me wrong, 'future proofing' is not inherently bad. The bad part is when you start applying it to every single project you work on. Implementing a flexible, extensible interface to to a system takes a lot of planning. There's a lot of indirection going on, several layers insulating the client from the nitty-gritty details. Java makes it quite easy to overengineer (and there is a great lot of overengineered Java code out there - particularly in the J2EE space). If your current project does not require all of that, then you wind up with bloated code that is more difficult to maintain and potentially less performant than it need be - overkill.
When I started laying the groundwork for Game #1, one of the first things I needed to do was to decide how to manage my cross platform code. I want to target two platforms: Windows and Mac. The decision was an easy one. This time, I chose to go with GLFW. So here I am, coding in C, and I have these wonderfully clean and flexible interfaces for display management, input handling, timers, threads, and so on. After all, I may want to switch to SDL in the future. Or maybe port to a platform where GLFW isn't available. When I started trying to decide the best way to translate between GLFW key codes and my own, I slapped myself and woke up to what I was doing - I was creating a platform independent interface to a platform independent interface.
If you look at OGRE, or Torque and some other crossplatform game engines, you will find that they often use native Win32 code for the Windows port but plug SDL in to their framework for the Linux port. That's fine for them as in those type of projects it fits right in to the project's scope. For what I'm doing though, no friggin way. I want to support Windows and Mac, use OpenGL exclusively, use GLFW on both platforms, and move on to the next project when this one is done and marketed for a bit. It is beyond this project's scope to port to other platforms or APIs. I don't even plan to reuse any code from this project other than some of the framework. It's a one-off deal.
I have become conditioned to think in terms of abstract interfaces because that's not only what I'm told to do (from books and online articles), it's what I've done a lot of. It's like the droves of people who post here on GDNet something like "I want to make a game, so I've started making my Engine". Did those people stop to think if they really need to code up a game engine to make their games? I think in most cases they take that route because that's what they are told to do.
So for this project at least, I am forcing myself to abandon my normal train of thought in design. I'm hardcoding calls to glfw in my init code and game loop. Some of the rendering code will be factored out into single functions to avoid redundancy, but I won't hesitate to mix up OpenGL types and function calls throughout the source. Logger objects? Forget it. There's a single log file that is a static local to the log module.
Somewhere between inflexibility and overengineering, each project has its own sweet spot. There's no such thing as one-size-fits-all. We shouldn't try to force a project into a particular design mold, but should instead tailor a design to fit the project. It's easy after some experience to knock up the most uber OO design evah! The hard part is training yourself not to.
| |
| Wednesday, October 26, 2005 |
| Ni! | |
Posted - 10/26/2005 10:19:10 PM | I spent some time with Pawn, took a look at SpiderMonkey, and looked through the Lua maual for the 100th time.
I evaluated PAWN a couple of years ago when it was still called SMALL and liked it then. I still do, but I'm hesitant to use it because there's no official Mac support (the Mac platform is as important to me as Windows). It's compilable on Mac, moreso now than in the past, but I'm not the one who will be doing the Mac port of the game - I'm handing that off to another developer (more on that later). Rather than stick him with the burden of building and maintaing a scripting language in addition to the game, I'd rather go with something easier to use.
As for SpiderMonkey, I've been aware of it for years. I've used Rhino on the Java front and really liked it. But I was turned off by the SpiderMonkey build instructions. I don't know if those are up to date or if you can really compile it out of the box with compilers other than those listed, but I decided I didn't want to find out. Even if you can compile it with different tools, it's again something I don't want to burden the Mac guy with.
Going back to Lua, I didn't like it the first time I saw it a few years back, and I don't like it now. That stack management stuff, with all the -1s and -3s and pushing and popping... yuck! I don't see how anyone finds that language at all attractive. There are some things I like about it: it's easy to compile on multiple platforms out of the box, it's performant, and it's lightweight. I just really do not like the C interface.
So that brings me back to Python. I've both embedded and extended it for different projects in the past (not games). And while I haven't extensive experience in coding Python, I do have more experience with it than the other languages I looked at. I was wanting something more lightweight for Game #1, as Python just feels like it's too much for what I want to do with it. In the end it makes sense to use it though. I'll be distributing a minimal set of modules with the game. I'll likely also ship a custom build with a modified search path so that only the modules I use are available and not any which may be preinstalled on the player's system (as desribed in the next-to-last paragraph here).
Until next time, Ekky-ekky-ekky-ekky-z'Bang, zoom-Boing, z'nourrrwringmm.
| |
| More Plumbing | |
Posted - 10/26/2005 10:05:01 AM | Time management is proving to be a bear this week. There are more errands to run than usual (including getting my dog to the vet for check-ups - he's fully recovered now and the stitches should come out soon) and my work schedule is quite erratic this week and has tripled my total commute time. It's been difficult to sit at the keyboard for more than an hour or two at a time.
Since I hate starting a task when I know I'm just going to have to drop it part way through to leave for work or an errand, I've decided to spend this week working on small tasks that can be completed in an hour or so. This has mostly involved reworking the framework and fleshing it out more, which I had intended to do later on down the road. For example, I've fleshed out the logger, added custom asserts, worked out a platform interface (for things like message boxes and user profiles) and implemented some of it, yadda, yadda. Lots of boring things that will make life easier down the road, aka much of the code that will be reused in Game #2.
I haven't been entirely unproductive on the terrain front. While I've yet to implement any prototypes, I have made use of my time on the subway: I've been doodling in a notebook and browsing through some of my books (GPGems, Game Engine Architecture, even the Massively Multiplayer Game Development series) for ideas and inspiration. Now I think I know what I'm going to do. I'll need to prototype it to be sure.
At first I wasn't too keen on using heightmapped terrain to create the vision I have in my head. But the more I thought about the gameplay, the more heightmaps began to make sense. It's hard to put my thought process into words without going several pages to describe what I'm visualizing. The short form is that I realized heightmaps would offer more flexibility over the other methods I was considering. Also, rather than using 8-bit grayscale images for the heightmaps, I'm thinking I can use RGB or RGBA and encode all of the data for an entire map in it - the heightmap, terrain details ('tile' flags, materials, etc...), building locations, and everything I need. That seems attractive to me for some reason.
As soon as I have a nice chunk of 6+ hours to sit at the keyboard, I'm going to try and knock up the first terrain prototype. In the meantime, I'm going to keep working on small tasks. I'll want to get font rendering up and running, and that means I'll need to get the basic resource system in place. Now is also a good time to look at integrating a scripting language. There are several areas of the game that will benefit from scripting. It's a toss up right now between Lua, Python, and PAWN (the Language Formerly Known as SMALL). I really love Python, but I'm leaning toward PAWN.
| |
| Family, Dogs, and Terrain Rendering | |
Posted - 10/23/2005 7:03:20 PM | Family
In addition to the mother-in-law, both of my wife's sisters wound up at our house for the weekend. One of them brought her husband and the other brought her daughter. Cute kid, but she's at that age where she just can't sit down for more than 2 minutes. The only way to keep her quiet was to let her on the computer to play flash games. Since my other box is sharing a KVM switch with the main one, I was stuck in front of the TV. No complaints, though. We drank, ate quite a bit (the eldest sister used to be a professional cook), and the mother gave the house a more thorough cleaning than it's had in a few months.
===================================================================
Dogs
My wife and I have two dogs, Charlie (a maltese) and Mini (a yorkshire terrier). Three years ago, Charlie had two cases of bladder stones with the space of a month, which resulted in two surgeries in the same time frame. He started showing symptoms again several weeks ago, but the vet we visited found no stones. Instead, he gave us some medicine and prescription food. Unfortunately, there really were stones. And because the vet didn't catch them then and because we didn't take Charlie back when the problem persisted (kept waiting for the medicine and the diet to work) the poor little guy developed a more serious problem called hydronephrosis - water in the kidney.
So a couple of days ago Charlie went under the knife for two procedures: one to remove the bladder stones and the other to remove his left kidney. He came out of it fine. The vet clinic we went to was the best I've ever seen in Seoul (huge staff including a radiologist, clean, modern equipment, open 24 hours, large space... much better than the little one man, dirty, closet sized shops with ancient equipment that are so common). The vet there said he has seen many cases of hydronephrosis, but Charlie's was the largest kidney he had ever seen. The little guy is still a bit wobbly, but he's eating like a champ and gaining his strength. We have to follow the vet's orders closely to prevent more problems with the remaining kidney in the future.
The bill amounted to about $900US. Not as bad as I had expected.
=================================================================
Terrain Rendering
So with all of that going on I haven't gotten as much work done as I would have liked. I do have the basic plumbing knocked up, and a quickly hacked together framework to get some prototyping done. Much of the framework will remain, though I need to restructure it a bit and flesh it out down the road. For now it serves the purpose.
In order to get something visible as soon as possible I'm going to be working on terrain rendering. Actually, font rendering will come first. But that's a 30 minute job. The terrain will be a bit more difficult. While I've got the game design fairly locked down, I haven't put as much thought into the tech side of things. Terrain will play an important role in the game.
One of the features that LoM has is a transition from turn-based strategy mode to real time tactical mode when units attack each other, or enter a dungeon, on the strategy map. This is nothing unusual in the genre, particularly these days (the Total War series, Rome: Total War in particular, has an outstanding tactical battle mode). I've decided not to include that feature in Game #1. I never liked the implementation in LoM, or its predecessor Lords of the Realm 2, because the battles were so small and always the same. On the other hand, I love the implementations in all of the Total War games. If I could implement a system on the scale of Total War, I would do so. But on my schedule and budget, I'm not even going to get something half as nice. I surely don't want anything like the LoM version. So real time battles are out for Game #1. In a future game perhaps (Game #3? - but that's getting a bit ahead of myself).
So the battles will be processed by the AI. The challenge for the player is in choosing the best leaders for each unit and in planning the overall strategy. The terrain plays a role both at the strategic level for the player, and at the tactical level for the AI. This means I need to be able to sample any point on the terrain and know exactly what type of terrain it is: grasslands, desert, forest, forested mountains vs. rocky mountains, and so on. Terrain height and slope need to be taken into consideration for line of site and ranged attack calculations. I don't need to drop into first or third person views. The game will be played from an overhead angle (with the angle adjustable within a fixed range) like most TBS and RTS games. So my goal is to select a terrain rendering technique that best matches these requirements.
The first thing that comes to my mind is a tile based system. But do I want to implement 'componentized' tiles (think of the tiles on a Rubik's Cube) or do I want to have interlocking tiles and LOD like the system described by Greg Snook in Game Programming Gems 2? To help visualize what I'm saying, when I say 'componentized' I'm picturing an effect like that seen in the Rollercoaster Tycoon terrain, where the tiles are discernable and terrain slopes are adjusted by manipulating the tile corners and edges. The interlocking tiles thing is another heightmap rendering technique, like Geomipmapping. Another possibility is to use premodelled terrain, with preset bounding boxes delineating the terrain types. Since the view will be at a fairly high level, that's not an impractical approach.
So this week will be spent on prototyping and choosing a terrain renderer. Hopefully I'll have some pics to show of the progress. And if anyone has any ideas on alternative terrain algorithms to look into (other than Geomipmapping, ROAM, and such that you'd normally use with a heightmap), I'd love to hear them.
| |
| Game #1 | |
Posted - 10/21/2005 8:27:31 AM | A surprise extended visit by my mother-in-law has sort of thrown a wrench into my development schedule for the next few days. I'm still getting work done, but not as much as I would like. But it's not so bad as I've a lot of time off work for a few days. So in the end it all averages out. It just always seems that family visits somehow coincide with my time off work. I wonder if my wife is passing info behind my back? Hmm.
===================================================================
Rather than bore you with details of loggers and display mode managers, I'll talk a bit about Game #1. It's a turn based strategy game inspired by games such as Lords of Magic. I've been playing LoM for several years and have always wanted to do a similar themed game. While I think it's a fantastic game, there are a few features I could do without and several I wish it had. Game #1 is a design evolved from that idea. The result is (on paper) a game that is quite different from LoM but still retains some elements LoM players will find familiar.
In Game #1 there are a number of clans and tribes sharing a small continent. For centuries they have cooperated, warred, and traded with each other. In recent decades adventurers from more civilized lands began to venture onto the continent, and were ultimately followed by settlers. Strange races with strange beasts in tow have established strongholds in coastal areas. Now, one foreign faction is poised to conquer all the peoples of the continent, both indigenous and foreign.
The player takes control of one of the factions (a clan, a tribe, or a foreign settlement). The ultimate goal is to defeat the conquering faction. The conquerers have more forces and more magic at the start of the game, but need some time to build up resources. The other factions need to build forces, magic, and resources. To win the game, the player will need to adopt one of or a combination of three strategies:
* diplomacy - ally with other factions to build strong coalition. This strategy requires the player to cooperate with other faction leaders. Breaking alliances could ulitmately cause the player to have several enemies and make for a quick end, but faction leaders are fickle and each has specific goals that may not coincide with those of the player.
* subjugation - force other factions to swear allegience. Doing so puts the faction under the player's control and makes the subjugated faction leader an 'heir' in case the player's leader is killed in combat.
* conquering - eliminate the leader(s) of another faction and capture their home base. Doing so will cause the conquered faction's remaining units to seek revenge (they will single mindedly try to destroy the player's faction leader), but will give the player access to more unit types and different types of magic.
Each strategy presents different challenges and benefits. Ultimately, I expect (more like hope) that most games will be somewhat of a mix of each strategy. If the gameplay allows the player to follow one strategy exclusively, there is a chance that players will gravitate to what they perceive as the 'easiest'. The solution is to balance the three strategies so that no one of them is easier than the other, but that's easier said than done, of course. My plan is to implement the faction leader AI such that following one strategy exclusively is difficult (never impossible). A fine line, but doable.
Originally I had intended this to be Game #2. The story and setting were quite different and tied in directly to what was to be Game #1. But the other game has more stringent art requirements and an even more complex AI (it's more of a Sim/RPG than a TBS). I expect it to be more expensive and take longer to develop. So I've swapped them and changed the story to reflect that. I'm rather bummed about it as I was attached the original story line (I spent quite some time refining it). The new story has been bubbling under the surface as Plan B for a while now. And while the gameplay remains the same, the story arc that ties the games together is quite different. That was to be one of my selling points of Game #2. Still can be, but it's just different now.
For those who must have pics, here's a shot from Lords of Magic Special Edition:
| |
| Thursday, October 20, 2005 |
| The Time Has Come | |
Posted - 10/20/2005 1:44:09 AM | For 2 years I have been toying around with a plan to get into the business of making games. During that time I've experimented with different languages, engines, IDEs and what not, trying to find the perfect fit for my ideas.
So now I'm done fooling around. I have two game ideas that I have fleshed out over the last couple of years. I intend to make both and sell them online. I'm going against conventional wisdom with my development. Each game will be built from the ground up with little more than platform and utility code shared between them. I'll also be using C, a language with which I have a long relationship and feel right at home with. The reason I am taking this route is that I just work better this way. I've gotten off to more than one false start in the last couple of years because I set out to design a reusable engine instead of focusing on what I really wanted to do - make games.
Two years of procrastanation has led to two solid and thourough design docs, which I've never had for any personal projects before. So that's a silver lining, I suppose. I've also got some programmer art I can get rolling with right away, along with other resources I've found around our wonderful Net. Work starts on the first game today, so some time in the next few months I'll be looking to contract out some content creation: models, textures, sound effects, and music. I've got a bit of a budget set aside for that purpose. Hopefully, I'll have enough money to create the game I see in my head.
Both games are niche. I'm not aiming at soccer moms. I think that market is busy enough without any contributions from me. I surely won't be quitting my day job anytime soon, but hopefully I'll be able to market enough to eventually break even on both games. I'm looking long term. These first two games will be used to try and develop a loyal user base. If I can accomplish that, I have a couple of different ideas on where to go.
On the business side of things, I still need to decide upon an official name and also decide where to do the paperwork. I live in Seoul, Korea, but I'm not so sure I want to start the business here. In the end, I may have no choice. But there are a few options I'm exploring.
I decided to make use of this Journal not only because I paid for it, but also because it's a great way to get feedback on ideas, design decisions, and general motivational comments when things are dragging. It's also a great way to focus. Plus with people watching me, there's no way I'm going to turn around and give up when I get bored or if I code myself into a corner!
| |
|
| S | M | T | W | T | F | S | | | | | | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | | | 22 | | 24 | 25 | | 27 | 28 | | 30 | 31 | | | | | |
OPTIONS
Track this Journal
ARCHIVES
June, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
