Random Thoughts After Modding, Playing PSO, Watching Bad Movies

Or as I sometimes call it, Saturday.

One of my downfalls as a modder is that I don't like to sweat the details. I love playing with the gameplay portions of a mod but generally get quickly bored with nearly anything else. This include HUD work and map design. Sadly for most of what I'm trying to finish in UT2004 right now, it's mostly HUD work and map design. I used to like map building, but in this age of static meshes, complicated volumes and tricky sky boxen - I'm just outmoded. I spent two hours on HUD stuff yesterday and just about clawed my eyeballs out. This isn't really helped by the fact that to adjust things in UT2k4's HUD code, you pretty much change a few digits in a very long properties value, recompile, launch, look and repeat.

Phantasy Star Online is amazingly impressive considering that this version we have for the GameCube (Wii) is essentially unchanged from the Dreamcast version, except with splitscreen and the content additions from over the years. That Blue Burst died a somewhat ignoble death (being nothing but a financial burden in the long run) is somewhat sad to me. Sure, there's little things I'd love to change like targeting, weapon swapping and the like - but the core of the game is as brilliant as the day it was born. What it really needs, of course, is a payment setup like Guild Wars or Dungeon Runners ... not WoW. It's a small team instance, not a massively multiplayer ... and people have learned to pay accordingly.

PSO would make such a killer DS title, or even a Wii one. It also a gold mine for a 2D roguelike.

Commando is a hilarious movie by nearly every measure of comedy, right down to the appearances of Alissa Milano and Bill Paxton in the film. It occurs to me that if we want to compare video games to movies, the problem isn't so much that it's not at all valid (though I attest it is not completely valid) ... but rather that many video games are just stuck in the 80's, narratively speaking.

Dev Diary: More Modding

The thing about this latest round of Unreal modding is that the foundation of it all is going really, really fast. Because it's all based on something i've done or abandoned, it's a lot like putting a jigsaw back together. Last night, for instance, I took my old Riftwar code and stripped it of all the campaign and player class code and dumped it into vanilla Unreal domination. There was a lot of little sections to rework or tweak - but in a couple of hours it was pretty much playable.

It's an odd goal - to do less instead of more. To resist the urge to add in some kind of configurable inventory or adding a bunch of new keybinds. I was reading the old ModSquad review of Freehold UT and realized that kind of stuff actually made that game good - that it was the ability to quickly jump though menus to buy health, or better yet keybind a whole package of goods, combined with a multifunctional constant powerup that made the game really what it was.

So much has changed since then though. That was back when mods were still, well, mods. Total conversions still weren't entirely the order of the day - although that was changing rapidly. Still the number one comment I got on the mod was why I was still using original UT models. Later, I'd get that same critique from Epic about reuising Unreal maps.

Although to a certain extent the map thing is a valid point - maps are very specific to the gameplay they're designed. You don't play CTF on a DM map for a good reason - the layout, flow, powerup setup ... everything ... is different. Still, the core of the Riftwar gameplay was still domination - as I just proved last night.

Still, I've put requests out for mappers for at least a couple of game modes. One is pure vehicular deathmatch - something which is actually oddly missing or at least rare from the FPS world I think. It has an old mod buddy of mine excited and so he'll probably contribute some code for it - which is great. However I can hear the crickets in the mod community which is post Make Something Unreal. There are times I hate to be right.

The only time I could interest a decent mapper into helping me was when everyone was trying to build the next great total conversion. This is what Valve and Counter-Strike has done. This is, of course, despite the fact that early betas of CS sucked ... especially some of the maps. A point which I'm sure will be lost on most people when I release with maps of equal quality.

Anyway, I hope to have more of an idea of what a preview of this might look like in the next few weeks. Right now there are about seven gametypes up for consideration with some potentially getting cut and maybe some added. I would actually predict more like five or six will make the cut. I've got a concept doc I'm using for notetaking that at some point I may clean up for public consumption.

Dev Diary: Modding Again

Trust me, I'm as surprised as you are.

No, I haven't finished any of the web/text/interactive fiction pieces I'm working on - although they are still in the cooker and not the backburner. The nice thing about those projects is that I can work on them in short little bursts from nearly anywhere with a net connection. The IF piece will take a good long time, though, so nobody should expect another Randolph Carter anytime soon. Whereas with Carter 70% of the text was recycled from Lovecraft and then extended, this is not only all original but there should be about ten times more depth as well.

The other, using code cobbled from work stuff and a little from the remaining roguelike code, is shaping into a kind of web-based strategy game. That might be done sooner.

So how did I get back into modding? Well I made the mistake of playing some shooters online again. First F.E.A.R. and then UT2004. F.E.A.R.'s sameness, this feeling that I had played the same game over and over again, starting to get to me. I think it was terribly aggravated when a cheater was complaining that he wasn't allowed to use his speed hack because the "running was so slow" (I kid you not). Then i realized I was surrounded by punkbuster, bunny hoppers, speed hackers and probably the occasionally bot and I started doing the time warp again. So I loaded up UT2004 to see how the old girl was doing.

And once again it hit me - oh yeah, I can change this. So I loaded up WotGreal and dug up an old project. Took me a bit to fix and compile, but then there it was.

This time though my goal is to change as little as possible. I was always really ambitious with ideas - purchase menus, upgrade paths, etc. This time I just want to see how much gameplay can be effected with the smallest changes. If I release anything it probably won't have new maps, mutators or weapons - just gametypes.

Naturally, nobody will probably play it ... especially online.

So I'll try to make sure the bots play really well.

Dev Diary: Text and Zombies

I haven't done a dev diary in a while so I'm sure it seems like I'm just not getting anything done. That's partially true, actually, as I have a lot of pokers in the fire right now, so to speak. I figured this was a good time to update a bit since I didn't want my only post of the day to have "Gilmore Girls" in the title.

The ASCII/AJAX roguelike is utterly tabled at this point. I just couldn't figure out how to tweak out the performance I wanted. Instead I'm melding some of the ideas I had into a new work that will use an updated version of the Carter framework. I'd like to tackle the common annoyances of Carter - too much guesswork in finding nows, too little causality, and some of the interface concepts. I'm willing to call Carter a success simply because I've been able to get all manner of feedback - and honestly when you're writing a completely new setup like that ... it's about the best you can hope for.

I'm in the writing phase of the new story - which means I'm not worrying about coding anything at all. I'm just writing the narrative out like anyone would a short or medium piece of fiction. The only real difference is that instead of being concerned with linear plot movement or concise descriptions, I try and add in as much detail as possible. Later I'll fold that into the actual interface. This time there will be a concept of inventory, puzzle solving and combat. My goal is to release in "chapters" will actually refer to locations. I have a backstory mildly fleshed out - but it's fairly shallow. The main story will be pretty simple too - think cabin story format with zombies essentially. Light horror - not comical or anything though. If it works I'll update with multiple starting points - each around the same concept of a lone character trapped in a small town where things have gone horribly wrong.

It's just hard to get stuff done because outside of normal job of building three sites at once - I'm also building about three web sites at once.

Dev Diary: Unroguelike

I've gotten some query as to the state of the roguelike project. I'm not sure how to respond. Right now, I'm porting the Dreadnought concept over to this weird hybrid of Randolph Carter and the roguelike alpha code. The interface is mostly text with a small map with ASCII representations for objects in the room. There will probably be a status window as well. The user could, in theory, use either the map or the text to interact with the story/world.

But I really only have a mockup right. One room, little interaction, nowhere to run to baby. Nowhere to hide. Not sure where it's going.

Also, my journeys back into the PC dug up my old turn-based Unreal code. I had forgotten how functional it was, even though there are miles of ocean between it and anything really playable. Someone from the old mod scene swung by last week to try and entice me into UT3 modding (when it hits). My reaction was pretty negative - I spent a lot of hours playing with UT2k3 and 2k4 only to hit mostly negative comments because, quite honestly, it's not the kind of stuff people are interested in. I'm not all hoppy to jump back into that again. I spent less time and have gotten much better feedback from Randolph Carter than anything I modded after my UT2003 mutator packs.

Yet - I know nobody else is trying this. Single player, turn based, etc. Before the CheapBox++ becomes truly obsolete, maybe it is worth salvaging.

Dev Diary: The Ugly Head Of Performance (again)

Yeah, it's getting a little frustrating.

I'm not even sure what pushed it over the edge this time - it might be because I was finally trying to get maps which resemble actual play up and running and the size is simply too much (again). It's not unplayable ... but it is annoying.

Not sure what to do at this point. I'm looking at the interactive fiction code I've got and thinking maybe I should try melding it in. Torque Game Builder is out of beta, so perhaps Garage Games beat the OS X performance issues and bugs down. I'd like to keep in the spirit of "an easily mappable" roguelike somehow, but I'm not sure which avenue to take.

Sigh. It occurs to me that I haven't really found many web-based games I've really liked, really felt compelling - Flash, DHTML or otherwise. I'm thinking I see why.

Dev Diary: Oh Wii, Oh My

My overall concern with Dreadnought right now is with it's format. Not so much "inner loop" like worrying about combat mechanics or "outer loop" like thinking about graphics - but rather more basic ideas like the size of tiles, resolution concerns, etc.

It occurs to me that the Wii might be a great baseline machine to keep in mind for designing webgames. It's a low common denominator with an energized user base. And anything that runs on the Wii will run on any PC and possibly even a few handhelds (depending on their browser implementation). In fact, if I avoid using AJAX it might make for a very wide audience - but I still like using AJAX for data loading ... so we'll have to see.

It's not easy though. The Wii has a tiny recommended resolution - about 600x450. That's not surprising ... TV resolution minus chrome, I suppose. However, I was trying to make the tiles large enough to be readable on high res monitors as well... so that means my viewable map area is now something like a 20x20 grid. Complicating that further is that the interface is based on absolutely position divs (which get compared to mouse inputs) which might make scrolling very complicated.

So I might make maps sectioned into 20x20 areas which will be linked togethers. There will probably be a limit to the number of sections as well. I don't know how much of a turn off this is compared to sprawling maps.

I just got the foundation for this working yesterday, so we'll see if I haven't changed my mind by Friday.


tagged: game, gaming

Dev Diary: Layers Of Distraction

First, head over to Jeff's project post - not just because it seems like a neat idea, but because he shares my shyness to talk about stuff that isn't entirely cooked (although I seem to overcome said shyness regularly).

That said, this is funny - that early screenshot is completely obsolete now. There's nothing that remains from it. As I've mentioned before - Dreadnought is no longer strictly tiles. Rooms are layers which can be placed on top of each other. Doors mostly work - but instead of dynamic shading rooms will probably be "lit" or "not lit" at least for the time being. Line Of Sight is something I still have to fix, actually, especially for ranged combat.

And instead of scrolling - I'm going to rely on stacked content to provide ... ahem ... depth to the maps. So a "task" might have like five maps which link to each other and each of those maps might have five distinct levels to them. Levels will be interconnect by stairs and lifts - but probably also by simply falling.

I got a basic version of the editor working last night - so LOS and leveled play are probably my next two tackles. The Brother comes into town this weekend, so I don't expect to get much until next week.

It is, however, fast. I think I've found some theoretical limits on the number of HTML divs the page can handle at once and so I might have to add culling routines once I have a properly loaded dungeon - but I'm pretty confident that this approach will allow me build complex maps that don't bring down a processor.


tagged: game, gaming

Dev Diary: Blue Skies

I'm going to talk theoretically here - so it's probably best ignored. This is actually the exact kind of thing I try to avoid - I feel it hexes me and often unfairly raises expectations on projects I'm more likely to half-finish than not.

So, seriously, you should probably ignore everything I'm about to write. I'm only here because it's a convenient place to jot my thoughts.

Currently, I'm travelling down option #2 for revamping the Dreadnought render code. This is one easy thing about working on a strict web concept - everything is so lightweight it's actually not too painful to toss it out and start over. And boy, this is turning into starting over. "Abandoning discrete tiles" turns out to be pretty fundamentally. As in going from a tile-based system to ... well, not. This means that while the test code I have working right now fundamentally behaves in a "tile" way - it's really just grids. If I have a room that is 100x100 with a player, monster and obstacle - that's four "objects" (very loosely defined). In a tile based system, it would be something for each square foot of real estate. Here if the room goes to 500x500 - it's still just four objects. You've just changed the info, not actually the size.

Perfomance wise - if that doesn't solve the problem ... nothing will. I'll know more when I have a properly sized map.

Fundamentally, this means that objects have to do things like check the info to avoid say ... walking through walls. One nice thing about a tile system is that you know where everything is at. Check that tile? Door? Ok... do that. And so on.

I think the complications are pretty minor. But it has me thinking. If a map is defined by sections and not grids - what does that mean? Well, for one thing it is a lot easier to think about graphic backgrounds ... including backgrounds which might have nothing to do with the grid itself (since the grid is just a handy way of dividing a room and not a real obstacle).

You could also, for instance, have real sections which exist above or below other sections. Pain to think how the editor would deal with it, but it would be interesting to be able to "jump" from a ledge and actually land on the floor below and then run under that ledge.

Does that mean I'd have to factor in falling damage?

Hrm.



tagged: game, gaming

Dev Diary: Performance, Take III

As an aside, it's cold enough to freeze the balls off a brass monkey right now*. Schools are closing, they city isn't recommending being outside and a concentration of mist, fog and steam creeps over the lake. Thankfully, no zombies. This would be a really bad time for zombies.

So after thinking that my making Dreadnought render in such a way that it didn't have to redraw an entire table at once that I had more or less licked my major performance problems. Take II on rendering was to determine precisely where things had been and were going and adjust specific tiles. I even tried to make a multidimensional array to hold the DOM elements to speed up lookups. My Mac still wasn't happy, so I replaced the entire table based map with HTML divs instead.

As another aside, there's a movement within web developers that tables are obsolete and divs are the way for virtually everything. My problem with that is - tables were designed to hold information side by side and above and below ... divs were not. Clever CSS tricks work around this problem but often cause brand new ones.

Also, when I replaced a huge table with a series of absolutely positioned divs ... I got no benefit. None. Nada. Nothing. Probably because for modern computers, a table which isn't nested simply isn't much of a problem.

No, the problem is just size in general. It seems to be the number of elements, not the type, and sectioning portions of the elements off seems to have minimal effect. I'm not sure if it's DOM manipulation in general. A single move can cause several elements to flip class and content. With a very small map (say 300 tiles), this is really fast. With a large map (say 3,000 tiles) this goes down to a crawl.

Well, on my Mac at least. But what's the point of making a web based game if at least a lower common denominator can't work with it? I don't want to publish processor requirements for a turn based game.

So I have three options:

1) Maintain only a series of small maps. In other words, your "dungeon" would consist of 300 tile blocks. This feels suboptimal to me - burden to map creation, restrictive to gameplay.

2) Abandon discrete tiles. Instead of using elements for every tile, use elements to define overall room specifications and then rework the event structure to match. This is a pretty major overhaul considering the amount of code that currently exists that examines an activated tile. Course, to keep that code - #1 is about the only appropriate approach.

3) Ditch the DOM and use a canvas tag. This has a couple of attractive elements. Canvas tag offers many more rendering options (non-uniform lines, circles, etc). It's actually about the only thing (other than flash) which resembles what I'm trying to do (graphically represent data). However, it's also the most severe departure and would definately limit development to FireFox ... not just now but probably permanently without another rendering (and event) re-write.

Hm. Sigh. This is definately the biggest snap I've hit so far - a potential fourth quarter "backbreaker" turnover if you will. Actually, it's not that severe - I just wanted to make a Super Bowl reference. It's been my experience that when you see a browser slug in the way my BonEcho (an optimized version of FireFox for PowerPC) is slugging right now - it's trying to tell you that you're abusing the system. It's better to have this early warning now than down the road.

* "brass monkeys" refer to the brass holdings for cannonballs on a sailing ship.


tagged: game, gaming

Dev Diary: Loops

Sometimes it's helpful to think of games as a series of loops of varying sizes. Epic developers used to talk like this to mod teams. An inner loop might be the action and reaction between pushing a button and having a gun fire. An outer loop might contain overall combat mechanics. Way outer loops involve things like UI beauty and pretty logos. The outer loops are related to your inner loops (that pretty UI might describe the gun you were firing) - but it's a lot more distant than the delay the firing animation is given.

I've been playing mostly with setting up Dreadnought's inner loops. I've got melee combat, basic ranged combat, a concept of movement, health, energy, loot drops, loot pickups and crates (chests). I just started thinking about the loops outside of that - choosing weapons and attacks, setting up player menus, etc.

Right now I'm at a bit of a crossroads. I could keep moving outward and start flushing out the editor more, build some better test maps and starting modelling out the crafting functions. Or I could keep focusing inward on try and get the combat basics down really tight.

I'm leaning to the latter. My worry there is that I'll tinker so long on finer details and eventually get weary. However, combat is key. It's really, you know, the game. I'd like to make melee more interesting than just bumping characters around. Plus, how combat actually works will directly impact how crafting works.

Probably inner. Then ... the Bears are in the Super Bowl! Maybe I'll just nap until Sunday.



tagged: game, gaming

Dev Diary: Want Some Rope?

Dreadnought is still coming along smoothly. I got "crates" and "loot" working, so you can actually get things now. You can't do anything with them, but they're shiny. I started to define some objects which might resemble the actual product like certain monsters and weapons. I'm going to start working on some of the more advanced interface concepts like switching weapons, declaring attacks, closing doors and the like pretty soon.

But I've been thinking about one of the major features I really want to add - the ability to easily create your own maps and tasks (quests). The question is ... how much rope should the player get? Enough to tie a knot or enough to hang themselves?

Theoretically, if a player can create any map they want - they could create one room, fill it full of crates with powerful weapons, play it and go beat down whatever they like. Now - some of that is contained because if Dread's skill system works as designed ... that Iron BloodBlade Of BeatDown won't be nearly as powerful because they won't have any powerful attacks with it.

That doesn't alleviate the possibility of map creation becoming a Christmas party, just lessens the after-effects.

The question is ... do I care?

For one thing, Dreadnought's entire engine will be in JavaScript. That means in runs on the client side and is nearly infintely hackable. I won't go into details here, but one could pretty much do anything from give yourself new weapons to double your health if you wanted to take the time reverse engineer the scripts and write a couple javascript: bookmarks (this being why Dread won't ever be multiplayer in this form).

So - it's the player's experience they are tinkering with. Their own backyard. So why should I make a restrictive system to protect them from themselves?






tagged: game, gaming

Dev Diary: Dreadnought Early Screenshot

Ah, the fidelity. Clearly the interface could use some work. Actually, I'm still working with the render basics in general.



tagged: game, gaming