UnrealScript's been cut from Unreal Engine 4, it was C++.

The Unreal Engine 4 tech demo shows this. The demonstrator changes the C++ code for the player's jump height and then goes back to the game while it's compiling. As it compiles, he repeatedly jumps up and down. The moment the code finishes compiling, his jump height changes without any need to restart the game or anything.

I'm not certain how they're doing this in Unreal Engine 4, but I did some looking around for ways to do it. While I haven't attempted it myself, it might be possible to put the bulk of your game code into a dynamic library, which the game then unlinks and relinks whenever you finish recompiling. There's plenty of ways for that to go wrong, and you would almost certainly still need to do a full relaunch of your executable if you change the layout of any variables (object or global), but you might be able to get it to work this way.

When the level restarts after dying, it ignores any keys that are already pressed down at the moment the level starts. So if I die and then begin pushing left before the restart to make my character run left immediately when the level starts, he'll instead just stand still, and I have to release the left key and then push it again. This can be frustrating because I try to time my movements from the moment the run starts. I try pushing a direction key right after the level starts, but if I push the key just barely too early, the character will just stand still and my timing for the entire run is thrown off.

Also, I don't know if this is intended behavior, but I noticed that I'm able to do a mid-air jump while in freefall if I just run off a block without jumping first.

My first game is long lost to history. I made it in the late 90s. It was a "Mortal Kombat" game built out of a set of flat HTML files. Each page had an image showing your opponent, your health bar, and his health bar. There were two links at the bottom of the page, one to punch, and one to kick. If you clicked the right link, you would do damage to your opponent. If you clicked the wrong one, he would do damage to you. A battle would be resolved after about two or three clicks.

My brother traumatized me when he immediately realized that you could move your mouse over a link and see the name of the HTML file it linked to in the status bar. While the in-page link names said "Kick" or "Punch", the files they linked to were named things like "right2.html" and "wrong2.html", so he beat the game flawlessly his first time through.

Huh, interesting, hadn't really thought much about this before.

Just to throw some of my own observations in to the mix:

The edge-bump panning is something I've seen more than a few new RTS players struggle with. They're trying to come to terms with the relatively complex UI placed before them, and then they suddenly find their camera panning away from the action, not realizing it's because their mouse is on the edge of the screen, and then they can't figure out how to get the camera back to where it was. It doesn't take much to get them back on track, but it's still a pretty unpleasant first experience. Even after they learn how that panning mechanic works, they still go through an adjustment period where they get comfortable with the sensitivity of the camera, finding themselves overshooting their town multiple times over, or fighting a battle with only half the action on screen.

The difference between edge-bump panning and mouse3 drag-panning seems similar to me to the difference between mouselook and analog stick look in an FPS. One of them (mouselook and drag-panning) maps actions one-to-one with results (move a little to the right scrolls a little to the right. Move a lot scrolls a lot. Stopping moving stops scrolling). The other (edge-bump and analog stick look) performs the action continuously after the command is given (hold down right or move the mouse to the right and the camera will begin moving to the right, and will not stop until the mouse/stick is moved away from the right). The only real situation I can think of where edge-bump would be superior would be when scrolling over a long distance, where the edge-bump scroll can rest the mouse until arrival at the destination, whereas the drag scroll would need to make several complete drags of the mouse. That said, that advantage is pretty seriously negated by the fact that one should probably use the minimap when distances get long enough that bump scrolling would be better than drag scrolling.

And...ammo. But again that's item design. I'm playing through Catfish's Maw and oh my god the lack of bombs is ridiculously annoying. Run out of bombs halfway through one of the minibosses? Have fun spending an hour trying to get enough randomly dropped bombs! Or completely kill the flow of the dungeon and walk back to the store!

I've noticed later Zelda games do a few things to try to avoid situations like that. For example, boss and miniboss rooms that require use of a certain expendendable item might include regenerating plants that drop that item when chopped down. Also, most plants will drop random expendable items, but if you're near a puzzle that requires a specific expendable item, nearby plants might drop that item exclusively. These tweaks serve the dual purpose of both keeping the player's inventory from running out of essential items, as well as giving them hints about what item is needed to proceed through the game ("Oh, all these plants gave me bombs. I must need to use bombs soon.")

A lot of what's been posted has some form of conditional that allows you to exit the run loop. Any reason you guys don't just call exit()? The OS will clean up everything for you, and probably do it quicker than if you tear things down yourself.

I have a loop exit condition in my game loop for iOS. When the user hits the home button, sending the app to the background, I exit out of the game loop. When the user resumes the app I start the game loop up again. I do this because iOS will sometimes opt to simply kill an app instead of suspend it if it doesn't stop doing work correctly while in the background. iOS will, for example, kill an app that attempts to make OpenGL calls while in the background. I also exit the game loop when they put their device into sleep mode, and start the loop again when they wake their phone back up. iOS won't kill an app for processing while the device is asleep, but it'll drain the battery unnecessarily, so stopping the loop is just a nice thing to do there.

Nothing too fancy.

Code:

- (void)gameLoopThread
{
    STime time = STimeCurrent();
    
    for(;;) {
        // If the game loop should be gated, wait for the gate to unlock,
        // then relock the gate behind us
        if(gateGameLoop) {
            SGateWait(gate);
            SGateLock(gate);
        }
        
        // If the thread should suspend, break out of the game loop
        if(shouldSuspend) {
            shouldSuspend = NO;
            break;
        }
        
        // Surround every iteration through the game loop with an
        // NSAutoreleasePool
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
        
        // Compute how much time has passed since the last pass through the
        // game loop
        STime now = STimeCurrent();
        STime deltaTime = now - time;
        time = now;
        
        deltaTime = MIN(0.25, deltaTime);
        
        // Perform all game-specific logic
        [gameLoop tick:deltaTime];
        
        // Clear out the NSAutoreleasePool
        [pool release];
    }
    
    running = NO;
}

This is for an iOS/Mac game. In order to ensure that things remain as responsive as possible, I use three threads. The first thread is the main thread, where all events from the system get processed. The second thread is the game thread where this code (and all game code) is run. The third thread is a thread that does nothing but listen for vertical blank display sync events off a CADisplayLink. I keep the game off the main thread because many events (including, notably, Game Center events), can take a non-trivial amount of time to process. The CADisplayLink is on a dedicated thread so I can have confidence that the CADisplayLink callback will reliably be called right when the screen is ready to refresh.

The SGate functions in that code involve a kind of lock. An SGate can be either locked or unlocked. A call to SGateWait on an unlocked gate will return immediately. A call to SGateWait on a locked gate will block execution until the gate is unlocked from another thread. The CADisplayLink callback does one thing, and one thing only: it calls SGateUnlock.

Hi all,

My name is Donald. I've been lurking for awhile and felt it was time to make my presence known. I've been programming for fourteen years now, professionally for the last eight (heavens, has it been that long?). Game development got me into programming, though I have yet to work on games profesionally. All my game development efforts to date have been on my own time.

In 2008 I started programming for iPhone, and I've been doing that profesionally since 2009. It's a good thing I'm quite fond of Objective-C! As a consequence, most of my personal projects these days tend to be for iPhone or Mac.

My game-playing history starts with the Atari, but my earliest memories are of the NES. My brothers and I would play Super Mario Bros., learning things like where all those vines that lead to warp pipes were. I remember we would take turns every death, and my brothers would tell me that various bottomless pits led to secret passages. I fell for it quite often.

We were a Nintendo house for many years. My only Sega system early on was a Game Gear (which I still have). Then we got a Playstation instead of a Nintendo 64. I had games like Final Fantasy VII/VIII/IX, Twisted Metal, etc, and was only able to play games like Mario 64, Starfox 64, and Mario Kart 64 at friends' houses. We got a Dreamcast, which remains one of the best consoles ever, and then we got a Playstation 2. Then I got a job, and since then I tend to buy all the consoles myself, even the Vita, which has yet to have a game I really want to play, so it just sits there looking pretty (which it does quite well, it's a fine piece of hardware, it just doesn't have games I want to play).

So that's me.