  The Framework | 
Posted - 6/13/2006 4:14:05 AM | I just ordered three game programming books to add to my ever growing collection - two on terrain rendering and one on game mathematics. I'm fairly obsessive about tech books, even books on tech I rarely use, so much so that I'm willing to pay $60 to have them shipped to Korea in 3 days. My shelves are overflowing and I have run out of space. I need to get a new bookcase soon. But all of these books together, game programming and otherwise, make for a great idea pool. I enjoy taking examples from books and adapting them to apply to my own projects.
The framework I put together is a hodge podge of ideas from several sources. At the heart of it is a game state system based on the one described by James Boer in Game Programming Gems 5. Combined with Java's dynamic class instantiation it provides a great deal of flexibility. It's a cinch to implement different game system tests during development.
Since games are resource intensive, a good resource system makes life much easier. The system I devised in the C version was not quite there. What I've done now takes ideas that I found on the internet and the book Game Audio Programming (again by James Boer). When I first saw the audio resource system Boer implemented in his book I thought it was fantastic. Extrapolating it to a more general case and adding pluggable loaders makes for a powerful system. As for the actual loading of resources, I took Adam Martin's modified version of Kevin Glass' generic loader and modified it a bit. Plugged into the Boer-based architecture, I have a highly configurable, easily manageable, generic loader that can load resources from local jar files, the internet, or the local filesystem. It's not yet optimized, but I'm not loading many resources yet to test it with.
When I get to the game itself I'm going to continue incorporating ideas from anywhere I get them. I know the big thing these days regarding game objects is composition vs. inheritance. I'll be implementing a component based system, probably based on articles from several of the GPG books with some ideas from Julian Gold's book, Object Oriented Game Development, thrown in for good measure.
It's amazing the number of game development resources we have these days. Ten years ago or so there wasn't much other than Andre LaMothe, Christopher Lampton, Diana Gruber, and a handful of amateur sites on the the net. Every book I buy, even if it covers a topic I'm already familiar with, gives me something new. Every author has a trick or two to share. Isn't it great?
| |
| Core Stuff | |
Posted - 6/8/2006 6:06:44 AM | I posted a few months back that I was trying to escape the resuable code menality with this project. I wanted to just knock out a game and move on to the next one. Even so, I found myself programming to abstract interfaces. Everything was modularized to the point that I could rip out a particular implementation and replace it with a new one easily. I could have replaced GLFW with SDL or Win32 without a hiccup (at least, until I forced myself to restructure things so that I was tightly-coupled to GLFW). I've become so used to that sort of design that I can't escape it even when I want to. It just comes out naturally.
Now that I'm back in Java land I'm coming at the project with the express goal of creating reusable code. I want to have a nice, easy to use foundation that I can use for Projects #2, #3 and onward. It's not just the components that are important to that end, but also the package organization. Right now I've got three distinct projects going: a collection of packages that would be useful in any Java project; a game lib that contains a framework and utility code useful for games; and finally the game project itself.
I'm also tackling the project with an eye for moddability. There are several aspects of the game I think it would be cool to allow users to mod. Java's dynamic nature gives me several options in this area.
I had gotten a little frustrated with the project a while back. I enjoy C to a certain extent, but there is a point where it becomes more of a headache than a thrill when using it. Right now, though, I'm really excited to be working on the game again. It's not necessarily because I'm using Java. I think I'd be happy even with assembly or Lisp just because I'm back at work again. Well, maybe not Lisp, but you get the idea.
| |
| New Beginnings | |
Posted - 6/7/2006 7:18:45 AM | I was happily working away on my game when I got a big surprise at the end of February - nearly all of my English classes cancelled the same week. I took advantage of the copious amounts of free time I suddenly had to head back home to Atlanta for about three weeks. My return to Korea involved seeking new, immediate sources of income. I picked up a couple of new classes along with a nifty little contract job.
A Korean startup signed me on to work on a Java project that was right up my alley - an interactive English tutor. The design called for several interesting features. There were mini-games designed to reinforce grammar, vocabulary, and listening comprehension. Lessons, categorized by skill level, could be downloaded from the company's servers. Each lesson was accompanied by a quiz and several lessons comprised a unit. Each unit had a test covering all of the material. An animated "counsellor" would make suggestions on where more focus was required, based on a user's quiz and test scores. Supplemental material could be downloaded automatically for those weak areas. Users could gather online for voice or video chat with each other and/or with native English speakers hired by the company. The native speakers could also be taken to one-on-one sessions for evaluation. Users that opted to could have their stats - taken from quiz, test and evaluation scores - posted to the company's website for a ranking system (sort of like a high score table). When I first was approached, I thought it sounded fantastic and jumped on board almost immediately.
To make a long story short, the company was a disaster waiting to happen. One thing after another fell apart. The design got a major overhaul twice after development had begun. The web app programmer quit suddenly and it took almost two weeks to replace him. Several other problems hampered progress in one way or another. But the nail that sealed the coffin shut was, I assume, a lack of investment.
When the managers contracted me they assured me that they had enough funding for the next year. Since my part with them was only for this one project, I wasn't too concerned. About two weeks ago, I got a phone call saying the project was cancelled. I would get paid for a full month, as per my contract, but it was done. It turns out, not only was the project cancelled, the company folded. I have seen small software companies start here in Korea on a small personal investment, with verbal promises from other investors to fund the company after seeing the final product, a prototype, or measureable progress on development rather than a business plan. I have also seen investors reneg on their agreements. I can only assume that's what happened here.
As part of my contract, I was forbidden to discuss the details of the project until it was completed. Even though it had been canned, I was still bound by the contract and could say nothing. Now that the company is no more, I can wag my tongue all I want. I think it's a fantastic concept. I had a lot of ideas that I would have incorporated had it been my project. If I had the money and the inclination, I'd try to implement a something similar myself. Such a product could make a killing in Korea. I mean, you could become wealthy practically overnight. English education and technology are huge here. Combining them would (and has) result in impressive synergy.
The good thing for me is that I'm back to work on Project #1. On that front, I took another look at my situation and decided to change gears. I've started over with Java. Ultimately that means that nearly four months worth of C code is in the trash, since most of it was plumbing. I'm fine with that, though. The switch to Java is going to pay off in the long run.
| |
|
| S | M | T | W | T | F | S | | | | | 1 | 2 | 3 | 4 | 5 | 6 | | | 9 | 10 | 11 | 12 | | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | |
OPTIONS
Track this Journal
ARCHIVES
June, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
