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

Labels: Indie Evangelism, Interviews, programming, Roleplaying Games

- posted by The Rampant Coyote @ 8:10 AM (Permalink) 0 comments links to this post

 
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.
Good luck!

Labels: productivity, programming

- posted by The Rampant Coyote @ 8:14 AM (Permalink) 1 comments links to this post

 
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.

Steamworks SDK

Labels: Biz, programming

- posted by The Rampant Coyote @ 8:08 AM (Permalink) 8 comments links to this post

 
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.

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 2:45 PM (Permalink) 2 comments links to this post

 
Frayed Knights: The Oncoming Dragon
More development diary stuff for Frayed Knights, the comedy-based indie RPG.

"The light at the end of the tunnel may be an oncoming dragon."

I saw that on a button once, as a kid. As a sci-fi / fantasy / RPG geek, I nearly bought it. It was a pretty lame word substitution for a more common pessimist joke, and I was broke, so in the end I opted not to buy this little bit of geek flair.

But it feels appropriate now. I just made the last "alpha" available to the testers (hey, testers, it's up, check the testing forum!). I call it an "alpha" because I'm still adding some new stuff to it, though with the help of the testers the bugs are getting pounded into some level of submission resembling a mid-beta (I think). But the testers are getting weary of testing the same game week after week. I expected this, Which is why I staggered out the testing groups.

The saved games from the last alpha were by far the largest source of bugs so far. I expected as much, but it has still been a pain hammering them out. As of this morning, I think I have all the save-game related issues resolved, but there could easily be more.

The next release - next week - will be our beta. Hopefully the one and only, but if any major bugs are found, I'll do a quick revision within 48 hours. Otherwise, my expectation is that the release of the pilot will be on or around the 25th. The short beta will hopefully be offset by the long alpha.

And then the oncoming dragon hits me.

There is a lot that isn't there that I hoped would be. There are a few things that I'm afraid will draw most of the attention from players, instead of other areas I'd like people to provide me with feedback. There are features I wanted to get in, and suggestions from testers I really want to implement, but I'm just out of time. That's how it always goes, though. Games are never truly finished, only released. I could keep working on this for a decade, and it would still not be "quite ready yet."

The effort I get to put in now is as much to support the release as to actually work on the game. stuff like updating the Frayed Knights website. Adding a feedback form. Getting the installer working. Finishing up the documentation. I really want to be moving on, implementing more of the requested features so far and adding the new content for the full release... but this milestone is my master right now.

For those who might be curious, here's most of the stuff that went into alpha 4, not including some minor tweaks and bug-fixes that I failed to record:

* Player now moves a little bit faster
* Fixed Bug: Front-End Music was... Whacked
* Switching between full-screen and windowed fixed res changes
* Resolution forced to 1024 x 768
* Forces full-screen if desktop size is 1024x768
* Fixed some Dialog typos
* Fixed non-container loot awards
* AI can now cast spells
* New Monster: The Pokmor Xang Priest (priest-class enemy)
* Fixed Crash on reloading saved game multiple times.
* Implemented "Curses!" spell
* Fizzles now end a character's turn
* Monster names should reflect targeting name.
* Reset drama point level on reload
* Monsters no longer attack in the middle of trap / lock dialog
* Cleaned up component connections between trap screens
* Added some minor loot to the front entry area to reward exploration
* Cancelled Drama Effect no longer consumes drama stars
* Cancel button on character selection menu no longer cut off.
* No longer force combat completion after phase 200 (old test code)
* Added Hotkeys!
* Traps: Game now chooses best default disarming character.
* Empty Bag in front hall was removed.
* Fixed disappearing item bug
* Improved drama point award for more difficult combats
* Certain events (like reaching the statue) now have an XP award
* Added Liquid Nap potions
* Fixed Pokmor Statue bug not appearing on saved games
* Escape and Enter Keys now have default actions across in-game dialogs
* Major clean-ups to world reset on load
* Fixed crash when changing zones after a load

There is a lot of work that needs to be done for the beta. I still have a list of bugs to get squashed, and there are a few features that I'd like to get into the game but which I'm not sure will make it. Things like buying and selling equipment; the leveling-up screen; improved UI art for submenus; a compass; the automap overhaul; new items (including Chloe's fireball wand); a couple of new spells; some additional hotkey commands to speed gameplay; lots of TLC for Ardin Village; additional interactives in the temple of Pokmor Xang; better combat balancing; sound volume corruption in the Torque engine; lighting optimization in the Torque engine; dropped loot for certain bad guys (that's half-implemented); and a lot more. As you can see, with only two weeks left to release, not all of that's gonna be in there.

But even so, I'm not unhappy with where it is right now. And I have to admit - as exhausting as this is, as crazy as it makes me... I really am having a good time making it.

Hopefully you'll like it.

Labels: Frayed Knights, programming, Roleplaying Games

- posted by The Rampant Coyote @ 9:01 AM (Permalink) 0 comments links to this post

 
Frayed Knights - Alpha 2 Laundry List
Boy, this week's installment of the Frayed Knights development diary will have you on the edge of your seats!

Okay, I lie.

It's not particularly exciting. I haven't actually heard many people singing the praises of the first alpha, which always makes me assume the worst. "Aw, crap, the game's a dud. NOW what?" There WERE a lot of bugs - about half of which I was aware of (though I had failed to record them all). I actually have enough bugs to carry me through an entire second week of alpha... but the sooner I know about other bugs, the better. On top of this, there are a bunch of suggestions (especially with the interface) and other last-minute enhancements I'd like to make before this goes "final."

Game development is just SO thrilling and glamorous.

DGM did make the comment that for someone who has been reading this series from the beginning, there weren't a whole lot of surprises. I think that will be an additional focus over the next two weeks - throw in some surprises. :) There are a few plot-development elements that I left out of the pilot that I want to squeeze back in.

Anyway, if you were in the first alpha group, the new download is available. Check the alpha forum for instructions.

I'll be adding people to the second alpha group today. Check your emails and private messages on the forum. I expect the alpha 1 group is gonna be all burned out after playing through one or two alphas, so I need some fresh eyes on things. If possible - keep track of how much time you spent playing (I really should automate that). Even though it's not a great estimation due to the lack of save and load functionality right now, it helps.

Sorry for splitting up the alpha into groups like this again... but having done a bit of testing myself in the past, I know how hard it can be to aggressively hunt down bugs in the fourth or fifth build that you've seen.

Outstanding major issues remaining in Alpha 2

• Temple is still not re-entrant (meaning when you go back, things aren't left the way they were)
• Save / Load games still non-functional (and still crash the game if you attempt to load a saved game)
• Inventory is still disappearing when you transition between zones
• Priests are not dropping random loot
• You can get stuck inside doors
• No buying / selling with vendor
• Hotkeys for pendant commands
• Priests not casting spells
• Item descriptions do not include stats
• Character Sheet doesn't reflect stat bonuses due to equipment
• Journal needs to update when quest completed.
• Need to fix the automap
• Removing an item from the bottom of the party inventory causes some weird inventory behavior until you close and re-open the window.
  

Fixes in Alpha 2 (at least all that I remember)

• Particles for all (current) spells
• All drama star effects are now working and use points properly (I think)
• Inventory Items are scrolling now
• Skeletons and treasure by cave-in
• More stuff in Kraltic's Room
• Bad guys in front of torture chamber
• Bad guys in front of meditation room.
• Fixed loot in pantry in food prep room.
• Current character frame pushed back and textured
• Fights through doors now force player into good visible position
• Barrel in middle priest room #2 made interactive
• Trigger zone encounters force player into appropriate position for combat.
• Fixed description and dialog of pool to repair typos, special characters, and to assume Dirk has a 10' pole to jam down there.
• fixed several typos
• Changed "K.O." to "Incapacitated" and make it separate from picture (and always up)
• Forced window / full screen to 1024 x 768
• Added base colors to Benjamin Sly portrait
• Fixed in-game options menu bug
• New texture on inn roof

That's all I've got the brainpower for this week. It's been one of those weeks...

Labels: Frayed Knights, programming

- posted by The Rampant Coyote @ 3:02 AM (Permalink) 7 comments links to this post

 
Frayed Knights: Going Alpha
More tales of the development of Frayed Knights, the comedy RPG. Or more specifically, the Frayed Knights Pilot - The Temple of Pokmor Xang!

This Week
I could tell you what I worked on this week. Which is to say, a little bit of everything. Just getting it so that the game could be completed from beginning to end without any major weirdness or bugs, up until the final "end game" menu (including stuff happening in town). I just got some new music AND a new tavern model, which required me to re-arrange everything in the tavern to suit. I really like the new tavern. A lot.


Last Minute Changes
I took Friday off, both for getting this alpha out, and for attending a wedding of two close friends of mine. This has turned out to be a good thing. Between the alpha and a bit of personal business, I ended up pulling an all-nighter, until past 6 AM. Most of the time was spent working on some major inventory screen bugs. I missed them back when there was only about a dozen things in your inventory, but with there being actual loot in the dungeon now, I discovered some problems.

I also devoted some effort to fixing odds and ends, and prepping the whole thing for alpha. I had to make some dialog changes (and I don't think all of the revisions actually made it into the alpha... oops!). There were way too many "known issues" that I just couldn't get to, but I needed to get people on the alpha. Some of the changes thrown in during the wee hours of the morning were pretty significant. I made some changes to how resting is handled that I still don't know the full impact of. And I know for sure the feedback mechanisms for some of the mechanics are woefully inadequate.

Getting the download size down from 120 megs to 71 megs was part of that effort. Writing something by way of instructions was another.

But the first alpha - and the invitations to the alpha test group - went out at the 5:00 hour. My apologies to the people who aren't in the first alpha group, but I really want to hold people in reserve as "Kleenex testers" for future alpha versions. Testers, check your private messages in the forum, and check to see when you get access to the Frayed Knights Testing and Feedback forum. Some people have it already.

The Road to Alpha 2!
Some things topping out my list for alpha 2 include such minor luxuries as actually having the item screen tell you what the item really DOES, so that you don't have to guess whether the iron mace or the broadsword does more damage. And having a visual display of how your maximum endurance drops over time would be kinda... I dunno... less confusing? And then there's the fact that players can get stuck inside of doors. That's not a happy thing. And some fixed combats end up taking place with the opposing forced practically across the room from each other but still swinging melee weapons. Yeah, that might be good to fix.

And actually implementing the weapon and armor proficiency restrictions might make the different character classes more interesting. Oh, and having the big bad evil boss guy actually USE the spells he's got in his arsenal... that might make a difference in combat. And the priests are actually supposed to drop loot once in a while. Now the operative word is only, "once."

This kind of torturous, bug-riddled gaming is what I subject my friends to. I am a bad man.

Development is going to continue at its previous pace for the next month, easily, so Alpha 4 should be pretty different from Alpha 1. My goal is to have each alpha released Friday-ish throughout March. Tuesday, April 1st, 2008 will be the public release date of the Pilot.

Placeholder Content FTW!
And just so all the testers know, Kevin wanted to make absolutely sure that they knew that the revised Tavern roof texture is only a stand-in.


Well, I managed to sneak in about three hours of sleep between 6:30 and 9:30. I have an appointment to meet someone in a couple of hours, and then I'm gonna try and get another nap in before getting ready for the wedding.

Have fun!

Labels: Frayed Knights, programming, Roleplaying Games

- posted by The Rampant Coyote @ 5:00 AM (Permalink) 3 comments links to this post

 
Questions for Indies Part IV
This article is the conclusion of the "XFire Debate Club Annex" that Corvus Elrod and I have been doing for the last month. In this series, we took a bunch of questions that were asked in the audience participation chatroom that didn't make it to the actual debate, and we're giving our best answers. At least, trying to mask our stupid looks and ignorance.

This week, we've got four questions about the business of making indie games. These are fun, because ... while I have answers for them, I don't have "THE" answers for them. There probably is no "real" answer. But these are based on my own experience, and that of other successful indies that I have had contact with.

I should have a permalink from Corvus soonishly, but he should soon have his response to these same questions: XFire Debate Club Annex, Part IV

How do you start making indie games? What kind of education do you need?
I'll start out by answering the education. You don't need any kind of education, but you need to be educated. Does that make sense?

In other words, a formal education might help, but it's not required. However, I can't count the number of times I've been asked by someone, "How do I get started? I have a cool idea for a game! But I have no money, no team, no art skill, no marketing experience, and no interest in programming." My answer is: "No chance." It ain't happening.

If you are going to make an indie game, you are going to wear many hats. If you want to be in charge, make your own game, then it means you will need to know a little bit about a lot of things - and where you are lacking, you are going to need help, and you'd better know somebody who can chip in their expertise. But for the most part, you will need to educate yourself about all of these things. Indies don't have the luxury of being paper-pushing middle managers, or sitting in some ivory tower and being "an idea guy." Indies are low-budget, down-in-the-trenches, roll-up-the-sleeves and get it done people.

If you aren't willing to learn and become educated (through OJT), you shouldn't be trying indie games. I'm learning new stuff every week. That's a big reason why I love doing this stuff.

Now how do you start?

You start as simple as possible, IMO. Pick your technology, pick your game, but make it something you can start (and finish) quickly. People ask me "how do you estimate the time it will take to complete tasks," and my only answer is, "Past experience." A hotshot programmer may be able to get something done in a day that takes an inexperienced programmer two weeks. A skilled artist may get something right on the first try, and an inexperienced artist may go through a dozen iterations and end up with something that is merely adequate.

The only way you can learn is by doing. Grab yourself a copy of Game Maker and make yourself a breakout game. Learn Python, grab Python and PyGame and maybe the source code to Hackenslash and and make something out of it that doesn't suck (or sucks less than what I made...). Start building. Try to make something in a single day, if you can. Or a week. Or a month. Just make something you can finish.

Start by getting a screen up. Then get some player inputs working. Then bring in your own custom art, and learn what that takes. Bring in your own sound effects, and see what it takes. Then wire in your game logic. Then finish all the features, menus, UI, and the zillion other tasks that you will discover your need. Then make it FUN. Then polish.

There's no better training in the world than actually sitting down and making a game, start to finish, even if its nothing but a Space Invaders clone. The scale and budget changes, but the basic process remains the same.

How big is your team? How big do you wish it was?
For Frayed Knights, my team is three people right now. I'm the designer / manager / producer / programmer / buck-stops-here guy, and I also do a little bit of 3D modeling and 2D art (where it's simple), marketing, business development (signing contracts, purchasing stuff), and ... well, pretty much everything else. Kevin Rogers is our internal level guy, a very specific task which he is very good at. James McEwan, who also did a lot of the models in Void War, is handling a lot of the 3D modeling tasks, and has also been jumping in to help out on sound design and 2D art. Mike Nielsen is contributing his awesome musical skills, and we've contracted out for other elements like concept art, character portraits, and the title screen. And I've also been imposing on friends to help me with things like writing and editing.

And I've bought a lot of content off-the-shelf.

For a long time, though, it was a team of one. The way I do indie projects, so far, is it starts out as a one-man project, and the team kind of accrues organically.

Team Size: In my dream version of Rampant Games, we have four or five people working on a game in a small apartment-style office. Plus contractors off-site. And that's as big as it gets. Seriously. I don't want a huge team working on the games - that dilutes creativity and personality, and introduces a huge overhead in communication and process. it becomes more of a widget factory all about process than a creative endeavor. And it really increases the cost of a game. Forget that. Small, tight teams!

How do you get funding to make an indie game?
I have a day job. Seriously. Making indie games is a privilege I pay for. I also sell some games from Rampant Games, mostly by other indies. It helps me pay for contractors, buy tools, and license content. And buy the occasional indie game. So that helps pay for the actual cash costs of making the game, and the rest is ... uh, "sweat equity."

Eventually, one day I'd like to be selling enough from Rampant Games so that I could actually devote myself full-time to making and selling indie games. But for now, I work a 9-12 hour day at the day job, commute, spend a couple of hours with the family, sleep maybe five hours, and devote most of the remaining time to doing this. For free. Easy it ain't.

But I'd rather be doing that than sitting around waiting forever for my 'ship to come in' or whatever. But hey - tell everyone you know to buy games from me so I can make that transition faster. That'll help. :)

Do you make indie games to up-sell to publishers, or do you self publish?
I expect to self-publish. If I end up with a publisher at some point, and the deal makes sense to me, and I knew that the publisher was legitimate, competent, and paid their bills on time, then I'd be okay going through a publisher.

And bear in mind there are some small, indie-style publishers out there too. Not every developer is Bioware, and not every publisher is EA (oh, wait, Bioware IS EA now... well, nevermind).

The thing would have to come down to what the publisher is bringing to the table, and to realize what I'm giving up in return. For it to make sense to me, I'd assume a worst-case scenario: The game sells poorly, and that this is a one-time deal. I think too many inexperienced developers happily give away their most valuable assets on dreams of retiring as a one-hit wonder or something. If the publishing deal got me on store shelves, allowed me to retain IP rights and continue to sell directly from my own site (and portal partners), then I'd be willing to talk.

But I don't plan on it when developing a game. I expect to handle all of it myself.


(Vaguely) related visual droning:
* Questions for Indies, Part I
* Questions for Indies, Part II
* Questions for Indies, Part III

Got More To Add? To Ask? Here's a Forum Discussion!

Labels: Indie Evangelism, programming

- posted by The Rampant Coyote @ 4:08 AM (Permalink) 2 comments links to this post

 
Frequent Demos Kill Software Development
Okay, today's post is gonna be a little more on the technical / development side o' the fence, and not even game-specific. Sorry.

A friend of mine, who had served several years in the military, once told me, "No battle-ready unit ever passed inspection, and no inspection-ready unit ever passed battle." I have no idea if that's remotely true or not, but the point was that the traits that get measured in an inspection were very different - and perhaps even contrary to - the traits required to succeed in actual combat.

I wrote some time ago about the root of some of my tendencies to procrastinate, the "local maxima problem." The problem comes from the fact that many times, in programming, you have to break things to fix them. The "agile programming" folks like to invoke a technique called "refactoring" - you basically throw out the old code and make a whole new version. No big deal - or at least it shouldn't be. In fact, it should be happening all the time.

The problem is that during the time that this is happening, apparent progress might halt or even appear to go backwards. From the perspective of an outsider, at the end of two days of frantic labor, you've got something that looks exactly the same as it did before. Oh, sure, as a developer you know that this new, improved version is ten times faster, much easier to maintain, and got rid of four bugs that were practically insurmountable in the old code.

Now, as a programmer, I should be in that mindset. Totally. But I'm not. And some things happened at Ye Olde Day Job that reminded me of why I'm usually not... and may be the source of some of my development hangups.

You go like crazy to hit a demo milestone. This is true both in the games biz and much of pro software development. And this, I believe is a good thing. There's another saying in software (and I think hardware, too) that "if it weren't for trade shows we'd never get anything done." It forces an integration pass, acts as a huge motivator, and can really help a team get the important things done.

But in doing that, you may throw in some crap code for the demo that's pure prototype to help the end-user see all what you've been working on. Maybe it's some slapped-together front-end menu, or whatever. You show it to the powers that be - your own upper management, or maybe your publisher. You decide on changes. And then - ideally - you go back to your desk, and proceed to rip certain aspects of it apart to refine and refactor and improve the project as a whole.

But lo and behold, after a certain point in the project, said Powers That Be become a lot more demanding and random. They suddenly want to see the latest and greatest version ten days AFTER a milestone. This is sorta like them coming by for you to take them on a test drive in your car while you've got the engine pulled out and on the garage floor Yet Again.

And this makes your publisher or upper management people grouchy. What the heck are you doing? The software was working just fine a week and a half ago, why is everything crashing and broken now?

So you become paranoid about yanking anything - which means real progress slows down because you are afraid to make any move unless you are sure you can get it back into a demo-able state within two hours' notice.

Sure, one might say - there's CVS - or whatever source-control system you are working on. Just make sure that everything is working perfectly before you check it back in. Great idea. But often impractical in a collaborative effort with a whole bunch of cross-dependencies. Never mind the treacherousness of trying to make a build and run it untested on some other computer besides a dev box in the middle of development, without having done a reasonable integration pass (and if you happen to do automated integration testing every time someone checks code into source control, give yourself a gold star... but you are probably still painfully aware of how dangerous it can be even doing that).

So - yeah. Bottom line - if you want to shoot development progress, fill it full of lead, and leave it bleeding at the side of the road in a toxic pool of virulent disease-ridden slime, perform frequent spot-inspections and impromptu demos.

That little bit of aversion therapy lives with me still, even as an indie answerable to nobody. I still find myself paranoid about retreating from the dead-end of local maxima.


(Vaguely) related bits of ranting
* Fighting Procrastination: The Local Maxima Problem
* Productivity Tip: The List
* Embrace Code!

Labels: productivity, programming

- posted by The Rampant Coyote @ 12:55 AM (Permalink) 12 comments links to this post

 
Frayed Knights - The Stupid Stuff Takes Too Long
Tales of Frayed Knights, the comedic independent fantasy RPG coming from Rampant Games in the not-too-distant future. I hope.

It's friggin' midnight. And I just realized why my weapons are not responding properly to the armor level of the characters. Inside the character class file, I have a function that gets their armor level.

It looks something like this:

function Character::GetArmor(%this)
{
// Gets the total armor level, including current magical effects on the character.
// To Do: Everything. This is a stub.

return 0;
}

Great. Oh, well, I'm already in the middle working on equipped effects (things that happen to you while an item is equipped), so this isn't such a big deal. But it does explain a few things.

Writing Dialog. This is my favorite part of working on the game, but it isn't easy. And it is surprisingly time-consuming. Some of it works, some of it doesn't, and every single bit of it needs a major editing pass to make sure all the plot points are being hit, and that the appropriate dialogs have at least a subtle shade of humor and are speaking with the correct "voice."

Then there's allowing a "freelook" mode, but I want it to snap back to a particular pitch you are done looking around at the environment. Unfortunately, Torque doesn't give you any control over this with the Player or ShapeBase class, so I have to make a minor engine change. No big... but it takes time.

Then I spend about an hour and a half working with James to get the mount point working on his models so that the weapons aren't growing out of the back of their knuckles. James lives about 850 miles away, so much of the delay involves sending files back and forth. But part of this is just nailing down a process for us both for future content.

A crash when traveling between the dungeon and the village has me baffled. I try and trace it down in the debugger, and find it's something to do with player movement - before the level is fully loaded? It stumps me for a day. Realize that for me, a day means spending nine hours at the day job, plus a slow, snow-covered, slippy-slidey commute each way, plus an evening scheduled with other stuff that comes with having a life, not to mention a blog post, so we're really only talking about two or three hours of actual time spend working on the problem - between 2:00 AM one morning when I call it quits for the night, and 9:30 PM the following night when I get cracking again. But after a day, I realize a (possible) solution, having worked with Torque a little too long. I schedule the level load rather than calling it directly. Bam! The bad crash goes bye-bye, and everything suddenly works.

There are buttons that don't work anymore because they are properly calling the new UI manager, but I'd neglected to upgrade the call their container dialog, so it's still manually being brought into existance. The UI manager doesn't know anything about it, so the buttons aren't working. And then there are inexplicable slow-downs when certain dialogs are up. But it's bad! I need to find the problem and fix 'em.

Grumble.

While the entire first chapter is, as of last night, playable from beginning to end, there are a couple of major issues still outstanding. Like, oh, saved games. And trading. A new and improved inn. But for the most part, we're down t0 "stupid stuff," which takes almost as long as the big tasks. All those little details that might fall through the cracks. And there's a LOT of it. It's those stupid, little things that take so much time, paralyze apparent progress, and drive me crazy.

I hate this part. And it's not even in the serious bug-fixing stages yet. This is the point in the project where keeping an updated "to do" list is critical, and where you have to take satisfaction from seeing lots of little, stupid things marked off as "complete." Because it doesn't make great screenshots, and the players won't notice it at all unless it's not done right.


Forum Discussion, Because Misery Loves Company

Labels: Frayed Knights, productivity, programming

- posted by The Rampant Coyote @ 1:08 AM (Permalink) 4 comments links to this post

 
Questions For Indies - Part I
Corvus Elrod and I decided to borrow some of the questions proposed in the XFire Debate Club last week that we didn't have time to answer, and offer some answers - in a lot more depth - in our blogs. Sort of a collaborative project, without actually having to collaborate. Since actually coming up with a topic is way harder for me than just spouting off about something I know nothing about, I loved this plan. And as a bonus, the ability to spout off about things I know nothing about makes me eligible to be used as an expert on Fox News!

Shamus "McLaser" Young fired five shots across the bow with stuff HE would have liked to know about how indie game developers work. Since his questions didn't suck, Corvus and I decided to start there. We figured we'd go in depth on two this week, three next week, and then tackle some of the others extracted from the logs as we go. And we are almost guaranteed NOT to agree with each other on all of these points. In fact, I really hope we don't, because he really hated The Witcher. And I ... uh, haven't had time to play it yet, but I intend to, I'm hoping it actually doesn't suck and that he was just smoking something. But he's also got a killer multipart retrospective going on about Ultima Underworld, so I can't dismiss his opinion lightly.

Incidentally, I also mentioned the questions to Amanda Fitch of Amaranth Games (you know, Aveyond and Aveyond 2 awesomeness) - she's actually made indie-dom her full-time job now, so she's more of an expert than either of us, so I will humbly refer you to her comments on the subject.

So Fire away, Mr. McLaser:

Question One: Why So Many Indie RPGs?
Shamus: RPGs seem really over-represented in indie games. (Or, you could say they are under-represented in mainstream games.) Why do you think indie developers favor RPGs so much?

This one took me by surprise. Because they... uh, aren't, unless you consider the dearth of mainstream RPGs these days to be "well represented." Short answer. Long answer:

Looking at The Great Games Experiment, as of a few minutes ago, there were a total of 936 games tagged "indie," and only 95 of these were tagged "RPG" (and some of those might be considered more, "games with RPG elements" and really stretch the definition of RPG. But we'll roll with it). So --- that's a hair over 10% of the indie games. Actually, if one out of 10 indie games were RPGs, I'd be a heck of a lot busier than I already am. But we'll look closer.

Subtract out all the titles that are tagged "in development", and we find that over 1 in 3 of those RPGs (36) are in that often never-ending vaporware state, as compared to under 1 in 4 of the other indie genres (224). So the number of completed indie games falls down to about 8%.

I think, however, that those numbers are a little skewed based on the community over at GGE, and that casual games (most of which are indie) don't have the indie flag like they should. There's over 1900 of 'em, and only 400 are tagged "indie." So if you assume only 2 / 3 of the remainder are actually indie games that just aren't tagged as such, the indie RPG count drops in half. Naturally, some RPGs (and other indie games) may also be missing the tag, so this is all just conjecture. But hey, you know what they say about statistics.

I personally would be thrilled to believe that 5% of completed indie games are RPGs. I personally think its closer to about 1%, but even at the above 8%, I wouldn't consider them overrepresented.

But Here's Why You'd Think That!
Indie RPGs had a banner year this year, and fans of RPGs can be pretty vociferous. This years crop got a lot of attention this year, partly because we had such excellent games released, and partly because there was really sharp, clever marketing going on (Thomas "Eschalon" Riegsecker, I am talking to you...)

I think a telling indicator - even if it's hardly exact - is the higher ratio of incomplete RPGs listed at GGE. I remember hanging out on the GameDev.net forums a few years back and hearing people constantly talk about how they wanted to tackle an RPG as their first project. These days, they've upped the ante and are usually talking about MMORPGs. More power to 'em... but even fewer of those will likely see the light of day.

But RPGs have a little deceptive quality to them. If you've played D&D, or a Final Fantasy game, you probably realize how the rule system (at least a scaled-down version of it) could easily be turned into a program. I mean, everybody computer geek and their cousin was doing it for their Apple IIs and Commodore 64's back when I was a kid. And RPGs are - as much as any other genre except maybe adventure / IF games - about story. Everybody has stories to tell. Just throw some graphics in there, and you got game! And hey, there are several RPG engines out there that could be used to just throw together a game! Why, you and some artist buddies could throw together something commercial with 'em by the end of the month, right?

So RPGs are tempting projects for indies to start with. So you may hear about a lot of indies making RPGs. Just far too few actually cross the finish line, unfortunately.

Question #2 - What Technology?
Shamus: Naturally indie games have to use older technology, which is less labor intensive and doesn’t require (as much) expensive software. But I don’t think that’s the only reason to do so. Certainly the older graphics - done right - can have a certain stylistic appeal as well. The other reason to aim low on the tech tree is so that you can hit the widest possible base of users instead of just the fanboys with $3,000 computers. If you could use any graphics technology you wanted - from Infocom to Crysis - where would you choose to go?

Ummm.... dang. Actually the technology I'm using now. Only I'd like it better, more stable, easier to use, and more feature rich, plzthx. It really depends on the type of game I'm making. Part of the design philosophy behind Frayed Knights was me deciding what kind of RPG would go really well with the engine I had on-hand.

I'd actually worry a bit about something like Crysis, because SOMEBODY has to make all those gorgeous models. And that somebody is probably gonna take a month per model, minimum. As an indie, I don't have time required to make it look good. And nobody but the really hardcore gamers - who really demand games that make their major video card investment look awesome - could run it.

Now, as someone who's been doing 3D graphics their entire game development career (starting with the Playstation 1!), I still gravitate towards 3D - just to leverage my strengths. But I shy away from the bleeding edge, and I'm constantly faced with the challenge of making 3D look good without trying to go down the photorealism route.

My Dream Engine
Now - my dream engine would be some modified version of the Exult engine (built to allow you to play the Ultima VII games on modern systems) with some 3D graphics for characters. And the scripting system from Neverwinter Nights. Something where I could leverage the best of 3D and 2D and have them mesh together nicely, works on low-end machines, is nicely mature and bug-free, and can pretty much have the entire game scripted out cleanly.

I think that style of game still has a ton of story-telling and gameplay value left in it. And it was simple enough for player to enjoy without having to constantly fiddle with the camera or any of that other crap they have to mess with in modern games. The 3D graphics would allow for some pretty cool special effects, particle systems, and a lot nicer character animation. The NWN-eque scripting system would allow far, far deeper levels of interaction in the game than Ultima VII originally supported.

And now, you can probably guess what my answer to Shamus McLaser's final question will be.

So... if I ever go back and turn my "Forrest Gump in Ultima VII" experiment into a full-fledged project, I may actually get part of that dream engine. Who knows? Once Frayed Knights has run its course, maybe I'll go back and try that out.

Well, I hope I've properly beaten Shamus's first two questions into the friggin' ground on my end. Whadaya think? And do you think the "McLaser" thing will stick? And for other developers reading this blog: Why are you reading this instead of developing your game? But as long as you are wasting time, what are YOUR answers to these questions?

Okay. Wanna hear what Corvus had to say on these same questions? Me too, I haven't read it yet. But I will now direct your attention to the link he just sent me:

Man Bytes Blog: XFire Debate Annex #1

And - Lookie Here! The Debate Continues In the Forum!

Labels: Indie Evangelism, programming, Roleplaying Games

- posted by The Rampant Coyote @ 10:00 AM (Permalink) 0 comments links to this post

 
Torque Game Builder 1.7 Released
GarageGames reports that their 2D game engine - Torque Game Builder - has just been upgraded to version 1.7. Lotsa changes here, though there's still no news on whether or not they fixed the stupid camera-jitter bug. But the short list of fixes and improvements is still very exciting.

But I am very, very NOT allowed to play with it right now. Sniffle.

TGB 1.7 Released

Labels: programming

- posted by The Rampant Coyote @ 6:48 AM (Permalink) 0 comments links to this post

 
In Defense of Game Patch
Every once in a while ("a while" being defined as "about five minutes") someone complains about the excessive patches required in modern PC games. I get as infuriated as anyone else, especially for those really nasty cases where the patch invalidates my saved games and makes me start over. Nobody likes seeing their game wrecked by a bug. Why didn't they bother testing before they released the game, anyway? And we're seeing day 1 patches (meaning, patches released at the same time the game hits store shelves) with huge lists of bugs fixed between the time the game went to the duplicators and the time it hits the shelf.

Something has got to be wrong here, right?

And it's no longer just PC games, either. Consoles games, now that they have downloadable content, are beginning to show signs of patch fever. Is this a sign that developers are just lazy, and use the fact that there's now means of distributing a patch as a crutch to release games in a buggier state?

Now, I'm probably an official "part of the problem," because I sympathize with the need for patches. And I'm a developer. And I've released patches for my games. So I'm gonna go on a limb here and actually defend this horrible practice of releasing buggy, broken code.

Well, not really. I can't condone that. But I do want to talk about why your favorite game is on its third patch in nearly as many weeks. It's probably not as bad as it sounds, and the publisher probably didn't just get bored and try to foist off a horrible mess on an unsuspecting public in hopes of getting a quick buck.

Probably. At least not most of the time. I think.

When people talk about how buggy games are, they often compare it to the old days, when you rarely heard about patches or lists of bugs as long as your arm.

Things Haven't Gotten Worse. Well, Not Much
But it wasn't that the games of yesteryear weren't buggy - it's just that there was no reasonable way to distribute a patch. I do remember getting a patch back in 1991 that was "by request only" - they'd fixed the bug post-release, but didn't really advertise the patch, because it cost them money every time they had to send out a floppy disc with the fixed executable. So if you called customer support and asked specifically about a problem addressed in the patch, then they'd send you the updated diskette.

Right, I said diskette. This was back in the day when the entire code and data could fit on a couple of 1.4 meg floppies.

Nowadays, many games are about three orders of magnitude larger than that. And we haven't suffered through an increase in bugs of similar magnitude, which says a good thing. But you can't compare Pong to Oblivion and say, "Oh, look, they are so sloppy these days... look at how many bugs Oblivion has compared to Pong."

I mean - it's Pong. You can test the whole game in about five minutes. And you STILL had bugs in some games in that era with scores that would wrap around from 255 to 0. Or that bug in the arcade game "Sinistar" (yes, in the arcade) where a player could - on demand - get himself shot simultaneously with getting himself eaten by Sinistar when down to only one ship... which resulted in 2 kills at the same time, taking his number of lives UP to 255. I don't know if they ever patched that one. It still has that bug in an emulated version of the game (complete with a video where one of the developers talks about the bug).

In the past, they simply tried to keep the issues secret to keep their happy customers from knowing that there were problems. Nowadays, there's more open communication, so the happy customers discover that all might not be well in their games. Personally, I'm for better communication, even if it might alarm customers.

Hey, I've been on the disaffected customer side of things, too. It happened to me with no less than Ultima VII part 2: Serpent Isle. To this day I have never completed it. I'll bet most of you old-timers who played Serpent Isle had no idea there was a game-killing bug that only seemed to affect players running the game on a Cyrix 386/40 CPU (according to the tech support guy who could only offer apologies to me at the time).

What Gets Fixed?
When you look at the list of bug-fixes to the game in the latest patch, if you are being completely honest, how many of those bugs were you actually aware of in advance if you don't frequent the message board forums to hear people grouse about them? If you were playing the game in a vacuum, oftentimes you may be completely oblivious to every single bug in the list. There may be some issues that you only recognize after-the-fact as being bugs that you may have only chalked up to some design quirk ("Oh, so that's why those healing potions didn't seem to work so well...").

Then there's the gameplay tweaks that get updated with patches. Little irritations in the game that weren't really bugs, but things that the larger player base recognized as being a detriment to fun. While I wish that all developers and QA people could see the forest for the trees all the time when developing and testing a game, the truth is that more eyes are always going to see more things. When you are working with an evolving game for a long time, you get used to things that you don't realize that you are being forced to get used to. Some recent indie game examples include the arrow patch for Eschalon: Book 1 (to increase the quantity of arrows available in shops), or the rogue enhancements in a recent patch to Depths of Peril.

Then there's the brand-new gameplay features and major enhancements that get thrown in. Things to make a (hopefully) good game even better. You might complain, "why didn't they do that in the first place?" If it's a good idea now, it was a good idea before the release, right?

Well, that brings us to another subject. Why modify a game after it's been released, anyway? They didn't do it back in the pre-Web days, so why should we do it now?

Motives For Patches
First of all, developers and publishers don't want people to be unhappy with their game. Back in the pre-web days, there wasn't much that could be done about it if you found out that 1% of your customers couldn't finish the game due to a game-killing bug. But today, patches provide developers with the means of solving that problem, at least for those customers who are online and pay attention to such things. It makes developers happy (usually) to solve problems, and it makes the customers happy, so it's a win.

Then there's also the very sad truth that games are never, ever finished. At least not these days. They are simply released. If the developer had to make sure it was perfect, the game would never be released. That's reality. Considering the number of "director's cuts" and "special editions" of movie DVDs that are out there, I suspect it's not unique to games. If a game goes out in it's "good enough" state, but then an opportunity (and motivation) comes along to make it that much better, it is another win / win scenario for both developers and players.

Then there's the fact that the players know what they want better than the developers do. When the players identify some "low-hanging fruit" improvements that the developers were unaware of, this becomes a great chance to make a game better with little effort.

Finally, there's a significant ulterior motive for releasing patches. Quite simply, it's a way to keep a game current and newsworthy. Public attention in the gaming hobby is both fleeting and fickle. As soon as a game become yesterday's news, its sales begin dry up. The release of a patch gives everyone an excuse to mention the game again, which in turn may rekindle excitement about it and - hopefully - generate more sales. Or maybe just remind people of how great the game was to keep them interested in an upcoming expansion or sequel. Patches may be more about marketing than anything else.

So if you get bitten by a game-interfering bug, feel free to grouse. But don't take the prevalence of patches as an indicator that code quality has gone to pot across the industry. I mean, okay, I've written some of that code, and I know how bad it really is, but I really do believe modern practices has made it better rather than worse.

(Vaguely) related bugliness:
* On Game Engines and Swarm Missiles
* My Worst Bug Ever
* Twisted Metal Trivia
* Why Software Design Isn't Like Architecture
.

Labels: programming

- posted by The Rampant Coyote @ 6:02 AM (Permalink) 11 comments links to this post

 
Game Programmers Versus Game Designers
One of the major differences I've noticed between working in the mainstream games biz now versus when I started *cough*thirteen*cough* years ago is the amount of work that goes into making the entire game very data-driven.

Maybe it's just the companies I worked for then, versus the ones I work for now. But it seems that the trick companies are using to help scale projects is put more burden on designers for creating the data, scripting solutions, and so forth. Not that this is new. We put a ton of effort into scripting in Outwars back in '97, after all, and even Twisted Metal and Warhawk had tons of parameters for the designers to play with. It just seems like a greater amount of emphasis.

What this means, from a programmer's perspective, is that you can write the most pristine, perfect, bug-free, wonderful code in the world - and its still gonna be turned into utter buggy crap by some designer's script or data when they don't know what parameter X is supposed to do. And the programmer is gonna get the blame by default. It's just our lot in life.

Of course, that assumes pristine and perfect code. You can ask the designers that work with me, and they'll let you know in no uncertain terms that my programming isn't in the same zip code as "pristine and perfect." We'll go back and forth, of course, about how I implemented the code in only twenty minutes because said designers suddenly decided they absolutely needed a feature only three hours before the milestone was due.

That's life in the games biz. Hey, on my indie project, I do 95% of the work at the design-level, through the built-in scripting language and all that, so I'm in the same boat. I can empathize. But I still turn into crotchety old programmer guy at work. It's just how things are expected to roll. Who am I to fight tradition?

Oh, right, I'm an indie. I buck tradition all the time. Okay. So I don't think I'm all that crotchety. And I'm not old! Except maybe in the eyes of some of the kids in the QA department who think Playstation 2 games are "retro." But I digress...

Things get more interesting. Not only is there a weird joint-custody relationship over stuff that makes the game run, but the designers are... well... creative. By their very nature, designers get very creative in the use of whatever tools you give them. We joke about bugs being "undocumented features," but sometimes a designer will find and take advantage of a bug. Truly use it as a feature. Sometimes they'll have no clue they are using some unwanted side-effect to make their mission work. And then they'll get mad when the bug finally gets fixed, because they'll have two levels that depended upon that broken functionality. They'll have written sixteen scripts that force this weird bug to happen because its just a cool effect, and then as a programmer you have to purposefully re-implement the bug in a more controlled, parameterized fashion to make 'em happy.

Not that game designers are ever happy. For more than a few minutes at a time, anyway, after they get a shiny new toy. It's like a genetic impossibility or something. Or something they learn in game designer school (they've got those now, these young punks... oh, wait, there's the crotchety old programmer guy thing emerging again...)

The solution, naturally, is keeping good communication going between the designers and programmers. Which can cause nightmares for some managers, because unbridled communication leads to feature creep and priorities getting knocked out of whack. Because programmers love giving designers shiny new toys to play with. If not out of the goodness of our hearts, it's out of the pains in our necks. Which means the solution to one nightmare leads to another set of nightmares.

Have I mentioned that game development is kinda hard?


(Vaguely) related old game programmer crotchetiness...
* On Game Engines and Swarm Missiles
* My Worst Bug Ever
* Jet Moto Memories
* Losing Your Limits Without Losing Your Mind
* Why Software Design Isn't Like Architecture
.

Labels: Game Design, programming

- posted by The Rampant Coyote @ 8:17 AM (Permalink) 3 comments links to this post

 
RPGDX is running an informal 48-hour RPG creation competition, using whatever tools you want. It begins Saturday (which is tomorrow, here in Utah...)

From the post:

"This weekend we're going to have a 48 hour RPG making contest. It starts from whatever time you wake up on Saturday to whatever time you go to bed at on Sunday, and can be extended into next week if a majority of competitors wish. The theme of the contest is Completion - the idea being that the time limit is the real restriction of the contest and the challenge lies in actually finishing and releasing something."

There are no prizes (that I'm aware of), but it should be a lot of fun. Well, for those of you who aren't slaving away on Frayed Knights this weekend, like I will be... :)

If interested, check out the rules and further information:

RPGDX 48-Hour RPG Competition

UPDATE: The time has been extended until Wednesday. So now it's a... uh... (pulls out calculator) 120-Hour RPG Competition.

Labels: programming, Roleplaying Games

- posted by The Rampant Coyote @ 12:27 PM (Permalink) 0 comments links to this post

 
Top-Down Dungeon Competition
Indie Developers:

You have until December 8th to make a top-down perspective (more or less) RPG. Details over at Retro Remakes.

Prizes are pretty much bragging rights, but I'm excited to see what comes of this. I'd participate, if I didn't have my back to the wall with that other competition and Frayed Knights.

Spotted on the RPGDX forums.

Labels: programming, Roleplaying Games

- posted by The Rampant Coyote @ 4:16 PM (Permalink) 0 comments links to this post

 
Torque 2 Game Engine Enters "Transparent" Development
Stephen Zepp of GarageGames posted today about "Torque 2" entering "heavy development." In addition, they are attempting "Transparent Development" - which is to say they will be making the development process visible to the community, and inviting the community's feedback during development.

Sorta like what I'm doing with Frayed Knights. Only hopefully much better.

What's this mean to indies using various flavors of Torque? Well, possibly a lot, but not immediately, except for the chance to have more active participation and visibility in the evolution of the new engine.

For one thing - their "hit list" addresses key issues that have been major pains to developers. Mainly, it's breaking down the monolithic structure of the game engine into modularized components. Since I've learned that too often making "one little change" in Torque involves eight different changes across four different files (pretty much "by Braille," since there's very little documentation on that code), this sounds like a good idea to me.

The new engine will incorporate both 2D and 3D technologies similar to what is currently in TGB and TGE-A, but will not be backwardly compatible with the previous engines. It will use "Poly Soup" collision handling by default, which means the old CSG-style / BSP-based interiors may finally go away. It is intended to be easier to "plug in" major systems (like Python or LUA instead of TorqueScript for scripting, Zepp suggests) with the new modular architecture.

But aside from this, a lot is up in the air. The "transparent" process means there'll be a lot of things discussed in the "transparent development" community, considered, and maybe even attempted that don't make it into the ultimate 1.0 release of the engine.

TGE, TGB, and TGE-A are going to be "sunset" at some point after Torque 2's release (once it has been given enough time to mature), and details are fuzzy (and likely not determined yet). But the post strongly indicates that any project currently in development - or entering development in the next 6-9 months - should use existing technology. Torque-X is going to remain an independent product and will not be affected by Torque-2's development.

GarageGames, not-so-newly purchased by IAC, now has the funding and manpower now to make this happen - here's hoping for some good stuff.

Labels: programming, Torque

- posted by The Rampant Coyote @ 7:13 PM (Permalink) 12 comments links to this post

 
Neurotic AI The Best? Don't Count On It.
There's a little bit of a stir caused from an article that appeared last Friday in the New Scientist claiming that Austrian Researches found that a "Neurotic" Artificial Intelligence player performed best in a series of test against the built-in AI in the game "Age of Mythology." Coming in second was an "Aggressive" AI personality.

According to the article, "The neurotic bot was more likely than the others to distort hard facts about resources - like the amount of timber around - and flip between extremes of behaviour. And it was better than the rest."

But the test was only made against the default AI in the game. I predict that against humans, it's not going to be nearly as interesting. This was the classic "Star Trek" attack against computers - be entirely illogical and make the computers short-circuit.

The thing is, it works. For all one of you who has been reading the blog that long, you might remember how I held off the strongest AI setting in Rise of Nations for nearly four days using the "Do Nothing Because I Forgot To Pause The Game When I Went For Dinner And Then Forgot About It" defense. Undoubtedly, if I had never resumed that game, the AI would still be dealing with my impenetrable defense strategy today, nearly two years later. Dang, I'm good.

For some kinds of games - particularly those in which the AI must rely upon heuristics rather than brute-force problem-tree searches -the AI performs at its best only if the player is behaving rationally and employing similar, tried-and-true strategies. Most artificial intelligence "bots" in commercial games are completely incapable of learning or adapting. The same tricks work against the AI over and over again, so it is extremely poor at adapting if the opponent isn't playing along in the expected manner. Behaving irrationally is usually not a winning strategy; however, may trip up the AI.

So this finding isn't particularly surprising to me. It is amusing, and I'd be interested in hearing how it fares against humans. But at this point, I'd not read too much into it.


(Vaguely) related pontification:
* Jet Moto Memories
* Elements That Make Believable AI
* Game Moments #5: Rise of Nations
* Playing Lately: Go
*