Scene2d

Wow, the scene2d framework has come a long way since I first looked at it, in some pre-1.0 version of LibGDX. In the last hour since the kids have been in bed, I've got almost half of my game UI mocked out using it, and switching from the draft/mockup to the "real thing" should be as easy as modifying the skin file, and then slightly nudging/resizing things.

I'd show some code here, but it's all so plain simple, I'm not sure what to even say. It's all super simple layout stuff, along the lines of:

    private Window buildControlWindow() {
        float paddingLeft = 120;

        Window window = new Window("Signal", getSkin());
        window.setPosition(0, 0);
        window.setSize(LifeInSpaceGame.WIDTH, LifeInSpaceGame.HEIGHT / 3);
        window.setMovable(false);
        window.setResizable(false);
        Label label = new Label("Radio Filters", getSkin());
        window.add(label).padLeft(paddingLeft).colspan(3).expandX();
        window.row();

        Button filter1 = new TextButton("     Filter 1     ", getSkin(), "toggle");
        window.add(filter1).padLeft(paddingLeft).expandX().padTop(10);
        window.row();

        Button filter2 = new TextButton("     Filter 2     ", getSkin(), "toggle");
        window.add(filter2).padLeft(paddingLeft).expandX().padTop(10);
        window.row();

        Button filter3 = new TextButton("     Filter 3     ", getSkin(), "toggle");
        window.add(filter3).padLeft(paddingLeft).expandX().padTop(10);
        window.row();

        return window;
    }

This builds the panel in the bottom right that lets you apply different "radio filters" to the radio signal audio that's coming in from the selected star, to help you try to pick out whether there are any signs of intelligent life coming from that star.

The next task is going to be the first somewhat challenging one: to have a cool waveform image scrolling by on the bottom left side of the screen to match the radio sounds that you hear when you tap on a star. I have some ideas about how to make it work really easily, but it might take a little finagling. 

Here we have some rough instructions (which hopefully I'll have time fill out later)

And the addition of the radio filter toggle buttions. The waveform should appear in the space to the left of the buttons.

LibGDX Game Jam

So this week I'm tentatively starting a project for the LibGDX game jam, a month-long jam with the theme "Life in Space"

Part of the jam is the requirement to document your progress, which I'm doing on their website. I'll try to cross-post a lot of it here as well, but my jam project log page is at http://itch.io/jam/libgdxjam/topic/12031/gauauus-log

The idea of the game is a very short story-based game where you are a researcher here on earth searching through the stars looking for radio signals that would show evidence of extraterrestrial life in space.  Because of the non-action, story theme, it's very different than other games I've done. And because the goal is to crank something small out quickly, it's been fun (for the 2 hours I've worked on it so far) not worrying about good extensible/general design, but writing just enough code to get the job done.

I'll leave you with a very minimal draft screenshot. The top starfield is where you search for signals. The bottom will be a control panel that lets you analyze radio signals as they come in.

Can I do this in a month? I don't know, but it'll be fun trying.

Door work and more

Ok, enemy spawning finally works right. There were a couple of minor bugs in my spawning code that I last posted (c'mon, nobody spotted them? I thought with a million eyes, all bugs are shallow? I guess that means I have a few less than a million readers that are also 6502 assembly programmers!) But I got the bugs taken care of.

I decided the next step, to try to get my brain interested in this project again, was to go ahead and start actually making the first dungeon. Awhile ago I posted a survey to see if I should re-implement the maps from the original Anguna, or make a new adventure. Everyone voted for a new adventure. But it sounds really fun to try to reproduce the first dungeon, at least. So that's what I started on.

And immediately realized that although I had worked out proof-of-concepts for my door code, it wasn't finished. Doors on the top worked. I hadn't finished doors on the bottom. Which required going back and modifying my display kernel code, which meant I was back to counting cycles.

But I think I have that working, finally.

I also originally only allowed for a left-side or right-side to be closed (if I wanted them both to be closed, I had to draw the room map with a permanently closed wall, which reduced that room layout's flexibility for use in other rooms).  But after playing with that, I didn't like it much. So I had to re-think how this was going to work.

Originally, I used the Atari "ball" graphics object, (which is a 1,2, or 4 pixel blob) extended vertically across the whole screen, to block off a left-side or right-side door. But if I wanted to block both at once, this wasn't going to work. (there's only 1 ball!) So instead, I counted and realized I had time to squeeze in one additional instruction in my code that pushes the background data to the right registers, so I could pre-load a byte in ram with a mask to be applied to the walls, and, OR that with the actual room wall data before pushing it to the display registers. Because I'm using a mirrored background, that could close both the left and right doors at once.

Both the left and right doors are closed! Hooray!

The next step is another part that I realized I never implemented: if you have a secret door that only opens when all the enemies are dead....well, it never opens.  Not because my code to open it doesn't work. But more because it turns out I never wrote that code.

So that's next!