Minigame suggestion: walk-point-and-click adventure game
#1
When lua is fully implemented (all library functions are done), and some other stuff (textures, sound, random stuff like water and transparency) it will be possible to create pretty much anything based on the ReCaged engine. The "Brick Fortress 2" is one example, here is another I've also been thinking about for some time:


A 3D point-and-click adventure game in first person

It's going to offer more physics-driven puzzles (and freedom of exploration) than classic games of this kind, but it will be somewhat inspired by the Monkey Islands games, take some inspiration from Lost as well as an old flash-based lego game I'm not going to name (but some of you might guess) and try to stick to the classic kind of storyline:

1) suddenly standing in a world
2) walk around and explore, solve simple puzzles (get familiar with the controls and the world) and learn about a big problem or antagonist
3) solve more complex puzzles
4) *big discovery*
5) puzzles
6) *big event*
7) *even bigger discovery*
8) more puzzles
9) *"boss fight"*
10) end

I'll put a lot of focus on the exploration part. I hope to be able to implement a large "open world" kind of game, with no loading scene. My idea is to have two simulation threads (instead of one) running: one performing the simulation of the current scene, and the other is instructed to load another scene when the player approaches an edge of the scene in the other thread. Any cpu with 3 cores or more will be able to handle it, and 1 or 2 cores should also, as long as it's powerful enough.

How much work I'll spend on this will depend on how the idea is received. I'm going to add at least enough for (1) trying out the concept and controls (I'm thinking a beach on which the player will wake up and can move around some distance).

And I'll be looking into creating some kind of cartoon shader for the 3D models. It... Just feels the right thing to do...


Storyline
The 4, 6, 7 and 9 are all spoilers, and the "boss fight" I don't even know yet (wont be an actual fight, if even violent, but some kind of critical point in the game). In fact, I haven't been able to figure what the big problem/antagonist will be. Maybe you guys can help?

I'll avoid spoiling the whole story for everyone. For those who would like to help developing it (game or story) or isn't so interested and would like to see if the story might justify the minigame anyway, just highlight the following:

===============
The "world" is an island. With mostly forest and desert, surrounded by an ocean. On the center is a volcano (which of course is what created the island), and -maybe- a higher mountain on the side of volcano (or maybe just the volcano is really huge). Maybe some snow on the top of the mountain (or volcano if no mountain).

Ok, the next part is going to be ridiculous. Seriously. Ok? Moving on:

There is no animal life on the island (only vegetation). The "people" there, and thus also the player, are sentient robots. There I said it. Robots. Hey, at least not... rowboats. Not bulky metal boxes, but instead fairly lightweight and easy moving biped humanoid things. Slightly shorter than an average human.

No one on the island seem to remember how they got there, or who they are. But they have been there for a long time and think of their situation as being the normal way (for some reason the player doesn't even remember anything until the start of the game, and learns this by talking to the other robots he/she meets).

But they know/feel that their purpose is to terraform (from their perspective: just inhabit and "fix" the environment), and they have somehow always had the skills (including some basic engineering knowledge). The common belief is that they arrived from space, most likely a certain blinking star which can be seen at night...

Ok, that's enough background.

Again, there has to be a problem of some sort, perhaps some antagonist(s). I don't know. Ideas?

As for the big discovery:

In a use-what's-at-hand fashion, they use the heat from the not-so-active-anymore volcano to drive some kind of steam machine (with cleaned water from the ocean) directly powering mechanical tools and some kind of makeshift generator (for powering their fuel cells).

In order to optimize the "infrastructure" on the island, they are digging tunnels (using direct torque from the steam machine) through the mountain walls, as well as attempting to mine iron and similar (needed to create machinery). Machinery? Remember they've been there for a LONG time (and got the skills), why wouldn't they try to create tools? At some point, there will be a MYSTERIOUS metallic wall blocking the path of one of the larger mining areas. On this wall there will be a hatch (Lost-ish reference).

In an unrelated happening (I'm thinking something in the line of traveling on a cablecar, which breaks, sending the player and debris down the wall of -I-would-prefer-a-snowy-mountain-), the player gets trapped in a cage (would prefer on a snowy mountain, since then the player can then be trapped by just letting an avalanche cover the exit), eventually (picking up a the light from the backpack, digging out legs from the snow and again being able to move), the player will discover another wall of metal far into the cave, with some text. I'm thinking some code which gets written down on a piece of -paper?-.

big event:

Somehow this code will work as a key to unlocking the hatch. The player climbs down through the hatch (revealed to be an airhatch), which seals behind (locking the player in). In there the player finds a button, which after being pushed. another hatch under/to the side of the player opens. After falling a few meters in darkness, finds finding a new button which turns on lighting in what is revealed to be the inside of a massive spaceship.

even bigger discovery:

on the black box on the ship computer everything is revealed: the (unmanned) ship was on its way (or returning) to a planet destined to be terraformed for human inhabitation (putting this far into the future). On its way, the engine had some problem (caused by what? ideas anyone?). and the ship fell towards an ocean on a planet. Once the trajectory was calculated and showed to head towards the planet, a emergency beacon was launched into orbit of the planet (the blinking star from which the robots believed they came from). The ship broke into (at least 2) pieces when entering atmosphere.

One small piece went through the water down to the bottom of the ocean and managed to crack the block to a magma pocket, causing a volcano to be formed on the ocean. The other part of the ship was trapped in the magma flow and covered by the newly formed volcano+island.

This piece of the ship is where the player has just managed to enter (after hundreds of years of mining, the robots ran into this piece of the ship underneath the island by accident). Looking further into the ship history, it's revealed that the automatic ship computer activated the standard terraforming robots, instructed them to remove the island which had covered the ship and somehow sent them to the surface (maybe there's another hatch far under the water?).

The log ends with the computer noticing that the robots had gotten their memories damaged somehow (em radiation from the broken ship engines?), and the ship had then shut down to power-preservation, relying on the emergency beacon to eventually lead to recovery of the ship and malfunctioning robots.

The player is then lead to the conclusion that the robots had kept most of their skill memories intact, but lost information of who they were and what they were meant to do and just assumed the standard terraforming instruction. And during all years which passed they somehow developed sentience (can expand on this somehow?).


With origin explained, what's missing is some kind of "boss fight". But I have no idea what this could be.

Finally, we have the ending: something in the line of the robots deciding they don't want rescue (which would probably means getting shut down and trashed as defective electronics). So somehow they disable the beacon. The final ending could be that they decide to build a boat to explore the rest of the planet ("what's behind the horizon?").

===============



Controls

The control is going to be pretty much standard fps kind, but with some simplifications:

mouse movement: look around
mouse left button: use/talk/push/pull/pick up
mouse right button: open/close backpack
W,A,S,D or arrow keys: move forward/backward and sideways

No crouching or jumping, no weapon slots (although a packpack screen where one can store and restore items).

Like any good adventure game, there are going to be many items to carry around. Some classic ones like lamp, maps, etc. But also some twists for the improved physics like a grappling hook.

Some items will not be possible to pick up, but is otherwise intractable (buttons can be pushed, people can be talked to, heavy objects can be pulled/pushed perhaps even lifted, but not placed in the backpack).

As for sound: there is going to be mostly some ambient music and sound (like waves). And some minor sfx (bumping into things, dropping things). But the speaking will be entirely in classic text approach (talk to people by choosing in a list of sentences for each person and getting a reply).
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#2
Yes! The world needs more adventure games.
Reply
#3
I really hope I get lua scripting working as I want. My only concern is that adding a lot of lua calls for events might cause a lot of overhead. But I guess it just remains to see. In any way this one shouldn't be too extreme with lua scripting, compared to the cars in recaged itself which will be using lua for wheel slip simulations (the current Pacejka inspired model in C will be moved to lua - hooked to some ode collision callbacks).

Update: by overhead, I meant in processing time, not memory usage...
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#4
A random double-posting-name-dropping-post. Just thought I'd mention some inspiration sources (to see if this gets some interest):

* First of all, one of my absolute favorite books: The Mysterious Island, by Jules Verne. I first read it long ago and I love the whole Crusoe meets unrealistically fast and successful crafting of a make-shift home meets unexpected discoveries. Bad summary, I know. But if anyone who has read it will understand.

* The Secret of Monkey Island. Well, not much to say here. In fact, with the Monkey Island itself in the game, this is the second inspiration source containing an island. Also the idea of just introducing the main character without any previous history (amnesia?) seems a good start for this little project as well.

* Tintin in Tibet. Just epic. Now it's not about an islandTongue, but the journey to/exploration of the mountains is just so... Fantasy stimulating. Seriously, there will have to be a giant snow-covered mountain in the middle of this (otherwise) tropic island to be explored. I don't care how unrealistic it is!Cool

update:
* And Lost goes without saying. But I'm not planing any supernatural stuff. Wink
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply
#5
Bump again, dem's the tripplepost!

Anyway, figured out a name for this thing: "Void". Ain't I a tricky bastard? :p

Also, figured out how to make the whole loading-free open-world approach working (won't reveal it all yet, but it will use a concept of "rooms", even when outside, plus two kinds of backgrounds: one "background" and multiple "middlegrounds", one for each room)...
Try systemd. They said.
It'll be just as reliable as init. They said.
It'll be completely bug-free. They said.
Our monolithic windows-approach is far superior to the Unix-approach. They said.
Okay, so the codebase has grown gigantic and no one but our paid group of full-time developers who created it can maintain it and fix bugs... but it'll be fine. They said.
Okay, we'll shove it down your throat whether you like it or not. They said.

I guess it's finally time to look into GuixSD and/or devuan.

Code:
systemd-journald(195): Received SIGTERM.
systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
systemd[1]: systemd-udevd.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-udevd.service
systemd[1]: Unit systemd-udevd.service entered failed state.
systemd[1]: systemd-journald.service has no holdoff time, scheduling restart.
systemd[1]: systemd-journald.service failed to schedule restart job: final.target is queued, ignoring restart request for unit systemd-journald.service
systemd[1]: Unit systemd-journald.service entered failed state.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)