While working on my iPhone port of Gundown the other day, I had a sort of sudden "ooooh, I wonder if this would be cool" moment. That feature was a twist on my existing control style: what if the user held the device in portrait mode instead, and used a finger 'flick' motion to fire projectiles? And so, I created a quick branch on Git (because Git rocks my socks) to try a crude implementation of said feature.
It was indeed a hack, but it was simple enough to strip out the existing on-screen controls, allow any touch's X value to be the player's X position, and do a cheap exponentially-weighted sum of touch movement deltas to get a 'flick strength' value. Luckily I had written my underlying 2D engine and Gundown's own UI code to be highly resolution independent, so in general things worked just fine after switching to portrait mode.
?? (A quick hack to test the idea. Naturally, certain things (right) broke pretty hard.)
I really like it. The metric for determining flick strength still needs tons of fine tuning, but overall I really like the mechanic involved here. In particular, I'm really excited by how much more accessible Gundown could be, since firing projectiles with simple flicks of one's finger is orders of magnitude more intuitive than the comparatively complex on-screen controls that I had been using up until now. More hardcore gamers might object, but it's my understanding that the audience that the App Store reaches is far more casual and non-hardcore when it comes to gaming. In addition, the people who I have thus far cornered and coerced into trying out the game in both its original controls and these all remarked that flicking one's finger felt far more interactive.
All that said, some measure of re-design will need to be done to figure out how to accommodate this new mechanic. Perhaps something glitzier and faster paced is the way to go, rather than the slower controlled pace that the original PC version featured.
Once this week's assignments are all cleared up, we'll see. We'll see.
It's been a good long while since I've last posted here! For a development journal, it sure hasn't been giving the impression that I've been developing much, has it? Rest assured though, plenty has been going on since I last inscribed an entry. Plenty has been jostling and bouncing around in my head as well about this whole iPhone game development venture as well, so consider yourselves forewarned for a bit of a brain dump on the whole ordeal.
Mounds 'o Progress
First, the most interesting tidbit, and certainly the item most apt to appear in here: my progress on ?Gundown for iPhone?. Last time I left off, the game consisted of little more than firing shell rounds off at little green soldiers who died as messily as they did noisily.
Given that phrasing, then I suppose things haven't advanced much further since then, heh. A bunch of new enemies were implemented, such as motorcycles, helicopters, and different flavours of soldiers. The UI is also looking much more complete, and some sound effects are in as well now.
What does that amount to?
(Me getting shredded by some pretty unfair opposition.)
Enemies are now also grouped into formations, which can be created arbitrarily without much difficulty. It makes the battlefield look a little more orderly, and the player should be able to rest a little easier knowing that the enemies' tactics can be somewhat predicted.
(Three different formations that will appear in the early waves.)
Furthermore, unlike the original Gundown, the game is to be divided into Worlds, which are, in turn, divided into Waves. After beating each wave, a progress screen will be displayed that marks off completed levels while also giving the player a notion of what's next.
I especially like the more organic feel that the marker-like indicators give against the far more rigid and mechanical table and text.
Overall, the game is beginning to feel quite solid. Only a handful of significant tasks remain, such as a weapon upgrade system and menu, saving and loading, and win/lose conditions. Naturally, more enemies and backgrounds will need to be created as well. It's rather nice to start to see some light at the end of the tunnel though. This project was SUPPOSED to be a quick 1-2 month affair, after all. =P
Since I began working at a local iPhone start-up in Waterloo in January, things became very exciting. The world of mobile development (game development in particular) was suddenly wide-open to me, and I couldn't have been more charged about the possibilities.
Cost. So excited and optimistic, in fact, that I purchased an iPhone shortly after starting. No regrets there ? my old little Android-touting HTC Dream was a nifty device, but was short on horsepower. By the end of February, I had bought myself a MacBook Pro. Under a month later, I had purchased an Apple Developer License. And still, just a brief two months or so after that, I caved and coughed up the dough for a brand new iPad. It takes very little arithmetic to see that this adds up to quite a lovely little bit of spending. The saying of Apple's products being like gateway drugs to MORE Apple products is absolutely true. To a newcomer like myself, tasty tidbits like OS X, the iPhone OS, the App Store, and sleek UI everywhere was incredibly appealing. Especially coming from a Linux-heavy background, where aesthetics was not always a primary focus. Being a developer on Apple platforms is not cheap, but the App Store in particular does reach a staggeringly massive customer base.
Boxed in. Apple has created a rather pretty little world for us consumers to live in, should we invest in their hardware ? and thus, their software. The novelty does wear off though after living in this world for a few months, at least for me, and that's when Apple's closed system philosophy starts to wear on you. I've been using my laptop more or less as my primary computer, if only because it's the only computer that I can do my new line of game development on. Which implies that I've also been using Mac OS X as my primary operating system. As a somewhat passionate *nix user, using OS X has been.. weird. OS X is as sleek, sexy and highly aesthetically pleasing, but is painfully closed and non-customizable. And, of course, I have to use iTunes for all my iPhone/iPad interactions. And, of course, I can only develop using Apple's Xcode IDE. Oh, and thanks to a new clause in Apple's developer agreement, I'm not allowed to use any scripting languages (beyond Objective-C and Objective-C++) in any of my apps. Goodness, it's a little stifling in here.
Money and profit. This has bothered me the most. Game development was supposed to be a hobby for me. Something to do in my spare time for kicks and the sheer intellectual challenge involved. Since I have every intention of selling my iPhone games ? a guy needs to make back SOME of his investment in this pricy Apple hardware ? I now feel fueled by the allure of profit that lies at the end of my development process. This, instead of wanting to finish a game because I sincerely enjoy it and want to see the end result. I'm realizing now that I would much rather pursue my projects at my own pace, without the pressure of making sales. Not to mention developing in a direction that interests me, regardless of what potential consumers might wish to purchase. Money really muddies the waters, I'm finding. Perhaps future non-profit projects for the iPhone would better suit my MO.
And so, that's where I stand. I'm not thrilled presently, but I am also dead-set on finishing and releasing this iPhone version of Gundown as a finished product before attempting to do so; too many hours and dollars were poured into it thus far to see it reach anything less than completion.
Phew, thanks for following that twisty passage along, kind reader. More news on Gundown as it develops!
Lots and lots of progress since I've last posted, kind Journal Farers. Over the course of the last month I've been working hard on the actual 'game' aspect of what was previously naught but a 2D engine. Some of you may recall, foggily, that I mentioned an urge to recreate an old arcade shooter that I wrote many moons ago, Gundown. The rationale? A small, well-defined game that had a good degree of replayability and was simple enough that just about anybody could pick it up and play it.
I'm also going into my final week at my co-op placement at Enflick, which was an absolute blast. It's been such a huge boon working there on iPhone-related software, and then being able to apply that knowledge to my own gamedev endeavors. [smile]
Like I said, lots of progress has been made over the last month. I dare say that it actually looks and (sort of) feels like a game at this point, which is a wonderful sensation to behold after holding more than a bit of doubt about whether I was going to end up finishing this project. [grin]
Voila, a miniature flood of screenshots:
First on the list was setting up an actual terrain-like backdrop and drawing the tracks that the player's artillery contraption was to live on. The wonky "just for testing" particle effects are still wildy going on in the background.
I really wanted to start moving the darned player at this point. Dean drew me a pretty mortar/gun enplacement sort of device, so it was just a matter of lining up the sprite with the fixed track and drawing it. The left and right movement buttons were the second attempt at a movement system. The first idea was to use the iPhone's built-in accelerometer and have the player tilt the device left and right. I never actually ended up trying it yet, but I already loathe all of the other iPhone games that use the tilting mechanic and find it awkward and the controls very course. Not to mention any accelerometer-based control would make the game rather challenging to play in the car or especially on the subway. [grin]
The controls still felt awkward, so I spaced out the arrows a little. A simple button for charging up your shots was added on the right-hand side, which meant I was clearly angling for a "hold the phone sideways and have a thumb on either side" set of controls. From what I've seen this is pretty standard and it's also the orientation and hand positioning that feels most natural if the player intends to have any sort of fine degree of control.
Boom! Charging shots, firing explosive shells, explosion particle effects, and spurts of gory blood were all implemented in one fell swoop. This is kind of fun!
Another go at the control scheme. I really like this one, so I polished it up and made some prettier buttons for them, with a bit of outside help on the fire icon. The 'movement strip' on the right side sets the player's absolute position on the tracks (on a 1/2 scale), which makes it really easy to simple keep a thumb on the strip and just slide it back and forth to move the player where you'd like. I'm totally sold on this control style and haven't been able to conjure anything more intuitive.
The next challenge I wanted to address was figuring out how to indicate the current shot's charge to the player. A bar along the top? No, that'd occlude enemies. So would a bar along the left or right side. And there's no room along the bottom.
In the original Gundown game, the player would have a visible tracer beam extending from the artillery contraption for the first few levels, to get a feel for how long of a charge corresponds to how far of a firing distance. The tracer would vanish after level four or five, since I found that it made the game a little too easy to aim. I equate this to the similar tracer effect in Puzzle Bobble/Bust-a-Move.
I'm still undecided whether I want to just keep the tracer mechanic in place of a more formal charge bar, or just use it for the first few levels as before. I *really* don't know where to place a darned charge bar. Ideas are quite welcome. [grin]
Oh, and just for visual goodness, the tracer dot stays where you left it after you fire your shot, growing and fading out as the shell strikes it and explodes. Looks purty.
Next on the list is finishing the base UI, which includes finding a creative spot for the health bar and earned-cash counter. Beyond that? Lots and lots of enemies, a shop for upgrading your artillery contraption, and plenty of levels. Did I mention lots of enemies?
The last week or so has been quite productive. I'm not sure what sorts of details to launch into though. For me this is the umpteenth time writing a 2D game engine for my stuff, so the last month or so of development has been little more than 'wax on, wax off'; a sort of unconscious progression of code that I've written many times before.
New since my last entry is font rendering, a particle engine, playing audio, and support for drawing the game in both portrait and landscape orientations.
(Listen, you're way better off not asking just who 'Ken' is.)
This was chiefly made by porting my old text rendering code from Skirmish Online. Since that doesn't explain much, let me be a mite more specific. AngelCode produced a Bitmap Font Generator that produces, given various input parameters, a bitmap containing the desired character set, alongside a text file with the metrics of the various characters in the bitmap. The bitmap is loaded in as a texture on the iPhone, and the text file is parsed for the locations/dimensions/etc of each character. When text is to be drawn, a 2D quad is drawn for each letter of the string, using the texture coordinates from the font bitmap that correspond with the character that should appear. If memory serves, I believe I followed this NeHe tutorial on the subject way way back in the day.
(Particles and proper display in portrait and landscape.)
Using the accelerometer, it's a simple matter to determine whether the device is being held in portrait or landscape. The only real 'trick', since the SDL port has no notion of drawing in 'portrait' or 'landscape' is to execute a 2D transformation -- a rotation about the origin followed by a translation -- on the projection matrix whenever you wish to make the game appear to be in a different viewing angle.
The particle engine isn't all that fancy either, despite never failing to produce visually stimulating results. Spawned 'batches' of particles are all stored in a single array to minimize the number of OpenGL ES calls, not to mention they all share the same GL state data (colour, size, texture). I'm using point sprites for the rendering itself, which is thankfully supported natively on the iPhone hardware. I have no idea if the older devices support it though, so it's somewhat likely that I will need to implement a fallback implementation eventually.
Audio is harder to capture screenshots of, so you'll have to trust me that it is in fact present. It's a mite hacked together. And by that, I mean I more or less nabbed the audio example that was included with SDL and wrapped it up in my engine somewhat cleanly. There are a few other feasible options out there such as Finch or fiddling with SDL_Mixer or even getting dirty with raw OpenAL, but I'm more or less fine with the limitation of using simple WAV files for my sound effect needs. I will need to get around to figuring out how to leverage the hardware audio playback when it comes to playing game music though. Thank goodness there is a vast abundance of examples available. [smile]
Anyhow, that's the scoop. All of the major items on my wish list for a 2D engine are now satisfied, and it's finally time to sit down and write, say, a game. [grin]
First things first: I finally took the plunge and purchased an Apple Developer License under my name. Many of you probably wouldn't make a face over having to drop a mere hundred dollars, but for me the purchase signified a commitment to following this iPhone development adventure through all of the way, and to work hard to get our masterpieces [subjective] up and onto the glittering promised land that is the App Store.
The main (or least the immediate) upshot of getting this license is that I can now sign my code and have it run on devices. For me, my only test device is my own personal iPhone, which is just fine with me! I can't express how cool it was to see my transparent rotating sprite showing up on my own phone -- after a lengthy bureaucratic process of course. Still, it was a huge motivational leap for me, and had the added bonus that I could essentially whip out my phone on a whim during the day and show my friends and co-workers my progress on my game literally as I developed it. Nifty!
Speaking of my delving into iPhone development..
It might seem a little soon to be doing so, but I will be delivering a short-ish public presentation at my uni (University of Waterloo) for the UW Game Development Club about my recent foray into iPhone game development with SDL. I'll be talking about the highlights of my experiences, going over some history and details about the iPhoneOS platform, what is needed to get started in writing games for the platform, and lunge into several runnable examples showcasing 2D and 3D graphics basics.
We're throwing around the idea of video recording the presentation, in which case I'd gladly toss it up on YouTube for public consumption, but that will be entirely dependent on one of the execs finding a camera in time. Don't hold your breath. [grin]
Despite being a rather busy humanoid lately, I've still been finding time here and there to slowly progress further on my 2D engine built atop the iPhone-flavoured SDL library. Why, I can almost envision me actually using it to *make* a darned game one of these days! =P
I implemented an entity management system first, which in English roughly translates to: I can toss lots of different types of 'things' (which for now are 2D sprites with different drawing logic and updating logic) at my game in a rather high-level fashion, and have the game more or less just 'take care of it'. This isn't a new concept to anyone here who has written any semblance of a game, of course. [smile]
A nice interface to the two input methods: the touch screen and the accelerometer. The former simply detects touch-begin, touch-moved, and touch-ended events, each with an associated unique index, and propagates each of the three event types to all registered 'touch listener' objects. In the context of my little 'test app', this is a ship sprite that flies itself toward the nearest active touch. The accelerometer is treated as a 3-axis joystick by SDL, which makes it simple enough to query for values. Moving the iPhone to various angles results in the aforementioned ship slowly sliding downward along the current vector of gravity.
Sprite animation. The below sprites are happily marching in a pretty animate fashion down the screen. Into oblivion, soon, once one can fire weapons at them. [smile]
(Trying to pilot my ship to charge the advancing infantry head-on via the touch screen.)
I'm getting pretty excited at this point, since only a few more key system, like a particle engine, font rendering, and playing audio remain until I can actually begin making some games!
Progress is moving along smoothly for my higher-level 2D engine wrapper atop SDL. Despite the iPhone port being reputedly at only alpha, the functionality available, I believe, is totally sufficient to knock out most any sort of 2D or 3D game as long as it doesn't strive to use *too* much of the SDL API. The core elements are present: creating a window, receiving input and quit events, loading images, and leveraging OpenGL ES.
For convenience and brevity sake, a montage:
Recent development work, as you can now see, has merely been about loading images, creating OpenGL textures for them, plopping them into a 'Resource Manager' helper class, and then using a variety of state changes to give a textured quad, "sprite", different effects like rotation, scaling, blending, and (not shown) colour tinting.
If you're toying with this sort of thing yourself, a key thing to remember is that after loading the original sprite bitmap onto an SDL_Surface*, you'll need to: a) use SDL_SetColorKey() if you'd like transparency, and b) re-blit the surface to another SDL_Surface* that is of the same pixel format as the iPhone screen. Okay, the last step isn't strictly necessary since at the end of the day you're just handing off pixels to OpenGL, but it at least lets your texture creation code treat all textures uniformly if they aren't already all the same pixel format.
Performance? Who knows?
Yesterday evening I navigated my browser to Apple's developer website and took the final step of 'the plunge': I purchased the $100 iPhone developer license so that I can actually begin testing the darned code on my iPhone.
In all of my reading on iPhone development thus far, one particular fact has been rather ubiquitous: don't you *dare* expect app speeds on the device to be anywhere *near* the iPhone Simulator speeds. A fair rule of thumb, methinks. But to what order of magnitude? My small demo above runs at ~200 FPS on my MacBook Pro, but I have no clue what that will translate to on an actual consumer device. If luck is with me, the performance drop won't be too bad. I'd really rather not have to burn more hours than I need to optimizing all of my OpenGL state calls and the like. [grin]
Next up is more inglorious engine-writing, namely an entity management system to easily propagate updates, draw calls, and collision detection across all of the entities (players, enemies, items, etc.) in a given scene. I've more or less been following the same design style as the 2D engine I wrote beneath Skirmish Online, albeit in Objective-C instead of Java. It's not exciting work**, but the idea of peeking over some random Joe's shoulder on the bus one day and seeing him playing one of my games on his iPod Touch is too cool of a notion to pass up. =)
** That's a lie -- I haven't been this pumped writing engine code since I first wrote Skirmish. =P
For the last few months, I have had a rather unique opportunity. Certainly not something to be considered a unique opportunity by all, but I think that I make something of a special case. As I mentioned in my last entry, I have been doing my present co-op term with a small start-up company, Enflick, who specializes in social networking apps for the iPhone and iPod Touch. Anyways, this has given me an opportunity that I've never really taken for myself before: working with the Mac OS X operating system.
Hearing that, you'll likely argue that this isn't a very special opportunity at all. Especially in a university environment like where I'm at, where our Math/Computer Science building has several labs chock-full of iMac computers. As a computer user who first used DOS and then Windows, I was positively entranced when I learned about the wonder-filled world that was Linux. Free software as far as the eye could see, boundless customization and freedom, and a vibrant community of developers. Macs were still, "oh, right, a Mac. So what? They don't offer me anything exciting". Given that Macs were still making the move away from the PowerPC chipset, maybe I was correct at the time. The point is that I never really sat down and gave the operating system a thorough looking-through. Much like the other two 'big' operating systems, Windows and Linux, Mac also has a variety of negative connotations associated to it from its various critics.
Working at Enflick gave me a chance to work with three things that were very foreign to me: the iPhone, Objective-C, and the Mac OS X operating system. In fact, I was most drawn to the original job posting *because* the notion of working with a set of new technologies that I had nearly nil experience with was a rather exciting one.
Okay then, so what? I've used OS X as (more or less) my primary operating system for the last two months, learned some Objective-C, and have done some iPhone development -- big deal. And you're right, it isn't a big deal. I'm still out to lunch as to what I think about Objective-C (that's a post for another day), but I really developed a nice feeling whilst using OS X.
Why OS X is a *very* attractive option.
I don't claim to be an expert, but I do know that OS X is running on a *very* Unix-like architecture underneath the sleekly streamlined user interface. I loved my time working with Linux and the variety of GNU and/or BSD (depending on the distro I had installed at the time) tools, the slew of free software, and just the general "Unix way" philosophy of doing things. Luckily I'm no purist in such ideals though, since OS X (and certainly not Apple's business practices) are not, but to me I really got an incredibly pleasant sensation of feeling like I was running a Linux-like system with my two main irks cleared up: a) device drivers just *worked*, and b) a set of streamlined, polished, fully featured applications atop the command line interface that also just *work*. There are other reasons, but those two really sold me over. Not to mention just about all of my favourite Linux software runs just fine on Mac either natively or via its X11 server. Oh, and it is rather perfect for my current adventures in iPhone game development. [smile]
Knowing all of that, and having had been doing some cautious budgeting for next several months, I buckled down and purchased myself a shiny new MacBook Pro.
I only unpackaged it this evening, but thus far -- including scribbling out this journal entry -- it has been rather pleasant. The hardware has made everything lightning fast and responsive, and the physical laptop itself is incredibly sleek. Even better yet, the 13" screen is plenty large enough to get into some serious development, which I could *not* say the same about for my old Toshiba 10" netbook. [sad]
This entry felt notoriously one-sided, but I'm still quite excited about having another set of technology to tinker and experiment with. Don't worry, I haven't fallen to the depths of fanboy-ism just yet. [grin]
I had originally begun scrawling out a very different, far more long-winded entry that dug rather deeply into the nitty gritty details of what I had been up to for the last several months as well as where I am now. However, it struck me that it would likely be much more interesting for everybody if I stuck to the cliff notes version of my tale for the time being.
The short of it is the usual student/hobbyist game developer tale, tempered with woe and time mis-management: "school, co-op, and even a semblance of a social life have been consuming my waking hours, and have been doing a darned good job at it". That would be the typical, "oh, have pity upon me!" sort of excuse, and it's not really one that I stand for.
A more fair and accurate depiction of the last several months is: "yes, I have certainly been busy, but the real thing preventing me from working on game development is myself". What began as, "whew, these courses are tough, let's put gamedev on hold for a week or two" grew into a month or two, and eventually grew into several more. However, game development being something rather near and dear to my heart, has nevertheless been on my mind this whole time, just something that I had somehow conditioned myself not to bother acting on.
It's such an odd and disturbing realization when you sit down and think, "golly, I honestly cannot remember the last time I sat down and put an honest few hours into working on a game". That might not be a big deal to everybody, but after completing several [decent] games over the course of several years, and having been used to almost always spending chunks of free time coding, it's been really *weird* not having it integrating into my weekly regimen. I want to make more games, darnit!
Into a challenging marketplace.
Presently, I am on my fifth co-op term along my route to graduating from the U of Waterloo's Computer Science program. I have been working for a small start-up company in Waterloo called Enflick, who specialize in "social networking" apps for the iPhone and iPod Touch.
Without jumping into too many details -- and evading NDA-induced unpleasantness -- it's sufficed to just say that I've had a most wonderful opportunity to do a lot of work with Objective-C, iPhone app development, as well as finally learning my way around the Mac OS X operating system.
Given that, I'll pose the question that I'm sure hundreds of wide-eyed developers have asked themselves since the iPhone's inception: "gosh, wouldn't it be well if I wrote a game or two for the iPhone?". Sounds too perfect, right? I have full access to the Macs at my university, own an iPhone, have two months of experience in working with Objective-C and Xcode, and experienced folks at my place of work who have no qualms with answering any development-related questions I might have. Plus, it'd sure be nice if I could accrue some profit from the ordeal. The App Store is a pretty saturated market though, so I'm not holding my breath on that last point.
Point of entry.
Anyways, some kindly gent during a previous Summer of Code wrote a very good beginning to a port of SDL for the iPhone. It supports 2D and 3D (via OpenGL ES) rendering, accelerometer support, multi-touch support, and does so all within the same interface of SDL that I am rather familiar with. Perfect! That lets me simply work in pure C and use a library I already know, as opposed to getting to heavily immersed in Apple's development dogma.
Right now, it seems like my best option is to test the waters. I want to get a game or two out there just to gauge how the market reacts. How can I get something out there fairly quickly? Let's port some of my existing games. That will allow me to evade most of the usual necessary design and graphics work, and simply focus on writing the code and polishing out whatever rough edges were left over the first time through. If I manage to make back my initial investment for the Apple Developer License, that would be perfect.
For simplicity's sake, I'd really like to get the ball rolling with Gundown, a small, fairly addictive game that takes a bit of a twist on the typical arcade shooter. I really think that it would lend itself nicely to accelerometer controls, and is small enough scope-wise that it shouldn't take long to port.
Meager but promising beginnings.
It feels really nice to have something "on the table" again after so long -- especially since I get the opportunity to work on an embedded system. More than that, the chance to revisit the original concept and design for Gundown, and being able to tweak and improve gameplay and artwork and polish is a really enticing notion.
Thanks for reading, and expect more on this story as it develops!
I can't believe how guilty I am of not posting for so long, but my current school term (Sept-Dec) has kept me unbelievably busy. Final exams are currently in the process of being written -- Japanese 101 is this afternoon! -- so I feel like I have a mite of space to just breath in and try to get myself back in the swing of this 'game development' thing.
EM Adventures: 24-Hour Game
I realized today that I never uploaded (or even really mentioned) a little 24-hour game I wrote for a competition at my uni a year ago, called Electromagnetic Adventures. It's a sort of physics-based coffee break calibre puzzle game with ten or so levels, using the nifty Chipmunk physics library. I wrote up an entry for it on my website, so give it a look-see if you feel like doing some light gaming for ten or fifteen minutes. Naturally, I've also included an attention-catching screenshot: [smile]
It probably wasn't widely noticed that the Skirmish Online website has been down for the last month or so -- my yearly hosting renewel at Dream Host was coming up, and I wasn't in the mindset to donate 120 dollars of my money into them. Instead, me and a roommate are splitting on some VPS hosting (at VPS Ville, if curious). I also need to renew the domain, so I hope to get that all back up very soon.
My current tasks for Skirmish are a little all over the place, ranging from implementing the user/host command parser (for commands like quit, join-team, ban, kick, change-map, etc.), to optimizing the outlines on text drawing, to migrating from SVN to Mercurial, to various fixes on the Master Server. I'm really really excited to be motivated and working on Skirmish again, so I will be posting when I have the website and related venues back online.
(And don't forget to check out Aardvajk's highly stylish Squishy intro!)
Good evening Journal Land. A short but sweet entry tonight, mentioning a few recent developments on Cyberspawn. Most notable is the (final!) implementation of sliding doors, which are currently functioning on a 'mostly working' basis. I say mostly working because all doors can only slide open -- an obvious limitation -- and there is no interference detection, meaning the door will close fully even if there are other props (or the player!) in its path, leading to some weird behavior. Still, it's a start.
The other development is the beginnings of a model for a autonomous bot which will make appearances throughout the game, currently titled the, "Nant Bot". Whatever that means. This is only the first pass on it, so there is only a model to show thus far; textures and animations will come somewhere down the line. This is the general appearance I'd like, although I'm not sure if the in-game shot represents the scale I'd like for the bot; perhaps a little smaller and it'd look less intimidating. [grin]
Another month, another entry. It certainly seems like my rate of posting has decreased, hasn't it?
My co-op work is as busy as ever with a pending beta release at the end of the week, and a recently developing relationship have a way of draining one's free time. Still, I'm determined to fit more of my time into game development once more.
I'll be keeping this brief, since I've been wracked with what I believe to be the flu for the last few days. On the upside, it's given me a chance to ponder about some gamedev thoughts between bouts of consciousness.
Oh, and keep the excellent development progress coming you guys -- you know who you are. [grin] Good night.
New since my last entry is the ability to pick up and throw away items, as well as a fairly attractive marble floor texture. Presently the only manipulatable item in the game is the Nuratech Pistol, so that is showcased in the above video. As you'll be able to see, the physics is entirely based around axis-aligned bounding boxes (AABBs), but looks reasonably decent. I'm feeling a little torn as to whether I want to take a stab at integrating a physics library. Anybody have any experience they'd like to toss in about that?
That's all for now. Hopefully coming soon: working doors. [smile]
Has it indeed been an entire month since my last update, dear journal?
So it has.
This month has been an utter whirlwind for me, in terms of both work and that elusive real life. Nevertheless, I've still been pumping in some work into Cyberspawn here and there whenever I can. The most notable additions lately have been in the form of content; models, textures, and so forth. The engine is far enough along now that I'm getting interested in starting to make the game look less threadbare overall.
The current state of things is something like this:
A very refreshing change of scenery from the strange cold surroundings of old. Texture quality still isn't up to par with my ideals, but I'm fond of the new hanging light and door models/meshes that you can see in this shot. Maybe a painting or two to hang on the walls here would give it a little more spruce. We'll see. [smile]
Over the course of Cyberspawn's development, I've been slowly trying to create more and more models in order to both improve my proficiency in the 3D arts, as well as fuel the natural demand for content that any game requires. I present: a potted plant.
A notable improvement is that I've now figured out how to use 'texture baking', which will go a long way in improving future models. Simply said, texture baking is the technique of applying numerous lighting and material effects to an object within a 3D editor -- Blender, in this case -- and 'baking' those effects onto a texture, which can then be applied to the object in real-time inside of the game. The shot on the left shows the baked model with only ambient occlusion calculated. This effect alone adds a great deal of subtle realism in the lighting.
The other significant feature implemented is a secondary lightmap, termed the 'actor lightmap' for the time being. This lightmap is generated across the non-solid areas of the level, and functions as a way to apply shading to actors that move around the level in and out of the path of lights. The player's weapon overlay also is affected by this, and can be seen (subtly) in the second screenshot.
It's easy to get caught up in small things like these, but I've learned that it goes a really long way in making a game look and feel better in the end. Probably the biggest lesson I've learned in computer graphics (and indeed game development in general) is the huge difference the accumulation of those subtle additions make.
So, once again I am back doing my co-op term at Sony Creative Software, a subsidiary of Sony way way off in the forgotten Canadian city of Waterloo. Tomorrow will be the last day of my first week, and quite a busy week it has been! The product we are developing is called Media Go, a media management application somewhat comparable to the famed iTunes. It's to be shipped with Sony Ericsson phones world wide in the very near future.
The specifics of my current task are of course NDA'd, but I can at least say that it's an interesting mix of application and UI programming. I'm not really a UI developer at heart, so while it's a bit of a strained relationship between me and my code, I'm managing. Working on the massive codebase they have never fails to motivate me to work on my own game projects. [smile]
And on that note...
The most recent items have been improving collisions and getting the inventory/item groundwork underway.
Collisions with the world work wonderfully, but collisions with entities was only sort of working. I had to manually define the sizes of the collision bounding boxes within each entity's definition file, and rotating the entities would bork up their bounding boxes. It was only a matter of adding some code into the 3DS model loading code to have it determine the minimum bounding box for the model.
Since I had decided on keeping collision logic simple, I wanted to stay with axis-aligned bounding boxes. This meant that when an entity was rotated (ie. rotating a desk 45 degrees in the map editor) it needed to have its bounding box recalculated to reflect its new (larger) size. This is accomplished by using rotating the four points of the bounding box (either top or bottom; doesn't matter since rotations are on the Y axis), and then finding the bounding box that contained those four rotated points. It can be kind of nasty though, since 45 degree rotations on long models (like desks) feel larger than they should. Short of rejeffing the physics code to support more complicated collisions, I don't have any other nice options.
The other major addition was the player's ability to highlight a nearby item or object by looking at it. The effect of this draws a simple little stippled bounding box effect (reminiscent of Deus Ex 1 and 2) and displays the item's name beneath the crosshair. Next, of course, is the inventory framework behind it that lets the player legitimately pick up that item. [grin]
After a nice visit back home, I'm back in Waterloo and getting ready to start my next co-op work term this Monday. I'll be returning to Sony Creative Software, a smallish subsidiary of Sony that focuses on multimedia related apps. Heard of Media Go? [Probably not, but] That's what I'll be working on once again this term, striving to boost the overall awesomeness up another few notches. [grin]
As for my own projects, my efforts have been focused on more adventures in 3D modeling. More specifically, trying to create a decent handgun for Cyberspawn so that I have some material with which to test items, inventory, and of course weapons fire.
For the curious, the hand was most certainly the harder of the two models. In particular, trying to rig up the bones and wrap the fingers around the gun model in a way that looked good was especially challenging. I'm not 100% satisfied yet, and I will almost certainly redo the hand and its grip on the gun, but it's a passing grade for the time being.
Between studying for final exams and other diversions (such as the lovely weather), I was in the right mood to sit down tonight and produce a few more pieces of art for my little isometric game project. A couple of new walls (with and without a light), and a grainy wooden floor.
I'm still generating the wall/floor images using Blender, and then using KolourPaint to chop that final image up nicely and do any final touch-ups. The overall process for creating a new tile still feels long and tedious, so I'm becoming very keen on writing some scripts to automate some aspects.
All of the game content works through a definitions system, which simply reads a text file containing text like the following:
[TileDef] name=Brown Wall Lit type=Wall image=wall_brown_lit base-x=29 # x/y location in image of where the base of the tile is base-y=86 offset-x=16 # x/y/z offset in world coordinates of the tile offset-y=0 offset-z=4 flip=true index=4
Most of it is probably self-explanatory, but the jist is that the game will read in these tile definitions from the file and create an internal representation. The base x/y specifies where in image coordinates the centre of the 3D object's base is. This is used to ensure that the image is drawn in the proper place. The offset x/y/z are in world coordinates and specify an offset for the tile or object. For example, an object like a mounted picture frame might want to be offset upwards in order to appear to be hanging on a wall. The other item of interest, 'flip', denotes whether the game should generate a second entry at load-time containing info for a flipped copy of this tile. Since walls can be aligned in one of two ways (look at the screenshot carefully..), this prevents me from making flipped copies of every wall by hand. I'm not totally satisfied with my solution to the flipping problem, but it works for now.
As I've been creating tiles, I'm getting a better and better feel for where I want the art direction to go. Heavy influenced by the Crusader games and System Shock, I'm interested in taking a mix of industrial, mechanical, and office-like decor. Perhaps the game will take place in some sort of large mysterious complex.
Finally, for anyone curious, the last screenshot I took of my workspace for the project looks something like this:
Just the other day I received my copy of "Advanced Game Programming: A GameDev.Net Collection" from the publishers. Several months ago John Hattan approached me with interest in adopting my metaballs article into their book. Naturally I was quite thrilled just to be able to see my name in print, but they ended up also offering a small but generous work-for-hire payment as well. Thanks guys for making me a part of this!
A Very Isometric Journey
My initial burst of interest in Cyberspawn has once again dwindled since I finished implementing lightmaps. My main quip was that making content that looked good in-game was very difficult, since creating a in-game model is a matter of modelling the object, creating a texture/mesh for it, applying it properly onto the object, and then trying to get it to look as nice as it did in the editor in the game engine. Given my inexperience in artistic endeavors in general, it just felt too far beyond my abilities.
However, I was still really keen to expand my artistic horizons. I had been using Blender all this time, and I've been getting pretty comfortable with it. Remembering all of those wonderful games like Diablo, Fallout, or the Crusader series, I considered the (hopefully) simpler task of producing pre-rendered isometric art for a 2D game instead. So far, so good; I have the basics of the art and the engine started.
The floor and wall didn't take too long to make. The hardest part by far was getting the camera set up at a consistent and correct isometric angle, generating the renders in a size consistent with world scale, and then adding final touches to the final renders to make them interlock with eachother in an aesthetically-pleasing manner. I really like the way it turned out, and am confident that I can maintain an art style of this level for the rest of the needed content.
My main beef with my initial results was that many of the shadows looked kind of blocky, which killed a lot of potential realism (see previous entry). I realized this was because of two factors: the lumels (the 'pixels' of the lightmap texture) were large, and that if the change in brightness between two adjascent lumels is large enough, the blocks will be visible to the viewer. Therefor, my options were either to make the lumels smaller, or decrease the change in brightness between adjascent lumels.
Presently the entire lightmap for a level is stored on one 256x256 texture, and each lumel is 8x8 units. To give you an idea of relativeness, each tile in the world is 32x32 units. I really like how small this keeps the memory footprint, so I didn't want to change the lumel size. Instead, I opted to apply a smoothening algorithm to reduce the sudden changes in brightness between lumels. This was a little tricky, since a lightmap for a level might look something like this:
As you can see, there is no real sense of "adjascency", since no planar relationship between faces is preserved in the final lightmap. This means a simple smoothening algorithm would cause artifacts near the edges, where two faces meet, since the smoothening is done independently from each adjascent edge. And, well, this problem is apparent in some of the screenshots if you look for it. I'll keep an open mind about solving the problem, but failing that, I intend to work around it as best I can. It's an inherently tricky problem to solve, given how the data is presently managed.
Without further ado, here are some shots which showcase the aforementioned features:
Other additions include a desk model, a better wood texture, and a coffee-coloured tile texture. Not AAA quality, but it's a level of quality that I'm mostly satisfied with for the project. My current toolset is GIMP, Blender, and KolourPaint; I'm hoping to improve my art as I continuously get more practice.
It's been far too long of a while since I've written here! I feel like I need to get my writing muscles back into shape, so please excuse me if this first entry is a little rough around the edges. [smile]
Cyberspawn? What's that?
A rather long while back, nearly a year ago, I wrote about a small scale first-person shooter project I had undertaken. At that time it was using a renderer I had implemented in software, and it looked sort of groovy:
I didn't really discuss it, but the basic premise for the game was to blur a little of the lines between cyberpunk greats such as Shadowrun and Deus Ex. The player was to take on the role of an amnesiac freelancer in a dangerous city, trying to determine what went wrong with his last job, and who he has to eliminate to set things straight. The story might not be entirely original, but it's general enough that I would have a ton of room for artistic maneuvering. My goal was to spruce the storyline aspect up, with elements like Morrowind-styled conversations, and flexible inventory/implant management. Things got busy with Skirmish again, however, so Cyberspawn went to the backburner.
Recently motivated to try and get Cyberspawn going again, I loaded up the ancient code, blew off some proverbial dust, and went to it. My first order of business was to add some more level features. Two such things were sloped floors and stairs, which I'm thrilled about [grin]. I also changed the rendering system; I broke it down by making each level a list of sectors, and each sector a list of faces. Each face could then be rendered, with all of the pre-computation (there's a bunch of sector-touching-adjascent-sector logic to make things look right) done on boot-up.
Anyways, the most important part was when I had the level essentially broken down into a big list of faces. Because of the nature of how it works, this put me in a position where a certain feature, lightmapping, would not be a stretch to implement. I won't go into the details of how lightmapping works in this post, but can discuss it later if there is any interest.
The important part is that lightmapping is something I have wanted to implement for a *long* time. Lighting is such a HUGE part of making a 3D game look proper; levels almost look freakishly boring without it. For example, these shots look boring, right?
Sprinkle on some lightmaps -- even just these basic ones -- and things start to look much prettier. [smile]
The current lighting model is very simple. Quadratic fall-off for light attenuation, and collision detection with the map to create shadows. Radiosity is still out of reach for the moment, but it is yet to be seen whether this model is good enough for the game.
Now, armed with features like stairs and lightmaps, I am very eager to start working on the actual game. This will mean teaching myself to model better, as well as use tools like GIMP more effectively to create game art. While I've always leaned heavily on my artistic comrade, Dean, for artistic assistance, I'm very excited to tackle the game art on my own ground, and try and learn how to create an immersive experience from both sides: the code and the paintbrush. [grin]
Stay tuned for more updates.
(PS. I have erected a small development gallery for Cyberspawn, for anyone interested in gleaning the history of its progression.)
I was first tempted to call this entry, "Why I loath Java", but I think I've calmed down enough to go on about this in a more civilized manner. [smile] I'll intersperse a few screenshots on the left and right margins to make things feel more interesting.
An Evening Tale: A "Heap" of Trouble
For the longest time -- and only on certain people's systems -- there would be this strange occurrance whereas the player would experience a sudden 'freeze' or pause in gameplay for a split second, every few seconds. This did not seem to lower the framerate or updates-per-second, and happened uniformly at some same rate. However, on other systems this would happen similarly, but the effect would vanish after several seconds. To further mystify this problem, it would happen to me if I ran Skirmish via WebStart, but NOT if I ran it from my IDE. Tres bizarre!
This being initially back in October or November, and I had been baffled for a while. I had first begun profiling in order to try and determine what portion of the code was causing this behavior. At first I suspected that the garbage collector was at fault, and that it must be complaining because I was creating so many 'Vector2's (a 2d vector helper class) all over my code in places like rendering and elsewhere. I somehow convinced myself that this was the root of the problem, and wrote a system on top of the Vector2 class that would maintain a pool of reusable objects to keep heap size down. The details are fuzzy, but I must have convinced myself that it worked, somehow, and carried on with life.
Not long after, my good friend Dean told me that he still regularly experienced this "pulse lag" bug, as he so aptly named it. I had not realized this, since I was still always running the darn game from my IDE! It turns out that the bug was still present, although only a handful of the testers would experience it. Oh man! Weird!
It was at that point that I decided to give it another go at the profiling, and figure out what the heck was going really going on. So, I did. This time, the source of the time-wasting looked to be the networking. I ran a few (admittedly VERY basic) tests to see if this was the case, and indeed it did seem that the raw network calls (recv and send) were sucking up a lot of CPU time because they were blocking the main thread from doing other useful things like rendering. This surely must be the root of this problem! So, I went off on a mini-project to make the entire networking system multithreaded. Several challenging weeks and a dozen or two hours later, that was implemented. Swell.
Not swell. The testers that had the "pulse lag" bug were still experiencing it in its full glory. However, most people noted that the framerate had increased by a decent margin. I once again had not fixed the bug, but Skirmish became a little faster through my efforts, and I learned a lot about concurrency.
Once again, today, I took a stab at figuring out where the bottleneck was. It was the strangest thing. It seemed almost like every time I cleaned up some code, it jumped to a new spot. Again and again. Puzzled, I took a moment to stop and take a few steps back and think about this thing. Surely these few areas of code were not of pinnacle efficiency, but they don't account for this kind of periodic freezing to occur. The only thing that would make sense would have to be..
..garbage collection. Or, more specifically, the heap size allocated by the Java virtual machine. In some ways, I am to blame for not allocating and handling objects a little more responsibly, but the VM was vomitting every few seconds because the heap was just too small. And, in a very anti-climatic ending, I simply increased the heap size for the VM and everything was well. Testers confirmed that the elusive bug was nowhere to be seen.
Is that a truly tale of victory? Or did I just evade my own inefficiencies by increasing the heap size? I'm still not sure whether I feel satisfied or disappointed. I was really expecting a grand victory, full of music, dance, and perhaps a large feast. Still, I won't complain. It works, goshdarnit. It works. [smile]
The Other Enigma: Windows Vista
On a equally pleasing front: Windows Vista is now able to run Skirmish properly.
If this sounds like news, then you probably weren't aware of this problem. To be honest, it wasn't something that I wanted to advertise. [smile]
For the longest time, Vista users have been unable to connect to the master server. It would simply outright refuse to connect. Boggling, I know! Unfortunately none of the Vista testers were developers, so they didn't really understand how to get me the system log that the game would produce. Fortunately, I had my roommate around today, who has a Vista partition, to get one to me.
Much to my confusion, the line it produced upon connecting was an exception: "Invalid argument: sun.nio.ch.Net.setIntOption". Huh? I don't claim to be a Java guru, but I had never seen or heard of this setting before. My instinct was that one of the many integer-based parameters that standard network sockets accept wasn't appreciated by Vista.
After some searching, the closest thing I found to a satisfactory answer was on Marlon Pierce's blog, although it's not quite to the same details as my problem. Not being a big Windows fan, part of me wants to just say, "Oh, right, Vista stinks". But that kind of grumbling won't solve the problem.
Anyways, it turns out Vista didn't like that I was using the TCP_NODELAY socket parameter when connecting to the master server. I'm still a little mystified about why Vista doesn't seem to support this parameter, unless Vista does non-blocking sockets in some other way.
Once again, this fixed the problem. Vista users could now connect just fine. Ironically, since my previous problem required me to implement concurrency to networking, it was not a problem that the socket was not non-blocking. Again, not a satisfying victory. Oh well. [grin]
Despite my ironic tone, I am actually very happy about the outcomes. Two of my longest-standing bugs are finally quashed, the the game has become a little more playable and stable.
Huge thanks go out to Patrik, my roommate, for all of his time helping me trace these bugs down, and of course to the kind folks who helped me test tonight. Yeah, you know who you are. [smile]
It's that time of the year again! Mid-February to Mid-March is always ripe with midterms, which means two things: Reading Week and studying. I think that Reading Week is more well-known in the US as "Spring Break". Whatever. [grin]
Tomorrow is my Intermediate German midterm, which I have been furiously cramming vocabulary into my head for for the last little while. I feel comfortable with the material we've covered though, so it should be just fine.
Next week is my Reading Week, which means a whole week's worth of time to study and otherwise spend time. I only have two midterms post Reading Week, so it won't be too intense. That means plenty of time for adventures and, of course, Skirmish Online development.
The last couple of weeks of development have been spent implementing concurrency into the game. More specifically, multi-threading the networking portions of the game. I had noted that there were occasional slowdowns in gameplay due to some (unavoidable) blocking in the UDP sockets. This was a big problem for people on lower-end hardware who got poor framerates already. We had already been studying threading and mutual exclusion techniques in my Operating Systems class this term, so I felt sufficiently knowledgeable to tackle the task.
I'd like to talk about the problems and traps I adventured through in my next post, since I need some precious sleep for tomorrow's midterm. [smile]
Good evening, Journal Land. Has it really been a whole month since I last posted? Time has been flying for me since the new year got underway. University has (as usual) been a flurry of new and interesting material. [smile]
Stallman talks freedom
Last Thursday we were visited by the illustrious Richard Stallman. Many of you, being active developers, have probably heard of him. He gained much of his fame from founding the GNU project and being an adamant supporter of free software for over twenty years. He is also the creator of the well-known editor, Emacs.
Mr. Stallman came to our university to talk about free software and the GNU project. Myself and a friend, having had decided to go (naturally!), were quite excited to hear what Mr. Stallman had to say. Upon arriving in the theatre where he was to appear, we learned that his plane arrival was delayed due to weather, and ended up waiting an hour and a half for Father GNU to arrive. I busied myself with a near-due combinatorics assignment, so it wasn't so bad.
Anyways, Mr. Stallman finally arrived, and there was a very strong applause. U of W is renowned for its allure to Computer Science majors, so we had a big audience that were all quite excited to listen to Mr. Stallman speak.
The first part of his talk was focused on defining what exactly free software is, and why it is important for our society. So far so good. He mentioned the four freedoms that are granted to us by free software: it can be freely modified, it can be freely distributed in its original form, modifications can be freely distributed, and of course, it can be freely used and its source-code freely read. This does not sound like a big deal for people who are not programmers, but Mr. Stallman claimed that since there are communities around these products (usually), there is still the ability for others who CAN program to make modifications on your behalf. Mr. Stallman was very adamant about proprietary software being an evil that takes away one's freedom. Even the exclusion of one of the four freedom constitutes a product not worth using. He argued that not using any and all software that is not free (as in speech) should never be used, regardless of the sacrifice required. He was very adamant about this.
He was doing a good job convincing me until he mentioned that last point. I think that free software is a fantastic thing, and while I do not actively support it, I support the idea of it by using many different pieces of free software in my day-to-day computer usage. Still, to bar oneself from using ALL forms of proprietary software is no solution. Proprietary software has the benefits of being developed (usually) by a far more organized, experienced, and well-equipped team than a free software team equivalent. This is simply because of one thing: money. Free software is (generally) developed for free, in developers' spare time. It's undeniable that many companies work with and develop free software as well, though. With hundreds or thousands or millions of dollars and structured organizations behind these proprietary products (that includes commercial video games!), the level of quality and technological achievement greatly surpasses where the free software community stands. Does Mr. Stallman suggest that we all live five or ten years in the past and use those product simply because they preserve a set of arbitrary freedoms that he created? Plus, I've never seen any free software attractively shrink-wrapped. [smile]
Mr. Stallman also had a segment on the history of the GNU project. It was interesting to learn that the GNU project was originally paying a developer to create a kernel for their operating system, but they ended up seeing Linus Torvalds' kernel, Linux, as a more feasible option. It turns out that Mr. Torvalds' kernel was not originally entirely 'free software' by the FSF's standards, so it was only a time afterwards that Mr. Torvalds ended up changing his kernel's license that GNU adopted it into their operating system. That's where Mr. Stallman suddenly grew very bitter. He was (still!?) very unhappy about how the public generally mistakenly began calling the GNU operating system with Mr. Torvalds' kernel "Linux". This perpetuated itself, and even today the operating system is most commonly referred to as Linux. I think even I am guilty of this misnomer. However, he still seemed very displeased that Mr. Torvalds received much of the fame of his and the FSF's hard work, and mentioned how many people mistakenly believe that Mr. Torvalds was the original father of free software, rather than Mr. Stallman. He also asked of us to call Linux "GNU/Linux" or "GNU+Linux" whenever we refer to the operating system. This was definitely the low part of his talk.
Things went up from there. He donned a robe and a placed a giant CD-ROM on his head, made to resemble a halo. He then jokingly introduced himself as Saint IGNUcius, of the Church of Emacs. He made several jokes that got a good laugh from the audience, such as "'vi vi vi' is the number of the Beast", and "using vi is not a sin; it is a penance". Hyuk hyuk. [smile]
He closed his talk in a rather unexpected manner: an open auction. He had brought several items with him to sell in order to raise money for the Free Software Foundation. A plush GNU gnu (hah!) was sold for $75, a signed hardcover book of Mr. Stallman's (I forget which, alas) for $95, and afterward softcover copies for $25 each. There was also a booth outside of the theatre selling free software merchandise. I think they did pretty well that night. I didn't buy anything, as per my rights as a free software user. [grin]
Finally Mr. Stallman requested questions from the audience. Things got pretty hairy here. There were several audience members that disagreed with the reasoning on some of Mr. Stallman's points, which I grew disappointed with how he handled. He became very outspoken, evangelical, and actually quite angry about anyone who disagreed with him on any of his points. In all fairness, though, he answered several (much more neutral) questions quite well.
Overall I am very happy that I attended the talk, even if I don't completely subscribe to Mr. Stallman's philosophies. I feel that I can appreciate free software more fully now, and understand the history of a behemoth like GNU/Linux (heh) much better. Despite it all, though, you still won't catch me using Emacs. [grin] (Okay, well, not too often.)
A belated Merry Christmas to everyone, and a cheery New Years' as well. I hope you are all happy with what you have accomplished last year, and are as eager as me to get cracking on all of the great new stuff just waiting to be had at this year!
Results of 2008 Resolutions
Every year I like to post my New Years' resolutions here, so that I can reflect on them a year later and see how I've done. Let's see how things stack up in 2008:
Continue development of Project Skirmish."I'm committed to seeing Skirmish through to the end, so a goal of unwavering development of Skirmish throughout 2008 is certainly a fair goal. To be a little less insubstantial, let's say a goal of being in open to the public by the end of the year, at least. :)"
I most certainly did make a ton of progress throughout the year, and I just about am at that golden point of opening Skirmish to the public. As always, it's easy to over-estimate where you'll be in the future, but I am perfectly content with how far I have gotten with Skirmish in 2008.
Complete a 3D game using OpenGL. "With plenty of experience in the small 3D demos I've made in 2007, I think it's high-time I write and complete a fully 3D game. I'm putting no minimum on how ambitious it will be. Even a Wolfenstein 3D-esque game would be a sufficient accomplishment."
Nuts. I still really want to do this, but I admit that I did NOT finish any 3D games this year. There are actually several fairly functional projects started, but due to stress-points like making textures and creating models, I've neglected it.
Get a personal gamedev website online. "I've been wanting to get my own personal website about game development up for ages upon ages. This year is the year that I get on this, and learn some more HTML and CSS in the process."
Bam! I'm pleased to say that I nailed this one. Heck, I even made a second one for Skirmish!
Resume creative writing. "I used to be hugely into writing stories and such in my spare time, but programming and real-life have come to consume that hobby years age. I've been bugging myself to get back into this, and I think there's no better opportunity to do so than now. We'll say a fairly light goal of at least 10,000 words and a minimum of one completed story. :)"
I'm very disappointed to say that this didn't even come close to happening. I definitely still want to do this, so I'll need to really focus on putting my creative-cap on this year.
Write another gamedev article. "With my metaballs article just about done, I'd really like to push myself to finish another article this year as well, if not more. Fingers crossed!"
Did not happen. I did, however, sign a deal with a publisher to get this article published in a book. I can use that to justify not completing the resolution, right? [grin]
Continue my language studies. "I've been learning German for the last two terms at university, which I plan to continue. I've also been very interested in learning Japanese, which I will also be spending time learning independently."
Definitely taken care of. I've been learning a lot of new Japanese, and I'm taking another German course at my university this upcoming term. Schon!
Resolutions for 2009
I'm thrilled with my accomplishments last year, and as per human nature, I want to do even more this year!
Keep on working on Skirmish. Skirmish represents a huge chunk of my ambitions. After putting 1.5 years and over 21,000 lines of source into it, I won't settle for anything less than a shiny and finished product.
Continue language studies (rigorously!). I want to continue focusing on German and Japanese, and learn as much as I can in the year ahead. I really want to prep myself up and eventually get my Zertifikat Deutsch.
Don't dare stop biking or fencing. I'm becoming more and more conscious of the importance of exercise and fitness. I took up both biking and fencing last year, and I really don't want to lose the fun nor the exercise that they both bring.
Dedicate time to teaching others. I won't lie: I've already made headway on this. Not only will I be continuing to be the VP of my university's game development club, but I will be working part-time tutoring a 1st-year Computer Science course.
That's it. It doesn't sound ambitious, but I picked the four things that I loved doing throughout 2008, and that I really want to see myself doing through 2009 as well.
Best of luck to everyone else and their goals. As always, wishes for good health and fortune in the year ahead. [smile]