Tales of the Rampant Coyote
Ye Olde Archives. Visit the new blog at http://www.rampantgames.com/blog/ - and use the following feed: http://rampantgames.com/blog/wp-rss2.php
Ye Olde Archives. Visit the new blog at http://www.rampantgames.com/blog/ - and use the following feed: http://rampantgames.com/blog/wp-rss2.php
Friday, October 23, 2009
Frayed Knights: Why Is This Game Taking So Long?
And here are a few words of update on the making of Frayed Knights, the comedic indie RPG in development by Rampant Games.
If there's a single common thread linking several of these updates together, it is, "Things are taking longer than I expected." I've yet to hear of a game getting done significantly faster than expected. Making games is hard. You'd think that after fifteen years of doing it, I'd know this by now.
You know, when I was working on the pilot episode of Frayed Knights, I had a couple of ideas. Really silly ideas, in retrospect. I should have known better. While I've never made a full-fledged RPG before, I've made plenty of games. So I don't have an excuse. Maybe it's some kind of suppression of bad memories taking place that made me believe these things.
But here were my beliefs: That when I finished the pilot, I'd have "most" (75%+) of the code for the game finished, and that my job from there on out would just be cranking out content, which would be easier and faster than code.
Wrong on BOTH counts. But I'm just gonna talk about the code part today.
My existing code, in many cases hastily thrown together just to get the pilot out the door, was woefully inadequate for the true rigors that would be demanded of it. Or the demands of players. In some cases (like the inventory UI), I've completely replaced the earlier code. In other cases, I've had to augment the code to something like quadruple its original size.
And then all the little "bits and pieces" that were ignored / shoved under the rug? That was a lot more than 25%.
Then we have something that programmers jokingly call "bit-rot." It's how we describe our code seemingly "wearing out" and developing bugs as it gets older and remains unmaintained. Naturally, code doesn't rot or change at all with age. But it doesn't exist in a vacuum. As its environment and dependencies change, it may fail. Or we may expose bugs that were always there but never visible. Or we call functionality that was never 100% done in the first place. Or... something.
So what happens is that code that was "working perfectly" (hah!) before suddenly, inexplicably, begins failing. New bugs crop up in old code that hasn't been touched in MONTHS. In several places. And as you fix the code in one place, something else breaks elsewhere.
So I've been spending a lot of time stitching things back together again. And integrating "proof of concept" code into actual working code that functions as it should in a real game.
Of course, there are other explanations, like my playing the Three Musketeers RPG or Knights of the Chalice instead of coding. I guess that's how those guys take care of their competition.
But hey, enough grousing. Here's what's new:
I've taken the visible "wandering monster" thing and made them actually part of the game instead of a tech-demo. So now you can dodge enemy patrols that you can actually see. But their respawn rates are dependent upon how well you've cleared the local area. There are still a bunch of issues to be ironed out there, but it's functioning.
I keep enhancing my dialog scripts to provide greater functionality within conversations. Now talking with people can give you XP or drama stars, give or take away items, set or modify game flags, or call an internal game function.
The area surrounding the Caverns of Anarchy is --- well, not done, but the principle geography is laid out. With a stagnant lake and everything. It's kind of a dismal place. But then goblins and lizard-men were never known for being brilliant landscapers. We've got two of the caverns "done," but they don't look much like caverns. That's kind of an issue when using the kind of CSG geometry we're using for interiors - organic-looking spaces are VERY VERY HARD to do. It's much better at representing regular, man-made locations.
Our explanation is that these caverns began as smaller, natural locations, and were later further excavated and built upon by their residents - who ended up living there for generations.
In spite of bug-fixes, all quests involving the Tower of Almost Certain Death should be completed this weekend (they should have been completed LAST weekend, but I kept getting distracted by other tasks), and I'll be working on some of the other quests and locations in the eastern wilderness and the "follow-up" scripting back in Ardin. The party gets (temporary) access to a major artifact and clues to a major mystery in the tower, and thus sets off the main storyline (although it was hinted at in the earlier parts of the game). This opens up the Caverns of Anarchy area, and Fishy Stuff Starts Happening.
Thursday, October 15, 2009
Ogre 3D Going "Even More" Open Source
Ogre 3D is a popular 3D graphics engine - and definitely the most popular Open Source 3D graphics engine. It has been used for numerous indie projects, and has started to gain traction on more "mainstream" game projects such as the upcoming RPGs Venetica and Torchlight.
It's gained popularity in part because its licensing - the "LGPL" - was a lot more friendly to commercial developers. The LGPL requires any changes or statically linked additions to be made available to the public in source code form. In practice, this has meant that so long as you dynamically linked the code to your game (for non-programmers: It was a separate file installed with the game), you only had to publish the changes / addition to the engine itself.
Ogre 3D announced a few weeks ago that it was changing the licensing on the next version (1.7) of the engine. The new licensing will be the MIT license - which lacks even the limited "viral" component of LGPL, which Ogre has used up until now. (Ogre also had a "commercial" proprietary license - the OUL - for those companies that wanted to use it without the source code commitment).
The new license does away with the requirement to release source code, and the OUL will be phased out for version 1.7 and beyond. Will this hurt Ogre 3D's growth as an open source project? The project leaders think not:
"While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, we’ve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. It’s our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to."An interesting observation on their part, and it makes sense. And as Ogre 3D is a fairly popular (and most technically hard-core) open source projects that has been kicking around for a while now, they'd probably know. Anybody who's had to work with code written by someone who either didn't know what they were doing, or didn't care who would have to maintain it after them, can probably understand where they are coming from. Grudgingly-provided source code is not much better than no source code at all.
So if that percentage of quality providers can remain constant, it makes sense that the best way to grow it is to increase the size of the user base. The less restrictive license may do that, especially for larger, commercial studios (who have an automatic allergic reaction to GPL and LGPL, and not entirely without reason).
The biggest concern here might be that some company might then make some minor, proprietary changes to the engine and then sell it as a competitor to Ogre 3D. But to be able to sell it, they'd need to make some pretty substantial changes to be worth the price difference, and the Ogre 3D's team hopes that this approach will make bigger advances in the quality of their own team's output.
Anyway, here's hoping this new approach will help catapult Ogre 3D to new heights as a free, fully-featured 3D engine!
Monday, August 17, 2009
48 Hour RPG Contest Post-Mortemy Thing
My goal this weekend was to participate in the 48 hour RPG competition. Build a simple RPG in 48 hours. It wasn't a "good" weekend for most participants - allocating much time to devote to just cranking away at a game can be challenging. But the results were pretty amazing for such a limited amount of time - you can check them out here and here.
To end the suspense here, I was unable to finish my game on time. With meetings, company, church, and so forth, I think I got a solid twelve hours I was able to put into the game. About half of that time was devoted to creating really horrible programmer art, though my brother Brian did help up with some graphics he whipped out on short notice (alas, much of it is not visible in the current tech demo).
That doesn't mean I'm done with it. While it now has to take a back seat to Frayed Knights, I think it's worthy of continued tinkering. But right now it's more of a stair-climbing tech demo.
If you are really, really bored, the download is here:
The Manor v. 0.1
Left and right buttons control movement. You can use the up and down buttons to climb and descend stairs - but you have to be right above (or below) the stairs - being next to them doesn't currently work. Don't say I didn't warn you - there's really no point to it right now. I'm just including it for the sake of example here.
The concept is the old haunted house story. In the spirit of some Steven King novels I've enjoyed in recent years, the house itself is bad. Your uncle has died, leaving the estate to whomever of his relatives can recover an artifact of his hidden in the house. There's more to it than just a silly contest. He knew how evil the house was, and it was only his own strength of will that kept the evil at bay. The new owner must be strong enough to take possession of the house, lest it take possession of the person.
So there's bad things happening in the house. Over the course of a weekend (or so), you must fight past the disturbing obstacles the house puts in your way - from fairly simple but terror-inspiring manifestations of its evil will, to more powerful semi-corporial apparitions and fiends and animated corpses, to finally taking on "the heart of the house" once you have unlocked the way and have the house weakened enough to take it on. Over the course of the game, the house becomes weaker as you defeat its minions, and stronger as you rest or are defeated. (Oops, sounds like one of those "positive feedback loops," but it's not, really. The game doesn't get more or less difficult as the house gains or loses power - it's just a distance to goal).
Well, that's the theory, at least. In practice, none of the cool stuff got in, so I'm left with a little maze-like Winchester Mystery House wannabe. I figure at least another twelve hours would be needed to get all the dialogs, NPC behavior, combat, and inventory system in place.
So here's a hit-list of what went right, wrong, and how I could do better in the future:
#1 - Should have had a clearer view of the design (and content requirements) up-front: Apparently, some design and asset / engine "preparation" was allowed prior to the contest's start, but I didn't have time. I had a somewhat vague idea of what I wanted it to be and look like on Friday, but I didn't go into the contest having a clear idea of exactly how I intended things to look and play. Not that any design survives contact with actual development and playtesting anyway, but it might have made for speedier development if I had been flying a little less by the seat of my pants.
#2 - Needed more familiarity with the engine: Admittedly, a big part of my goal with this exercise was to experiment some more with Torque Game Builder. But I spent a lot of time looking stuff up and trying to figure out how to do things I had never done before with the engine, and trying experiments with certain features that turned out to be a dead-end. Which brings me to the next point:
#3 - Inadequate Technical Support from Engine Vendor: *Sigh*. Okay, I could totally rant about GarageGames' dropping of the ball on support of everything that isn't new, shiny, and in initial development. But those who would actually care (Torque users of legacy products) are already well aware of the problem in general, so I'd just be preaching to the choir. But the Torque Development Network - which was somewhat of a "community self-support" site in the first place - has been on the blink for weeks now, and this weekend it finally became completely impossible for me to access anything. Apparently I am not the only one. This made it very difficult to look up information on how to use my engine. Sure, the offline reference docs are actually pretty decent, but they don't capture the wealth of information, experience, sample code, and bug work-arounds that you get online.
#4 - I Underestimated art creation time. Again: I do this a lot. You'd think my terrible programmer art could be bashed together in seconds. And really - I think it could be if I allowed myself to get very sloppy, and the differences between that and what I did would probably be undetectable to the human eye.
#5 - Enlisting my brother to help with art: Way too much of my time was spent making art assets, which is kind of embarassing because they aren't very good. My brother jumped in and offered to help. Even if some of his stuff didn't get into the game by the deadline, having that off-loaded helped free me up to work on actual coding. He also pointed me in the direction of a character maker for RPG Maker games which I used to make the main character. While he looks nothing like what I'd want in an actual release, it was very helpful for development.
#6 - Still Too Big of Scope: Um, yeah. I know something of my limits. Yet I continually try to violate them. I should have tried for something smaller. But - Meh. I'm still intrigued by this project.
Some bits of trickiness I discovered while working on the game and with TGB:
#1 - Mounting the camera to the player works, but is very limited in what it can do. I'd need to dig a lot deeper (possibly into the source code) to come up with a way to actually control the camera better.
#2 - Once I did that, I could find no way to set some images to be camera-relative as opposed to world-relative. So any UI-type elements or unmoving background images also had to be mounted to the player, which seemed really weird and convoluted. I hope there's an easier way that I just haven't discovered yet.
#3 - Trying to use physics and collisions for the player was an exercise in frustration. While I still use collisions to limit horizontal movement, it was far easier AND more robust to just to calculate where the floor "should" be algorithmically under the player based on where he was in the level. That solution doesn't scale well to a lot of varied levels, but it worked nicely for this project.
#4 - I could spend days playing with the particle editor. It's not as fully featured as I'd like, but it's definitely reasonable. Too bad there's only one place in the whole demo where I'm actually using them.
So there you go. Well, after not touching Frayed Knights all weekend, I'm ready to jump back into that one, but The Manor may see some future development!
Friday, August 14, 2009
Reminder: Indie RPG Development Competition This Weekend
For indie game devs who might be interested:
Remember that this weekend is the RPGDX Side-Scrolling RPG competition thingie. I am certainly not putting 48 hours into it - I'll probably be lucky to get eight. But hey, let's see what can get done in a limited amount of time, shall we?
I personally think these kinds of things are a GREAT exercise for indie game developers. There's nothing like a really tight deadline to help you focus on priorities and getting the job done. I probably need the refresher course, myself, as I at one time harbored an idea that Frayed Knights might be done by this fall. And these little prototypes whipped out can provide seeds for future products. A "Game In A Day" exercise performed at one point by NinjaBee created a game that would eventually become their hit title, "A Kingdom for Keflings."
So ya never know.
Good luck, and have fun!
Thursday, August 06, 2009
How to Sell Your Indie Game
Amanda Fitch of Amaranth Games (Aveyond, Aveyond 2, Aveyond: Lord of Twilight, etc.) has put together a quick-and-dirty guide for newbie game developers on how to sell their indie games. We're talking traditional download-and-sell type things here, not online games.
It is far from exhaustive, but it's also a nice step-by-step set of instructions for people who are just getting started. The guide suggests how to do the following:
- Beta Testing your game
- Obtaining a Business License
- Setting up a website
- Setting up an installer for your game
- Setting up DRM for your game (we're not talking about the draconian psychotic crap the big publishers do, just wrappers to make it easy for you and for your users to unlock the game with a registration key)
- Setting up an order processor for selling your game
- And --- selling.
How to Sell Your Game, from Amaranth Games
Anyway - while the options suggested in the PDF may not be the best for you or for your game if you are a game developer or living outside the U.S., they are a good start.
One thing she left out was the marketing side of things - to which I can only suggest shelling out a few bucks for Joseph Lieberman's excellent Indie Developer's Guide to Selling Games.
Wednesday, August 05, 2009
And Another Indie Game Development Contest!
Starting today, and running through October 19th, The Escapist is accepting submissions for the "Stonking Great Game Contest." The game must be an original Flash-based title about the popular Zero Punctuation series.
To help us poor programmers who have few art skills, they are also providing a library of assets related to Zero Punctuation to help us on our way.
Once again, the prize is basically braggin' rights (and some swag), though I imagine the attention from such a popular series would not hurt an indie gamer's career. Unfortunately, all game submissions become the property of The Escapist's parent company, but since you'll be using their assets anyway you really couldn't do anything with it without 'em anyway. You'll have to re-write and re-brand your game for that. :)
Anyway - it sounds like another interesting opportunity for Flash developers. Gentlemen (and ladies) - start your editors!
RPGDX is having another RPG-making competition. As usual, there are no prizes involved, but there's some definite value and bragging rights in cranking out a game for this kind of thing. The date is tentatively planned for the 15th and 16th of August - the weekend after next.
The theme for this summer's contest is "Side Scrollers." Yes, a side-scrolling RPG. I have visions of the original Golden Axe and Rastan arcade games going through my head suddenly, though perhaps the most appropriate recent entry in this category would be The Spirit Engine 2.
The trick, obviously, is that you have only 48 hours to make your game. You CAN use an existing game engine and even some pregenerated resources, but the game design and creation must all occur within the same 48 hour period (naturally, you should probably have some IDEAS before you start).
I'm tempted. Not that I have the time to do it or anything. But I'm tempted anyway - perhaps as a way to recharge the ol' batteries.
Got the guts, want the glory? Here's the official announcement and rules, all subject to change:
RPGDX Summer Indie RPG Competition
Saturday, July 25, 2009
More 2D Game Development Libraries / Engines
Just a short note that more 2D game engines / libraries / languages have been added to the list in the forums:
2D Game Engines / SDKs
Thursday, July 16, 2009
Frayed Knights: Edgar the Enchanter and the Endless Interlocutions
It's once again time for me to check in with the latest in development musings about Frayed Knights, the upcoming comedic indie RPG being made here at Rampant Games.
Here's the concept art for Edgar. Edgar is a magic user in the Heroes of Bastionne, rivals of the Frayed Knights. In keeping with the theme, Edgar is in many ways Chloe's equal and opposite. He's clear-headed, tactical, subtle, conservative, restrained, fabulously well-educated in the art and lore of magic but pretty badly lacking in terms of street smarts and field knowledge. He has an inflated opinion of his own skills, and how cool he looks in that blue robe. If Edgar was a player character in a dice-and-paper RPG, he'd be the guy run by a somewhat uncreative rules lawyer / power gamer.
Edgar is fun. He's just asking to be abused. I wish he had a bigger role in the game than he does, but it's still a secondary role primarily in the second act ("act" works better than "chapter" for my brain for some reason). But he's got some amusing dialogs.
Dying on Dialogs
Speaking of dialogs - Argh!!!!
Anybody who has ever made a significant module in Neverwinter Nights understands some of the challenge of creating a dialog. Let's take a simple case - an NPC whose sole purpose in life is to give the player a quest. I don't feel like making a flowchart, so here's kind of a bad pseudocodeish example of how their dialogs might fire:
IF (Is this the first time the NPC has met the PCs?)
Dialog 1: "Hi. I'm NPC X. Good to meet you. Oh, I've got this quest. Interested?"
* IF (The player accepts)
* * Dialog 2: "Awesome. Here are the quest details. See me when you are done."
* * Dialog 3: "Fine. I'll wait for some REAL adventurers to offer them this quest."
ELSE IF (the player refused the quest?)
* Re-offer the quest. Repeat dialog 2 or 3 based on player response.
ELSE IF (The player accepted the quest but hasn't made progress yet?)
* Dialog 4: "Good luck on your quest. And here's a reminder of how to get started, since you probably forgot"
ELSE IF (The player start the quest but hasn't finished yet?)
* Dialog 5: "Wow. I'm glad to hear you are progressing. Here's a hint to help you finish."
ELSE IF (The player finish the quest and hasn't talked to the NPC since doing so?)
* Dialog 6: "Ah, cool! You finished the quest. Here's your reward."
* Dialog 7: "Hello again. I've got nothing more to say to you. Toodles!"
So - seven dialogs to accomplish relatively little. Now, since this is Frayed Knights, I don't just leave it at a single sentence or two that the NPC speaks - I (usually) expand it into a two-way dialog between the NPC and the various party members. And I try to inject some lame humor where I can. This comes out to a surprisingly significant amount of writing.
BUT ... it gets worse. Far worse. Oh, so much worse.
Are You Talkin' To Me?
The above only handles a very simple case for an NPC that has only one purpose in the game. And that's currently how NPCs are behaving in-game. But that's inadequate. I'd like characters in the game to project at least a slightly deeper illusion of life than simply being a person-shaped quest dispenser.
But what happens if an NPC is part of another quest, and has some key dialog to say if the player happens to be on THAT quest. Oh, our IF / THEN / ELSE logic gets a lot more confusing doesn't it? What if the NPC has a minor role in two other quests, AND has a follow-up quest to offer after the first one? What if the player has somehow angered their NPC (perhaps by "failing" a quest), and we need multiple dialogs to deal with a honked-off and non-honked-off character?
And what if they are also a merchant?
Whatever the case, the relatively simple logic of the example falls apart pretty quickly when you end up with more complex states. That means (to me) setting up a queueing and prioritization system for NPC dialog - queueing up all the dialogs that apply to the current player / game / NPC state, and then dropping all low-priority dialogs unless they are the only dialog in the queue. (And if this made any sense to you at all, you are probably a more l33t programmer than I am, and you are also able to translate from Coyote-ese, which makes you a very dangerous person).
It also means tons more writing, much of which the player will never see on a single play-through. Considering the quality of my writing, you can probably count that as a blessing.
Monday, June 29, 2009
Game Programming: Harder than Ever?
I learned computer programming when I was twelve years old, purely (at the time) to make games. I wanted to create my own clones of my favorite arcade games. And write adventure games and make games that emulated the D&D experience. Some dreams never die, I guess. But originally, it was all about the games. Software development (both gaming and non-gaming) has been putting food on my family's table for fifteeen years. So I guess as far as hobbies go, I did pretty good for myself.
As I mentioned in passing last week, I've been looking over some old books on game programming - including the ancient tomes that effectively taught me programming: Basic Computer Games and More Basic Computer Games, which are pretty beat-up but still in (mostly) one piece on my bookshelf.
It occurs to me that I kinda hit the 'sweet spot' in learning to program games. I started in an era where "home computers" had just become affordable, and many of them were built with the idea that the "users" would be programming. There just wasn't much of an industry out there at the time (especially within the first year of release) to support computer owners with software. Many systems had the BASIC programming language built in or shipped with the core package.
It was simple - relatively speaking. Other than saving and loading your single-file program, you wouldn't need to worry about files. Basic was an interpreted language, so you didn't need to worry about compiler settings, the executable, or anything like that. In fact, you could write a simple one-line program (like 10 PRINT "HELLO, WORLD!") and then type "RUN" and see your code in action right after the computer booted (or after you booted the BASIC disc).
You had very few options, tools were virtually non-existent unless you rolled your own, and the machines were dog-slow, barely capable of handling much more fancy than a Breakout clone in real-time unless you learned to write some machine code subroutines. You had - at best - sixteen colors to work with, very limited sound options, and a lot of the more advanced things you wanted to do required you to dig "down to the metal" and set hardware values via a memory map. You had to learn to avoid any unnecessary division or non-integer values (because they were very slow).
But, on the other hand, you usually didn't have to worry about upgrading drivers or tools, or having multiple programs running that interfered with your own, or sizing the window, or what weird hardware combination the user might be using, or how much memory they had, or whether or not their video card supported certain features, or whether or not you had something flagged wrong in your project settings for the compiler. It was a bare-bones experience, but the simplicity let you focus on the important things.
Contrast this with what an aspiring game developer has to do today. Sure - we no longer have to create spites on graph paper and manually convert that into byte values (well, okay, most of us wrote our own tools to do that back in the day anyway). But just learning how to use the tools available can be staggering. Take something like using PyGame to write a game (which I used for Hackenslash). A learner would need to do the following (for Windows):
* Make sure video and sound drivers are up-to-date
* Download and install the latest version of Python
* Download and install the latest version of the Windows Python extensions (1)
* Download and install the latest version of PyGame (1)
* Choose an editor for Python - learn how to use it. (I'm partial to PythonWin, but I haven't tried Eclipse with good Python plug-ins).
* Create a directory structure for their development area
* THEN - learn to program games in Python / PyGame
* ALSO learn the basics of your tools to create any content assets - though admittedly plugging in numbers for bit values for sprites is a WHOLE LOT harder in the long run than just learning to create .PNG files in The Gimp.
(1) - And make sure that the versions are compatible with each other - sometimes a problem shortly after a new major Python release.
Granted, maybe PyGame would not be necessarily for a purely text-based game of the kind found in Basic Computer Games. And, alternately - Microsoft Basic Express edition (or Visual C#) plus DirectX might make make a simpler installation - but IMO those aren't as easy or as straightforward to learn to use as Python.
Then there's another option, which is to use a game development toolkit like Game Maker or RPG Maker to construct a game. This is probably the easiest option that I can think of now - but it limits you to a very restricted universe. There's definitely a lot of valuable game development knowledge to learn going that route - especially in terms of game design - but I'd also worry that a lot of that knowledge wouldn't transfer very well to using more general tools.
So - since we have some development-folks who do hit this blog from time to time: What would be your suggestion for the easiest / smartest tool for someone learning to *program* (not just design) games?
Wednesday, June 24, 2009
The Evolution of a Game Engine
Scarily enough, I've been at this game development thing for a pretty long time. I have a few pretty obsolete books on making games in my library. Even discounting the really ancient ones (like Basic Computer Games and a couple of books on Commodore 64 game programming), there are some pretty vintage books.
I've been thumbing through some of these old books recently, including one that I picked up as a professional in 1995 but had hardly ever read. It was Lary L. Myers "Amazing 3D Games Adventure Set." Mainly, the book explained the source code and use of his "Publicware" raycasting engine, ACK-3D, which was a little more sophisticated than Wolfenstein 3D's engine.
The ACK-3D engine was released in the post-Doom era, which made it slightly obsolete even when new. Of course, the engine is almost hopelessly useless in this day and age, fifteen years later, except possibly by some indie developers who embrace the retro ethic (while I believe it uses a different raycasting engine, Terry Cavenaugh and Stephen Levelle's recent narrative game Judith would be a recent example).
But out of curiosity, I went online to see what ever had become of that little engine. How far did it go, and were there any notable examples of its use?
To my surprise, I found out that it is the great-great grandfather of 3D GameStudio. I doubt there's a single line of code in common between the 1993 original source and their latest A7 Engine (which, I should add, seems to be priced appropriately for indies, though I've never worked with it).
I doubt anybody but a code-monkey like me with a passion for game development would also find that interesting, but I thought it was an intriguing bit of history and look at the evolution of a game engine over the years.
Friday, May 22, 2009
Frayed Knights - Not Giving You the Time of Day
Because you demanded it - well, okay, you didn't. But because someone somewhere might be remotely curious... Wait, that doesn't sound quite right either. Okay - because I said I would, in spite of the complaints and angry pitchfork-and-torch-wielding townspeople - here's another installment in the continuing saga of the development of Frayed Knights, the comedic indie role-playing game (RPG).
When Last We Left Our Intrepid Adventurers...
This week, I focused on "The next five minutes." Not minutes 6-10 of the game, because that's already been covered (if subject to some changes) in the pilot. No, I wanted to focus on what happens in the next five (to fifteen) minutes of the game after the pilot ends.
If you remember, the pilot ends with Benjamin leaving the Frayed Knights in shame (and under threat of bodily harm) after it was discovered that he'd revealed their quest information to the leader of a rival adventuring group - Florentine - while in bed with her a couple of nights earlier. As a result, her team - the Heroes of Bastionne - had beaten the Frayed Knights to the punch, taken the prize, and used it to get into the good graces of the local member of the Adventurer's Guild.
Loose lips sink ships. And sink chances of getting a coveted membership in the Adventurer's Guild.
The pilot episode (which is going to remain in the full game in pretty much the same piece - enhanced, updated, improved, but not fundamentally altered) is somewhat constrained and a little more linear than I'm generally trying to go for. The next morning things open up a bit more. Shops are open, more people are about, and opportunities open up for more exploration.
This means a lot of work for me.
(Not) Giving You the Time of Day
One thing which I wanted to experiment with was changing the time-of-day. Now, I'm using the Torque Game Engine, which has some pretty nice lighting, but it comes at a cost - it relies heavily upon "static lighting" which it can pre-calculate in a lighting pass in advance. This is time consuming, and it caches the results so that future lighting passes take less time.
I spent a bit of time this week working on a dynamic time-of-day system, which unfortunately has a lot of ugly side-effects. For one thing, it breaks the lighting cache, so that it means we always have to relight all the time to make sure we've got things lit properly for whatever time-of-day you are entering the world. And it is time-consuming. Annoyingly so. Especially as the scenes and towns get more complex (as Ardin is about to...) .
So I'm looking for an alternative. This probably means having duplicate versions of areas -- one for daytime, one for nighttime -- which is going to be quite problematic, especially for setting up triggers and events based on area geography and my existing flag / event record system. There may be other solutions as well that might not look as good. Or I may have to fall back on not having time-of-day - which would suck. Because I'd hate to lose this:
Ardin By Day
Ardin By Night
Kicking Ben Out of the Party
So Benjamin was kicked out of the party at the end of the pilot. I didn't actually boot him from the party roster at this point, because there were more important things to worry about at the time (like getting the save-game working).
However, because the party roster WILL change a little as the game progresses, and because the player could probably use the ability to change party order around as things change, I implemented that this week. So the next day begins with Sir Benjamin NOT appearing in this party - he shows up as an NPC (non-player character).
Once again, I was impressed with how much flexibility I'd placed in my system to allow this, as well as by how much additional work I still had to do to make this happen properly. I had to create a "reserve party" to compliment the "active party," and a mechanism to switch between the two. The reserve party must also be saved with the save game - you don't want to lose a character's stats and updates in-between sessions, if they may be rejoining the party later, right?
This isn't to say that the Frayed Knights are going to have a revolving door policy on membership. Or that the world will be filled with recruitable NPCs. Since Frayed Knights has an emphasis on character and dialog, I have to keep pretty close tabs on the party. (This is part of why characters are "incapacitated" rather than killed or unconscious - I want them still able to talk! As a side benefit, it makes torture much more convenient...)
In addition, I added some other tweaks - like having speaker-less text in dialogs. And flagging it as an "aside" - an aspect of dialog that I have never used and I may never use outside of speaker-less text. The idea was that if party members are talking to each other without the other characters hearing what they were saying, this would be noted by a different color of background. In practice, I'm not sure it matters. But I like having expository text for the player.
The Big Event!
One major advantage of using Torque is the scripting system. While it can be amazingly frustrating to work with sometimes, it's also amazingly powerful. I mean, you can stick a script anywhere and execute it. I would go so far as to say it's moderately more powerful than the system in Neverwinter Nights. A lot more powerful, if you consider the ability for me to go into the source code and add even more functionality to the engine that can be accessed by scripts.
But - it's not all "hugs and puppies." There is a lot of framework in place for triggering recurring, non-saved-state events based on what is assumed to be a pretty static environment . TGE was optimized for first-person shooters, after all. Heavily conditional triggers based on sequences of other events firing don't have a lot of built-in support. Keeping track of humongously complex RPG states across saved games has virtually nothing built-in to help. So any support for this sort of thing is a do-it-yourself opportunity, which makes it a little harder to make some of the cool, complex behaviors and events like I used to do in Neverwinter Nights (which had it's own problems, as well).
Nevermind my willingness to kill for access to the amount of customizeable content I had in Neverwinter Nights, too...
Besides creating that level of support for myself (a bunch of "black triangle" work, some of which has been thankfully bearing fruit now), I've been going through a bunch of old RPG walkthroughs analyzing their quest and event structure for research. These games had fairly simple quest / event structures as well, and the designers managed some pretty cool things with very simple tools. They also managed to create some pretty amazing bugs, too, which is not anything I am immune to. But it has pretty helpful both to organize my thoughts and come up with some neat ideas, while avoiding absurd levels of complexity that I might otherwise saddle myself with.
Well, that's it for now. Time for me to hit the ol' dungeon again... meaning I have to build it. The Tower of Almost Certain Death is getting a new basement level, because it was just too small as a tower.
Sunday, May 03, 2009
Arcengine / Dungeon Eye - Version 0.1 release
Remember the "pseudo 3D" dungeon-delving RPGs like The Bard's Tale, Eye of the Beholder, Dungeon Master, Wizardry, and others?
Well, someone out there is laboring on an engine capable of making those kinds of games. While not as focused (or as cool) as the now-apparently-dead "Dungeon Maker" project, they developers have been making a remake of the Eye of the Beholder games within the engine. Entitled "Dungeon Eye," it's open source, and the source code is freely available. The documentation is practically non-existent currently, so it'll only be valuable to the technically savvy.
Now, I'm not 100% sure why you'd want to use this engine instead of something more mature like GameMaker (which would probably be quite up to this kind of task as well), but I'd be interested in seeing if anybody picks up the ol' torch on this one and does something cool and original with it.
Arcengine / Dungeon Eye
Thursday, February 19, 2009
The Most Influential RPG I Never Played
The original Wizardry (full title: "Wizardry: Proving Grounds of the Mad Overlord") was published in 1981 for the Apple II, written by Andrew C. Greenberg and Robert Woodhead. It was definitely one of the most influential computer RPGs of all time, and it was certainly a big influence upon me. And yet, I never played it.
Okay, "never" isn't entirely true. But I didn't have a machine that would even run it for many years. I played it a little on friends' computers when I could - particularly the gimped IBM port on my buddy's IBM Peanut - but I never made it past the third level.
But I read about. Oh, did I read about it. It was the single game I wanted most to be ported to my platform of choice during the mid-80's (by the time it was finally ported to the Commodore 64 - in 1987 according to MobyGames- I had moved on). I read about it and its sequels in magazines. I talked to friends who played it.
In 1983 I bought a book entitled "The Survival Kit for Apple Computer Games," which I still somehow have in my library. Not that I had an Apple. But back then, books on computer games were still pretty rare. And there was almost nothing for the C-64 out yet, though I knew many developers were frantically attempting to port their libraries to this new system. So I picked up the book in anticipation of seeing some Apple II classics hitting my beloved machine. I was especially interested in the Adventure games and RPGs (which they called "fantasy games" in the book).
I read and re-read the chapter on Wizardry. This was the game. The Cadillac of RPGs. Later, it would be dethroned by Ultima III: Exodus, which enjoyed a much speedier port to the C-64 and would totally blow my mind.
The cool thing about the book is that authors Ray Spangenburg and Diane Moser would not only include some hints and tips for playing the game, but would offer some prosaic paragraphs highlighting interesting or key locations in each game. In so doing, they would inject a little bit of their own imagination into what was otherwise pretty rudimentary, workmanlike in-game descriptions.
So in my mind, I envisioned Wizardry as a glorious masterpiece of programming and game design virtuosity. Sure, I understood its limitations as a self-taught programmer, and I expected nothing that was technically unfeasable or outside the obvious bounds of the design. But I did envision a narrative thread and event-handling that was far more detailed and complex than really existed. At least, I think it was more detailed and complex than really existed - having never completed the game, I can't be certain. But the Wizardry in my imagination was probably closer to what was eventually realized in SSI's "Gold Box" D&D games (with a touch of Zork) than what less hardware-disadvantaged players were enjoying.
But that imaginary Wizardry became my goal as I continued to improve my coding chops and trying to envision where computer RPGs would be in coming years. I was tilting at a pretty awesome windmill.
I ended up with one "playable" game that in a proud creator's blinded vision might vaguely resemble Wizardry. It was a party-based game. It allowed you to create characters,which meant accepting random stat rolls, picking a class, and giving the stat-block a name. You'd travel through a randomly generated maze in search of an "orb" - a very original goal I came up with all by myself. The upper-left corner would display basically one room's worth of walls and doors, and you could turn and move in pseudo-3D. I had maybe a dozen different monsters that would attack, with a little six-note musical fanfare that would play when combat began and ended. I started out by making the dungeon ten levels deep (with 10 x 10 rooms), but ran into memory issues and had to scale it back down to six. I don't believe the goal of the game - the "orb" - was ever actually possible to find, but some friends and I had some fun playing my little game together one weekend.
Later, I taught myself assembly language and wrote a routine to display a more complex bitmapped world several squares deep, similar to what you'd see in The Bard's Tale or the SSI Gold Box Games. It was a simple painter's algorithm thing that could display fountains and trees and stuff in addition to walls, floors, and doors. I failed to think far enough to realize I could render the whole scene in an off-screen buffer FIRST and then copy to the screen - so as you walked you could catch a split-second glimpse of whatever was behind the nearest walls. That project was never more than a tech demo, though. But hey - the visual display was cooler than that of Wizardry!
But it was the design possibilities that really got me thinking. As I mentioned last week, I'm all about exploration in RPGs. And I struggled not only with the technical issues involved in scripting a world big enough for my imagination, but also just coming up with a world as full and exploration-friendly as I wanted. I wanted a world with all kinds of meaning and story.
I'm still tilting at that particular windmill.
Friday, February 06, 2009
Frayed Knights: Little Victories
I was about thirteen when I got a Commodore 64.
I'd learned to program in BASIC on a Sinclair ZX80 earlier that year. The Sinclair had 1K of memory. Programming games on that thing was nigh unto impossible. A random game of tic-tac-toe was about the extent of its capabilities. Going from that to a whopping 64K of RAM (48K actually usable) was like heaven. Why, with that much memory to play with, I could make ANYTHING!
But there's a difference between having the technical capabilities of making something, and actually knowing how to make it. Naturally, I wanted to make RPGs. Or adventure games. There really wasn't much of a delineation back in those days. But I had no clue how to do it. After searching for inspiration in David Ahl's Basic Computer Games and More Basic Computer Games, I had some idea of how to drive a semi-data-driven interface so I could have a webwork of connected rooms that I could walk through with a text interface of directions like "north," "e," and "up."
I got it working at about 11:00 one night. I was exultant, but I had to refrain from cranking my music up and dancing a victory dance to avoid waking up my parents. They wouldn't understand. It was a Black Triangle moment. Anybody else looking at it would say, "Huh? What's the big deal about that? People have been doing that in adventure games for years."
But for me, personally, it represented a big step. I was able to walk around a virtual 12-room text-based world. I had found "The Way," and it would later provide the foundation for a few adventure-like games I wrote in my spare time (no, none were ever released to the public). I was able to see that.
When programming, there is roughly 10,000+ different ways of doing something. The trick is trying to figure out "the right way." The way that won't disintegrate into an unmaintainable mess when you realize you missed a critical feature and have to shoehorn it in. The way that won't make your life harder as it goes from exercising test data to using real data. The way that will probably STILL get completely overhauled once you've finished it and realize how you could have done it better.
And yet the average person will not appreciate it in the least. For example, doing UI stuff. Which I am STILL working on. For the average player, the amount of work that has to go into making a working drag-and-drop inventory is probably going to be completely lost on them. They just know that it should work.
On the design and coding side, there are a lot of issues to take care of.
Like what happens to the object - logically - when it is picked up from one an inventory and dragged across the screen? Does it remain in the original inventory, but hidden in the interface? Or do I remove it from the original inventory the moment it is picked up, but before the player has chosen what he's going to do with it? What happens if he tries to shut down the inventory screen or bring up the option screen with a keypress while holding an item with the mouse? If I bring up a pop-up screen of the items stats when the player hovers the cursor over an item's icon, should I still do it if he's dragging another item around? Will that be confusing? And what if I don't WANT to move the item, but simply want to activate it?
For what seems like a simple behavior, there are a ton of questions that need answered, code that needs to be written to deal with exceptional cases, and bugs that need fixing. Or I end up walking around with a wand icon stuck on the screen and my fireball wand permanently missing from my inventory, as happened in the picture.
All these elements all have to work together consistently. Otherwise, it feels clumsy to the player. As the first iteration of many UI elements did for a lot of players who tried out the pilot. I can't guarantee this new stuff will be a huge improvement, but it will be an improvement.
It's all boring, black-triangle-y stuff, yet I find myself feeling all excited and exultant when it works. Just as I was when I completed the rudimentary system to walk around a 12-room text-based world when I was thirteen.
But really, I'm just looking forward to it all working perfectly so I can FORGET ABOUT IT and just have it work for me so I can move on to bigger things.
Tuesday, January 20, 2009
RPG Design: Computer RPG Pattern Catalog
Ah, ya gotta love it when academia and computer games mix!
Here's a paper from 2005 where college students from the University of Alberta presented a catalog of higher-level CRPG "patterns" that could be used to replace the tedious, error-prone process of manual scripting. According to the abstract for their paper:
"The current state-of-the-art in computer games is to manually script individual game objects to provide desired interactions for each game adventure. Our research has shown that a small set of parameterized patterns (commonly occurring scenarios) characterize most of the interactions used in game adventures. They can be used to specify and even generate the necessary scripts. A game adventure can be created at a higher level of abstraction so that team communication and coding errors are reduced. The cost of creating a pattern can be amortized over all of the times the pattern is used, within a single adventure, across a series of game adventures and across games of the same genre. We use the computer role-playing game (CRPG) genre as an exemplar and present a pattern catalog that supports most scenarios that arise in this genre. This pattern catalog has been used to generate ALL of the scripts for three classes of objects (placeables, doors and triggers) in BioWare Corp.’s popular Neverwinter Nights CRPG campaign adventure."I haven't delved too deeply into it yet. But the point is to add a higher level of abstraction to the scripting process - which would, in turn, make the process of creating content much easier. Granted, it works across a limited universe to accomplish things in a fairly "Neverwinter Nights"-centric way. They do mention similar patterns in Morrowind and Fable. But I think CRPG developers would do well to take note and at least browse the paper and the list of patterns.
I've been thinking about making similar abstractions in Frayed Knights to make it easier to create (and maintain) the quests and events, and this has helped solidify some of my thoughts.
Computer RPG Pattern Catalog
A Pattern Catalog for Computer Role Playing Games (paper explaining the catalog - PDF format)
On a side note, isn't it awesome that we live in an era where you can find academic papes on this kind of thing?
Leadwerks 3D Engine Review
Okay, I really don't know why so many of my posts these days are about game DEVELOPMENT. I guess when you got your nose to the grindstone, you tend to think about the grindstone a lot. But that doesn't explain MY problem...
Anyway - GameProducer has a review of the Leadwerks 3D game engine, which also caught my curiosity a couple of weeks ago. VERY valuable reading, if you are an indie game developer.
Leadwerks 3D Engine Review
Friday, January 16, 2009
Frayed Knights: Butt-In-Chair Work
When I was working on Jet Moto, 3D modeler Michael Makarczyk was commenting on how a certain change to the code was going to force him to go back and change how his models worked. When producer Danny Lunt asked if that was going to be difficult to do, Mike responded, "Nah, it won't be hard - it's just a lot of butt-in-chair work."
I've used that term a lot since then. It pretty much sums up about 80 - 90 percent of game development. It's not particularly exciting or sexy. It's tedious. It doesn't make great screenshots. But it has to get done.
Implementing new UI systems is like that, as I am right now in Frayed Knights. Fixing bugs in the new code is like that. I spend a lot of time stepping through code, checking variables in a watch list, and muttering "WTF?" to myself a lot.
Some bugs are easier to fix than others. Bugs where things are just happening wrong are easy. You trace back through the code, find out where the virtual wires are getting crossed, and fix them.
Bugs where memory gets corrupted are a real pain, as the bug often occurs long before you see something go wrong. The worst of these are the dreaded "Heisenbugs," which seem to never occur in exactly the same place or time, and the bug disappears in debug mode.
Not quite as bad, but also among the more annoying bugs to fix are the ones where nothing happens. Everything looks right. But events just are not firing for some reason.
It is especially tricky when you are working with a third-party codebase, and when you've got the layers of indirection between a scripting language and the actual code, as you have with Torquescript. Have I mentioned lately that I'm kinda disgusted by Torquescript? It's not BAD, but it sure can be frustrating on big projects. If something doesn't work, you have layers upon layers of possibilities to try and figure out which of many stages simply didn't do what they were supposed to. Was it the triggering condition? Some variable that's not been set that needs to be set before some process you don't know about will actually execute?
Well, back to getting my butt in the chair and getting work done. Later!
Wednesday, January 14, 2009
How Much Money Can My Indie Game Make?
This question keeps coming up, and keeps getting answered the same way:
Not Much. Or Enough. Or Even Lots.
Really. Nobody Knows. Here's Why!
How much can your game possibly make? Roll on the Random D20 Treasure Table, but determine your game's level is determined by rolling 1d12 - 5, with values less than 1 resulting in a yield of nothing or incidental treasure because your mother had sympathy on you and bought a copy.
I've tacked the question myself. A couple of times, from my limited vantage point. And it really is one of those "how long is a piece of string?" questions.
Now, if it were really an absolute crap shoot, you wouldn't have any indie game companies still around. But the problem is that if you are asking this questions, there are so many variables that you don't understand (and many of them that I still don't understand, myself) that it might as well be random. Once you've blind-fired your artillery once, you can make an estimate of how far you missed your target and in what direction, and try to correct it for your second game.
When it comes to estimating sales, no amount of formulas and hand-waving can beat experience. But even experience can be misleading - for example, what makes a particular subgenre of casual games sell might be completely different for an RPG. Or - maybe not. But in general - ya don't know until you try, and it involves a tremendous number of variables involving competition, target audience, execution, polish, and marketing.
Ditto for estimating project schedules and budgets, by the way. One more reason to do a much better job than me at keeping good records on the amount of money and time spent across the board while developing your game.
Tuesday, January 13, 2009
Torque 3D Pricing and Other Indie 3D Game Engines
This is old news for those who actually care, but GarageGames is currently discussing plans with the community to beef up not only the power of the upcoming "Torque 3D" over previous products, but also the price. This has many GarageGames fans concerned, but not necessarily alarmed. According to Brett Seylor of GG, most concerns were centered more on making sure the new engine was actually worth the upgrade.
As for me, this spawned off some curious browsing on the web to see what the current state of indie-friendly game engines was out there. I don't have a detailed report or anything to make here, as I haven't had time to make an exhaustive search or anything like that, let alone put the other engines through their paces, but I think the sea of possibility for indie developers will remain deep and wide even if GarageGames were to go insane and price Torque 3D out of the reach of non-professionals.
The Unity engine is a recent popular choice, especially if you do Mac-based development. It powers Off-Road Velociraptor Safari, which is good enough of a recommendation for me. :)
The Game Creators GDK is a non-commercial free game development kit that's included free-of-charge with Microsoft's Visual Studio 2008 Express. Upgrading to a commercial license costs a mere $30.
The C4 Engine is still going strong, having just released version 1.5. They've bumped their standard edition pricing up to about $350, which is still a great price for a serious indie, but not such a great 'entry-level' price for beginners.
As a fan of Python, I found that the new Python binding for Ogre 3D is now called Python-Ogre, and looks pretty dang cool. Temptingly so. And the latest release of the open-source graphics engine Ogre 3D, version 1.6, was recently released - built in C++, but with multiple bindings besides Python.
I was pleased to find out that the good ol' open-source Irrlicht Engine is likewise alive and well. Version 1.5 was just released in December, and while the core engine capabilities haven't changed much since version 1.0, a lot of little things keep getting fixed - those annoying little bugs and missing features that you don't notice until you absolutely need it and then feel the pain setting in. Not to mention optimization.
3D Game Studio A7 remains a popular choice.
Truevision3D advertises itself as more of an API and "middleware," but is likewise indie-priced.
As a fan of Blender, I should know a lot more about the Blender Game Engine than I do. It's GPL (I think), which makes it pretty uninteresting to me.
The Cipher Game Engine looks to still be alive, but just barely.
Blitz3D - still an option for simple 3D game development, but I have no idea how scalable it is for larger projects.
Nebula 3 - This is a new open-source engine based on the Nebula 2 engine. Still a work in progress.
Leadwerks 2.0 - A new 3D engine (as opposed to a fully-featured game engine) with physics, great dynamic lighting (including volumetric light scattering in version 2.1), shader support, and an extremely indie-friendly price tag of $150.
Reactor 3D is an XNA-based 3D game engine in public beta right now, currently donation-supported. If you don't mind being limited to Microsoft platforms, it may be worth checking out for easy 3D programming.
You can take a look at the DevMaster Engine page for (somewhat) up-to-date entries and reviews on tons of engines of all different flavors.
And then of course, there are the current flavors of Torque, which I both love and hate, at their current pricing. Current TGEA owners have been promised a discount on Torque 3D when it ships, whatever its price.
So all-in-all, I think the potential out there for indie 3D game development remains more vibrant than ever, and looks to be getting better by the year. There are a lot of difficulties facing indie developers wanting to create 3D games, but it looks like the availability and pricing of reasonable technology isn't gonna be one of them.
Wednesday, December 31, 2008
Learning to Make Games - What's Available?
This is a pretty off-beat question, I know, I wonder if aspiring indie game developers out there have found that there is sufficient tutorials, books, and examples out there to learn how to make small, indie games.
From my perspective, there seems to be tons out there. Most of it is oriented towards beginners (that's hardly unique to making games), but one question is whether or not they adequately handle the breadth of possibility out there. Just handling a single subject like sound can take an entire book (and has!).
Back in the day (way, way back then...) we had a handful of books devoted to game programming on our platform of choice (the Atari 400 / 800, the Apple II, Commodore 64, VIC-20, TRS-80 Color Computer - informally called the "Trash 80" or "CoCo", the TI-99/4A, the Sinclair / Timex, etc.) They pretty much covered the same topics, and there just wasn't that much area to cover. The C-64 has some special-purpose hardware sprites and a fairly unique (and powerful) sound chip called the SID chip, but otherwise making a game was making a game, and your language of choice was BASIC until you got ahold of a decent assembly compiler and took that step yourself.
Nowadays, just choosing your language and core engine / API can cause analysis paralysis. Or what modeling package you'll use. Or your target hardware requirements.
I've been curious because I've received several emails from people asking, "How do I get started?" I really don't know the best way to get started anymore. I'm a little bit past the "Game Programming for Dummies" stage, so I've not really investigated what's available, but I'd like to help. We always need new blood coming in and showing us how it can be done!
Wednesday, November 19, 2008
Torque Game Engine Prepares to Ride Into the Sunset
After many (too many?) years in service to indie game developers, it sounds like GarageGames is preparing to retire the Torque Game Engine from active duty, to be replaced by the "Torque Game Engine Advanced" as their flagship 3D product. Here's the scoop:
Torque's 2D and 3D Future, Volume 2
This probably won't mean the end of games made with TGE, or the end of its availability, simply the end of it being actively maintained by GarageGames. According to Brett Seylor, "you're not likely to see an update to TGE soon, or perhaps every again..." So while not put out to pasture yet, it sounds like it hasn't been an active concern for a while. He continues later, saying, "At some point, TGE will likely either go away, or be licensed in a different way... To be honest, we haven't decided and we won't be doing anything about it right away."
I sorta expected this sooner, truth be told. The problem has been the lack of maturity with the advanced engine. Until the tools could get up to snuff with TGE - and especially before they had OpenGL or Mac support - there was just no way TGEA could shoulder the burden of replacing TGE. But it looks like times are changing, and TGEA has advanced enough that pulling the plug on their 7-year-old product (built on top of an even older product) is only a matter of time.
What does that mean to prospective game developers? Well, it could mean that TGE might become cheaper in about a year... :) But if so, with the reduced cost will come limited (if any) support. It also means that TGEA is getting the level of tender loving care that it needs. But as Seylor makes clear, it's still up in the air, and there's no urgency in making any kind of decision. They may just leave TGE as a second-string, less-promoted, less-supported option on life support for years to come.
As for me, I'm not planning on switching engines until my current projects are completed, so I'm still in my TGE "Franken-engine" for the time being, no matter what GarageGames decides or when it pulls the trigger.
Friday, September 19, 2008
Frayed Knights: Back From the Dead
So here's the latest update on Frayed Knights, the comedic indie RPG in development from Rampant Games (an older work-in-progress "pilot" available here).
Frayed Knights has been dead for a couple of weeks.
Not dead as a project, but for me, Frayed Knights has been non-functional for a couple of weeks. Merging my heavily modified 1.5 codebase for TGE and the 1.52 codebase for TGE plus the AFX special effects code, plus TGB 1.3 (the last version that was pretty compatible with TGE) overlayed on top of that felt a little like making a time machine out of a DeLorean. But since even a used DeLorean costs over $25,000, this option was more economical. Plus, I didn't run the risk of splitting up my parents before I was conceived and thus unmaking myself in a time-travelling paradox.
With the stress and long hours of the previous day job behind me (and let me tell you - the loss of that stress literally felt like the relief of a physical burden - I can't tell you how much BETTER I've been feeling the last three weeks), I've felt the strength and desire to proceed to the next phase of Frayed Knights' development. This allowed me to tackle the merge which I had been putting off. But the resulting problems frustrated me and reduced me back to "tinker" mode - I'd work on a map a little bit, make some design notes, add to my "wish list," and then go back to surfing the web and playing Wizardry 8. Yes, I can procrastinate with the best of 'em.
The saddest part? Fixing things, once I committed to doing it, only took a couple of hours. I am once again reminded that I work best on a milestone schedule, with a list of tasks I am (loosely) committed to completing by a certain date.
So what does this merge give me? Well, besides a bunch of bug-fixes and optimizations for a planned Mac build, it gives me access to some new and improved interior changes used by Torque Constructor. Since I've had some waking nightmares with the "legacy exporter" in Constructor, this will hopefully improve my content development pipeline. There are some improvements to lighting, particularly with static meshes.
And then there's the AFX code. In a nutshell, it includes a whole slew of changes to the decal and particle system - primarily, though there's more to it than that - that allow some pretty awesome spell effects. There's a screenshot to the right of AFX in action in the Torque demo.
With that done, I'm back to working on some core technology. I am considering some massive changes to how AI works, how combat plays, and how inventory management is handled. I also need to finish the journal system and the transition map system now that we'll have more than two areas to go between.
Since I work best committed to a deadline (it stops me from "tinkering"), for next week I'm going to finish the design work and the rough-out of the Tower of Almost Certain Death and the first wilderness area, get trading completed with NPCs, and get started on the revised journal system. That ought to keep me busy.
And I'm gonna get back to trying to post an update weekly (or at least semi-weekly), as I was before I went into soul-sapping crunch-mode hell. Public reporting of progress keeps me from falling back into "tinker" mode.
For those who haven't tried out the demo yet, community member Demiath has uploaded a YouTube video of the first five minutes of the Frayed Knights Pilot. Which I think is extraordinarily cool. Feel free to go there and comment on how cool Demiath is, or your predictions on how Frayed Knights is going to outsell Diablo 3 when it is done (hey, if you are gonna dream, dream big...). It also helps to watch someone else play the game to remind me what things I need to fix / improve. Here it is in all its embedded glory (you will want to switch to high-quality mode on YouTube to be able to read the text):
And that's it for now. TTFN!
Monday, September 01, 2008
Torque Makes Me Feel Stupid
I've been a professional programmer for nearly 15 years. I've worked with several game engines, programmed in lots of different languages, and done everything from GUI development to AI to assembly-language pipeline optimization for the dual Hitachi SH-4 CPUs in the Sega Dreamcast.
Yet the Torque Game Engine still makes me feel stupid. I've been working with the thing - on and off - for years, and I still don't fully understand its architecture. I'm not sure anybody does, anymore. Maybe Melv May.
Not that it's a bad code base. Anything but. I've worked with a lot of game and graphics engines, and they all have their warts. Every single one.
But I just did a merge of the existing "FrankenEngine" for Frayed Knights, and tried to merge it with the new, updated code and the "AFX" advanced lighting / particle effects code. It seemed to merge pretty easily.
One might say... too easily.
Now I'm trying to play Sherlock with code that ALMOST works, but is completely unplayable. Catching something like a crash bug is easy. Catching where something somewhere is silently failing and just not working is a lot trickier. So I'm feeling awfully stupid right now, because if you aren't totally sure of why stuff works, it's a lot harder to figure out why it is not working.
Monday, July 21, 2008
Making Game-Making Easier
Archimedes claimed, "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world."
I think Archimedes was a game developer, and the rest of his quote (translated from ancient greek) reads, "... because I really need to move the world 200 units in the positive Y direction so I can stick the new sewer passages in before next week's milestone."
Game development has changed a lot since I first got in the business. Once upon a time (before my time), it was more about programming wizardry. Now it's much more data driven. And while programming wizardry is still a significant part of things, the bottlenecks I keep seeing are found in the tools and the tools pipeline.
Well, the tools are the various editors, modeling packages, and so forth that you can use to make content for your game. One of the problems with tools over the years is that they have gotten significantly more powerful, but not easier to use. In Doom's heyday, a solid level could be cranked out in a single day. Maybe another day or two for polish. Nowadays, a level generating approximately equal amounts of gameplay might take an entire man-month to create.
Herb Flower, of LinkRealms, was talking to me last year about his days with ReWolf, doing a commercial half-life mod. He said that back in the late 90's, the mod scene was vibrant and alive for all of these games. But now - not so much. In part, it is because of the commercial viability of the mod scene - teams are very likely to fall apart over squabbles of who gets what potential share. But it's also in part due to the complexity of making mods. The requirements for what constitutes "acceptible" quality is much higher, and neither the tools nor the modmakers can keep up.
The tools pipeline is a whole 'nother story. This is the path that takes all the content generated by the tools, and imports it into the game. This has been the weakest link in the chain everywhere I have worked, including my own Rampant Games. The process is typically slow, tedious, and error prone. This makes it hard for the artists and designers to actually see and test their work.
Somehow, miraculously, old data finds its way creeping into the build, and things that were fixed days ago become broken again. Something silly like a missing texture won't be detected until twenty minutes into a 30-minute process, which forces you to start over from scratch. Annoyances like that, which compound upon each other, until what should have taken less than an hour ends up taking all day long.
Just think about it - what if making a game level were not much more difficult than sketching it out on graph paper? (And yes, before you say anything, I do know about SketchUp). Could we compress the amount of time it takes to do 90% of the work? Could we begin working on "meta-tools" - tools to make tools - for game development? I look at the (relative) simplicity of putting together Neverwinter Nights modules. Sure, there was some missing power there, but the thousands of user-created mods that came out is evidence of what that level of productivity you could get from designers and content creators when you make it simple, easy, and error-resistant.
(Yes, I have been fiddling around with level editors this weekend, how did you know?)
Frankly, if we want to talk about making better games, we should quit thinking about better pixel shaders or more realistic hair movement. The limiting factor is no longer in those technological elements, but in what I'd consider logistical ones. A skilled designer, animator, artist, or even programmer with a world-class set of tools and a painless, fast, error-free pipeline can be 100 times more productive. Which would mean better gameplay, better polish, and more innovation.
Wednesday, June 18, 2008
Steven Peeler Talks Indie with RPS
Rock Paper Shotgun has a very cool interview with indie RPG author Steven Peeler, the guy behind the awesomelicious Depths of Peril. Some bits of trivia coming out of the interview:
* As I expected, Steven is the only full-time guy at Soldak Entertainment. The other names in the credits are contractors.
* Shortly before leaving Ritual, he pitched another RPG design - a very tense, scary, first-person-perspective RPG. Nothing like Depths of Peril.
* Soldak is not his first start-up company (or his first start-up company working on RPGs)
* His inspiration comes from an outstanding list of classic, old-school RPGs --- and Dungeons & Dragons.
* He's got another top-secret project that's "pretty far along now," but not talkin' about it yet.
He also talks about his decision to go indie after being pretty up the programmer hierarchy at a major development studio, where he came up with the design of Depths of Peril, the difficulties inherent in creating such a dynamic-world game, and much more.
If I were to teach a class in making indie RPGs, I'd put this article on the "required reading" list.
RPS Interview With Steven Peeler of Soldak Entertainment
Monday, June 09, 2008
How Do I Make An MMO?
Friend and fellow veteran mainstream & indie game developer John O. forwarded me an email he sent to a young aspiring game developer who asked him for a step-by-step process to create an MMO. I doubt the young man who asked the question realized that it was something akin to asking for a step-by-step process to building a space shuttle.
But John answered his question as best as he could, because he's just that much of a nice guy. And he shared his answer with me as something I might address here on the blog, because I'm lazy and love to borrow (with permission!) someone else's content. Although in this case, I'm gonna paraphrase most of his answers.
Step 1: Identify Your Rationale
Why do you want to create an MMO? Are you looking for fame & glory? Do you think you could do better by yourself than Blizzard and their hundreds of employees and budget of hundreds of millions? Are you interested in making tons of money? Are you just wanting to learn? Do you see some virgin territory within the genre that you'd like to explore? The last two answers are pretty good. The others - not so much. But the important thing is that you identify your reasons and choose a path that satisfies that rationale.
Oh, and if it's tons of money you are after... go into some other field, not games.
Step 2: Educate Yourself
Okay. Bottom line - if you have to ask how to make it, you aren't ready to make it. If you are looking at going into mainstream game development, you are going to need to specialize. If you are going the indie route - well, you've got even more to learn. If you want to be a programmer, you'll want to study up on math, geometry, physics, and of course programming languages. I don't care what language you start with. I started with BASIC, which is obsolete today. Python, C, C++, C#, Java, LISP, whatever... start with a language you have access to, where you can find lots of educational and game-development resources for (I'm partial to Python and C++ myself), and learn.
Study up on storytelling. Study literature and fine arts. Those will help you with design. And art, if you also take that route. And if you really do want to go the indie route, you should study up on marketing and business management, too.
Study up on the game industry. And play games! Play the games you don't like. Study the successful ones. Study the unsuccessful ones. Learn to identify the difference. And do not just look at mainstream games. Play those games your mother and your kid sister like.
Step 3: Keep Track of Your Ideas
John writes, "Keep notes on game ideas and designs. Organize them. Include maps, statistics, artificial intelligence, algorithms, look and feel, quantities and quality levels. This stack of notes will be what you draw from for future projects."
I say there are three things going on here:
Number one - almost all of your ideas will be lame. Probably. Deal.
Number two - Write them all down and keep track of them anyway. That's a killer habit to get into. The more you track your ideas, the better they will flow - both in terms of quantity and quality.
Number three - learning to organize those plans and determine all the little bits and pieces that are needed to support the design are critical skills. Skills I too often lack, and that bites me in the butt. Often.
Step 4: Start Small
Write games. Don't start trying to write World of Warcraft from scratch. It'll only end in tears and frustration. While it may be far from your dream game, take your baby steps. Old-fashioned arcade-style games are a great start.
Learn to mod bigger games. Neverwinter Nights is a great place to start, IMO, because it incorporates a lot of elements that are also present in Massively Multiplayer Online RPGs. I also highly recommend you try to build a small world on some kind of MUD / MUSH / MU* codebase. That's a lot of where the MMORPGs came from. The folks who were working on those things a decade or two ago have in many cases forgotten a heck of a lot more about creating multiplayer worlds than many professionals making MMOs have ever learned.
John also recommends joining another game development team, perhaps on an open source game.
Step 5: Go To College
John writes: "Go to college. By the time you’re 18-19 you should have a good idea whether you really enjoy coding (computer science), electronics hardware (computer engineering), or would rather concentrate on team management (business) or model design (art). Getting an undergraduate degree will give you a safe backup plan. That way you can either land a job doing games, or get a job doing whatever your degree qualifies you for, and then work on games on your own time."
I may not agree 100% with this one, but lacking some compelling reason to do otherwise (like being a successful game or business tycoon at age 17), I'd say follow this advice. You really want a broad education when you go out in the world - in the games business or otherwise. And while it may sound impossible to imagine right now, there may come a time when you really want to something other than games in your life, and you don't want to be unqualified to do anything else.
Step 6: Start With a Kit or an Engine
Okay, once you are finally ready to make a "real" MMO, I'm going to say here - don't start from scratch. There are lots of engines and code-bases out there that will give you a leg up. Now, the downside is that Betty Crocker's EZ MMO Mix is going to result in a pretty generic MMO when you are done compiling that doesn't come close to matching your vision. That's okay. Remember back in step 4 when you were learning to mod games? This is where that skill comes in, but on a larger scale.
This is my own addition to John's list. While it's cool to have the skills to create a game from scratch, including the engine, you have to decide for yourself where your passion is. Remember step 1? Do you want to make a game, or create technology? There is no wrong answer here, but if you create your own technology, be prepared to never have time to move on to the game.
Step 7: Ignore the Steps
The order presented here doesn't really mean that they should be followed in any sequential order. You can do all of these at the same time, actually. There are a lot of indies who are doing it all while still going to college (though I don't want to imagine what their GPA looks like...) Yeah, it's going to be rough when you start out. Just remember that just about everyone who was ever awesome at something didn't emerge from their mother's womb as an expert in their chosen field. They had to struggle and learn and grow, just like you.
Friday, May 02, 2008
Steamworks SDK Now Available
Released yesterday... the Steamworks SDK.
While it's absolutely free for developers, I suspect that in the long run it's going to make Valve a hell of a lot of money. The whole "Windows Live" gaming thing ... the Windows equivalent of XBox Live... is pretty much stillborn. It looks like Steam is going to be the XBox Live for the PC. I give it less than five years before Valve becomes the "evil overlord" people complain about.
Anyway, the API includes calls to handle Stats & Achievements, Multiplayer authentication, matchmaking, anti-cheat, networking, community calls (to pull up things like the other player's clan, avatar, and so forth), integrated in-game voice communication, and everybody's favorite... DRM.
Friday, April 25, 2008
Frayed Knights - Pilot Release Hours Away...
More Tales from the development of Frayed Knights, the indie RPG of humor and high fantasy.
There really ain't much to tell. Not that this has ever stopped me before.
My drop-dead date is Tuesday. I need to get the file to a magazine on that date. I'm trying to get another beta out tomorrow-esque for the testers to hammer on. There's so much I wanted to get in for this release, but won't make it. But I think the game is fun, and will do a good job of what it's intended to do - solicit feedback, and gauge the reaction of players.
The automap is back in, and better than before. This was the biggest, most critical task I've been facing, one that I wanted to get in before Beta, but failed to pull off. Aside from that, and implementing a few very minor suggestions, I'm focused entirely on bug-fixes. Doors that don't work right. Scrolling on the party inventory that isn't functioning properly. Etc.
The biggest frustration at this stage of the game is that things are progressing excruciatingly slowly. I'll be very glad when this pilot release is done and we can go crazy again with content. I expect the game WILL metamorphize somewhat in its core code based on player feedback. However, my hope is - now that we have a semi-stable game, it'll be content city. Scripts, dialogs, maps, monsters, treasures, and character progression, baby!
Watch this space for the announcement of the public release.