next »

[PsySal]

@brog you are welcome, sir!

[PsySal]

Why The Legend of Elkanah Sucks


I recently finished a game, The Legend of Elkanah. It's a simple side project that is supposed to play something like a storybook, based on the Bible story 1 Samuel 1, with a bit of a feminist bent.

I have to say it's not very good, but it's interesting to look at why:



Pacing
As soon as this game was done, I knew I had created a snore-fest. There are a few reasons that it feels so slow:

Subject matter. Let's face it, this isn't a really exciting story-- although I do think it's interesting from a feminist perspective. I don't regret the choice of story.

Inactivity Triggers. There are a few key events that only happen after you have done NOTHING for a certain number of seconds (usually 2.) Players can't anticipate this and will want to progress the story forward, to do so they will intuitively try acting. This stymies them, of course.

I don't know yet if this latter is an absolutely terrible device, but to work properly this problem has to be solved. I like it, because it has the effect of the game interrupting YOU. I.e., there is one part where Peninnah says, "Sister," to interrupt whatever you are doing, and I think it's an effective device; or could be if we weren't frustrating the player.



Immersion
The game could do a better job of bringing you in, as a player. A few things break immersion:

Sound. Close to the end I realized this game would be overall fairly bad and as I hadn't invested any time in sound effects, I didn't make much of an effort. However, nighttime sound effects, wind, etc. would add a lot to creating a storybook setting for this type of game.

Interactivity. There aren't any objects you can interact with, or places you can go on your own. You are more or less trapped on every screen, and moving left or right is purely cosmetic; it doesn't affect the gameplay whatsoever where you are on the screen. Interactivity, even very simple, can help a player's imagination to enter into the world.



Replayability
This is the most interesting lesson learned, for me. We have in essence a branching path like this:



There are some major choices, and some minor variations.

The trouble is that you've got to go through that first branch three times, at least, to see all endings. That's really not too fun! Worse, whatever variations you see are fairly random and it's certainly not worth replaying the whole game over again to see them.



A Better Story Stream
A better stream would be something like this:



The blue arrows mean we are given the option, after reaching that ending, of rewinding back to the previous point.

There's a small "common" section at the very start, after which you make a choice. The story follows similar but not identical lines for awhile, then branches further off. If we hit a dead-end in the story we are given the choice to go back.



Onward!
I think the next side project I work on is going to be for the kids; i.e. just a regular game without much originality. Maybe an exploration-RTS in space or something, there's not many of those in flash and it wouldn't be hard to do...

This is not admitting defeat, just a break! =) I have at least 2 weird art-game projects and 1 plain weird thing sitting in the back of my mind that I will almost definitely make, too.

[Geti]

This is really interesting to read, keep it up

[PsySal]

The Holiness of the Update Cycle



Most games have what's called an "update cycle". One way or another, there are a bunch of entities/objects with an update () function, which is called periodically (usually every frame.) These might control enemy logic, particle positions, animations, etc.

Here is something that I have found to be incredibly helpful in reducing bugs.

Holy Means "Set Apart"

Consider that your entire update cycle is "holy"; that is, your objects are ONLY allowed to change their state meaningfully within it. For example:

• Suppose you have an Enemy class, with an update () method and a hit (damage) method.
• The hit (damage) method will typically have some logic to decide if the damage should destroy the object, and make it explode if necessary.
• Then, there is a Bullet class, which within it's update () cycle checks to see if it's colliding with any Enemy objects, and if so, calls hit (5) for 5 damage.

How Something Gets Hit by a Bullet

Here's how I will structure this:

• The hit (damage) method is outside the Enemy object's update method, so it's not allowed to meaningfully change the state of Enemy. In OO-terms, any changes it makes must be strictly private, and not change the public appearance of the object.
• This means that the hit (damage) method is NOT allowed to explicitly kill the object; as well, its not even allowed to affect the outcome of a function such as isDead () (which might check if the hit points <= 0).
• So, what you do is you have a request variable, such as "damage_accumulator" which accumulates the damage over a frame. the hit (damage) function just adds damage to the internal damage_accumulator.
• Then, in the object's update () cycle, you perform hit_points -= damage_accumulator; damage_accumulator = 0; and a check like if (hit_points < 0) { explode (); };

Reasoning Why It's Better

I don't know exactly why this saves me so many headaches, but it does. For sure, it's something "like" a transactional system; changes are being collected (e.g., in the damage_accumulator variable, above) and then being applied later on, all at once. The update cycle for an object knows e.g., that the object will explode before it heals, or vice versa.

But I think it's actually more to do with unexpected side-effects where an object's external state changes more than once per frame. For instance, suppose object A had update () called, then object B's update () determined it needed to call A.changeSomething (). At this point, A has looked three different ways in the game's update cycle: before A.update (), after A.update () and after B.update ().

It definitely seems to be working for me-- maybe it'll help you, too!

[PsySal]

@Geti there you go. PS I'm giving away all my secrets here =) Hehehe...

[Carrie Nation]

This is some brilliant stuff Psy.

You have this great Fuck-all attitude to everything game dev related you do. Don't ask me to explain that.

[PsySal]

@Keyser: Aha! Thank you =) I don't know what you mean but I don't want to, either. =)

[Geti]

I think I'll go about getting that kind of thing happening now, actually. I've always felt that it'd be a better way to do it, and I do for the most part, but while I'm coding sometimes I just take the copout route of directly accessing something's HP or whatever Seems like I should really adopt better practice.

[PsySal]

@Geti I myself only do this about half-way; there was a really great post (by Blecki) on my LJ page explaining an even better way of doing this, which is basically a two-phase update cycle. What you gain by doing this is that it becomes irrelevant what order objects are updated-- even nicer. LJ link

I do think it's worth it, overall. It really doesn't add any overhead, it's just a different way of organizing things.

[Geti]

I think it's more that it's a way of organising things that means the expected result always happens, which is great. I'll make sure to read through that link at some point :D

[PsySal]

Scott Pilgrim vs. The World



I went to see this movie with friends yesterday, and really enjoyed it. I hadn't read the books but maybe I enjoyed it even more for not knowing anything.

Some weird feelings are settling out for me today, so I'd like to write about them now, while they are fresh.



Games' Symbolism is Formative

Zelda: Link to the Past came out around 1991, so I was about 12 years old when I first played it. When I was a bit younger, I played Zelda I and II, and it was a lovely, social thing. We would head to lunch at my friend's house to methodically burn bushes, or to write down long Gambling Cave sequences in a futile effort to crack the RNG.

Perhaps I'm on the cusp of the possible age to where playing videogames could be a formative experience. There are older videogames than Zelda I but they were under a certain threshold for complexity with respect to their symbolism, I think.



Religion

The human brain does weird things. Just like we used to find all sorts of nonexistent patterns in Zelda's Gambling Caves (something every slot addict must surely do) so too we find all sorts of unlikely analogies or explanations for other natural acts.

To pick a hopefully not-too-incendiary example, think about the US constitution. Certainly it's very important to the US, but what's so strange to an outsider like me is that people are so affixed to it, even to a religious extent.

In fact President Obama recently referred to it as the "Founder's Writ", which sounds a lot like "Holy Writ" to me, and Old Timey term for the Bible. Americans friends in earshot get this: it doesn't work like this in other countries. In Canada at least we really don't take our constitution that seriously, though it is of course important. Does this blow your mind? =)

Humans tend to get our brains wrapped tightly around certain ideas or symbols, extracting ever more meaning from them, and coming to ever more totally strange conclusions about the natural world because of it.



Scott Pilgrim

The imagery in Scott Pilgrim helped me to understand videogames in a different way. Symbols in games have the same kind of mythology that powers religious beliefs. They are, kooky though they might seem, a way to understand the real world.

There are some obvious examples from the movie, but I won't spoil anything here. Instead, let's pick an interesting example from games in general.



Warp Gates



Warp gates to a game designer are a handy way to refashion the game space to help the player get around. They reshape space in a way which really isn't in accord with the natural world, but which is useful.

If you grew up playing games with warp gates, maybe these are part of your mythology. The idea of a door might have a religious significance to you, as something that can somehow reshape space.

I'm not suggesting our generation are somehow confused as to the laws of nature, but interacting with gateways in games maybe has changed our perception of what a door can be. Even if that understanding never causes one to doubt the real purpose or structure of a door, it has become a powerful symbol for changing place, for shortcutting.



My Warp Gate

Actually, I just remembered something amazing. When I was about 10, between two houses one day, I saw a "cut through" or pedestrian walkway. I had passed by hundreds of times, but never noticed it. Naturally, I went through. What I found I called The Lost City of Paved Alleys. This was a paradise to me as a kid, because you could ride your bike very fast without worrying about cars so much.

So there was a real warp gate for me. I even still use it sometimes! Here it is.



Baptism and Eucharist


The most powerful symbols in a religion are interactive. I grew up in a church where certain things were very important: Baptism (where you are dunked under water as a sort of dedication to God) and Communion (which is where you eat bread and grape juice that symbolizes your belief in Jesus' Resurrection, past and future.) There were other interactive parts of a church service, like singing songs or saying special prayers, which are really pretty compelling especially when you do them in sync, as a group.

Psychologists will proscribe sometimes physical actions for you to take in helping to grow past some difficulty you are having. Maybe this sounds crazy to some people but it makes sense to me.

I once knew somebody who believed that screaming at the top of your lungs was really therapeutic. I'm sure he was right. He had some other weird habits.



Abstraction

We have to a large extent already abstracted the world we live in. Cars are real-life warp gates, bending and shaping space. You will understand this if you walk or bike somewhere that you would normally drive (but walking is best for this, as bikes are warp-gates, too.)

We rarely think of cities as a wild space, but I think that's how animals see them; forests with lots of people. For us they are an abstraction of place-nodes, and lines linking them. These are meaningless to animals, though they doubtless have their own strange way of understanding it (maybe in terms of danger, food, noise, and water.)

The day I went to see Scott Pilgrim we saw a Magpie (a local variant of crow) bathing in a fountain, inside a jewlery store. Somehow he got into the mall. After his bath he went next door for some candy. I'm not making this up.



Nature

The risk for us is that this abstraction will one day come tumbling down, for instance if oil becomes scarce, or we nuke ourselves into oblivion, or our system of money loses meaning through massive fraud or mismanagement. These apocalypses sit themselves behind all our symbols, because we do at some level recognize our abstractions for what they are.

I'm not sure the role that videogame-mythology might have in a world without all the modern abstractions, but it interests me.

[baconman]

IMHO, the videogame itself is all ABOUT the "warp gate." I mean, think about it, you choose a setting and mythos, full of virtual creatures and characters, power it up, and "warp" (IE: immerse) yourself into it. Your fingers are the brain, and your character is the body; and you've already "bent" not only time and space, but laws of "questionable Nature" itself. We are the creator and narrarator, just as we are the explorer, to semi-quote a certain fishy tail.

Granted, our narrative in such a setting doesn't override our physical being, or our other natural needs or states; we can't "plug ourselves into the bathroom" for instance, in our need to use one. You can spend a month "cooking" in a video game, but it's not going to feed "your" mouth.

This kind of thing makes me wonder about the external setting of the world - what if something bigger works in ways completely different of our own? I mean, to some extent, life and art have their imitative nature - cars existed way before video games for example. But there are games without cars, games with cars like our own, and with cars much UNLIKE them, as well.


It also makes me wonder about real life, and if there's intrinsic patterns in it to break (hint: yes there are). I walk a LOT - to and from work, to and from stores, I'm one of maybe 10 people in my modest-sized town that walks as much as I do. Likely 12 miles a day (which to many, is unimaginable. I've seen people give me crazy-stares for going to the local 7-11 on foot, because it's "just so far!!!"), so I know EXACTLY what you mean with that kind of thing. It gives me a totally different scope and perspective than, dare I say, most people have nowadays.

My idea of a long walk: Walking 11 miles to a mall across town, participating in a DDR tournament, and then walking back home. Believe it or not, I pulled the entire thing off without stopping, too.

But as I approach intersections, they have a rhythm and routine about them that rarely deviates, just like many people. Little details change, but the major outcomes don't. So if I'm taking a consistent route home, the timing of crosswalks, and the optimal order of them rarely changes, if at all. I'm still trying to find other patterns to flow with (like: always buy 3 bags of chips when on sale, when you need more they'll be back on sale again).

The Zelda gambling game is easy to bust. Always go to the right. Is real life so simple? Doesn't seem that way, that's for sure. But part of me can't help but wonder - what if it really IS?


Haven't seen Scott Pilgrim, to be honest. And it's been awhile since I've found or taken a "Warp Gate" like the one you mention, but generally I've found them all over. In whatever I do. Lately "aisle 4" at work (grocery/freight) has become one, as it's generally the least packed and easiest to navigate quickly.

It's not the change in abstraction that scares people. It's the inevitability of that change; it's something that always has occured, and always will again, out of natural necessity. It's especially damaging when it comes to topics like economy, religion, rights (which is WHY America takes it's Constitution so seriously... it's basically what protects it's people from it's government - possibly the biggest challenge to our freedoms - and increasingly evident over time). People use these as fundamental foundations - for their lives and philosophies to their everyday decisionmaking and even the definitions of "common courtesy" and "normal life." Take that away, and what do people have?


The story of that Magpie is great! There's a few Kit Foxes around where I work that do the same kind of thing. Nature and Civilization not only can coexist, but inevitably will.

[PsySal]

@baconman Cool, I really like your reflections here. Somehow I missed the analogy of games as a warp gate themselves, but it's true. 11 miles is really a lot, 22 miles blows my mind. And you *do* have a different perspective than a person possibly can have who can't conceive of this. Life is truly amazing.

I know what you mean about pattern breaking too. There's a bike ride that I've done only 4 times; and already today I think I stopped in nearly exactly the same places each time for water. Not sure if that's a good or bad thing, more likely it's something not needing a value judgement =)

Thanks for your thoughtful post.

[Bad Sector]

I like the look of what you make :-).

Btw, these "metacomputers" you are talking about are more commonly known as Domain Specific Languages (DSLs) and are very common in languages which allow great flexibility on their syntax (like Lisp for example) or when building your own interpreter. Related wikipedia article (which might enlighten or confuse you :-P).

A cleaner example of a DSL is this: i have made a scripting language similar to Tcl called LIL (Little Interpreted Language) which has a simple syntax of "command arg1 arg2 arg3 ..." and works on strings substitution (arg1 can be, for example, "[cmd2 arg arg arg]" which first calls cmd2 with the args and then the whole bracketed expression is replaced with the result of the cmd2 before being passed to "command").

I this scripting language i've made documentation files similar to this: (note: { and } are actually quotes, similar to "s, but there is no string substitution done inside so they're used verbatim)

Code:

doc:func "sqrt" {
    doc:argument "n" "number" "a number"
    doc:returns "number"
    doc:info "Returns the square root of the given number."
    doc:example {
        set four [sqrt 16]
    }
    doc:see-also {sqr}
}

doc:func "sqr" {
    doc:argument "n" "number" "a number"
    doc:returns "number"
    doc:info "Returns the square of the given number."
    doc:example {
        set sixteen [sqr 4]
    }
    doc:see-also {sqrt}
}

The above code, as you know, is plain text data and it clearly has a tree-like format. So a C program can be written to parse this tree and create HTML output (or whatever else).

However it is also valid LIL code: each entry is a call to "doc:func" with two arguments (remember that { and } are used to quote strings verbatim without further processing). One argument is the function's name and the other is text in a simple format which follows mostly a key val1 val2, etc format that is very easy for lil to parse. But it is easy for lil to parse it since it is the same format used for lil code itself: it is a bunch of code. And here we come to what you said about metacomputers: code=data=code.

So i can simply write doc:func, doc:argument, doc:returns, doc:info, doc:example and doc:see-also as lil functions which generate HTML (or whatever) code, something like:

Code:

func doc:func {name code} {
    set global current-func $name
    set global arg-list {}
    set global return-type "nothing"
    set global info "No info for $name"
    set global example "No example for $name"
    set global see-also-list {}
    eval $code
    doc:generate-html
}

func doc:argument {name type info} {
    append arg-list [list $name $type $info]
}

func doc:returns {type} {
    set return-type $type
}

func doc:info {text} {
    set info $text
}

func doc:example {code} {
    set example $code
}

func doc:see-also {items} {
    foreach item $items {
        append see-also-list $item
    }
}

func doc:generate-html {} {
    print "<!DOCTYPE html>\n<html><head></head><body>\n"
    # use the above info here
    print "</body></html>\n"
}

So documentation (data) is plain lil code. But its also data so a dynamic PHP page can parse its tree-like structure in order to display, say, a page for each function with user comments and corrections, without the need to have a complete lil interpreter - which in PHP's case would be slow since PHP is an interpreted language itself (this is how a simple syntax helps).

Here is also a more game-oriented article on DSLs

[PsySal]

@Bad Sector I didn't reply just cos I didn't want to be overbumping my own thread but thank you for the link, I do think it's really close to what I'm doing and I did read what you posted. I've been thinking a lot about these little machines/language lately and trying to understand better why it seems to make my life so much easier. Anyhow!

I did another blog post last night, this time it's a (shortish) "Let's Talk" where I just talk a bit about the process of Open and Closed loops. You really need to check out the Kate Beaton video I mention!

About halfway through is a longish gameplay scene of me chasing around and being chased by this mop-weilding bandit. Pretty awesome, they can deflect bullets with their mop.

Onward to Let's Talk Episode 4 - Open and Closed Loops

[PsySal]

Ah Summer, Where Have Thou Gone?



No insights lately, sorry!

But here is what I'm up to:



Texas Submitted to the IGF

Trailer is Here

I think the IGF is a fabulous event. There is a certain noise surrounding whether the judging is fair, whether "indie" is really indie, and so on but overall if I look at the winners and nominees from last year I think it's pretty reasonable. People can never feel satisfied with judging, this is simply normal.

I am glad to be part of it. The field looks very, very good this year so it will be interesting to see what cream rises to the top. Here's hoping! If Texas doesn't really get noticed I won't be too surprised because there are many other fantastic games. Still, I can't help but feel proud of what I hav emade.

The trailer above was posted on The IndieGames.com Blog which is exciting for me.



Texas Is Almost Done



Since the big push for the IGF, I haven't felt much like working on The Real Texas. Life has been busy in other (fun) ways. Doubtless that will soon change, and I feel like one more big push will get 'er through to the end.

Then I will do user testing like mad to find out where people are getting stuck. I also scored an older Mac Mini that I will use for the Mac port. I'm of course not sure exactly if the HW will handle it properly but it should at least let me build and see that it runs.



Game Dev Advice

When you don't feel inspired to work on your "Project A", relax!! Don't force it, take a break, and make something else, instead!

So I took my own advice and made 2 things! Wow!



GUN - WINNITRON 1000 Game



I don't really have anything playable for you on this, but I finished a game for the WINNITRON 1000 which is an indie arcade machine in Winnipeg.

The game is very complete, missing only a hi-score table and hopefully some real playtesting feedback (I shouldn't put in hi-scores until the playtesting issues have been worked out.)

The game is a 2-person game where you shoot robots to rescue your dog. Some (hopefully) lovely surprises and many types of enemies, this was designed right from the start to play on the WINNITRON and that's why there is no play in your web browser version (yet) -- I'll need to adapt it somehow.



Waterwheel



Another little game/toy here.

This one is sort of a foray into Chaos Theory.

dx/dt = \sigma (y - x)

dy/dt = x (\rho - z) - y

dz/dt = x y - \beta z

Thank you, Mr. Lorenz!! You didn't fix the weather, but that's A-OK because you gave us some cool ideas! =)

[PsySal]

Game Dev Trix - Arguments
Today I have some things to tell you that are technical mumbo-jumbo-ey. This one is really juicy and I promise I'm giving away all my secrets, so ignore at your own peril!





Seeing the Small Picture

As programmers, we are used to dealing with nitty gritty details. For instance, if you show "openFile" and "OpenFile" to many programmers they will interpret "openFile" as a verb (i.e., "open the file") and "OpenFile" as a noun (i.e., "the open file"). A silly and sort-of wrong example, but it shows how tiny details change meaning for a programmer.

My programmer brain spends a lot of time wrapping itself around such minutae that it starts to seem normal, which of course it isn't. The danger is that I will lose perspective and see only tiny details.

This is why programmers sometimes do not finish making games. We spend all our time on bump mapping, when we should just have everything flat-shaded!



Parameters vs. Variables

One thing I didn't appreciate until recently is the difference between a parameter and a variable. We often think of functions in terms of arguments. Naeively, to draw an alien to the screen we could do:

$bitmapData = readBitmap ("alien.png");
drawBitmap ($bitmapData, 5, 10);

It probably makes sense, however, to have a Sprite class that captures some of the details:

$bitmapData = readBitmap ("alien.png");
$alien = new Sprite ($bitmapData);
$alien->draw (5, 10);

Let's loosely define a parameter as something which we do not change that often, and a variable as somthing that does. In this example, we have parameterized our bitmap data; the alien's (x, y) position might change every frame, but his graphic does not.



Grey Areas


As programmers, we tend to see everything in terms of arguments. Ha, ha! That is actually a pretty good pun! Anyways.

What I mean is that as seers-of-detail we take the above and realize that "all we've done" is reorganize things. $bitmapData is still being passed as an argument to $alien->draw (5, 10), it's just implicit:

$bitmapData = readBitmap ("alien.png");
$alien = new Sprite ($bitmapData);
Sprite::draw ($alien, 5, 10);
// or if you prefer, we could just call drawSprite ($alien->bitmapData, 5, 10)

It's important for a programmer to understand the above code, but we lose the big picture if we think it means that there is no difference between parameters and variables. Worse, I don't think we can draw a line exactly between them-- something else that programmers relish.

My point is there is a degree of variable-ness and parameter-ness to the inputs or context of a program, class, or function. Programming, in part, is carving up the parameter space cleverly into smaller and smaller chunks until we have a model that does what we want. In the broadest possible sense, the most "parametery" parameters are like the laws of physics (and aren'tprogrammers more willing than most to accept that these are somehow "reset" at the big bang/big crunch?)



Particle Systems


As every game programmer knows, particles make things awesome (just ask Rob Fearson). Writing a particle system is normally an issue of setting certain parameters: the rate of particle generation, the size, the rate that their size changes, the initial velocity, the acceleration due to gravity, the rate of "spread", controls on the initial position or size when they are first emitted, their color, the rate of change of their color, the rate of change of their alpha, and so on. A heckuvalot.

All of these we normally think of as parameters. We might have a few that are realtime adjustable, for instance the "origin" might be a variable so that the particles can track a moving object, or perhaps even the overall rate of emission-- then a spaceship can emit more fire as it moves faster.

As a real-world example, the particle system in The Real Texas has 28 (or, if you count a vector as 3 parameters instead of 1) 46 parameters. Only the "origin" that the particles are emitted from is a variable.

But the trouble with particle systems is tuning. With so many possibilities, it can take forever to get them looking proper! Most combinations of arguments are useless. But many combinations of arguments give great and varied effects, too! You can create very nice effects if you can get the arguments just so.

We could put all these into an interactive simulation with sliders and so on to adjust, and that would give us some artistic control. I think this is a good solution if you can afford it (or use a game development environment that already has such a thing for you.) But maybe you can not/do not have such creature comforts!



Parameter Wrapping

At run-time, these parameters do not change and so are truly parameters. But at tuning-time, they do change, and a lot. So when we are adding a frost effect for the Cloak of Ice, we should think of these parameters as variables. Tuning is hard because there are so many variables!

This is important: when viewed at from run-time, they are all parameters because none change. But viewed at from tuning-time, they are all variables because they all change. It's an important conceptual leap to see the development process as part of the program.

Anyhow, let's reduce them.



Trix 1 - Coupling

One strategy is coupling. To couple two variables, we recognize a relationship between them. Suppose we have two variables, emitAreaRadius which describes how large of an area to emit from and emitRate which describes how many particles-per-second to emit. We can rearrange these to be emitAreaRadius and emitDensity, and then just calculate:

emitRate = emitAreaRadius * emitDensity.

At first glance, it may not appear that we have the number of variables. In practice, however, we did, because at tuning-time we are going to fix one, for example size, and adjust the other. We have made one of these variables more parameter-like at tuning-time.



Trix 2 - Grouping

Another strategy is grouping. Suppose we have three tuning-time variables that control the color. One might be alpha fade rate, another one initial color, and another one describing a rate of desaturation (so that a bright orange flame particle turns into grey ash.) What we can do is group these together into a single tuning-time variable, colorType. When we set colorType, we are going to automatically set all of these tuning-time variables accordingly. This is helpful because we might want to make larger or smaller fires.



Trix 3 - Naming

This is really just a variation on Trix 2. When adding a particle effect to a jet engine, we might specify all 46 tuning-time variables as part of that object. But a better solution would be to create a super group containing all these tuning-time variables together, and call it for instance "jetEngineFire". Then we just create a jet engine and set it to "jetEngineFire", and can re-use this for other objects.



Not Just For Particle Systems


I use this same approach everywhere in designing assets in my games. For instance, a 3D model can be thought of as having a thousand design-time variables (every vertex, together with texture and color coordinates) or just a few (thickness, texture type, height). Clearly, at design-time the second is preferable. If you are into that kind of thing, this is really just another way of looking at procedural generation.

Hope this helps you! As a final bit of advice, I'd suggest to not over-design or look for a perfect parameterization of some function with many variables, but just cut things down to managable complexity and then run with it. Part of throwing out detail is that there is no holy grail, no perfect way to make the cut. At the same time, as you create more and more managable models you are going to see better ways to describe things.

Good luck!

[PsySal]

Final Boss is Finished



Today, after maybe 4 years of solid development, I reached the first "finish line" for The Real Texas.

December 7 I started work on the final boss mechanics. Today, 20 days later, it's basically complete. I will still need to do some major tweaking and add a few minor-ish things, but there you have it. And oh, dear friends, have I been slogging.



What's a Boss Battle?
I try to generalize the idea of "Boss Battle" into what is really just a climactic gameplay event.

These kind of climactic battles take a lot out of me, because I try to avoid formulas. As a result I do not work very efficiently and they take forever. In fact, when faced with a boss battle I end up wasting a lot of time browsing the internet or just sitting around the apartment and thinking. For me these are the hallmarks of having run out of creative energy.

Once an encounter picks up some momentum, however, it's more possible to focus. Like a puzzle that comes together, once you see certain things in action you can see more easily what is required to complete them. But reaching that critical mass is a long and painful process.

Each "boss" encounter in The Real Texas is somehow unique. I'm not suggesting they will blow your mind, but none of them are "memorize the pattern and hack away until it dies." And by unique what I mean is that they represent situations you should not have really encountered in games before or would not expect, exactly. Not that I claim 100% originality, either.



What's Left
There is now nothing major left for me to do to finish the game.

My list is roughly:

- One area for the epilogue.
- Some drawings for the "THE END" section and maybe to redo the intro drawings.
- Fill in a few areas with foliage/etc.
- Maybe a few small mini-dungeons/puzzles for reward items.
- A number of end-of-game cutscenes.
- Rework some quest sequences.
- Figure out one major-ish subquest's resolution.
- Fill in more object/enemy interactions, particularly with respect to the later-game weapons.

After this comes the truly end-game stuff of final play-testing and of marketing, which I will do in parallel. I need to try and get the attention of Steam and other distribution services. At the same time I will need to work with a number of people to play the game through and find out where the sticking points are, and resolve them.

Fortunately I have a great list of volunteers who have played the game in the past and/or are eager to give it a try! If you've asked me before, you are likely on this list. If not, you can post a comment here or email me at [email protected] and I will add you to it. I can't guarantee that I will get to you but the list isn't that long so the chances are good.

ONWARD!



A Present
In commemoration of this momentous day in my life I have drawn a picture of Gannon for you. He looks oddly at peace with things:

[floatstarpx]

only just spotted this thread.. style of the game looks really interesting, and i skim-read some of your stuff (and chicken AI), and it's a nice read. 

[mildmojo]

Where has this thread been all my life? Thanks for the writeups; lots of bits that say, "hey, what if you think about it this way?"

As a non-painter, the 3-tone shading palette was a complete eye-opener. And I'm going to see if I can work two-part updates into my next effort.