Blog for Ted Southard at GarageGames.com

Talking to NPC's... Now in 3D!!! (screenshots)

Ted Southard — 2008-07-09T02:32:27+00:00

I wanted to withhold my post until the demo level was built, but alas, my uber Alienware laptop is puking bluescreen-hex into my lap every time I try to use Constuctor (or trueSpace, or Age of Conan, or WoW- occasionally). So, a new task on my list is to fast track a new laptop that doesn't go nova on me when I make DX calls more complicated than what Solitaire needs (I'm sure that's next on the blue-screen list).

In any event, I've been able to run TGEA in bursts short enough to work not-nearly-as-impeded and get most of the features from the TGB version of the game ported over. Since I wasn't scripting client/server calls in TGB, that led to some forethought on how to split the functions up between the client and the server portions- or to put it better: How to split the functions so that the client is basically treated as a "viewer" and the server as the "streaming content". That analogy isn't the best, but I'm sure you see what I'm getting at with it.

So, progress has flowed from all corners of the design triangle that are involved in the process: Myself and two friends who just happen to have very complimentary skills (writing "lore" and concept art) to my own (scripting, coding, 2D/3D art, and diarhea of the mouth). Lore is being created for the first continent of the first "world" that will go live, and that is mostly Rick and Chris (the "Lore Designers" I think is a good title for them). A lot of the ideas are ones that I never thought of and really take the cultures and social "issues" of the game in directions that will be quite interesting (especially for the players who think they're logging into a cheesy WoW type MMO).

And on the feature front, it's time for some show and tell:

The log on the left shows off the output of a number of features that were being tested in this image:
1) Inventory functions (equipping, unequipping, deleting items, using them, buff/nerf of stats).

2) My beloved NPC conversation system (I think that's the first time I showed the GUI for it, but it's mature enough to start showing off- and I have another two or three huge revisions to throw at it). The best thing it doesn't show is that it directly links into the memory of an NPC, and while I demonstrated at IMGDC in March it's ability to store a "familiarity" rating for players... I upgraded that to allow for the NPC to remember what topics you've talked about in the past, and to what depth, which adds a new dimension to the Artificial Emotion system that hooks into the conversation system. There's other, more complex, conversation mechanisms that will be implemented before long, and if they work (and they should), then it will make talking to NPC's as much of a game as any other part of the game. Also, you'll notice that Emotes are tied into the conversation system, and do more than just make your friends do a chicken dance in the middle of town- NPC AI is designed to take these into account (so don't go flipping off the master-at-arms, or else). I really like this feature.

3) Towards the top of the screen are a triplet of stat-bars for Kork, which appear and disapear when he is selected and deselected. The neater thing is that if you select rocks or buildings, you get stat-bars that are relevant for those objects (mainly just damage). One of the things about the game is to make everything more interactive, so clicking on many objects will bring up context-sensitive HUD components that reflect the status of the object, as well as the options you have in interacting with it. The only problem with this GUI is that it looks like crap, so I have some other designs that are both more sophisticated and better looking. Remember, fellow designers: Every time you create a crappy GUI, God kills a kitten.

4) What you can see without really seeing: Everything but the terrain is pulled from a "mission table" in the database at the time the server starts up. When the player logs in, they get datablocks and whatever is supposed to "be around". Some people may be a little puzzled as to why I took this route with rocks, buildings, trees, etc, but to explain: In order to maintain a more dynamic world, the server should be pushing out changes to objects in the gameworld that can be persistently changed by players. NPC's are an obvious choice, as are MOB's. But with an even more dynamic environment, just about everything in the zone needs to be spawned by the mission server dynamically, so that changes to its states (destroyed buildings, etc) can be disseminated to players who need to see it, and also saved for persistence. Stress testing will most likely lead to adjustments in this so-far simple system, but I have hopes for it.

5) The Action System is in play here with the use of inventory items, and it is the underlying system for pretty much every single action taken in the game by players and NPC's (and probably MOB's too, because they do that ugly pouty thing when they get left out of a feature and I'm sick of it). Item actions, crafting, combat, magic, emotes, and even dialog break down into actions that can be used "against" targets. This is basically to unify the system so that I don't confuse the crap out of myself while scripting all these different features. Just make it an action, make the action components, and fix fewer and smaller bugs.

So that's the update for now- I wish it were more revealing, but wedding-season has taken it's toll on me, lol. Also, I'm bringing up the new website on a new host so that I can have a shopping cart and a forum and do other things all at once. It's even cheaper. Go figure.

The next update should show the work that my soon-to-be new laptop is enabling me to do with the "Danger Room" zone, and the evolution of several ideas, and a few others I only barely touched on here. Kork will still be in it, since I'm still not looking to form the production part of the team just yet, until I have a much better handle on the gameplay. Oh, and I'll have more to say on procedural content as well by then. I don't want to spew too many ideas without screenshots to back them up at this point, because everyone likes eye-candy =)~

And the NPC lived happily ever after...

Ted Southard — 2008-04-10T16:37:14+00:00

Or not, if you plunged your +2743409 Sword of Everlasting Beatdown into his chest. But that wasn't even the point of your adventure. It was the journey to get to that moment of defeating the big bad NPC... At least, it would be if you weren't playing that story out in an MMO, where 50,000 people had played it out before you...

My latest blog is straddling the fence between a dev blog and a rant. I had the very cool opportunity to get to sponsor this years IMGDC in Minneapolis, Minnesota (kudos to Jonathan Stevens and Last Straw Productions for pulling it off again), and while I was out there, sort of do some shameless promotion (and for those of you who went, you'll probably agree that I was shameless about it, haha). Also, I got to sit in on a number of really informative sessions, panels and roundtables pertaining to various issues surrounding persistent worlds and MMO's.

One of the roundtables proved to be more of a hoot than others, and that was the "RP vs XP" roundtable, which seemed to have a few AAA MMO developers in attendance. Without going into a huge amount of details, I think it's needless to point out that just by the name of the roundtable, feathers on both sides of the issue can get ruffled- and in a very professional way, that's what happened (after all, it's not exactly the forums). In any event, one thing that I took away from the roundtable was something a particular developer stated. Even though it ruffled my own feathers, he was very correct. It pertained to the opening up of persistent worlds to more dynamic use (and abuse) by users, with features such as dynamic content, quests that allow for failure, striving for more "unique" content, and designing features that naturally allow roleplaying to affect a game in ways that did not involve Old English. His response, in so many words:

It's too hard.

Now, that's what ruffled my feathers, even though I understood what he meant. And not even those words themselves, but just the one in the middle: too. That word denotes that the amount of effort required is prohibitive. It amounts to giving up. Someone else pointed out that what I wanted with all those features was not an MMO, but a virtual world...

But... Isn't that exactly what an MMO is supposed to be? Especially the ones with "RPG" tacked on the end of them? Like I said, it was an interesting roundtable, and good points were brought up about many issues, and I think at the end there was some level of agreeing to disagree at the table, but that line was mostly drawn by the amount of work involved, as well as the amount of risk- a very big deal for the larger companies, the developers readily (and rightly) admit.

However, I'm not one to mince words, so I'll just state my position on the matter: It is entirely possible, and should have been done already.

Throughout the conference, I took every opportunity I could to molest the gaming press into checking out my PC-NPC chat demo, including firing up the laptop at the after-party (I'm a whore for self-promotion... it's all good). That Sunday, I added another feature to the conversation system called "familiarity"- better known as "short-term memory". It's something of a buffer between the PC and the NPC where the PC has to work a bit harder to get acquainted to an NPC before they can have "deeper" conversations (or before the NPC decides to offer a quest to the PC).

And speaking of NPC's giving quests to PC's... How would you go about generating quests? It's a rhetorical question...

1) Old School: Hire writers. Give them lore book covering the world they're working on. Make them write out quests for PC's to follow. Insert into game.

2) School So New That It's Not Even Open Yet: Hire Writers. Give them lore book covering world they're working on. Take into account the factions/races/classes/professions/locations of NPC's. Make them write out parts of stories that can be reassembled in such a way as to make sense when done by a server. Make functions that will do that without making writers want to chase you down with pitchforks and torches. Insert into game. Succeed. Or Fail. Then whichever happens: Adapt and adjust it.

Okay, so I admit that the school in #2 was actually touched on slightly by Anarchy Online's mission generation system. But the system was about as far as I've seen anyone go. The potential of it, should it be expanded to encompass much more complex plots, is enormous...

<cliffhanger>

Chatting with NPC's, and making them violent...

Ted Southard — 2008-03-04T03:57:49+00:00

This is probably going to be a shorter update than the last one...

I re-architected the part of the dialog database that allowed me to provide multiple answers to single questions based on "scoring". Basically, that was limited in an approach that relied on a database structure, and I needed to go well beyond what that could provide. Instead, I changed a thing or two and now i can do several things stemming from dialog interaction. One of which is checking for which answer to give, like the previous iteration of the chat feature- but more importantly, I can call arbitrary functions by talking to the NPC's. These functions can depend on nothing or everything, and have variable amounts of arguments. Sure, it adds CPU cycles, but on the other hand, an NPC punched my character tonight because he didn't like the question I asked.

That output there also signifies the beginings of the combat testing. I have user-agnostic action functions in the game which allow NPC's as well as PC's to call the same exact action. This is basically for laziness, but it works great, especially when you tie it into the chat system like above. If I had switched to the combat screen, I could have punched back, but it was too much fun goading NPC1 into killing me.

And with that, the chat feature is getting close to being where I want it to be- at least initially. It's sufficiently complex that a lot of testing needs to be done on it, and the volume of which that would guarantee all those strange scenarios you need to account for won't be provided until an alpha or beta testing session, which is far down the road. By then, though, it should be a lot more mature.

So from here, I have a number of things I want to jump on before IMGDC, even if it's in a preliminary sense:

1) Combat: It's no fun when only one person is doing the fighting, so a super-simple system is getting thrown together in the next few days. I don't really need to concentrate on it beyond basics right now because: a) The 2D testbed will show it's limits for what I want to do, and b) The combat system really isn't the hardest part of what I'm doing, and I want to show off my progress on the hard stuff. standard MMORPG combat is old hat. Chat is not.

2) Inventory: It's not difficult to implement, but it's needed for other systems, should I get them in place for the conference.

3) AI: This is another big one. Luckily, I found this awesome book named "Writer's Guide to Character Traits", which contains a ton of information on behavioral profiles of all kinds of people. Combined with the character-trait-based AI I was already wanting to implement... I don't know. It's going to be a test that will pass, fail, or need some sort of work. Probably the latter, but that's just fine with me, as long as it works right, otherwise I need to find another way.

4) Conditions: I had this working in concept last week, except I sort of scrapped it with the changes to the conversation and action systems. Getting it back up and running shouldn't take long though, and it's designed to have conditions ("kill dire rat") that are dependent on conditions ("get sword from Mace Windu"). I only tested a simple condition though, so I'm refraining from any news on that.

5) Mission Generation: This is the biggie, and it depends on everything else falling into place in the next two and a half weeks. At the least, if I get the inventory system in with basic conditions, I can rig up something along the complexity of Anarchy Online's missions in a day or two. If I can pull off a miracle, I can do something more complex. As it stands, however, I'm in doubt as to whether I'll have any of this feature to show off in time. Worst comes to worst, it will show up here as screenshots later in the spring.

So that's just about it for the update on Epic Frontiers. To those who have asked last time, I am still thinking of "weaponizing" the chat system as a code pack, but the specificity of it means that that will have to wait a few months if it is going to happen.

NPC Chat status (and screenshots!)

Ted Southard — 2008-02-22T04:16:26+00:00

Yeah, it's time for another update on this weird chat interface that I'm developing. To give a basic overview, I am developing a chat interface that will allow players to converse with NPC's in an MMO world with the following goals/restrictions/features:

1) Must be scalable (this is an MMO we're talking about).
2) Must not use parsed language or grammar. This is due to bad grammar, bad language, misspellings, and localization, which would mean rewriting all of those other algorithms.
3) It must be tied into the AI/AE (Artificial Intelligence/Artificial Emotion) system.
4) It must actually have a bearing on the game world.
5) It must be modifiable on the fly by a dynamic mission generation architecture (more on this another time).

Okay, so that's asking a hell of a lot out of your NPC's, but if it is done creatively enough, well... it can be done. In previous blogs, I've talked about how I'm utilizing a database implementation of canned dialog elements to represent conversations, which immediately addresses #2 (it also dovetails with any future localization efforts, because we'd only be translating canned dialog). As a database, it also addresses #1, but only in it's implementation, where I received some help on normalizing databases from my day-job's boss, who is a SQL ninja with about 12 years of that under his belt- he taught me a lot about how to solve MMO problems in a database, including how to streamline the data. To emphasize: If anyone is planning an MMO, learn SQL early on, and keep tweaking and optimizing how your data is represented. That's your meat and potatoes right there, and you don't want it crapping out on you.

Back to the topic at hand... #'s 1 and 2 are taken care of, but then again, so is #5, due to the dialog being represented in a database form. Of course, there are certain data types I'm using (which shall remain nameless for now) which help me to do quick queries for pairs of dialog, even when there are multiple answers to a question. By "multiple answers", I mean that an NPC can give you a right or wrong answer, a lie, an answer colored by emotion, or even no answer at all (yeah, that NPC is totally ignoring you, dude). This also lends itself to a tool that I created to create new pieces of dialog in an in-game editor, so that you can expand your NPC's conversational abilities on the fly as you test the system. Some coding would still be required for the AI/AE pieces (done in script), but for the dialog itself, you can click through a conversation, find where you want to expand the dialog, switch to the editor, and add what you need there, then return and go along as if you never stopped. Once the dynamic mission generation system is running, it will do things like this automatically using templates to generate specialized dialog tailored to a mission.

Item #4 is self-explanitory, and depends more on me not putting stupid subjects in there, but it's a valid issue if you don't know what those NPC's should be talking about. And lastly, the system needs to be able to be influenced by the AI/AE system so that the dialog actually reflects the rest of the experience. So, before I get to the screenshot, I'll give status on the items below, and some challenges I've encountered:

1) Some more normalization needs to be done, but after a revamp or two of the database structure, I think it's in a place where data can be pulled together rather quickly. I will need to create testing applications to stress the system at a later date, but I think for dozens or even a few hundred users, the system will hold up relatively well, with acceptable lag times on a very modest server.
2) Canned dialog FTW! Honestly, it solves everything in this item, though it poses a unique problem in that when it comes time to hire on a writer(s), they will be in a difficult position creatively. Creating dialog without knowing all ends is going to be a bit of a learning experience for them, though the ability to do it while playing the game should give them the ability to play through the dialog and sense what else needs to be "said", and then add that...
3) Adding the AI/AE into the mix is not as tricky as I thought it would be, but I still want to abstract it a bit more so that there's some extensibility. Doing it that way should also benefit the AI/AE systems on their end of the scale as well, though I've hacked it in for now for lack of a fully clear view of which way to go with it. In the next few days, I'll have this decided on and the system testing. As it is, the basic principles of their influence are already there- it's just the way the backend goes about it that I think I can do better.
4) Dialog's bearing on the game world is starting to make me think in very deep (and mundane) ways about my world. If you want to talk to an NPC about it, then you can get a huge amount of information from these NPC's. They won't all have the same dialog or "knowledge", but instead will have knowledge of topics to a certain extent, which is variable. This is where lot's of backstory needs to be written up.
5) The extensibility of the dialog is already working with the editor, and it's just a matter of seeing what kinds of dialog are needed for the dynamic missions, which are the next targeted feature that I'll be working on. The good news is that this was designed in tandem with the dialog system, and the bad news is that this is all terribly complicated.

All that said (if I'm making sense anymore), take a look at a quickly-rigged test app in TGB (with TGB "Asteroids" tutorial art in it, for those that will wonder):

This demonstrates varied answers to the same question, as well as failed attempts by the player to get an NPC to answer the question. The blank lines where it looks like something was skipped are actually unhandled dialog (my own mistake with some early on that I haven't fixed). The logic behind it can use a lot more AI, but that system isn't really implemented yet, and I'm just testing the variables that affect dialog right now to make sure they work, whereas when the AI system goes in place, I'll have to test to ensure that they work "believably".

For those interested in this kind of MMO tech, I'll be doing some informal demonstrations of it at the IMGDC coming up in Minnesota at the end of March. By then it should be in a much more advanced state, and other game functionality will hopefully be added to it as well to provide a more rounded experience. Don't expect the sample art to change though- I'm not concentrating on that at all until I get these core systems tied together over the next couple of months. In the meantime, comments, critiques, questions, concerns (uh, should you be concerned?) are all welcomed!

So, exactly what is there to talk about with NPC's anyway?

Ted Southard — 2008-01-30T04:20:02+00:00

Honestly, it's not like they watch the game or anything... But still, chatting with an NPC can add a new dimension to gameplay, and while Interactive Fiction has been tackling and trying to drag that particular quarterback to the ground for decades now, MMO's have largely forgotten all about it...

In my last .plan, I discussed some of my ideas for getting dialog with NPC's back into MMORPG's (or even plain MMO's, for those that aren't RPG's), and here's a very quick and very dirty version of the chat done up in Excel and VB (used to quickly emulate a database and quickly code out some functions):

Snazzy, eh! No? Well, that's because I reinstalled my shitty Alienware laptop with Vista and only have Paint on here to cut and paste the relevant cells from Excel, but the other reason why you're not treated to the fabulous "cells of mysterious numbers" that my last .plan had is because: a) It's even more cluttered than usual, and b) Work product.

I'm hoping to learn how to grab video out of TGE soon after I actually improve on this, move it to MySQL, and tie it in with some rudimentary AI (also shown in the last .plan), but for now there's only these odd glimpses of bad conversation between myself and an NPC about things you probably would never ask one about.

However, the point of the excercise was to prove that a database-driven dialog solution is actually possible that does not involve Natural Language Parsing, which this does not. As a matter of fact, it has absolutely no idea what any of those words on the screen mean, but the way that dialog snippets are generated are theorectically geared towards providing for a large range of response. That said, the generation of dialog is not going to leave human hands, and even with the creation of database tools to allow for smoother generation of these dialog pieces, it promises to be a tedious process- just like most other data generation tasks that MMO's entail. But the "canned" nature of the dialogs ensure that users can't burden the system with bad grammar and/or spelling, and certain other methods are meant to make it easier for my side of the equation to dynamically create an NPC with the dialog it needs to know, without it having dialog that allows it to talk about absolutely everything in the world. So no, the old guy on the corner probably doesn't know where those bandits who kidnapped the farmer's daughter are, but he could chat about how sunny and warm it is outside.

And I do apologize for the rambling nature of the post, but I'm a little excited and wanted to share- especially since dealing with the laptop set me back a full week, and even after that I was one of the unlucky ones cut off from connecting to the forums until today (kudos to David Blake for helping me out with that!), so I'm a little pent-up.

In any event, back to work. Hopefully, I can polish it up in time to show off at the IMGDC in Minneapolis this year so I'm not just the weird guy with the weird gui sitting there and talking design with nothing to show. In the immortal words of Howard Dean: Byyyyyaaaaahhhhhhh!!!!!!!

Here's a little story that I'd like to tell...

Ted Southard — 2008-01-03T16:23:35+00:00

So there's been these discussions in the forums lately about game ideas, and how they're stale. Agreed. And how games would benefit from more openness. Agreed. And then the discussion revolves around the "end-game" of that gameplay- what you can do:

example: In my game, you'll be able to do anything you want! It's gonna be awesome! You can be a thief, a cop, a barbarian, a farmer, and you can talk to the NPC's, and they'll talk back!

Okay, fine. How do you go about that?

example: Don't crush my dreams!

Right. So I was at the laundrymat last night (where I do a lot of my game development thinking/sketching), and thought about new ways to represent chatting with NPC's. The problem is that other ways that I've been thinking about, including a Fuzzy Cognitive Map-based method of personality traits (below), are not yielding good results.

A less complicated version holds slightly more promise, but I'm starting to feel that it lacks the depth of the former plan:

So the problem is two-fold:
1) How does one construct dialog in a game in such a way as to allow interaction with NPC's in a more freeform way than the usual script-driven dialogs that are currently used, while allowing for realistic dialog?
2) How does one tie that dialog system in to the AI in such a way as to allow "soft" skills and actions by the player (as well as "hard" ones) to influence the course of dialog?

In other words, how do you make NPC dialog actually part of the gameplay, rather than just a way to get canned information from the NPC's? The answer is not the least bit clear, at least for the first question. Researching where research is at for the structure of dialog, you won't find a consenus for how conversation occurs. With that in mind, I had to sit down and decide not how conversation occurs outside of the game, but the way that conversation should best occur in the game.

Approaching the problem from this angle, I blocked out conversations with NPC's in my head and on paper where conversations took different turns, and accomplished different ends. This was done to help solidify the types of "dialog types" that would be used, such as "question", "acknowledgement", etc. These generic headings make it so that, instead of using natural language processing (NLP), I can use more generic "dialog actions" such as "thank NPC for his time". In this fashion, you can avoid having to parse a player's language (especially if their grammar is not perfect, which means wasting cycles on spellcheck, or asking for repeated inputs).

Remaining problems are how exactly to reference the branching between dialogs, and how to encapsulate the information (though I think I have some information groupings that mimic the real world more closely than just having all the information scattered in a database). There will still need to be some heavy AI behind this, and I look forward to seeing my first server failure from the stress ;)

As for the second question... It's a good question, isn't it? Just how do you describe a personality in so many words, when the words we use are not at all sufficient in and of themselves to do the job? I'm leaning towards a combination of personality traits and emotions, but the list is so up in the air right now that I won't even write too much about it. Suffice it to say that the list is going to have to reflect both the influences of dialog actions as well as physical actions in the world. If it doesn't, then you can have an NPC get angry at you for an insult, but you can go upside his head with a monkey wrench and he'll still be happy to see you. As amusing as that would be, it makes for very bad gameplay ;)

On other fronts, I've been learning Visual Basic, which I really like! It's fast to prototype with, and when used with Excel (as you're seeing in the screenshots), you can easily track all the data and the results with ease. Here's two shots of worksheets I'm using to simulate dice rolls, combat, skill level score calculation (because I went the hard route and did away with experience levels), etc.

Dice Rollin':

RPG Sim (not fully coded out yet):

I should have the RPG Sim page working after this weekend, but it's not a priority since it's mainly geared towards making sure that inventory combinations don't have adverse reactions on the player, balance-wise. The Dice Sim page was more important in that it helped prove to myself (in about 5 minutes) that the skill level system worked the way that I envisioned on paper.

And in yet other news:

1) I'm happy to say that I'm not only going to the IMGDC this March, but my company is also a sponsor this year!

2) trueScape 2.5 and mapExporter are confirmed working with trueSpace 7.5 (basically because trueSpace 7 is just a wrapper with some fancy tools around trueSpace 6). With that said, I am probably going to rerelease trueScape 2.5 through my store. mapExporter may or may not be rereleased, depending on it's relevancy (Constructor kinda puts it to shame like nobody's business right now).

3) Still working on textures, which I'm accumulating faster than I can work on. A recent trip to Ethiopia has yielded one or two hundred more source photos that I need to comb through.

Oh, textury goodness...

Ted Southard — 2007-07-10T02:18:51+00:00

Whoooo.... Textures!

Who knew it would take so long to get a pre-rolled shopping cart working? Not me. Two weeks of tweaking and testing (sometimes during D&D sessions, which leads to a lot of WoW-style default-action-taking-from-behind-the-laptop-screen, which is boring for a rogue- especially one named El Dingo), and I finally have the DigitalFlux Entertainment Store up and running!

The first product that DigitalFlux Entertainment has to offer is the first in a series of Terrain Texture Packs. These texture packs are seamless textures made from high resolution photos taken all over the world. Of course, considering the quality, resolution and uniqueness of the textures (and what it takes to get to some of them), the $10 price tag is well worth it.

The first Terrain Texture Pack has the following:
- 103 photo-based, seamless textures in power-of-two resolutions
- 8 at 256x256, 12 at 512x512, and 83 at 1024x1024 resolution in jpg format
- All textures are seemlessly tileable in at least one direction (82 are seemlessly tileable in both directions)
- Concrete, asphalt, grass, dirt, gravel, scrub, pine, mulch, mossy ground, sand, and volcanic stone
- Locations of yielded textures include: New York City, Detroit, Israel, Washington State
- These are not simulated textures cobbled together from several photos just to seem as if they can fit into the environment that they claim to be for. The volcanic rock textures come from a volcano in Costa Rica, the mossy rock textures came from mossy rocks in Washington State, etc. Each texture is extracted and made seamless from only one base photo- or the photo gets tossed.

Reduced-size samples can be seen here, at the product page. These textures are perfect to use with your game, and the higher resolution give you the detail that you need.

Futue texture collections in the works will expand on this category, and add others such as textures specific to ruins (Rome, Greece, Ethiopia, Turkey, Europe, etc), signage, decals that can be used on top of other textures, foliage, as well as the full gamut of standard texture categories. Future texture resolutions will be at 1024x and 2048x resolutions (depending on the photo's yield for quality), ensuring even more detail.

Back from the dead...

Ted Southard — 2007-05-20T02:49:20+00:00

...or it certainly feels like it. I hadn't realized that my last blog was in 2005, or else I would have done something about it. Nothing really happened last year anyway...

So what am I up to now that rates a blog? Well... The new DigitalFlux Entertainment website is up, along with a sub-domain for Epic Frontiers. There's a forum in there as well, which I'm debating on whether to start some MMO roundtable discussions on, or to leave it for the Epic Frontiers community that will inevitably spring forth like a tidal wave of fans when the project nears completion. Yeah, better start up the roundtables ;) hehe...

Another announcement to make is that I've released some unused UI art here. Basically, it's from iterations of the Epic Frontiers interface past, and I no longer need it, but since it's laying around, it might do someone some good. Check it out in the products section of my website, and there's other goodies there as well. The only caveats to using them is that they cannot be resold in any content pack of any kind. If you use them in a game, free or commercial, it would be nice to give me credit for what you used :)

Some more things on the horizon are texture packs. One is completed, with 100 terrain textures ready to use and seamless, all based on photos taken by me on my travels around the world. Texture format is PNG, though I'm considering JPG to bring the size down below the 194 megs it is now. Pricing of the packs is also being determined, but will be very affordable. Texture sizes range from 512x512 to 1024x1024. In the future, I'm going to try for 2048x2048 as much as I can as well.

Other texture packs will cover metals, wood, masonry, stone, foliage, signage and decals, and special textures such as engravings and things of that nature. With the 100 packed up, 300 miscellaneous done, and 1200 raw photos to process, there's plenty of textures on the horizon. And if anyone has a category they'd like to see, I'm all ears.

Thursday Feb 10 5:26

Ted Southard — 2005-02-10T05:26:00+00:00

Epic Frontiers update, finally!

Unfortunately there's no screenshots in this .plan, but the next one will have some nice ones... Specifically, missions. So far, here's some progress made since the last .plan:

- Got the dedicated server working. Not only is that routine, but I have it pulling assets from a database and populating the mission. This is very good on a couple of levels. First, it let's me not worry about what is in the .mis file on the client machine so much, as the cool stuff happens on the server and the client sees it only when they log in. Secondly, it also proves out what I need to do for adding assets to the world from the dynamic mission generator, which is starting to come together after 2 years of research.

- MySQL is installed, and I'm ready to start pushing data from Access to MySQL so I can finally stop getting those "too many client tasks" errors.

- Finally, things to kill besides clones: We have an animated character in now, as well as an animated bot or two, and with my new animator on board (Ezy and Kuba rock!), things are moving in the animation department, pun fully intended.

- Added the doubleclick support to the object selection resource, and added functionality behind it to transfer and delete items on the ground that are tagged for it. In other words, you can now pick up stuff ala any other RPG or MMO out there, and it winds up in your database.

- The mission generator architecture is falling into place. It's not far enough along for me to go into great detail yet, but it should work well enough to allow for not only sub-missions and plots, but for "branching" of plots as well, when partial-success is a viable option for the mission. This can help bring more realism into the game, and facilitate more complex mission types.

- I'm most likely going to move the project over to the TSE after they hit Milestone 2 for a few reasons. Not so much the shaders, though one reason does involve shaders for the character customization feature, where I can use a shader for colorizing parts of the character textures for individualized skin and hair colors. But also, it's the terrain. After installing the resource for disabling terrain tiling, I realized that my zones look horrible. Very horrible, because even if I rendered out the bottom of my skybox, you could tell that there's nothing down there, and that you're approaching the edge of the terrain.

What to do? Move the zoning triggers in closer? No, because then I lose real estate and the user gets a very noticeable "bump" from one area to another. What TSE can do by offering larger terrains is that I can now cut up my heightfield differently, so that you don't get near the edge of the terrain when you hit that zone trigger, and so don't notice the visual artifact. Also, it allows me to create irregularly shaped zones, since the entire heightfield will probably not be all used up by the zone.

Another thing I've noticed is that a lot of MMO projects start out with lots of artwork, and that contributes to their "bling" factor quite nicely. Epic Frontiers, on the other hand, is slowly building momentum on the feature side while getting ready for what will probably be something like an "explosion" of art in the later stage of production. With the great artists I have on staff, as well as two new talented programmers who've joined, this project is starting to reach that tipping point where it's no longer a question of if we will suceed, but how well we suceed at launch.

We're still looking for talented 2D/3D artists and 3D animators to join the fun, and there's no shortage of work to do. So, if you're 18 or over and looking for a good project with real steam in it, then we're your team. I'm not shy about my plans for the game, so you can check my previous .plans for a good idea of the project's progress, and even hit me up for a .zip of the design docs to get an idea of what I want the game to ultimately be. Or, you can get on board another "best ever" game project ;)

Saturday Dec 18 3:45

Ted Southard — 2004-12-18T03:45:23+00:00

Massively Multiplayer GUI's!!! Okay, so they're not that massively multiplayer... But they're designed for more than one player, does that count?

The GUI's are coming along nicely, even though they insist on putting up strategically placed fights here and there ;) Fought a bug yesterday and today that cost me a good 10-12 hours in all, but basically came down to some changes I made a good long time ago to make the GuiHealthBitmapCtrl draw horizontally instead of vertically. The upside of that is that I now know that control very well, and in addition to changing it so that it can be hooked up to any generic value (instead of pulling the player's health), I'll be trying to fix it for stretched drawing as well, after which I'll post it as a sequel to the original resource.

Here's what it looks like in action as part of my skill GUI, where you can increase your skills and whatnot:

That GUI still has a couple of hours of scripting behind it before it can do everything it needs to for gameplay purposes. I'm learning that the functionality behind it is a bit tricky in order to fake the scrolling and "page flipping", as well as get and set all the skill values and do validation on the server, etc. But when it's done, it's a big part of the GUI puzzle done, and it will be done this week. <- That's me holding myself to the promise, hehe...

Another piece of the GUI that's almost "there" is the main Inventory panel here:

Here, I also do the "fake paging" thing, to get around scrolling for both myself and the player ;) Information is shown on the right-hand side (might be a bit hard to see in the jpg here), and the drag and drop icons are on the left. This brought up the interesting problem of left and right clicks on the icons, and I think I'm going to redo the rest of the GUI's to execute actions on right-clicks instead of left-clicks, to better facilitate "examining" items without accidentally using them.

As a matter of fact, it was around yesterday when I realized just how much of a persistent world's functionality is contained in the UI itself, because of the player's interaction with the world and the functions to support that through the UI. After the Skill GUI is done (probably Sunday), the Equip and Tradeskill GUI's are next, as well as the database functions that they entail. What this means is that by mid-January, I should be in a position to have 80% of my UI done, and I should be able to concentrate more on the core gameplay rules behind it. That means more time for content, and an open Alpha for load testing!

Of course, there still won't be much to do in the game, since the task generator has been neglected so I could get the UI done, and content is still very hard to come by with my animation famine still going strong. If there's any animators out there willing to put some time in, email me at Ted@DigitalFlux.com I do have a coder now, so hopefully I'll have something to work with as far as the character customization code soon :)

But, for those who want to log on and "play" when that open Alpha goes, you get to try and crash my game server in addition to whatever quest generator I have up and running- wait, crashing the server can be a quest! ;) Here's the target's specs:

DSL 1.5/256k
Athlon64 3400+
1 Gig PC3200 Ram
(2) 80GB SATA in RAID 0

The drill is to find out:

1) How many players can fit in a zone before the server pukes.
2) How many players/zones can fit on the server before it burns my house down.
3) At what point does the DSL line shrivel up like a Cheese Doodle(tm).

Those numbers will help me gauge network traffic and what kind of servers I need to support the game. Off the top of my head, if I can get to 50-100 players sustained without the DSL line snapping like the underwire in Anna Nicole Smith's bra, then I'm in good shape. On the other hand, even if it does, I have some tricks up my sleeve that I'm looking to use to trim down the network bandwidth for the game(thanks to Alex Swanson telling me about the RTS pack's "lighter" Player class).

And I'll need it, because this game will be pretty heavy on the bandwidth even after the optimizing, given the amount of data that will potentially be slung back and forth. And that means that in early January, this Access database I've been using for testing has to migrate to MySQL. Access already complains if TGE talks to fast for it on simpler things, much less rapid-fire requests for dozens of players, but I never expected it to hold up to that, just to be easy to set up while I get the GUI and main queries in place. Exporting to MySQL shouldn't be that much of a headache, though I'll miss working with the tables visually ;)