Times, trials, and turbulence.
Monthly Archives: September 2007
It’s been a little crowded lately for that, it seems. Yesterday and today have just been crowded with assignments and studying, so progress on my article and website just haven’t happened yet. To be honest, I’m still working myself over the initial “getting started” hurdle on the article. I have a pretty clear idea of what I want to cover, but that first pen-to-paper moment is always the hardest. This weekend isn’t too heavy in terms of school workload, so I’m going to push to get the draft written tomorrow. That’ll just leave revision and demo-writing before it’s good to go. I’ve also been learning some various tricks in regards to web design from a friend, but I’ll jump into that pool of piranhas later!
Jobs jobs jobs
My first interview(s) has been scheduled, thank goodness. They’re combining my interview for being a CS125 and CS134 Tutor together, which means a little less time I’ll be stuck on campus wearing nice dress pants and a fancy-dancy shirt. Sheesh. 🙂
CS125 and CS134 are both first-year intro-to-programming courses that use Java to teach programming concepts. 125 is the “totally new to programming” course, while 134 assumes you have a basic understanding of the ideas behind programming. I was pretty sure that I would get interviews for these, so the tutoring jobs will (assuming the interview goes well!) effectively be my “back up jobs” if I don’t manage to snare a more alluring position elsewhere. Not to suggest anything detrimental to being a Tutor — on the contrary, I think it would be a fantastic learning experience. It’s win-win all around.
Phong Illumination Model
Jon has been tinkering away at yet another game development article, this time focusing on a the more theoretical side of graphics programming. His article talks about the ideas and basic implementation of the Phong Illumination Model. If you’ve ever been interested in raytracing, he’s planning on following the start he’s making with this into a full-fledged series on the topic. Keep an eye on his journal.
It feels like I only just started the school term, but they already have us out applying for jobs once again. Our co-op schedule follows the pattern of alternating between school terms — one term being three months — and work terms. We go through a system called ‘JobMine’, which is a massive database of jobs that heaps of employers send co-op offerings to. It comes in two waves, whereas we go through and apply to jobs that catch our fancy. If all is well, then we are offered an interview. After our interviews, we rank the jobs (which we may or may not get an offer for) in order of preference, and then the highest ranked job that we actually got an offer for becomes our co-op placement for the next term. That’s our co-op system in a very brief nutshell.
Currently I’m on my way to the interview phase. I’ve applied to about 22 jobs — all of which are in Waterloo; I don’t want to deal with subletting my place — and am eagerly waiting to see how much I will receive interviews for. As usual, there was a great diversity of possible placements, everywhere from McAffee to Research In Motion to Capcom to Sybase. Shame the job for Capcom is all the way in Burlington. 😦
News on this as it develops!
Ich muss Linux lernen!
As I delve deeper into my studies (and the business world), I’m realizing that Linux/Unix knowledge is becoming a greater and greater asset. Being unsatisfied with the sluggish pace that I’ve been moving at by only using Unix (well, Solaris) in the school computer labs, I’ve moved over 90% to Linux on my desktop. I still need Windows to play my precious games, but I mostly just write documents (OpenOffice) and work on Skirmish (NetBeans) anyways, so it’s not like I’m unable to do most tasks. In the long-run, this will mean many things will be challenging to do the first time around, but I will learn a lot more from doing than from reading some dusty Linux textbook.
As another upshot, it’s given me a chance to work on getting Skirmish working properly for Linux, which has been painful so far. It’s almost working, so I’ll save that for another entry.
Making a game is hard. Looking back at that game a year later and writing one’s thoughts and feelings about the development of that game is arguably even harder.
Mike Stedman (Ravuya to “teh intarnets”) is such a developer. About a year ago (nearly to the day!) he completed Glow, an impressive futuristic zombie-bashing top-down shooter. He has just completed the arduous process of creating the post-mortem of his work of art. And thusly, my recommendation to you, dear reader, comes in
two three steps:
First and foremost, I’d like to extend a huge thanks to everyone who took the time to try out the Skirmish demo and replied with feedback. The consensus seems to be that it works on Windows without any hassle (to be expected, as the development platform :P), Mac OSX works with a little bit of fiddling, and Linux is a little dodgy. Like I said, hopefully I can find someone with some thicker Java+Linux experience than myself to help aid in that.
The overall conclusion (sans distribution methods) is that the game runs exceedingly well on most semi-modern systems. I actually had several rendering optimizations already planned in case lower-end machines were struggling, but nothing reported seems to fall very far of 100FPS in the worst-case. I will, however, need to rework my update timing, since the UPSes are all over the place. Groan, my friends. Groan.
I’m going to start looking into WebStart for future distribution of Skirmish-related files. Huge kudos to Jon for writing up a mini-article on using WebStart.
I wouldn’t call it a hiatus, but I’ll leave it to you to determine how to look at it. I will be taking a short break from Skirmish in the coming ‘several’ weeks, in order to work on some ‘personal development’.
Personal development? Yes, that’s intentionally vague. 🙂
I’d like to think that I’ve accomplished a lot during the years that I’ve dedicated to game development and programming, but I can’t help but feel like I’ve been leaving a lot of things out. Writing games is certainly something that I’m comfortable doing at this point, but there are quite a few areas surrounding that which I really haven’t taken the time to explore. Like what, you ask? A few things:
Articles. I have absolutely avoided the article ‘world’. I wrote a small mini-article or two ‘back in the day’, but it wasn’t anything that I was really happy with or particularly informed about. They say that to be able to write and discuss something is to show greater understanding of something than simply demonstrating its use. Sure I’ve written raycasting demos, fractals, metaballs, and other games/demos that show a direct application of the theory behind them, but I still can’t really ‘talk’ myself through the math and ideas of it all. I really want to solidify my understanding of many of these ideas, and, as a nifty byproduct, I get to show informative articles to the world that can help others learn. Once again I have Jon to thank for the motivation to take on this direction — he’s been quite active in article-writing for several years now. I’ve seen how much writing articles has helped him in his work, and I can’t think of a better way to give back to the community.
Websites. Take a look at my ‘flagship’ game project — Membrane Massacre — and it’s awe-inspiring website. Does it fill you with the same sense of “from under which ugly-rock did that thing crawl forth?” that it gives me? I’ve been downplaying the marketing of my games for ages, and I would really like to do something about it. As a programmer, things like HTML and CSS are certainly not beyond my understanding, and I’d like to think that I have a good enough sense of style to pull of a decent website. When I point people to MM, I really want to write that URL with pride, not show some dinky template-generated 4-frame website hosted on gamedev.net. After all, that’s the kind of stuff I paid for this webspace for!
A good start, I think. Since this notion of ‘personal development’ is the sort of thing that should continue for the remainder of my career, I’m not going to really say that “I’m going to work on this for N weeks and then return to Skirmish”. Instead, I’ll work on my articles and my websites when I can, and work on Skirmish when I can. Overall this will mean a slower development rate, but I think that this is a tiny price to pay compared to the gains of putting time into these ‘personal developments’. I’m interested in hearing about similar endeavors any of you have undertaken in the past. 🙂
Article 1 – Metaballs
For my first article, I definitely want to start off with something that I know I understand. Well heck, I remember writing that little Metaballs demo a while back, why not write about those? Fair enough. So, I set about creating an outline for the article.
After sliding in a few points for what the introduction would cover, it didn’t take long for me to realize that I really didn’t know much about the theory and concepts behind isosurfaces — isosurfaces being the more formal name for the type of ‘object’ metaballs are — and that I couldn’t just write an article about a vague notion of what metaballs are and a couple of formulas. After all, this was supposed to be about becoming informed, right?
So, I hit the books. The online ones, that is. It turns out that there really is a lot more behind isosurfaces (or ‘level sets’, mathematically) than I had realized. Researching really is a critical component of writing articles. Articles are about facts (the good ones, at least :)), not about general opinions or beliefs of “what it probably is like”. Just in spending an hour or so of the evening reading up on isosurfaces and metaballs proved extremely enlightening. This transformed the original dilemma of “what can I write about other than the definition and formula of a metaball?” to the problem of, “what stuff do I leave out? I can’t fit all of this in here!”. 10/10 times I think I would pick the latter. 🙂
The article is going to focus on isosurfaces and their applications to game development. This development journal’s focus has always been rooted in writing games, so I want to make my articles tuned into that wavelength to some degree. Since my audience is also of that vein, I doubt there will be many complaints. As an upshot, I even get to write a couple of small demos involving isosurfaces for game-related effects/mechanics. Exellent. You can read the (rough!) outline here, and are encouraged to provide any feedback or suggestions.
Sometime in between that endeavor and my assignments, I will also try and also build an outline for Membrane Massacre’s upcoming website. Perhaps brush up on my HTML and CSS knowledge as well. I can think of at least one web design guru I can prod at if things go awry. 😉
And that’s all (for now). I hope that those of you that are here because of interest in Skirmish can understand my reasoning for undergoing this — er, ‘delay’? — side-project. In the long-term it will doubtlessly help me as both a developer and an individual.
Until next time!
Project Skirmish: Demo One
Just a short and to-the-point entry tonight, featuring the first downloadable demo for Project Skirmish. This is a demo of the press-mouse-to-spew-firearms functionality that I wrote about a couple of entries ago. Click to spawn random guns. Simple enough.
The goals are:
- To ensure that my distribution
guessesmethods are proper for Windows, Mac OSX, and Linux.
- To determine the game’s average performance on various systems.
- To gauge if my current method of calculating updates-per-second is going to hold under non-development-computer conditions.
- Fun? 🙂
If you would like to test one (or more) of these out, please be sure to respond with the following information:
- What OS(es) your feedback applies to.
- What steps you had to take to get the demo to work. (if any)
- Your system’s processor speed, amount of RAM, and video card.
- Your FPS and UPS at: 0 props, 100 Props, and 500 Props
- Any bugs, glitches, or odd occurrences that may have taken place.
A huge thanks in advance to everyone who takes the time to help test the existing Skirmish base. 🙂
Phew. Thursday and Friday were the university’s “Club Days”, where all of the various clubs gather for two days in the Student Life Centre to show off their wares and recruit members into their ranks. This is my second time helping man the booth for Club Days, and it certainly hasn’t gotten any crazier. 🙂
It’s packed. Perhaps not as ridiculously so as I’m making it seem, but it’s definitely bustling all day, so it’s very hard to engage in discussion and conversation with people that are more than a foot or so away.
My tactic was largely to stand out in front of our booth — I learned quickly that standing behind it would ensure nobody could hear what you were saying — and say something like, “Interested in game development? Y’know, making games?” to anyone who’s eyes lingered on our three-fold poster for more than two seconds. Given two days of doing this, I’ve managed to aptly categorize potential developers into X genres:
- Gung-Ho’ers. These are the rare ones that when you ask them about game development, you can actually watch their eyes light up with glee as they fumble with the pen beside the sign-up sheet. These folks have had previous experience (usually at an intermediate level) with game development, enjoyed it, and were already looking to get some more. Not-so-coincidentally, these were always programmers.
- Shruggers. A few notches down from the aforementioned genre, but the Shrugger usually shows some promise. These are usually artists, musicians, or writers that have only just had the notion of combining their skill (be it art, music, or writing) with game development. The concept seems to bedazzle them somewhat, since they sort of shrug their shoulders, nod their head to themselves, and then write their name down. We’re trying to have more to offer non-programmers, so hopefully these guys will stay.
- Ambitionists. These ones are either dripping with promise, or are laden with failure. These people look to be really excited about game development, but then again, they also seemed really excited about the last five clubs that they visited and are holding pamphlets from in their other hand. They’ll sign up pretty quickly and write something like “Everything!” for the Area of Interest section. Either they are legitimately interested in game development, or we’ll never see them again.
- Long-Shots. To be honest, they weren’t really that interested in game development in the first place, but after chatting and convincing them for a few minutes, they sort of manage an, “Oooh, I guess…” and write their name on the sign-up sheet. Usually they have a fairly developed skill in one of the areas (usually any of them except programming, oddly enough), but they aren’t really too interested in applying it to game development. Oftentimes it seems to be a, “Oh I don’t want to be a nerd” thing. If they show up for the initial meeting, it’s a surprise.
- Impossibles. “Have you ever wondered how games are really made?” I would challenge the passerby of this genre. They would walk a few more steps before actually briefly making eye contact, “No. Sorry.” and just leaving me standing there. These are the most common, naturally enough. There will always be the bulk of the crowd that just has zero interest.
Long story short, we ended up with about 80 names written down by the end of Friday. This certainly beat last term’s record of ~60 names. We barely had enough room for everyone during the initial meeting, so I don’t know how we’re going to cram everyone into one room this time. It’s going to be intense to be showing the grandness of gamedev to such a huge audience! (Gah, this Thursday!)
Skirmish: Ever Forward
It’s been a while since the last update, which has been largely unavoidable. Classes and assignments consume the vast majority of my time, with the gamedev club and social life chewing up most of what’s left. The tail end of all of that is what little time Skirmish receives. Bit by bit though, it’s getting there.
The props shown in the last update are now unified under a generic “Item” class, which will abstract the things like picking things up and throwing them away, which will work the same for all items.
Similarly, an even more abstracted ‘selection highlight’ interface exists for Props in general, which will really serve as a visual indicator so that the players knows when s/he is in range of a Prop in the world that s/he can interact with. Green will represent a pickup-able Prop, whereas later on there will be other colours for things like Switches/Buttons or Staircases/Elevators or defusable landmines.
As shown in the above screenshot, a simplistic inventory interface was implemented to allow me to develop the inventory system without needing to actually make any decisions about how the HUD will work. Right now the player can simply scroll through their inventory. Also shown, the game will work upon the assumption that the player can only have one “Held” item at any given time. This differs from the previous Skirmish insofar that there will not be quick-use hotkeys for throwing grenades or using a melee attack. At least not in the same sense. This will probably be possible via macros or a similar facility.
The last thing remaining on the “basic item interaction” system is discarding items, which works by throwing. Since most online games like to have a simple discarding system, such as, “drop item in front of player with no forces applied”, I figured that I would spice things up. The player will be able to ‘charge’ any given throw, meaning that a player could simply drop the item in front of him-/her-self, but the option remains to fully charge the throw and actually heave the object at an enemy. This will be particularly useful with certain items, like knives. Additionally, this will mean that the ability to pick up background Props (chairs, plants, trash cans) will also be on the feature list again, since these will function exactly the same as any other Item.
I’m aiming to put up a downloadable demo tomorrow, featuring the version I showed in my last entry (the “gun-spawner”). The plan is to get feedback about how well (or not well) the game runs, and to ensure that the game launches/runs properly on Windows, Mac, and Linux.
And, given the late hour, I think I’ll save my ravings about writing binary tree algorithms in assembly (for my CS 241 course) for the next entry as well. Hoy. 😉
University & Classes
The first week of classes is now done and behind me. It’s a bit longer of a hike to the campus than I had expected — about 20-25 minutes if I keep a decent pace going. From here on in our university includes bus fare with our tuition cost, so it is sort of ‘free’ for me to take the bus as well. I really dislike the ‘bus-stop scene’ though, so I walk when I can.
I’m taking five courses this term, which are all exceptionally interesting. I’ll toss in a brief paragraph about each:
CS 245 – Logic. This course looks at logic on a fundamental and computational level. It’s very heavy on proofs — in fact, it’s virtually all proofs — based on four logical operators we have at our disposal (conjunction, disjunction, implication, and negation), as well as introduction and execution rules for each of them. It’s extremely interesting to work with logic on such a ‘raw’ level, and has obvious benefits for anyone interested in CS.
CS 251 – Computer Organization and Design. In a nutshell, this course begins at the level of assembly and machine code, and then works its way down, towards the machine itself. Only the very basics were covered this week, but I’m thrilled to be learning more about how a computer really works on the bottom-most levels. I’ve browsed through the textbook a bit, and it looks fascinating.
GER 102 – More German. Not the actual name, but you get the gist. I need to make a prerequisite chain of length three as a degree requirement, so I figured I’d continue my study of the German language. It’s challenging and often frustrating to learn a new language, so excuse me for not sounding as worked-up as I did for the other courses. It’s certainly interesting, but in the hair-pulling way. 🙂
PHYS 111 – Physics I. Officially, I’m taking this because I need a Science credit for my degree. Unofficially, because it ties *directly* into my growing interest of the computation and simulation of physics (both accurate and the crude stuff for games). This course covers kinematics and dynamics, which is exactly what I’m interested in. It seems like everything beyond that in physics (waves, quantum physics, etc) is too mind-blowing to do much in terms of the simulation I’m in to. Looking very forward to using this course to augment my basic knowledge of physics.
CS 241 – Foundations of Sequential Programs. This course starts at the level of assembly and machine code, but unlike CS 251, it works its way up, towards languages. Without a doubt, this is going to be the most intriguing course of all. This week we were writing raw machine code for an old CPU called MIPS — or rather, a MIPS simulator. I think if we were all writing real machine code then most of the campus’ servers would be down by now. 🙂 It’s really really really fascinating stuff, and we haven’t even touched the bulk of the course: writing a compiler for a simple programming language. This blows my socks right off, so I’ll definitely be writing more about this as it develops. We have to use the basic language that they specify, but I’d like to start my own off on the side, just for kicks.
I didn’t forget about Skirmish. Oh no. 🙂 In my last post (or 2nd last, rather) I promised that I would have a surprise ready for Monday, when I had thought my internet would be good to go. Since it’s functional now, I might as well make good on that promise right now.
Given my recent habits, perhaps the surprise could have been that I’m still regularly and eagerly working on Skirmish. I think that’s probably a surprise to many of you, but I won’t stop there. Read on!
Props & Physics
What it’s boiled down to (internally) is the idea of Props. A prop, in terms of Skirmish, is any physics-driven object that [can be] maintained over the network across a hosted game world. This includes: chairs, tables, grenades, bullets, rocks, guns, rockets, empty shell casings, and even big wood splinters left from destroying a crate.
This leads directly into the fact that all ‘items’ are now technically ‘weapons’ in the sense that all items create an Entity (be it a physics-driven Prop or otherwise). Firing a gun creates a bullet, throwing a grenade creates a grenade, which is obvious. However, using a medkit will create a healing entity, which will essentially be a particle effect that also restores lost health from nearby teammates. Melee weapons create a melee damage entity, which will really act like a short-life invisible projectile released from the player.
It sounds sort of strange from a player’s point of view, but it will be entirely transparent to players — they won’t be able to tell the difference between this and if I had coded each type of item completely separately. From a developer’s point of view, it means that one type of network message can handle all items, and naturally having all items under a unified system makes life much easier than having several cases for each item type.
I’ve implemented the foundations of this Prop system already, which can be viewed in the video below. In terms of performance, since Props use collisions based on a single point, are very low-cost. I can easily simulate hundreds of active Props at once, colliding with the map and static Props (crates in this example) with little performance hit. As a plus, when a Prop stops moving, it goes into stasis (read: no collision checking), which kicks up the speed as well. This will go a long way in making the game feel more dynamic.
(Note: Standard YouTube low-quality, but you can see the gist of what’s going on.)
Bell says that our internet will be activated on Monday. Expect a juicy update then. 🙂
(On a sidenote, the dev-log has broken [a paltry] 2,000 views. Hurr.)
I’m currently mostly moved into my new house in Waterloo, but we don’t have an internet connection set up just yet. I’m filching a neighbour’s at the moment, but the connection is poor; I’ll have to make this brief:
All is well. It will be a week or so until I have an actual internet connection, so don’t expect anything new here until then (or thereabouts). I am preparing a nice surprise however, despite the downtime. Hush hush until then! 🙂
Movin’ Yer Shtuff
This will be my last night at home before moving back over to Waterloo, bright and early tomorrow morning. I’m certainly going to miss all of the free meals, but it’s going to be fantastic getting back over to university and feeling that collective energy that just can’t help but buzz around the area. Definitely going to be another excellent term.
Leaving the previous year of living in residence behind, I will be moving in with two other chaps I met in a reasonably sized townhouse not too far from the campus. They’re Computer Science nuts like me, so I’m sure it will be just fine. After selecting our phone/internet/TV plans, I’m incredibly thankful for the wonders of splitting bills three ways. We decided to splurge a little on internet and get the Cogeco Pro package, which offers a whopping 16 mbps of hardcore download transfer speed, and 100 gigabytes of bandwidth. I’ll have to lay down the law about torrent downloading though, lest we go over our cap.
Tomorrow I’ll be moving in, and so is one of my other housemates. The third moves in on Sunday, which means I’m guaranteed to not get the smallest room, so all is well. 🙂 Medium or large is fine by me. After all, I can’t be expected to write code without being able to have a good leg-stretching here and there, right? Right!
It’s been a little hectic lately for coding, so it’s mostly been design work lately. I’ve decided how to manage weapons and projectiles — which I won’t delve into just yet, since I doubt it’s an area of interest — but it will allow for the best flexibility in adding lots of different types of weapons through a common interface (rifles to grenades to flamethrowers to rocket launchers to baseball bats). As you can see from the list, firearms, melee weapons, explosives (thrown and planted), and tools (medkits, armour, stealth devices) will all go through the same system. This makes for faster development speed, and, even more importantly, a far less painful networking model.
I’ve also decided to — regrettably — downgrade from the Object Model that I spoke so highly of before. I would absolutely love to have fully dynamic objects with nice collisions/physics, as well as allowing for such a high level of interaction with the environment. However, I also need to be realistic if I hope to complete anything. Having an over-ambitious physics model is the largest factor in Gloom‘s downfall, and I won’t let it crash Skirmish as well. For the time being, the environment will become static, meaning props in the world will not be interactable, sans basic collisions. This excludes Items, which will be dynamic — referring to dropped guns, thrown grenades, or loose rocks/grit/shrapnel laying around, which will react to forces like being kicked by a player or knocked away by explosions — to the best degree I can manage. This may or may not lead to allowing props (eg. crates, desks, chairs, trash cans, etc) to be destructible, not still not movable.
I plan to discuss the Inventory/Item Model for Skirmish in my next entry, and how it fits into the game/gameplay. This will be a pinnacle part of the game, so I will be interested in hearing feedback to make it as interesting as possible. Stay tuned.
This only scratches the surface of each of these projects, and my own history in game programming. Still, hopefully it will give a decent overview of the efforts I’ve exerted over the years towards creating my ideal online shooter game — nay — my dream game. It all began five long years ago…
2002 – “Bizlof War”
Back in my first post was where I first mentioned Skirmish Online. But it began far before that. The undying firey passion to create this online game began all the way back in 2002, five long years ago. This was when I was rather new to the idea of game programming; anything beyond a text adventure was “far out”. I was introduced by a friend to the online game creation utility known as BYOND, or, Build Your Own Net Dream. It uses a C#-meets-Python-like scripting language, and lets the developer build atop of their existing network and world code. You were constrained to their object-based networking system, and their 32×32 tile engine. Despite this, it was still enough power for a budding developer such as myself. It wasn’t long before I had created the first incarnation of my dream game, Bizlof War. The name was made up on-the-fly, but despite its look, it has no Russian background or relation. Who knows?
Bizlof War wasn’t that pretty, but after looking at the screenshots from the link at the top of this post, one can see a strong resemblance.
Bizlof War took place in a more futuristic setting than Skirmish, featuring weapons like railguns, plasma weapons, and allowing players to ‘warp’ to teammates. The damage per-shot was also lower than most games, allowing battles to take place for longer than a quick encounter. The characters were also broken up into ‘classes’, such as Soldier, Pulse Trooper, Commando, Stealth Op, and Weapons Expert, whereas certain weapons would only be usable by certain classes.
The game saw moderate popularity, but my inexperience in writing games combined with its performance/gameplay being hindered by BYOND itself (it was catered towards slow games like puzzles or RPGs) resulted in a less than optimal outcome. Still, there were several games hosted with 20+ players, which was a simply fantastic experience, and was what spurred me to keep on aiming for this ideal online game.
2002 – “Bizlof War: Tactics”
After Bizlof War‘s completion, development quickly began on a sequel, Bizlof War: Tactics. The idea behind this game was to encourage more tactical and stealthy gameplay, while keeping the overhead shooter aspect that I enjoyed in the first game.
Bullets became instantaneous, whereas the player would aim at a tile and click the mouse to fire a ‘burst’ from the selected weapon. This would be 1 round from pistols, 3-6 for SMGs/rifles, and 8+ for shotguns, with the rest somewhere in between. Recoil was also a factor, so battles wouldn’t become stand+click wars.
Another inclusion (which I loved) was gas grenades. They came in both the Chlorine (damaging) and Nerve-Gas (stunning) flavours, and continuously spawned gas-cloud entities that drifted and shifted about for the lifetime of the effect, blocking line-of-sight and dealing out its effects. It was neat to be able to trap someone in an office with a well-placed gas grenade, and wait around the corner with a shotgun for when they came rushing out, unawares.
The game worked on the idea of a ‘slotted inventory’, rather than classes. A player would choose items to have in his/her inventory prior to appearing in the game, each of which took up a certain number of the total seven slots they had (seen above). Items had no cost associated with them, so the player was free to experiment and customize their arsenal in whatever way seemed to best fit the play-style they wanted.
Bizlof War: Tactics also received a luke-warm response, although seemed to fare a little better than its predecessor. BYOND itself was still the factor that was limiting me. I had begun learning Pascal and Delphi in highschool at this point, so I planned to venture even further towards my dream game…
2004 – Bizlof War (Delphi)
After an intermission of a year or so (developing other games all the while), I found myself back with the online game fever, and it would not let go. It was time to leverage what I had learned with Delphi and try to make a ‘real’ online game.
Code was hastily slapped together, and very quickly (read: ~2 weeks) the game was vaguely playable online. Players could join, exit, chat, use weapons, and kill/be killed. It looked crude, but I was blown away by the fun of just a few players online gunning eachother down could provide.
After a couple more months of development flew by, it began actually taking on a semi-professional look:
I was absolutely ecstatic about how well everything was going, and how intense the battles were becoming. The gameplay followed along the vein of the first Bizlof War, taking on a futuristic theme with more fictional weaponry, and slower-moving bullets.
In terms of response, I saw far more interest than I had seen with my BYOND-based creations, which was to be expected after I had broken free of its constraints. No more 8-directional movement, tile-based movement, slow input reaction speeds, and inflexible network code. Things were far better than they were, but still, things were not good enough.
The code was sloppily written, on which I blame my naiveness at the time. I was still fairly new to programming, and this was the biggest game I had ever written. I also lacked practical knowledge about writing network code, so the networking was extremely inefficient. Once untraceable bugs started sprouting up and the network code was all but collapsing on itself, I gave a great sigh, and closed the project. It never even reached ‘public’ status.
2005 – Skirmish Online (1)
I had gained a lot of experience in the following year, and so I decided to undertake this project once again. This time I would opt for as visually pleasing of a game as possible to ensure success with future players. I chose to use OpenGL to wriet a 3D-overhead viewing style, combined with polygon-based maps. I was also especially pleased with the GUI system I had written.
As you can see, I focused on the visual components far more than I should have. This attempt didn’t even reach the networking phase before I realized that I was in over my head. I actually rewrote this all in C++ (the original being in Delphi), and starting integrating Newton before I decided that it was all too much.
I learned a lot while writing this attempt at my ideal game. The main lesson to be learned, however, was to keep your ambition in check. I wasn’t ready for a 3D game then, and I think I’m only barely ready for one now, 2 years later.
2006 – Skirmish Online (2)
I received the best response on this (and most recent) attempt at Skirmish, even though it too never reached the ‘public’ phase of operation. I wrote this in Delphi as well, and took the lessons that I had learned from my last two attempts: 1) write code in a clean manner that will allow for long-term use, and 2) don’t get overambitious with the features.
As a result, Skirmish used a tile engine for its map system, and a simplified GUI system. I had learned tons in the last year about network programming, so I wrote much better network code.
Unfortunately, despite my vast improvements, “better” is still a very relative term. I made great strides, but still fell behind. The code and networking again became unwieldy, bugs crept up around the corners, and I found myself back where I was before. It was here I learned my final (major) lesson, that planning one’s code in advance is just as important as planning one’s game/gameplay in advance.
2007 – Project Skirmish
This is where things stand now. Project Skirmish is a temporary name for the game until something more original comes to the surface. I’m writing this game now, using the code I wrote back in July, which saves me a month of writing broilerplate engine code.
I’m going to be taking full advantage of the lessons that I have learned over the years, and carefully write every piece to the puzzle that is my dream game. I’ve certainly had my ups and downs with game projects, but, as you can see, the plan to create this game has never wavered or faded away.
And so, I’m sure it’s very obvious what my ‘new’ game project is. I consider the diversions of the last couple of months as a simple intermission for my motivation to resurface, and thus Project Skirmish gets resumed. Refactoring has already begun in the intent of keeping organized code, and the game itself has begun to be developed. Stay tuned, for sure.
The dream shall be attained!