next »

[tjpalmer]

Thanks for checking in on it! I've made a bit of progress but not enough to be worth showing. Guess I've been focused on other things in life, and that's okay, but I want to get back to this game more seriously. Actually getting a project done sometime would be nice. Maybe I need to constrain my scope a bit more (even if it's a small project to begin with), given my apparent constraints.

[tjpalmer]

Different resolution and so on, but I figured I should stop being lazy about learning shaders. Toyed around with Shadertoy a bit:

https://www.shadertoy.com/view/4t2XW3

The blue and yellow are placeholders, and lots still isn't done. Planning to spend more time learning the full GL stack better. Should be calculating surface normals for more general lighting, too.

If I get anywhere with this, maybe the modern form will be high res, and maybe I'll have an option for the old graphics, too. Life's busy, but maybe I'll work on it.

[tjpalmer]

And working in my own code base rather than Shadertoy, I've also now got surface normals partially working:



The normals themselves need fixed/refined, but I think the basic functionality is close to correct. I also need to get some texture on those bricks at some point.

The glowing light is just for kicks right now, but various game features could produce local lighting, and this will make things look nice.

[tjpalmer]

Just random tile placement here, but I've got a few different tile types now and even with texture again:



The only third-party code I've used directly is simplex noise stuff (from https://github.com/BrianSharpe/GPU-Noise-Lib/blob/master/gpu_noise_lib.glsl).

I plan to use texture data for multiple light sources, but that's for the future.

Next on the to do list is kinematic trees for rendering character animation. Those vertical gray rectangles are placeholders.

[alvarop]

Any news? It's been a while!

[tjpalmer]

Thanks for checking in!

Guess I got busy with life again. I think based on my time limitations, I'm wisest to stick to the original plan: Get the thing done. I learned a lot playing with GL and shaders, but I already have graphics. I should make it work in the most straightforward way possible, using my original graphics. Then when it's working, I can work to crank out new visuals if I prefer that to working on new projects.

I too often spend more time restarting things than getting things done, so that pattern's what I need to fix if I'm going to do this.

[tjpalmer]

Making progress again. Using original art as placeholder for now, with intent of keeping it as an option after redoing graphics later maybe.

Demo video (made blurry by youtube):

[tjpalmer]

Back to lousy LICEcap since lousy Windows 10 recording isn't working. I promise it runs at 60 FPS on my weak computers.

Guns are in, and they can kill more than just you:



I also abusively changed 2 black pixels to white and 1 white to black in my source image. Sacrilege. Made it easier to use the simple shot graphic.

Also, if you have Chrome (limited time, and planning to distribute on Electron eventually by current plans), you can demo current state online.

https://tjpalmer.github.io/zym/

Again, Chrome only! Sorry. And probably only desktop, too. And you need WebGL.

[tjpalmer]

Just a quick shot of the editor for today:



I've added enough features that we've started making interesting levels, so I've started improving level management: excluding levels, naming levels, exporting files for backup or import elsewhere, and so on.

New game features include coins that given temporary speedup and also guns falling and riding on biggie (big bad guy) heads.

Online demo (need to make your own levels for now), is updated here: https://tjpalmer.github.io/zym/ (Chrome only!)

What's the best way on Windows 10 to do video capture, by the way? Everything I've tried is unreliable, and when I search Google, I'm not sure I like the options I see. But everyone else seems to do a good job here.

Maybe I'll just add my own video exporter or something for during gameplay.

[tjpalmer]

Not much to show, but you can now make separate groups of levels, which I've decided to call towers. You go up from level to level, and the planned new graphics theme will be ancient decayed city towers.

Multiple towers, among other things, allows me to start designating an official tower for standard play mode instead of starting from the editor.

Oh, and the new game name is supposed to be Phase.

Well, <planet name> Phase, were the planet name is yet to be finalized.

[tjpalmer]

I've added invisibles as an option for most tile types. You can see all invisibles when near any. And an invisible bonus both makes you temporarily invisible to enemies and able to see all invisibles wherever you are.

Invisibles can be abused, but I think they can also be used for good. And you can already make broken levels, anyway. So I figured that level designers can be given the tool and be allowed to be wise in how they use them.

And invisibles were in the original graphic, too, although I now represent them with translucency rather than using the specific invisibles editor tiles from the original graphic. I did a similar generalization with enders earlier.

I've also added enemy respawn points. These were supposed to be portals, but I repurposed the tile. Figured that the directional launchers were good enough teleporters.

Figured I'd post an update, since that's easy enough. But I haven't had feedback for a long time, so I might not bother with a screen capture.

[Flatgub]

I'm still following this intently, I've just not had much to say beyond "Keep up the good work" 

[tjpalmer]

Thanks for the feedback!

[tjpalmer]

For a bit of status, the tiles circled in cyan are the ones I haven't done yet but intend to do:



These are:

- Single-use breaking blocks
- Acid droppers
- Smashers to destroy things beneath them when you fall on them
- Ice for slipping

The hashed tiles circled in yellow are for fake tiles, like the fake bricks in original Lode Runner. But I'm not convinced I like them. One of my sons is trying to convince me to make dropping blocks instead that fall after you use them. Maybe.

Everything uncircled is implemented to some extent. But I might still want to improve things.

[tjpalmer]

Nothing too exciting, but I've been reworking my physics some to allow for unaligned motion inside ladders (and in open space), if you can make out the guy among all these bright yellow ladders:



Original Lode Runner and at least some clones tend to keep you aligned to rows and columns, and I started that way, too. But in my case, it was making some of the other physics broken, especially when walking off enemy heads. And some upcoming features might exaggerate that.

Also, in mythical new graphics land, I want patches of ladders to be rendered more as mesh fences, so it would make sense to allow freeform motion inside them.

But to allow entirely freeform motion doesn't work, either, because you need to be able to fit into exact openings in the grid, so manual pixel alignment is too hard. And sometimes unaligned motion looks bad. So I have to align you sometimes. I think I almost have the logic worked out, though.

And in unrelated distractions, I've also been toying with Flatland-ish actual 2D game ideas. It's pretty mind warping.

[tjpalmer]

I've always imagined these as acid:



They kill the player. I have guns currently kill the droppers, and the drops themselves also stop drops (slim chance of that collision in most cases) but not destroying the drops. The drops don't kill enemies for now, and I'm inclined to keep it that way. Unlike guns, they drop even without seeing the player first, so they could randomly kill enemies for no good reason.

I have them dropping at 3 second intervals at fastest, only one drop at a time per dropper. The first drop initializes based on position, which causes the alternating shared drop times seen above.

[tjpalmer]

I got tired of feeling forced to make large levels. I also got tired not being symmetric for odd widths. I felt these were making me choose poor designs. So now you can crop to whatever size you want, such as this tiny game of chicken (just for testing, probably):



I've cropped a lot for pictures here, but they were always parts of larger levels before.

Question is whether I want to zoom larger on screen for small levels, or just leave them taking up only a smaller part of the screen. Probably defer that decision for now. In edit-and-test cycle at least, it's better not to have things jump around.

[tjpalmer]

Lousy capture again, but here's the latest:



Few things left to go, beyond fixing physics. That impacts the implementation here, too.

[tjpalmer]

I just found some graph paper drawings from a time after I made the original graphics (but still 1995), but when I didn't have a computer handy. I forgot I'd ever made these drawings. And there are other pages I didn't include here, because they're more boring or even uglier.





Obviously some ideas different from or beyond what I had in the graphics and therefore out of scope. And I'm sort of happy with the limited physics of original Lode Runner style rather than the more elaborate physics and control I describe above. And I'm not sure what some of those robots above were supposed to do.

Anyway, just seemed like fun to post these after I found them today.

In actual game dev news, I've now made it so that robots flip switches and activate crushers instead of just the player character. Maybe I'll post some gifs of that sometime.

[tjpalmer]

Second to last major gameplay feature, blocks that break after you use them:



That shows a partial run with a failed sequence, followed by one with a correct play. There's also a flash of editor mode in the middle.

Rather than using the breaking graphics from the original, I apply a consistent mask to all blocks, so I can make other types breakable.

The last feature I need to implement is falling blocks, which are to take the place of fake blocks. Fake blocks were in original Lode Runner and in my original plans, but I'm not convinced they are a good game mechanic.