[computergeek6]

I'm making a Portal clone in MZX. So far I've done the portal system, and the first 3 levels.
Images:
Level 1:
Starting
Portal open
Level 2:
Start
Partway through
Please comment!

This post has been edited by macgeek: 30 May 2008 - 07:22 PM

[asgromo]

You should rehost these screenshots on http://www.imageshack.us/ or something and edit your post to suit. But they're very bland and uninformative. I can't think of any particularly interesting portal-based puzzles you can fit in two dimensions, while granting the player a full view of the area around him, either. Can you?

I guess the idea could always be used to obfuscate some other form of puzzle, like standard slider stuff...

[computergeek6]

I think that some of my planned features will enable some cool puzzles. I already implemented portal shots going through portals.
I'm going to post an engine for it when I'm done. Maybe it could add something to action games.
For 2D puzzles, Portal: The Flash Version is a good example.

This post has been edited by macgeek: 30 May 2008 - 07:52 PM

[computergeek6]

I finished a demo version:  Portal_MegaZeux.zip (1.11MB)
Number of downloads: 64

[Risu2112]

I would recommend making it a side scroller. Portal without gravity would be kinda boring. Gonna have to do something about the cosmetics of this though. Do what you have to do now, but once you develop some better robotic skills, I say sprite it up with some larger player and objects.

Also you need to work on level design a bit, it's far to easy to trap your self right now.

This post has been edited by Risu2112: 31 May 2008 - 07:10 AM

[NoahSoft]

well i would recommend u 2 finish starfilght mzx HOW BOTU DAT

[Koji]

I was actually working on something like this a week ago.

The first incarnation was an overhead adventure like this but was scrapped, however I did use a nifty way to generate the visuals, it was very roguesque, basicly the view available to the player was like a raycasted 2d thing using the portals to teleport the rays around and generate a 2d representation of what the player would actually see where he was standing. It was cool, however, as a puzzel game it doesn't work, it's probably best adapted to an adventure game.

I tried to turn the overhead action into a more 2d sidescroller like ken said, but it quickly deteriorated and now it's just another folder in my mzx directory that won't get opened for a while. I hope you are more successful with yours and thanks for the flash game I was delighted to see someone had done it.

EDIT: The reason why overhead action + portals doesn't make a good puzzel game is because there just aren't enough constraints on the player on how he can move around in the game space. You'd have to add more complicating elements to the puzzel in order for it to work, ideas that immediately come to mind are limiting the number of portal shoots, limiting the number of steps the player can take, or adding more special walls and objects to interact with other than the generic weighted companion cube. And if you do that it'll get complicated quickly and the player is likely to either lose interest.

yeah 2d sidescroller + portals is best.

This post has been edited by Koji: 31 May 2008 - 06:00 PM

[computergeek6]

I'm probably going to let it stay overhead to improve the portal engine, but making it into a sidescroller is a good idea. I'll do that when the engine is good enough.

[paulguy]

When you make it a sidescroller, put some decent physics in there, too. not just constant move player south.

[Kom]

I had considered doing a Portal sidescroller in MZX once, I didn't think that people would really enjoy an attempt at portal in MZX. Horrible image host BTW.

[nooodl]

I once made something like this. You could click on any wall on the board with the left and right mouse buttons and they would link together like portals, but you could shoot anywhere so it wasn't good for making puzzles at all...

Also, all the walls were robots, so it was kind of messy.

[hob nado]

nooodl, on Jun 6 2008, 01:28 AM, said:

I once made something like this. You could click on any wall on the board with the left and right mouse buttons and they would link together like portals, but you could shoot anywhere so it wasn't good for making puzzles at all...

Also, all the walls were robots, so it was kind of messy.

There's probably an easier way to do that.

[computergeek6]

That's the way I did it. The wall robots are not very complex, though. They just ask when hit, then do a BECOME BLUEPORTAL/REDPORTAL.

[Risu2112]

I _strongly_ encourage you to find another way to generate the portals, using robots as all your walls is going to be ultimately VERY limiting, also find another way to select which color portal is being fired, that box popping up is very intrusive.

[hob nado]

Shouldn't the portal colors change automatically?

[paulguy]

In the game it had primary and secondary fire for orange or blue.

[computergeek6]

Maybe I'll make the shots be robots instead of the walls. That might work. It would also enable energy-balls

[Koji]

Thought I'd throw up a brief desciption of my former portal engine.

Firstly, you have a rudimentary physics engine for momentum (you really need this) I also decided to subdivide each position by like 4x2 or something, set it up so that pressing an arrow button will increase velocity in that direction until a terminal velocity is reached. In the case of a 2d side scroller there are two different terminal velocities, that of your x movement (how fast you can run) and the y movement (how fast you can fall). When at or above the terminal velocity you can no longer increase your speed. You will also have some sort of friction involved for when the player is against the ground or a wall to decrease their speed.

Second, you have your portal system. I defined two sprites which would display either portal, and when ever one was placed by a button click, the other was subject to being moved. when the player sprite collided with a portal sprite the players location would be changed to that of the other portal, and if the portals orientations were different (like one was side to side and the other was up and down) the x momentum and y momentum were switched.

Third, you have to remember that once a teleport has happened, deactivate teleportation until the player is NOT colliding with a portal. If you don't do this the portal system will screw up alot by flickering the player between the two locations. Making the collision and teleport code wait till the player is no longer colliding with either portal immediately after a teleport makes sure that the flickering doesn't happen.

That's all. My project got really complicated when you went through a portal that would transpose your direction because I used a ray system to create the view so going through a portal would seem to rotate the whole area in order to stay consistant to the view through a portal. At which point it became difficult to play

[computergeek6]

I'm starting a complete rework of the portal system. I'll release another demo when I'm done.

[computergeek6]

I kind of stopped reworking the portal system, but I'm working on a side-scrolling physics engine for it.

[T-Bone]

Kom, on May 31 2008, 07:16 PM, said:

I had considered doing a Portal sidescroller in MZX once, I didn't think that people would really enjoy an attempt at portal in MZX. Horrible image host BTW.

Yah I actually was close to doing something like this myself. Influenced by the flash version of the game.

[computergeek6]

I finally got around to doing the portal system re-do. Now the Q and W keys fire portals, and portals are created automatically, without wall robots.