ASCIIPortal Development

[Cymon]

Update: ASCIIpOrtal has taken off like crazy! I expected some response, but a tweet from Erin Robinson put me on the map and now I've got a full beta team. Stay tuned.



FAQ: What OSs will this be available for?
I have a windows XP, so all binaries will by default be for Windows. But I will also be including the source code with the distribution and am doing my best to write it cross-platform compatable so it should compile in Linux and Mac. I've had successful builds done in Linux. I have not had successful builds in Mac, tho I don't know why.

UPDATE! There is a high chance we'll be seeing an online version. Don't know how that would work for the level thing. It probably means I'd have to write a level editor within the game. I was trying to avoid that, but I guess I'll cross that bridge when I get there.

FAQ: Are you doing this opensource?
See above.

FAQ: Can I get in on the beta?
Thanks everyone. But at this time I'm saying just wait for the game to come out. You'll still be able to make levels.

FAQ: But I wanna be in on the beta. I promise I'll...
And I'd love to have you. But I gotta draw the line. Don't worry, you'll get to play the game, I promise.

FAQ: When's it come out?
When sound and menus have been added. Soon-ish.

ASCIIpOrtal has been mentioned on:
Bytejacker (twice)
Boing Boing  and OffWorld
Kotaku
Wired
Joystiq
Rock-Paper-Shotgun
SlashDot
GameSpy
reddit
TIGSource
.Chronicles
Halflife2.net
I was really amused by this comment. And the one after it that quoted it wholesale with a "Yup." (For the record, I've never had a Mountian Dew or played D&D believe it or not.) Also the one who

I had the first couple of posts below on the main site, but then I created these forums so I took them off the main site and put them here, hoping for more interaction. You can begin at the beginning of ASCIIpOrtal below or you skip to the end and see what I've done so far.

[Cymon]

This is the first part of a multi-part series where I will document my next project, an ASCII version of the popular game Portal, as it is developed.

The first step, I feel, to sharing this project with you is that you need to start where I started. So this first document will be a quick introduction to the project by introducing you to what led me here. First of all: what the project is. The name is pretty self explanatory. It will be like the game of Portal by Valve, but with text graphics. However, this leaves a lot of leeway, so as I introduce to you the games I'll tell you what caught my attention in each of them so you'll know what to expect. I don't actually expect anyone to follow all these links, but...

Portal preview (youtube) - When I decided to do this project I had actually not played the game itself yet. All I had was this preview. Like so many others I fell in love with the portable holes idea presented in the game. The idea of looking through a hole and seeing yourself, and then actually walking through and being there was disorienting but powerful.

Portal TFV (wecreatestuff) - Among those who were immediately enamored with Portal was the team at wecreatestuff who created a flash version that was, in a word, brilliant. Fling mechanics were implemented and the portals reacted as you got close to them making a slight illusion of being able to see through them, tho it was little more than a trick to pretty up teleport points.

Narbacular Drop (Digipen) - Since I didn't have the hardware to play it right away, when I learned that the team that created Portal based their work on a game they did at Digipen I had to check it out. (Free is good.) It was a different game in many respects, but it solidified the idea.

Portile (TIGSource Demake Compo) - increpare's entry to the TIGSource demake compo was up against the almighty  Super 3D Portal 6 and so was never really given a chance, even by increpare. But I loved how it worked the ghosts images oriented to the portals made this, in my mind, the only 2D version of portal that really caught the disorienting effect of the portals. Plus it had the fling effect. I also think it was the unfinished nature of this version that really got me going and inspired me to start the process in earnest.

Portal (Youtube Video)

- Then, I finally got the game and played though it. (This series of walk-through videos really capture the subtleties of the game, I feel.)

Super Serif Bros - Incredibly simple text mode interactions, this game had at one time a ton of user created levels. I wonder what happened to them. Still, worth playing. "C" will quickly skip to the next level if you're hitting a wall. Levels 10 and 13 features some cool interactions.

I should also mention at this point, and I'm sure it will be mentioned later, that there does exist a project to make a text-mode Portal already, but that version is buggy, incomplete, topview, and the portals are merely objects like in Super 3D Portal 6. My version will be quite different. (Ooh, glad I checked back. He released the source. Somebody should finish that one.)

So there you have it, my muses, my inspiration for this project. Check them out and next week I'll start sharing with you my brainstorming!

[Cymon]

Initial thoughts:

To call Portal inspirational hardly does it justice. Even before it was produced wecreatestuff started working on a flash version of the game based on the

trailers

(and possibly insider information and Narbacular drop). Shortly after it came out someone modded the original

Doom with a portal gun

. A TIGSource competition produced a Portal game that could actually be played on an Atari 2600, Super 3D Portal 6. ...

Then I played a tile based, low res version of Portal called Portile. Somehow this one sparked something in me. Maybe it's because the code was available. Probably it was its use of echoing aligned with the portals to create a sense of the disorientation effect that portals produced. Maybe it's the fact that it was incomplete. Either way this game is what really got me started.

Through the looking glass:

What I first started thinking about was Portile's echos that it aligned with the portals. This provided something that was absent in other 2D implementations of Portal, the disorienting effect of having your room extended in weird, non-euclidean ways and made the portals more than just teleport points. It was brilliant but somehow not enough. For instance, put two portals next to each other on the ceiling and watch it freak out. The illusion is shattered. Put a portal next to an internal wall and it pretty much didn't do anything.

It was the internal wall thing that I put my mind to first. Here is a mini level to illustrate:

[Illustration lost to wordpress formatting issues. Maybe I'll draw a picture one day.]

The blue portal is pretty straight forward. The overlay would just line up the portals and ignore what was on the other side. The red portal is the problem. Draw the echo on top of the portal and what happens if you go behind it? Draw it behind and you don't get the effect.

The solution is something that makes a decision based on the location of the character. This leads to other assumptions having to be made:

• The normals of the portals have to be kept track of. No entering portals from behind.
• This also means that there can be no portals on the corners. Otherwise how will we know what the normal is supposed to be? We need something on either side to calculate the portal's orientation (normal).
• The visibility through the portal will move with the player.

At this point I made a decision that is sure to make this project more challenging. I decided that when you enter a portal I want the view to shift around you instead of teleporting you with a "pop" to the new location. But how to accomplish this if you reappear in a different part of the screen? Easy enough.

• The view will always stay centered on the player.

Okay, this allows a few cool things to happen and I can already start to see it in my head. And now I don't need to limit level size to a single screen size. But I begin asking myself questions. Do I want to have the viewable area be a radius around the player, a viewable square around the player, or the whole screen? That can be answered later, but one thing's for sure. I can now list as a feature:

• When you enter a portal there will be a moment where the view will spin around the player in 45 degree increments until they are oriented properly (if necessary) before depositing them on the other side.
  

You have to deposit them out the other side because unlike Valve's Portal our ASCIIPortals have a depth. If you simply let the player sit in the portal they could go back, and how could you keep track of that? The other option that I just thought about is to waited to turn the view until they're actually through the portal. Maybe that would work. Not sure how I'd make it happen. I toyed for a moment with the idea of allowing you to exist in some quasi space if you're inside the portal where the world is half rotated and physics are based on that. But since we're dealing with text graphics letting 45 degree rotations sit on the screen too long could get ugly. Better just use 45 degree rotations for momentary transitions.

Text mode graphics

Portile's blocky graphics were okay, but the decision to stick to color filled blocks seemed rather limiting. Since I'm doing quite a bit with PDCurses, and text is more or less tile based it seemed a no-brainer to extend the game with text graphics. After all, it worked for games like

Donkey Kong on the ZX81

.

It's time to make a list of the features I want to see. Pushable blocks and treadmills immediately spring to mind. Ladders. Switches. I wonder if I could pull off crushing pistons? The whole time I'm listing objects I'm thinking about how to depict them both in data files and in the game. Like lode runner I want adding levels to be a fairly quick and easy process. Super Serif Bros served as another point of inspiration here. If you haven't I recommend you play it. (Tho at the moment it's level pit missing is a serious downside. It doesn't showcase the user power of the user generated maps.)

As I was considering upon the depiction of the graphics I realized I had another decision to make. Console characters are nearly twice as tall as it is wide, which is why for games like Alleytris and Nibbles the blocks are doubled to make squares. (The alternative would be to cleverly use the half blocks like in the old

QBasic Nibbles

game.) And since I want the levels to be viewable rotated 90 degrees through portals I either need to come to terms with having skewed rotations or do some character doubling myself, which raises new problems. Do I represent the player character icon with two characters or one character and a space? If I only do one and a space how to I handle when you're up against a wall without confusing the player? If I do character doubling can I find two characters characters that can be represented rotated for every possible character? Clearly it's something that needs more thought and perhaps a few experimental programs. (Note to self: Make some experimental rotation programs.)

Features List

At this point my brainstorming is starting to become a formalized idea. It's time to revisit the list of features i want in the final game and decide if it's do-able:

• The view will always stay centered on the player.
• The visibility through the portal will move with the player.
• The normals of the portals have to be kept track of. No entering portals from behind.
• This also means that there can be no portals on the corners. Otherwise how will we know what the normal is supposed to be? We need something on either side to give us orientation.
• When you enter a portal there will be a moment where the view will spin around the player to orient them properly (if necessary) before depositing them on the other side.
• The levels will include: pushable blocks, treadmills, ladders, switches, doors, crushing pistons, impassable walls that you can shoot thru, and spikes.

Seems doable so far. But decisions still need to made about control schemes, how to aim the portals, the mechanics of the engine, the mechanics of rotation, and the mechanics of drawing through the portals, plus the fact that the scope of this thing is a project for this website. Will I be able to contain it within these constrains?

But I'm running a bit long so I'll save these questions for next week.

[Cymon]

When the last part ended my brainstorming about what ASCIIPortal was going to look like was starting to form into solid ideas. I had some idea about the way portals would work and a few of the world objects. Now I'm going to focus my thoughts on what I think would make a good game.

If I want this to be a good game there has to be puzzles. A game is defined by it's limitations and working within those limitations to solve problems. So this kind of becomes meta-gaming where I'm solving the problem of how the game will solve problems. But I digress. Part of the fun of games can come from finding a solution to a problem that seemed impossibly complex. Part of the fun of games can come from facing a problem that required spit second timing and decision making and getting it right.

Maybe I should start by thinking about what problems other games have had the player solve in the past. In Portal the problems to be solved were "open door, get to door, pass through door." In other words the puzzles were about getting yourself to a destination. In Super Serif Bros the problem was to collect (or destroy) all of a certain object and then get to the door. Same with Lode Runner. Games like Doom (broadening my view) and arguably most FPSs that have followed the goal looked like it was to crush everything you saw, but in reality you could win simply by running around the labyrinthine passages for the exit (after maybe collecting a few keys you needed).

I seem to be stuck on these two ideas. Get to the end or collect something and get to the end. Okay, so that's the goal. We need an exit door and your goal is to open any necessary doors, and pass through them. Do I want to add a collection aspect? Do I need to? Probably better to leave it out so the game "feels" more like it's inspiration.

At this point I consider making an original game that just uses the portal aesthetic. Like Narbacular Drop. It's possible that an original game that isn't Portal but played like portal could exist. Put that on a back burner.

To jump or not to jump? Hmm. In Portile you weren't allowed to jump, and for a block based game that seemed like a pretty good idea. Super Serif Bros did the same thing, tho they allowed you to step up short rises and part of the game play came with finding something to stack up to help you build inclines. Jumping's always kinda weird with chunky games. Maybe better ditch that.

Carrying or Pushing? In Portal you could carry weighted storage cubes from one place to another, drop them, and makes steps. Flash Portal did too. I've played tile based games who's whole aesthetic revolved around this, tho I've never made one. Potentially you could just shoot a portal under a block and drop it wherever you wanted it, so maybe a carrying aspect will only be making things difficult on myself. I think I'll drop this idea in favor of pushing, but I'll keep it in mind.

Aiming the gun. Now this is important. Portile had a rather complicated 2 control stick scheme where one set of keys controlled your direction, another controlled where you shoot, and you had to press a button to modify your shot to open the opposite portal. I don't like it. Flash Portal used mouse input. Not a huge fan of that either. Here's what I'd like. When you walk left there is a aiming dot that moves to your left. Move right and it points right. Press up and it goes to a up/diagonal direction. Press up again and it's pointed above your head. Press down and it goes to a down/diagonal direction. Press down again and it's pointed below you. If your aiming guide is trying to sit inside a wall or floor that you can shoot that wall or floor will change color to indicate that if you pull the trigger you'll get a portal there. That way you've got the normal direction keys and 2 buttons (one for each portal), and maybe a third button if I decide to make life hard on myself and allow you to carry boxes.

On Screen Objects. Time to revisit the list. This time I want to think about the on screen representation and how they could be represented in the datafiles (in parenthesis).

    * Boxes (O) - Appears as a Square. Pushable. Should I make it possible to push a whole like of boxes or make it like Super Serif Bros where a box can stop a box? I think I like the pushing a line idea.
    * Switches (a-f) - Appears as a tilde ~. If there's anything above them they're on. Certain switches stay (a-c) open once opened, certain switches (d-f) need boxes above them to stay open.
    * doors (A-F) - Appears as | or -. To be opened by switches.
    * Crushing Pistons (==] [==) - Pretty much appears as seen. Initial direction is assumed to be forward. Will push boxes, reflect power balls, and if the object they are pushing can't move it will destroy that object. When they hit a wall or another piston they retract until they hit the wall, then they turn around.
    * Boulders ({, }) - Appears as an 'O'. Follows gravity, activates switches, and crushes you if you come in contact with them. When they hit a wall they reverse direction. (The direction of the brace just defines the initial direction.
    * Ladders (H) - Appears as an H. Climb up them.
    * Normal Walls (#) -?  Appears as a white wall.
    * Un-portal-able Walls (X) -?  Appears as a Gray wall.
    * Un-shoot-through-able Walls (%) - Appears as a blue 25% block.
    * Shoot-through-able but Un-pass-through-able walls ($) - Appears as a red 50% block.
    * Timed triggers (1-9) and fuses (.) - I really loved these in Super Serif Bros. So they will appears Pretty much as they are in the data files.
    * Treadmills ( ))) , ((( ) -Appears as white background, black parens. Moves anything above them.
    * Moving Platforms (---) - Appears as a double line in the game. Anything above them moves when they move. Need to figure out a way to make several of them move in a line.
    * Spikes or toxic goo? (!) Appears either as green 50% blocks or W. Have to see what looks good.

Power Balls. These were such an important part of Portal and Flash Portal that I don't want to leave them out, but getting my head around how they should work has been troublesome for me. Heretofore I've thought that I'd represent the data with one array that had the map character plus an int where I could keep directional data for things like the balls or pistons, or the door a switch opens, that sort of thing. But this is going to require I keep a seperate list of all balls, their life remaining, and their generator so when the land in a reciever they stop generating. It's a pain, but its esential.

    * Power Ball Generator (^/>/</V). Appears yellow or orange. Creates a power ball that moves in the direction it was generated.
    * Power Balls (*) Appears as an orange or yellow star. Moves in a constant direction and bounces back when it hit's a wall. Going to need some cleverness to make the react to portals properly, but this is important.
    * Power Ball recievers (V/</>) Appears blue until activated, then it changes to X and moves one step backwards so they can triger a switch. For this reason you can't have a ceiling recieve

ENOUGH! Okay, this is threating to balloon out of control if it hasn't already. I'm already envisioning page long case statements. Can I do without some of these things? What do you think. Let's open this to the comments.

[Cymon]

The plan at this point was to do a section on writing a design document, one of the educational moments but not strictly necessary in an environment like this. I kept putting it off and putting it off and in the end I decided to just move forward with the game and skip the superfluous design docs. But just in case you want to know how to write a design document, here's a template.

So the next step is to start writing code. While some folks may be able to just jump right in, as I look over what I've decided I want to do in this program that I left off with last time I realize there are a few things I want to move from theory to actual code first. Specifically: rotation. Sure I know how it works, technically, but I've never actually done it. So it's time to write a prototype program.

x' = x * cos (r) - y * sin (r), y' = x * sin (r) + y * cos (r). Shift the points so that you rotate around your desired center and shift back when you're done. Simple enough. If you don't know anything about sin and cos here's a little primer: sin and cos are functions. Numbers go in, numbers go out. What you need to know is that the numbers going in are floating point numbers and are NOT the standard degree rotations that you are used to. The numbers going in are radians, meaning instead of going going from 0 - 360? around a circle it goes from 0 to 2pi. pi = 180?, pi/2 = 90?, 3pi/2 = 270?, etc. It's not something taught until trig and for some (very good, actually) reason the folks who wrote math.h decided to use it

Let's see what happens when I try to rotate something:

rottest1.zip

Now as I play with this I notice a couple of things. First of all the 45 degree rotations are a little bit off of what I expected them to be. And while I'd love to figure this one out, in truth they aren't going to be used for more than a visual effect in the game, so I won't worry about them now (unless someone who has experience rotating sprites wants to help me out). Second, the 180 degree rotations are torn. No way I can let that slide. Somethings got to be done



I think I know the problem. Floating point error making pi/4+pi/4+pi/4+pi/4 != pi. I guess the computer doesn't know how to reduce fractions. So we need to change tactics.

If we want precise rotations we need precise responces back from sin and cos. At first I start making a table of values to pass to sin and cos, but then I realize I could simplify matters by writing my own sin and cos. I could even use degrees if I wanted, tho I don't. I'm only going to be doin 8 degrees of rotation, so why do I need to bother with anything other than 0-7? That should make things pretty because, if you know anything about sin and cos, since we're only dealing with multiples of 45° anges we're only talking about four possible return values: 0, -1, 1, and 1/root(2) aprox= 0.70710678118654752440084436210485. I wonder if there would be any difference if I just used 0.7?

rottest2.c / rottest2.zip

Looking at the rotations, I think I could probably get away with not worrying about the non-square nature of text characters that I went off about a few posts ago. Plus, maybe I can employ a square font in an enhanced version that utilizes PDCurses with SDL. (Which would mean I could put sound in too. That sounds good, doesn't it?)

If I may humbly say so, I've successfully handled rotation the way I want to. There's still some things to work out, making sure it aligns the portals and what not, but the underlying math has been sussed.

What's the next step? Looking over my desired list of features I don't think there's anything else that warrants a prototype program, so I'll call this post complete here. At this point it's a game of building the program one feature at a time. So now it's time to prioritize the features I want in the order I will work on them. Hmmm:

• Load levels from text files
• Centered view/moving around
• Walls
• Un-portal-able Walls
• Un-shoot-through-able Walls that you can walk through.
• Shoot-through-able but Un-pass-through-able walls
• Ladders
• Spikes or toxic goo (death blocks)
• Shooting portals.
• Portal visibility.
• Portal transitions
• Boxes
• Boulders
• Power balls (I'd love to save these for last, but they really belong here)
• Switches/Doors (related to the power balls)
• Timed triggers and fuses
• Treadmills
• Moving Platforms
• Crushing Pistons

Yeah, that'll do for a start.

[Cymon]

It's been a while, but I've entered on the phase of this project where I can no longer get by with onesy-twosy code changes.

Well, there was one thing.

Load levels from text files
Getting levels loaded required a shift to C++ so that I can take advantage of the dynamic memory allocation of vectors. There weren't many challenges in getting level's to load, except for, perhaps, keeping lines and columns straight. But in the end it came together pretty well.

loadinglevels.zip

Cool, now I can load levels into memory, and there's very little processing going on. In fact, processing was the very next step.

Centered view/moving around
Well, I got half way on this next step, but it was a doozy. See, I needed to:

• Process the raw data
• Treat dynamically moving objects and static map objects differently
• Create a centered view

So it was time to set up the framework for pretty much the whole game. So to start an enum was created to give a framework for everything. It passed through a few iterations, and ended up like this:

Code:

enum GameObjs {NONE, GOAL, NORMAL, FFIELD, PFIELD, LADDER, LTREAD, RTREAD,
  ASWITCH, BSWITCH, CSWITCH, DSWITCH, aDOOR, bDOOR, cDOOR, dDOOR,
  SPIKE, COUNTER1, COUNTER2, COUNTER3, COUNTER4, COUNTER5, COUNTER6, COUNTER7,
  COUNTER8, COUNTER9, FUSE, DUPLICATOR,
  NBALLGEN, SBALLGEN, EBALLGEN, WBALLGEN, BALLSTOP,
  MAXWall,
  PLAYER, BOX, BOULDER, PISTON, LPISTONHEAD, RPISTONHEAD, PLATFORM, EBALL,
  MAXObjects};

The MAXWall and MAXObjects entries are there just to help in type checking. At one point I had them separate, but that turned out bad.

Next I wrote a function to process the raw map objects creating the static map and a vector of dynamic objects. Well, I guess I'll have to define what an object is now. The process of writing the function to process maps was a repeated cycle of decisions, writing, road block, debugging, and making a new decision.

Once maps were processed, I needed to write the drawing and updating function. For some reason I was stuck on this for a while. I had a brain block that I couldn't pass. I knew I was forgetting something and refused to move on until I figured out what it was. In the end, it was this:

Code:

do {
  move_objects ();
  draw_screen ();
} while (still_alive());

This is called the main body loop, and for some reason I couldn't wrap my head around it. I've done tons of these in one form or another, but this time I just couldn't figure out what needed to be done. Why was this such a hard thing for me? Once I remembered it, things progressed well.

I decided to make the characters to output and their colors in a giant look up array, which meant I needed to make decisions on the visual aspect of everything in the game at this point, or at least come up with some decent place holders until I make a final decision. (Most notable the easterly ball generator is still 'E' in the raw maps, as well as the goal being 'E' in the raw maps. I'll have to make a decision there eventually.)

A little more wrestling with the A_ALTCHARSET (note to all PDCurses programmers, store chars as an int or the '|'or opperator won't work) and it's good to go!

loadanddraw.zip

Next, I need to make things move. Shouldn't be that hard.

(...yeah, right.)

[Cymon]

Hey, I just made a typo when making a news post on the main page and thought it was pretty cool. What'd you think if the capitalization of the project was changed from ASCIIPortal to ASCIIpOrtal?

[Cymon]

Things are moving great.

I'm kinda busy at the moment, so I'll just sum up this one by a few bullet points:

• The character is moving.
• Treads are moving stuff.
• You can push companion cubes.
• You can step over small obsticles.
• If you get to the goal you win the level.

Downloads: moving.zip

[idontexist]

Hey, I just made a typo when making a news post on the main page and thought it was pretty cool. What'd you think if the capitalization of the project was changed from ASCIIPortal to ASCIIpOrtal?

I like it.

[Cymon]

Hey, I just made a typo when making a news post on the main page and thought it was pretty cool. What'd you think if the capitalization of the project was changed from ASCIIPortal to ASCIIpOrtal?

I like it.

Even better.

ASCIIp()rtal

[idontexist]

Hey, I just made a typo when making a news post on the main page and thought it was pretty cool. What'd you think if the capitalization of the project was changed from ASCIIPortal to ASCIIpOrtal?

I like it.

Even better.

ASCIIp()rtal

I agree.

[purpleflayer]

This looks like a fun idea! I suppose you have already seen Jacob's Matrix, Jeff Lait's 7DRL which puts his ideas about similar topics into action.  With your trouble regarding 180 degree rotations, is it possible that the trouble is due to the numbers for the coordinates rounding off to an integer incorrectly?  That was what I thought.  For example if you are just doing "float->int" conversion, it will probably be rounding down, which means that say 3.99975 would be converted to 3.  this might give the problem you saw.  The solution would be to explicitly "round nearest"; you can do this easily by adding 0.5 and then rounding down.

Please keep us updated

[Cymon]

This looks like a fun idea! I suppose you have already seen Jacob's Matrix, Jeff Lait's 7DRL which puts his ideas about similar topics into action.  With your trouble regarding 180 degree rotations, is it possible that the trouble is due to the numbers for the coordinates rounding off to an integer incorrectly?  That was what I thought.  For example if you are just doing "float->int" conversion, it will probably be rounding down, which means that say 3.99975 would be converted to 3.  this might give the problem you saw.  The solution would be to explicitly "round nearest"; you can do this easily by adding 0.5 and then rounding down.

Please keep us updated

The difference between Jacob's Matrix and this is Jacobs matrix wanted to make a map that was non-linear, this one is very linear but will trick viewers into seeing through portal, much the same way that the original portal did, as a matter of fact.

Hmm, maybe using the round function would have fixed the problem, but since I'm only doing 8 rotations it's easy enough to just write my own functions and handle it that way.

This project is not abandoned, but I'm not working on it right now. Ive got the 7DRL reviews to finish right now, site problems to fix, I want to start working on the book right now, and then I'll come back to this one.

[Cymon]

It's been a busy few months and I've had to put ASCIIpOrtal (preferred capitalization) on the back burner. Well, I finally go the chance to crack open the code again and admire what a mess I'd made up to this point. Note to self: don't ever be afraid of really useful variable name.

So now I've programmed hazards into the game. Spikes, Particle fields that destroy non-player objects, and force fields that kill the player, but not non-player objects. I also tightened up movement. Now you can't walk on air like before.

New download. Source and executable included in the zip. hazards.zip

Well, now we've got a game. You can win, you can lose, it's pretty good stuff. We have a game, but we don't have the game yet. I've still got a portal gun to program, a fling mechanic to implement. I may have to undo the walk on air thing to make it work, but oh well. Still, if anyone is so inclined you can make your own maps by editing the files in the maps directory. Add as many as you want in sequence and they'll be loaded up. I'd love to see what other people come up with. So far the only levels I've made are to test out the features I've implemented.

[Cymon]

Okay, here's the last public beta for a while. That is to say I'm not going to release any more compiled binaries or code until I'm done with the game. Why? Well, because the very next thing I'm going to work on will be the portal mechanic, and I do not want, once that's up and running, for folks to get all excited about an incomplete game and then never come back once they've played that out.

So what's in this release? A cleaned up code base and boulders. Boulders that can push the companion cubes the same way you can. You can also shoot portals, tho they don't do anything yet. So check it out and tell me what you think so far.

boulders.zip



Lemme tell you what's coming next, to whet your appetite:

• Portals
• Doors and Switches
• Dispensers
• Level Messages
• Sounds

And then I'm going to call that it. I know that's less than I initially had planned, but I don't think I'll be disappointing anyone but myself.

At this point there's a heck of a game there as-is. You can edit your own maps or make your own (just increment the number in the file name, make as many as you like). The current levels are just there to show what can be done. But I'd love if someone were to make some clever levels for the game as it stands. So to that end let me provide a key for making your own levels:
E - GOAL,
# - NORMAL Wall
N - NONSTICK Wall
% - Particle FIELD, destroys everything but you.
$ - Force FIELD, Destroys you.
+ - LADDER,
( - Left Conveyor Belt
) - Right Conveyor Belt
@ - Start Location
& - Companion Cube
X - SPIKE
O - BOULDER
Just combine the above elements in a text file named maps/mapxxx.txt (where xxx is the next level in the sequence) and run the game. You level will be added to the ones currently there. Or over write them if you don't want to play through the demo levels. There shouldn't be any limitations of size, big or small, so go at it.

I'll update you with screenshots as the rest of the game progresses.

EDIT: I'm shamelessly promoting this trying to generate just the right amount of buzz. I have no pride, I promise this will rock. But to the end of shameless promotion I've made a video showing the game as-is:
http://bytejacker.fliggo.com/embed/iSXaZCyT