Monthly Archives: May 2009

It’s a 1.7 mb 32 second video.
So youtube compressed it. Assholes.

Continue reading →

I’ve uploaded a new JileEd beta. It’s really turning into a Zelgine-specific editor.
My download plugin broke and I have no idea why.
Continue reading →

First, let me say, Behind The Dumb is very slow right now! I’m spending a lot of time on the site update stuff (not covered on the show), and the game is suffering. I haven’t actually filmed anything yet, and it should’ve come out last week! I think what I want to do is officially make it biweekly (which I’ll probably be late for this week too…). You’ll hear more about the site update in the future, and why interesting things are happening behind the scenes here.


But here’s the input I seek! I have two interesting Behind The Dumb show ideas, but I need your help for both. Please email me these things:


1. Questions and comments. Yeah, the usual stuff I put in the email segment, but I’m looking for big questions (about anything really, though perhaps the game would be a good topic) that I can springboard into a discussion from. I want to make an entire show that is made of emails, with each email leading into something interesting instead of just a simple answer.


2. Suggestions of stuff you want to see on the show. For example, Atkins has already said he wants to see code explained through interpretive dance, which is a perfectly logical feature. What do you want to see? I’d like to do an all-request show, and it could be quite amusing if your suggestions are worthwhile.


I know I won’t be able to use a large percentage of what gets asked/suggested, so feel free to send both things, and more than one of each. Send more later, send anytime. Send many emails, pack many things in one email, whatever. I want lots of options! Continue reading →

First off, I’ve made a first gameplay video and finished revamping my website. You can see both of them here:

http://www.kittylambda.com

I think that I can’t continue to separate game development from game promotion. I think I’m going to do some kind of video blog, because I’ve really enjoyed Hamumu’s Behind the Dumb:

http://hamumu.com/behindthedumb.php

However, I’ve spent most of the past week working on this stuff, and I think it’s now time to move on to other things; namely actual game development. I’m going to start off by changing the deer animation and then start adding some more game objects, like a suit of armour for the east hallway and maybe a chandelier or two. Continue reading →

towlr-genre
download:
Windows
OSX 10.5+ (Intel)
Source
controls: mouse
EDIT: oops had a major bug that made it weirdly easy. Fix’d.
Continue reading →

It never fails, or at least in the two that I’ve participated in, that Ludum Dare competitions produce a great variety of styles and quality in graphics and gameplay. Here are a few of my favorites from Ludum Dare 14, “Advancing Wall of Doom.” Scroll down past the ratings to … Continue reading →

For handy marketing and development purposes, I’ve created the two following forum threads:


Why do you like Hamumu?


What don’t you like about Hamumu?


Your input is greatly appreciated in both! If you are shy, you can send me an email (you can even use the Contact Form without putting in your email to be anonymous – just don’t do it when logged in, or it’s a lot less anonymous!) instead of posting. But please please send your information. It’s for your own good!


The first question will be very helpful both in knowing how to market the site so I can bring you more new friends to play with/abuse, and in knowing what the key things to keep/expand are. The second question will tell me what the key issues are that need improvement around here.


Which reminds me that a major overhaul is coming. Probably not soon, only because these things take a long long time to finish. But it’s underway! It won’t be like the last one – we’re keeping most of the underlying technology intact. I’ll just be adding more interactivity, integrating everything better, making it much easier to navigate (somehow!?), improving the looks, making it look more appealing to the n00Bz, and fixing whatever you complain about in that second thread! Well, if I agree. Continue reading →

Windows (800KB)
OSX 10.5+ (Intel) (1MB)
Src (9KB)
Controls
Cursor keys + s + d (+ space for menus/dialogue)
(ps. it’s completely linear)
Continue reading →

Now let me tell you about BeautifulTimer; this is (close to) the best way I’ve found for doing game loop timing.

First, you (of course) split your game logic into update (T) and render () sections. update (T) controls all game logic and animation state, and T is an input variable representing elapsed time since the last frame. render () just draws things to the screen, based on the current game logic and animation state.

Timer Type 0: Type 0 game loop timers are those that ignore or don’t have the T-parameter in update (), and don’t have any special waiting cycles. This can be effective I’d imagine on very specific hardware, but it’s problematic for two reasons. i) if the hardware is too fast, the game will run too fast, and ii) if the hardware is too slow, the game will run too slow.

Timer Type 1: Type 1 game loop timers are where you have an additional wait () method in between frames. The idea is simply to figure out how long it’s been since the last frame, and wait long enough. Think of this as a fixed frame rate timer. Given that ii) above isn’t a problem, then using this the game will run at a constant framerate. In this situation the update (T) does not need the T parameter; each time it’s called, you can call update with the same value for T since the same amount of time (ignoring ii) has elapsed.

Timer Type 2: Type 2 game loop timers are where you now call update (T) with a T value containing how long has elapsed since the last frame, and where you have a wait () method as in type 1. This takes care (ostensibly) of i) because you wait () to make sure that the game doesn’t run too quickly, and ii) because you’re updating game logic with larger timesteps: the player’s brain will fill in the details.

Most game developers will be familiar with all of these types of timers.

There are some problems with Timer Type 2, that cause many developers to revert to using Timer Type 1 and trying to optimize their code enough to avoid ii).

Problem 1: Physics and other game code becomes unstable/unreliable with large timesteps. As the game takes longer to process each frame, the gameplay can completely go off the rails: stuff can fly through walls, oscillating relationships can explode, and so forth. You don’t want a game where on a slow enough machine, the player can just walk through walls or past the final boss, or where the player can’t swing his sword because it causes a floating point error. Eew!

Problem 2: Coding everything to relate to parameter T can be a chore. This might be true, but I actually don’t think so. When you code logic updates without T, you are thinking in terms of frames. This is an additional calculation for your brain to make to create a very good intuitive guess as to what game behaviour should be. For example, do you want the NPC to stand and look at the wall for 1.5 seconds, or 90 frames?

Parameter T is always present, it’s just that if absent then it’s implied to be the time for one frame. And, well, you can teach yourself to think in frames, but I think seconds might be a bit more intuitive. And coding relative to a floating-point time value might make some code easier to tweak.

This bring us to BeautifulTimer.

First, we observe that if we just clamp T to a certain range, say to a maximum of 1/10th of a second, we can avoid many “exploding” or gameplay logic errors. How big MAX_T can be is a bit of an exercise, but you can always implement a debug mode with the largest-possible T and do your testing that way.

Second, we observe that often the render () code is why things run slowly. When the camera pans out, there usually isn’t more game logic to calculate, there is just more to draw to the screen. Likewise, situations that cause the game logic to suddenly grind to a halt are probably things that have to be avoided or optimized away (e.g., a flock of enemies replicating exponentially will cause your game logic to stutter, but probably indicates a bug somewhere).

Further, the update (T) game logic code can often be optimized more easily than render (). You’ve always got to show a complete screenful of plants, buildings, people, monsters and items. You just can’t normally leave any of them out (assuming they are supposed to be visible). But, you could tweak your spaceship AI code to only run half as often, when you discover using a profiler that it’s a bottleneck. Easy.

What we do then, is allow to run update (T) more than once per call to render (), if T exceeds MAX_T. We still probably want to clamp this, i.e., only allow at maximum 3 or 4 calls to update (T) per one call to render (), and there might be more sophisticated ways to figure out where the bottleneck is, but that’s the core idea.

So the final game loop using BeautifulTimer looks like this:

MinT = (1/60)
MaxT = (1/10)
MaxCycles = 5 

LastFrameTime = TimeNow ()
loop:
   
   -- handle the waiting; make sure the game never runs faster thna 1/MinT FPS
   CurFrameTime = TimeNow ()
   T = CurFrameTime - LastFrameTime
   if (Elapsed < MinT) then:
      WaitFor (MinT - T)
   LastFrameTime = CurFrameTime
   
   -- compute the number of update cycles so that we never call update with T > MaxT
   NumCycles = 1 + floor (T / MaxT)
   CycleT = T / (NumCycles)
   if (NumCycles > MaxCycles) then: 
      NumCycles = MaxCycles

   -- call update T the appropriate number of times
   for NumCycles times do:
      Update (CycleT)

   -- now, render to screen
   Render ()

That, my friends, is BeautifulTimer Continue reading →