Myst like game?

Game Engine Game Engine Support and Discussion
1

Recently I started thinking about how one would do this and I wanted to try it in blender. However I want to upgrade myst a bit and have a video play when the character is moving around. As far as I can tell there are a few ways to do this.

  1. Looking around with the mouse, up down, left and right, a full prerendered dome.
  2. Scrolling around and not being able to look up or down, with the mouse also.
  3. Clicking with the arrow keys and upon doing that the character will turn 90 degrees.

Personally I’m a fan of the third option, because when the character starts walking you can render the video right away and not have to align the camera correctly before playing the video. It’s the easiest option.

I suppose what I would have to do is to create a cube of cameras, each 90 degrees wide. Create a scene, render out each camera then stitch them together in photoshop into a panorama and then paste them onto a cylinder? Correct me if I’m wrong here since this is my first thought.

But ideally you would want things to be animated in the scene, for example maybe a looping waterfall, I suppose a 2 second looping video clip would have to be rendered out from each camera. It should be possible to stitch those video clips together in photoshop as well into a very wide panorama video.

Then areas that should be clickable need to be masked out by some invisible geometry. Anyway what do you guys think, is this doable or might there be some better method to recreate a myst type of game?

2

I tested rendering out a panorama and it’s distorted at the edges, hmmm. Is there some method to render out a panorama without distortion?

3

Why projecting on a cylinder?

Just keep the camera where it is, play the video on a plane (like a cinema). For turns play a video that shows turning. It is exactly the same as walking to another location:

  • Play the video
  • Exchange the interactable objects (the objects you can click on)

The same thing happens on any other interaction.

The benefit of such a method are:

  • it is simple
  • you can have really high quality results in graphics and animation
  • low system-requirement performance-wise
  • simple to maintain on behavior (as it is simple behavior)

The drawbacks are:

  • limited interaction and movement
  • lots of videos
  • hard to maintain on assets (as you need to re-render and deliver a bunch of videos)
  • nearly no reusable assets

The origin of Myst was the low performance requirement on the customer side. While the hardware didn’t provided much performance they were able to show high detail content. Nowadays the situation changed. If you are not able to provide much better results in offline render than in real-time render this technique is not worth the limits you get.

But … you can still mix it with other methods. The “pre-rendered” background technique is often used (especially on backgrounds ;)).

4

you can render a cube map and then texture the inside of a cube?

or render 1 shot for each face of the cylinder?

5

The drawbacks are:

  • limited interaction and movement
  • lots of videos
  • hard to maintain on assets (as you need to re-render and deliver a bunch of videos)
  • nearly no reusable assets

While it would be nice to have everything on one plane it’s making it very hard to manage the game. You would have to render out two videos per turn. That’s 6 videos per scene, there might be maybe 25 scenes per level or whatever, that’s 150 videos you would have to render out in a decent resolution, movement too which would make that 175 videos. Each of these 175 videos would have to be played at the correct time, I suppose activated and deactivated by variables. That would be an absolute mess to manage, then the masked objects that would have to be removed from the videos or that might trigger a video to play. I don’t think this is an effective method.

Putting the camera player inside a cylinder however and having the camera turn 90 degrees whenever you hit the arrow keys, you would not have to mess around with variables for videos. It would be one wide panoramic video per scene I guess. Then if something is triggered or moved around I guess a second video would have to be rendered out. I’m not sure exactly what would be the best way of adding interaction.

The problem I’m having right now is that while stitching the panorama together the side of each frame is distorted, I read somewhere that 35 degree focal length on the camera would remove the distortion, but is that going to be a 90 degree wide shot?

I think you have to go with the panorama mapped onto a cylinder, the question is how to remove the distortion and what would be the best way to interact with objects, any ideas?

6

Using videos as transitions between areas is a O(n!) problem in a fully connected system. This means file sizes and complexity will quickly balloon out of control.

If you have a game like Colossal Cave (1977 text based adventure), it has 66 rooms:

http://rickadams.org/adventure/maps/adv_1.gif
adv_1.gif3188×2155

Let’s assume you have 4 mB per room skysphere, that’s 66*4 = 240mB of images.
Let’s assume you have 20 mB per transition, that’s probably 100 transitions: 2GB of video
Let’s assume you 50% of those rooms/transitions have alternate versions for various events/pickups.

Ok, your game will be 3-4 GB.

7

That is why I listed the benefits and drawbacks. But your estimation is not that correct:

It is one video per interaction (left turn, right turn, forward step, interaction with items). Not to forget the idle video.

Indeed this will quickly sum up, especially when the interactions cause status changes.

Example: you open a door.

So you need: left, right turn, still twice one with opened door and one with closed door.

So you should look for ways to reduce the number of videos to render.

I guess you are thinking too complicated. Talking about variables at that stage is a sign of that.

You play exactly one video at the time. All you need to do is to determine when to play what video. It is a simple “When happens What” scenario as in every game.

You need to keep the game status somewhere. I think a finite state machine would fit really well here (there are a lot other options). A FSM usually comes with a state graph. This can easily be transferred to locations and how you can travel from there. It can and should contain interactions too.

E.g. when you open a door (status change) the player can travel into that direction. While he could not on closed door.
You do not need to consider anything behind the closed door as the player can’t get into that situation (unless he can close from the other side).

The state graph shows you dead ends as well as loops.

You can care a single state without influencing other states.

Just a suggestion I do not want to go into details here.

This is an abbreviation for a single task (turning).

Lets talk about that. You can pan the video/image on the plane, while the camera stands still - without any distortions from cylinder projection. When you really want to move the player you can parent the plane on the player. Then you get a mix of pre-rendered background and 3D Models as mentioned earlier.

The advantage of paning or turning would be that you can keep the idle animation in place. The other mentioned solution would show the exact same video for turning without considering the currently played idle video pose.

You see there are many options, with different effects.

8

Let’s assume you have 4 mB per room skysphere, that’s 66*4 = 240mB of images.
Let’s assume you have 20 mB per transition, that’s probably 100 transitions: 2GB of video
Let’s assume you 50% of those rooms/transitions have alternate versions for various events/pickups.

Ok, your game will be 3-4 GB.

It’s not uncommon for games to be that big today, but you would obviously use a small format for videos. Also the panorama video, if that’s the most efficient way to do it would not be more than a 4 second looping video. For example one can imagine a looping waterfall, or a looping windmill or perhaps some trees waving. A 4 second medium resolutioned video on a low format probably wouldn’t be quite 4 MB big. Also the video that would lead you to another scene wouldn’t be many seconds long either. Also some areas wouldn’t have any animations in them which would mean no video is required.

An estimate would probably be 2-3 MB per scene, 5 MB per transition. If we got 66 rooms that’s:
198mb + however many transitions that is and additional video for interaction, the game probably wouldn’t be more than 1GB large.

It is one video per interaction (left turn, right turn, forward step, interaction with items). Not to forget the idle video.

I think we’re thinking of slightly different things, I was thinking of something like this when it comes to movement. You would be able to face 4 directions at all times:

And then instead of just moving forward, upon walking to a new area a video would be played and you would be walking up stairs, or go behind a cliff or whatever to the next area of interest. With the resolution and image quality of the renders of today the graphics could look quite amazing.

You need to keep the game status somewhere. I think a finite state machine would fit really well here (there are a lot other options). A FSM usually comes with a state graph. This can easily be transferred to locations and how you can travel from there. It can and should contain interactions too.

I’m no programmer, I only know of sending messages, changing variables and states to trigger new things to happen. A state machine sounds quite complicated, anyway managing the amount of videos that would have to be rendered out would be a mess.

This is an abbreviation for a single task (turning).

Lets talk about that. You can pan the video/image on the plane, while the camera stands still - without any distortions from cylinder projection. When you really want to move the player you can parent the plane on the player. Then you get a mix of pre-rendered background and 3D Models as mentioned earlier.

Parenting the plane would indeed make it possible to create some interesting effects I guess, I’m not sure how it would be useful though.

The advantage of paning or turning would be that you can keep the idle animation in place. The other mentioned solution would show the exact same video for turning without considering the currently played idle video pose.

You see there are many options, with different effects.

I think I see what you mean, if turning is a rendered video effect, the idle video might be cut off mid playing and you would notice the loop getting messed up when the turning video is played. I still think projecting a video onto a cylinder would be the best method, I managed to put a rendered panorama on a cylinder but it was distorted at the edges. If I could render out the panorama correctly a short test scene could be created and then one could try to see if interaction and transition to another scene is possible.

9

I do not think that you can get rid of the distortion, unless you render a video that takes it into account. This is what stichers are doing.

You might be able to achieve this effect with UV-coordinates, but it might be more effective to have it in the video already.

BTW. The FSM is a design/architecture less a a technical thing. It helps you designing behavior in a more abstract way by reducing the available options. It useful when there are not much transitions between states.

The graph representation is easier to read (and draw) than tables or code. This way you can have a much better overview of the game flow.

But this is outside of your request.

10

I do not think that you can get rid of the distortion, unless you render a video that takes it into account. This is what stichers are doing.

Silly me, there’s a button that makes it possible for you to render out panoramas inside of blender. It looks decent when you put it on a cylinder, seamless and without distortions. The problem is how to put the cylinder at the right distance from the camera to match the distance at which the pillars in this case were rendered.
http://i.imgur.com/oGy9tDQ.mp4

I’m not quite sure how to get the most accurate result, any ideas? Maybe it would be enough to just align the edges of the cylinder with the height of the camera?

11

I did some further tests and yeah I don’t know how to do this, it seems when it renders out a panorama it actually renders the spaces above and below the camera as well. Is there some way to just have it render out a 360 degree horizontal view of the scene?

12

You may search for fish eye. I do not know if that even helps. It creates a distorted half dom projection.

13

I found a game that sort of uses this method, looking quite nice, wonder how they did it. I suppose it’s possible to say that it has better graphics than some next gen games even.

14


this is the puzzle game I was about to work on for fun sake.

15

That doesn’t look pre rendered.

16

no but i hope someone will do a unity remasterd. (my unity is useless.)

17

For me Schizm: Mysterious Journey doesn’t look pre rendered. I think it is made like a normal FPS only with animated camera transition between the points.