Motivation Part 2


nathanielbabiak 2022-02-18 06:18 (Edited)

(I'm really good at complex stuff, and on this system that means graphics. But, I'm bad at making video games. I can't do game mechanics.)

I posted about motivation a while back, got a little lost as I was working on it...

Basically I realized I want to make a game people (not gamers) want to play (not watch), and I want to do it within the confines of LowRes NX, and I want to make it graphically impressive. THOSE are my constraints, no others. (And honestly, with 1 clock-cycle floating point, is it really a tough constraint?)

So now I've got a new motivation, something I've been workshopping for a while. It'll use my latest raycaster/display engine, which includes full-color dynamically-textured walls, doors, secrets, and a few surprises too. But this engine is constrained such that it cannot show in-game sprites (for example, the enemies in Wolf3D).

So it'll be a maze game. But what kind of maze game? What should the player feel?

I've got the storyboard and plot finally figured out, but I could really use some help. So if anybody would like to respond, I'd appreciate it:

TITLE: Runes

IN-GAME INTRO: You're an archeologist exploring a dig site, a sprawling collection of ancient stonework. Leaning in to investigate an intriguing half-buried inscription, you begin to expose it. But once fully visible, the wind changes direction sharply, and looking around, you realize all of the dig site has been fully excavated, the stone restored to its former grandeur, and calling out for other members of the field team yields no response except the wind...

FADE-IN: You're in the maze. You start in a dead-end hallway facing toward the first maze. One wall of the hallway near you shows a rune.

TECHNICAL NOTE: "dust" particles floating in the wind will help orient the player. It was easy to get lost in Wolf3D, try to avoid that here

nathanielbabiak 2022-02-18 06:52

I should clarify: I'm hoping to define the intersection between game mechanics (switches, locks, etc.) and plot

Timo 2022-02-18 10:46

Cool, that sounds similar to an idea I worked on with Unity. It was just an experiment I stopped working on.
I wanted to create something where you just explore ancient ruins in a desert. The idea was, that there are no enemies and not even real puzzles. Only sometimes you should have to remove some stones to discover caves etc.

Probably for a very simple 3D engine this would be a bit boring. But for me some simple switches in a maze could be enough. Maybe add some notes in the stone walls to add some story about the ancient culture? This way the player could add some details to their imagination :)

nathanielbabiak 2022-02-18 13:38

Agreed. The simplicity of the 3D engine makes this tough to get right. What I've found from early 3D maze games is that they're either really hard or so easy they're boring.

Perhaps it could be blended with mahjong then? (Meaning a rather simple maze but far more symbols.) Or maybe something geometric to spice it up? (Years ago I played a non-euclidean recursive maze game in 2D...)

In any case, it's just really hard to make traditional games on touch devices, due to the lack of physical buttons. So, I'm hoping to do something a little bit slower.

McPepic 2022-02-18 16:42

I also feel like the player should have a reason to go into all/most of the rooms. If you made it a little more than going from point a to b, that could bring out the play time a little and make it more fun.

was8bit 2022-02-20 17:02

The only math i have never figured out is billiards or pool, or carrom.. i understand the raw mechanics (for one free ball hitting another free ball) but applying the code in lowres where many balls are touching and hitting simultaneously, this has always yielded me problems... not that this has anything to do with 3d... but in a way, it IS complex if you think of each individual ball as a dimension... so in a standard game of pool you are dealing with 16d

Benimo12 2022-02-27 22:22

(You can skip if this isn’t what you’re looking for)
I’d advise you start with a simple “sketch” of what you want to do… (doesn’t even have to be in 3D)

If you’re doing a maze with puzzles, you’ll need a fully functional collision system, a player and many variable switches.

If it’s push puzzles you’re into, a simple 0/1 should do the trick once the “button” detects a sprite is on it. You could also make a switch which also operates on the 0/1 logic but, it needs a sprite to toggle it.

If you’re looking for more interesting puzzles, you could make a push puzzle with a 0/1/2… logic which could detect the number of sprites on it and react accordingly (somewhat like pressure) or a 4-direction stick switch which could act as some sort of passcode.

Log in to reply.