So this project has been worked on quite a bit already, and i am bringing it over here to Cemetech This is a real nice community, not sure why i haven't come here more often!

So this is an 2D version of the famous Portal game by valve. When i was young in the area of calc programing, i wrote a Basic version of Portal that can be found here . After i finished that version, i discovered Omnicalc and invisioned a version that used the sprite routine to truly take Portal to the next level, adding in momentum and all the other concepts that were in the original game. Of course Omnicalc wasnt up to this and it was soon forgotten...

...Then Axe came along and i remembered! The same day i got a basic demo working, and progress has been going ever since. The original progress thread can be found on Omnimaga here which contains all the screenshots. Here are some of the more impressive.



Here are the features supported so far:

Code:


To Do List:
Plasma balls
Oscillating plasma fields
Fix Emancipation field bugs

After that, my engine is done and i can start writing the game The game currently compiles to around 9300 bytes of code, and i believe i will be able to fit everything into a single page App ^^

Edit by Kerm: added some screenies from your topic. Feel free to change them

The mechanics here look hugely impressive, BuilderBoy! I'd swear this was written in ASM based on the speed and complexity. I also modified your post to contain two screenshots from your first post in the Omnimaga topic, and one from the 23rd page.

Very nice, BuilderBoy. I honestly had this idea not long ago, but with all the projects I run simultaneously, I'm very excited to see someone else working on one (since I know it'll actually have a chance of being finished ).

Keep up the good work, man. It's looking great

I actually thought about adding Portal-type mechanics to that M-Game beta I was working on back in the day, so you might eventually have some competition there, Builderboy.

wewt!

Competition =

Haha if you ever finish N game then I will start to worry

Also this is a crosspost from Omnimaga where I am debating the current Portal control scheme:



I am reluctant to try variable angle, because that would mean you lose fidelity when you are in the air.

Smells like a trademark violation to me.

M-Game, not N-Game. I contacted the original developers for permission to use the name, and they suggested I use a slight amount of creativity with regard to the name and mechanics, since they were just releasing an XBox version of the game, but still encouraged me to take the concept where I could.

Although nikky is a bit blunt about it, perhaps you could indeed come up with a slightly more creative name than Portal? Perhaps pull out your thesaurus?

And regarding the control scheme, I think that attempting 22.5 degrees might be nice, although you don't want to start making it too complex. Definitely not arbitrarily-variable for the sake of shooting Portals while in the air, as you mentioned.

Lol I would be honored to create an accurate enough game that valve takes notice I *am* planning to implement a fair bit of story behind the puzzles as well, so changing the name to something else kind of defeats the purpose of remaking the game in the first place. Right now the actual working title is PortalX but all of it is subject to change. Be assured that the final name will have Portal in it for sure

and as for control, I think I am leaning towards 22.5 as in order to make the variable angle work, I would need to implement 2 control schemes, one for accuracy and one for speed.

Haw haw. Because ripping off ideas is

Hence the point of a port my friend. If nobody used the idea we wouldn't very well have any portal for the calculator now would we

How about PorticoX or GatewayX?

Ah, sounds good; how would you allow the user to switch between the two?

I'm sticking with Portal, plus some subtitle to diferentiate it from the first Portal I made. Simply for the same reason I named my Shift remake shift and now something like warp.

As for the alternate control scheme, one idea was to have an angle that you could control with plus of minus, and then enter to fire or something, but then pressing the number keys would jump to an increment of 45 and shoot. I decided against this tho, since as it is, 45 degrees is more than sufficient for puzzles, 22.5 is the farthest one would need to go.

The issue I am worrying about is that for the multi keypress version, there would need to be a delay to account for the 2 keypresses not being pressed at the exact same time, I'm not sure if this would he bothersome, or if the setup would be easy to use in the first place. I'm going to implement the 22.5, see how it feels, and make my decision from there.

I like Gateway.

LÖL It has to be Portal!

As long as its true to the original game, it should have the same name. In fact all my games on ticalc right now are ports and have the same names as the originals. However I do agree that there's nothing I hate more than seeing a game called "Mario" or "Sonic" and then when it comes to actually playing it I find I was grossly mislead.

As far as ports go. Without them, I would not have made any games. Missile Game 3d, Tetris, Impossible Game, Z-Rox, Bubble Breaker, Geometry Wars, Lights Out; search any of these on google and you will find the original.

So I say, keep the name.

Eh, I often try to play it safe. My (what I consider a very accurate) Risk clone is called World Domination, and my Age of Empires 3D clone is Civilization Simulator I. My Tetris and Sim City keep their original names, and my Megaman trio of games actually has nothing to do with the original Megaman.

Well Portal is here to stay. And in other news i tried 22.5 degrees and it was a lot more difficult than expected to press the 2 keys needed with only one hand and still have it register and be accurate in timing. That, and the fact that if you didn't press the 2 keys close enough together, it would result in 2 portals being shot, which would mess up what you already had in place, a side effect i didn't foresee. As a summary, im sticking with 45 for user simplicity, and ease of use.

Ah, that wasn't a problem I foresaw. Good luck with it, glad you figured out a good solution.

Happy to announce with that some more code reworking i have managed to decrease the size of levels once again Even though the data for buttons took up 2 bytes, the tile for the button added around 2-4 bytes of data to be inserted, since its such a small tile, it interrupts lots of flow with the run-length--encoding. Plasma balls are even worse, with 3 bytes of object data, and an additional 4-8 bytes of tile data.

However, now all tile data is discretely inserted into the tilemap by the generator after the decompression but before the display. So now the workings of the tilemap displayer works like this:

0) Load tilemap data
1) Decompress Data into Tilemap
2) Initialize objects
3) Insert object tile data
4) Display map dynamically

I also added a new tile, Im not quite sure what to call it, but its a small hole that goes through a wall and you can shoot portals through it but you cant move through it. Its very handy dandy

Im currently working on cleaning up the map generation code and starting work on the plasma ball elements.