Wednesday, March 31, 2010

Globetrotting - Debugging part 2

So, I think I've tracked down the true source of the chug, and it's pretty funny.

You see, the way my drawing code works is that I check to see if the player is on the current floor, and if it is, then draw everything within so many tiles of him. If not, then just skip the entire drawing section. Sounds like a great idea, right?

There's one major problem, and that's that the objects I draw have no place to be until I actually go onto their floor, because their location is based on the draw code. Which means they'll all appear to be on square 0,0 - but won't really be.

The other problem is that while I'm not drawing any of the procdural art for these foors, I am still loading all the movieclips for them. And they don't go invisible until I've left the floor they're on. Which means, if I change the code for things to go invisible as soon as they're loaded, we should lose all the things showing in the top left corner of the map, and thusly the chug with is confirmed to only be associated with them being on the screen.

EDIT: Yep, this solved it. I can now have all the dungeons I want... well, almost. Items are still being annoying, but I figure the majority of the same fix will work for that problem, too.

EDIT2: turns out it was a different problem for the items, though the walls soltion dropped down the chugging by another sizable amount. Every frame something is handled, everything that is being told to calculate what it's doing goes invisible. Every time it's told to draw itself, it becomes visible. Thus, if something is told to draw itself, but then never toldto do anything - it will stay visible forever.

Which brings me to the issue with the items. Items are being held on tiles. Tiles tell the creature on them to calculate what they're doing. The did not, until a moment ago, tell *items* on them to calculate what they're doing. As such, the moment an item appeared on sceen (which before was when it loaded, and now is only when the player walks onto it's map) it stayed there forever, as it didn't get a 'calculate what you're doing' command until someone picked it up.

Now, items are told to figure out what they're doing, even if all that means is that they go invisible - that's what I really wanted them to do anyways...

Sunday, March 28, 2010

A funny debugging story

As I'm debugging, something funny popped into my head that happened at work a while back, which prompted me to test something different than I usually do.

At work, two years or so ago, we were starting to see slowdown in one of our games, and we simply couldn't figure it out. The particular game was less complex than our other games, but it was running so much slower that it was starting to become unplayable.

Then, one day, I noticed this tiny little line at the very top of the screen. It must have only been one pixel. I hovered over it, and I got the text cursor. I thought 'huh, that's odd'. So, I clicked, then hit ctrl+A, and ctrl+C. Went over to notepad and hit ctrl+V. You know what I found?

The transcript for war and peace was printing on every line!

Nah, I jest about that - but the amount of debugging text that was being printed to the screen in a place it couldn't be seen but was still required to process was of a similar size (text takes up a lot of space in a vector engine, it's about the only thing that's more efficient to do raster-based, AFAIK)

So, here we are, wondering why everything is slowing down, and I go into the code, toggle off 'display debug', and run it. *BAM* it's running so fast we have to go in and decrease the framerate. It's funny how that worked.

I say this because my previous blog I realize - hey, what if my slowdown is coming from all the traces I'm putting in, whenever I run the game I'm running it in debug mode.

The answer: Makes no difference. Good to know, though.

Globetrotting - debugging 1

So, I've been working on fixing the extra walls showing up in tinyworld, and I've made a lot of progress.

The first thing I did was I added a clause in the 'draw a room' function. You see, when a dungeon gets built, it only actually calculates the size of the first room - everything off of that is recursive (well, kinda). It just says 'based on the size and position of the first room, draw a room over there'. Which means if a 20 space wide map generates a 10 space wide room, and it wants to have a ten space-wide room on either side of it - those would have run off the edge of the map before. Now, they just look ugly. >.> Which is an improvement, running wise, but I need to come up with a more eloquent way of keeping that from happening.

Actually, that makes me think of another thing I need to add to the program - a recursive dungeon generator. What I have is highly random, but not perfectly so. There's only a few dozen possible combinations. Something to add to the random, but stay away from that spaghetti dungeon feel would be great...

Anyways, keeping rooms from generating off the edge of the maps made a noticable difference in the number of 'null location walls' that were drawing at world 0,0. That's a great thing. But it didn't fix all of them, only a few less than half. I soon realized, that's because every time I drew a wall, I just threw away whatever was on that space beforehand. Okay, that's fine - except that I draw rooms adjacent to one another, I redraw the walls, because the code doesn't care what walls are external. So, for a 5x5 room with a 5x5 room adjacent, I'm creating adn then losing track of five walls. With six rooms (often closer to 10x10) across five floors times five dungeons, that means probably 200 (or 500 with less conservative numbers) walls being created, told to keep track of themselves, and then dropped.

So, I make it clear off a square properly before adding a wall on it. Instant speed increase. But it still doesn't get them all, and I think - well, it's probably the same problem but slightly different.

The answer is staring me in the face - doorways. I draw doorways after I draw walls, and that involves deleting the wall there. I was right, I wasn't removing them properly. I don't see a speed increase here, but that's okay - it's only really affecting twenty squares to the previous change's 200.

Still, there's one square left that's eating away at me, and I can't figure it out. I'm almost positive it's related to the stairs, and it dissapears once I reach the top floor. Weird.

I've got other debugging and optimizing still to do, but the change is enormous.

Previous time taken to take one step: minimum ten seconds. Now? One and a half. Still unnacceptable, but there are a bucketload of things I'm doing wrong somewhere, and that last null-location wall is going to fall some day.

Saturday, March 20, 2010

Globetrotting - part 1

Tinyworld currently is just that. Tiny. If it were the real world, there would be the space for about two football fields side by side, and that's it.

But, the world is more than one map large, and more than one map tall. It is, effectively, a three dimensional world. Good for it. I've recycled my stairs code to connect one map to another side to side and top to bottom, and like all good fantasy worlds, it loops.

But some old bugs have come back to plague me, and I fear I won't be able to continue working on the world until I sort them out, and I hate debugging. Even when it's my own stuff. Especially when it's my own stuff.

So, every tile contains a number of items, two of which can have art associated with them - the variable names for these onMe, and the holding. onMe is anything that fills the space. A player, a creature, a tree, a wall, things like that. Things will run into and interact with these things. holding are anything that can be picked up. swords, shields, eventually gold.

When something is off screen, it's supposed to not draw at all. But that doesn't work. When a holding item is on another map, it still draws, and that takes up a lot of memory. Furthermore, if a building ever hits the end of the map, it will attempt to draw an item in a square that doesn't exist, and those will also always draw.

Which is where we come to the problem. Drawing stuff takes insanely longer than simply calculating it. My testing environment was a 5x5 world containing 10x10 maps. That's 2500 tiles to calculate. Without dungeons, no issue. With one dungeon, mild slowdown (okay, each dungeon increases the number of tiles by 500 or so, but see below). with two, it's chugging. Three or more and it's unplayable.

But I know it's not the tiles. I've tested this by increasing the number of maps to 20x20, and the size of the maps to the same amount, that becomes 160,000 tiles. Not a chug in site.

So, I have to stop and debug. First, the obvious problems - when a dungeon gets too big and draws outside of it's boundaries. Ironically, I could avert this by having huge maps, but that's a little counterproductive, because I want to make the dungeons bigger than they are, too. So, fix overflowing dungeons. Then fix overdrawing stuff. Then, back to the top, and see if we can have dungeons in the world...

Friday, March 19, 2010

Plans for the TinyFuture

I've been thinking about tinygame lately. Most of the programming I've been doing has been to simply get the game to work, with all of those darn 'make the game fun to play' problems being put on the 'do it later' shelf.

I've still got a few impotant things in the single dungeon area, which is arguably going to become the bread and butter of the game, but once I finish those few things I've got to start thinking ahead for the future of the project.

The next step, of course, will be to get a world (and a world map, damn, there's another new thing). Then towns. Then NPCs, then come up with a better way to generate and handle all the equipment and monster data in the game...

It's going to be a big projct, I just wish I didn't get distracte from it so easily.

Thursday, March 18, 2010

The players see a plot device

For any of you who don't know, Paizo's been holding their annual RPG Superstar competion over the past month and a bit, and the've gotten into the finals where the competitors each have to produce a full adventure proposal, the same sort you'd normally submit if you were a professional wrter.

Anyways, the idea is for the community to vote on them, based on the judges comments.

Now, I respect the judges of this competition a lot, they're industry pros, game designers, and generally awesome people. But there's one peeve of mine that cropped up a lot in the adventue proposals - 'and so the players '. Sometimes it's as simple as 'and so the players see the shadow flicker'. In fact, I'll use that exact example.

One adventure states 'the players see shadow suddenly whoosh away outside. While chasing it...' But, the players have no idea that they should chase the shadow. It could be a trick of the light, it could be a trap, and at this point, they probably don't even know that the person they're speaking to is an imposter. In fact, without knowing that fact, it seems like the shadow is more of an alarm to summon help, rather than anything else. I don't think I know anyone who, while interrogating a theif, if they saw the theif's shadow run away would follow it. Mos of them would stay there and interrogate the theif as to why, which would lose this thing.

Anything that assumes the players will act in one specific way, especially when it's an important aspect of the story (in this case it's crucial for the players to continue), is a bad idea. And I'm really surprised nobody called them on it. In the previous challenge, the judges marked down entries for saying so much as 'the cold is uncomfortable' because there might be players immune to cold effects - and here none of them notice that some of their most lauded entries use this not just once or twice, but several times each.

Perhaps I'm just picky, I mean they did have to come up with something entirely from scratch in only a week or so, but I feel they could have done a lot better in that regard, seeing how good these people all are.

Thursday, March 11, 2010

Marketing Bananzi

Last post, I was talking about starting adventures, stories, games, movies, whatever. I was talking about the little peices of information you have to get whe you start something to determine whether or not it will be interesting to you. But really, there's more than that. There's even things you get before you have access to the product that might determine whether you'll like it or not.

It's called marketing.

Before you even turn on your console, before you even open the first page of a book you see it in the stores. Most of the time, your first impression will be the size, color, cover image, and title of a product. You have to form your initial impression before you even touch it. Many people will know the difference in what they like between 'The flowers of Jehusbeth' and 'war of the death-tyrants', but what abou 'Mr. Smith'? It could be anything, and while it's most likely to be a biography or something similar, it doesn't provide enough information.

Now, we get to the image they pick for the cover. Most of the time, the images you'll see on any advertisements are artist representations of some of the content. Sometimes it'll be totally accurate to the content, sometime it won't. Terra in the final fantasy series is a good example. In the games, she has yellow hair. You can see it right there. In all the advertisments, she has bright green hair. Needless to say, people were confused at the time, but not much. Fast forward a few years, and Final Fantasy Dissidia comes out, using the advertisment art as the basis of the characters, instad of the in-game art. Now people are totally confused, because Terra looks totally different. These characters were based off a character based off her character.

Still, the images are really the selling points on most products. You probably would buy a air freshener with flowers on it. You might by an air freshener that was in a solid red container. You probably wouldn't buy an air freshener if it featured the picture of a fire hydrant. Who wants their house to smell like fire hydrants and dog-pee?

The problem here arises because you're most often going to see a dozen of these things at once. Artists have to pick either one of the most dramatic scenes of the book to illustrate or someone looking at the cover will choose the dragn breathing fire on a princess over the guy with a cloak in a hallway.

Ah, for the simple call of 'hey guys, let's play some DnD'

Wednesday, March 10, 2010

Starting an Adventure is Always the Hardest

Every world has to have a jumping off point. A first line you read in a story, the first image you see in an atlas, a first decription your dungeon master reads you. The question is, as always, what do you want this to be?

This first snippet of information can be the basis of your audience's entire perception of the world, and it had better be good or you might lose them. In today's market, people need to be hooked in seconds or hey might never delve deeper. But I can get into the ADD of marketing another time.

In an adventure in dungeons and dragons, the starting point is where the players meet. Oftentimes, the players will meet in a tavern, and get roped into doing something they had no real initiative to begin. Others are more creative, driving all the players to a common location by means of a threat, or even having the players be captured by some now-common foe that they must escape. But, even the best adventre hook can feel estranged when the characters don't have any motivation to be there.

One thing I try and do when creating a campaign, is give a notice to the players about things they need to involve in their backstory. 'You need to be broke, and willing to work for money' 'You belong to a theives guild' 'You must be searching for a specific holy maguffin' are all examples of requirements I've given players in the past. It's like building in a handle for your adventure hook, and it makes campaign planning much easier, because you don't have to design a hook for any imaginable subset of characters, but for any characters that might fall into a particular category. If every one of the characters seeks the same maguffin, they have a very strong reason to keep working together once they find themselves out of whatever trouble they found themselves in.

Of course, you can't expect this connection to the first hook to continue to be the hook for every adventure, or the players will start to feel dragged along by the nose. Higher level and follow-up advenures still have to be tailored to a general group of just about anyone.

This hook/handle concept is something that other dungeon masters should consider, to make their own lives easier, and the players feel more connected.

Tuesday, March 9, 2010

Response Ready

As you know, I work as a game developer, and while I do take pride in that position the projects often take a long time, and since they're educational games, they're a little dry for taste here in this blog.

But, even dry content is better than no content, right?

In between the other projects at work, Ive been working on refurbishing one of our oldest games, Response Ready. This game won all sorts of awards, got all sorts of attention, and is still in the news today, simply by virtue of still being in the news. I've never been party to old news re-hashes before, but I've seen it now.

Anyways, Response Ready is, at it's core, the child of a hidden object game and a choose your own adventure, with a time limit and a resource management game thrown in. You're given a scene, and are tasked with identifying the dangers in the area. For example, the gas pumps might spill, or the train running nearby might derail, or someone at the furniture shop might knock over a shelf of wood-treating chemicals. Then, you rank them as you find them based on how dangerous they are and how likely they are to happen, and you get a procedure out - for instance 'clean up spill'.

Then, you go into the timed choose your own adventure, and immediately something goes wrong. From the list of procedures based on the dangers you found, you have to respond, and get your people moving to solve the problems. But it's not just that simple, as you're working the emergency continues to worsten, so you have to be both proactive and watchful.

It is a good game, and a brilliant idea, but it's really old. And the art is only a handsbreadth above 80s cartoons (admittedly, it was styled that way on purpose). Really, the game needs a makeover. I'm porting it to a new system, then we're going to add new levels, and if I can find someone we'll redo the art for it. But, that's in the future.