TPorter64

That's a really good idea! I'll try to see if I can get some good gamepad support. I'll have to make a few modifications to the menus, since they're all click based, but I'll try to figure something out. Glad to know this is father approved! I'm trying to make it accessible like Mario and Sonic. And you're correct: facial expressions are VERY important indicators in this game!

zsangerous

Kill them?! That sounds a bit harsh, since there are no enemies in the game, only friends! <img src="smileys/smiley17.gif" border="0" align="middle" /> You get a hint at what you're supposed to do when you're with your friend at the very start of the game, similar to entering the door, but I don't intend to add any full on tutorials. I'd like to encourage players to explore and try things out, which is why there's very little penalty to do so. At least in the first few stages. You have all your controls and abilities from the get-go; it's up to you to play with them.

Another thing I'm intentionally avoiding is dialogue. For the story being told and the way it's presented, dialogue is unnecessary. It allows a little interpretation from the player, but still let's you understand the important plot points: your parent is sad, and you're running around in your dreams trying to understand why. I know that last bit isn't completely clear yet (I'll be adding in imagery of the parents to allude to that point in the levels) but that's the basic plot. You dream about making everyone in your dreams happy because you want to make your father/mother happy.

Or at least that's the intention.

Which brings up another thing: this game really is an 8 bit version of Inception, minus guns. Dreams within dreams, oh my... <img src="smileys/smiley36.gif" border="0" align="middle" />

everyone else!

Thanks for the props! I'm already almost done with the tileset for Stage 3, which will feature..... robots.

So I'm working on a game. Thought I'd release the 2 stage demo for you guys to play around with / break. Let's look at some pretty screenshots!

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness01.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness02.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness03.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness04.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness05.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness06.png" border="0">

<img src="https://dl.dropbox.com/u/20459682/Happiness/happiness07.png" border="0">

The two stages in the demo are pretty much complete, aside from maybe a few tweaks here and there, dependent on playtesting feedback. I've got ideas and concepts developed for 4 more stages, and the plan is to have around 8-10 stages when the game is finished, each with their own unique themes. I may also include other playable characters as well (no unique abilities though due to the kind of game this is).

It's a simple plot, but I like it. I'll leave it to the player to interpret what it means.

Don't forget to press F11 for a fullscreen experience, and feel free to leave any thoughts here! <img src="smileys/smiley1.gif" border="0" align="middle">

UPDATE! 7/20/12

The latest revision of the game, contains 3 stages.

Happiness!

Known Bugs:

*End of Stage 2, the black bg is in front of the score text, should be the reverse.

*End of Stage 3, you have control just before the robot begins moving. If you manage to jump into a pit before the robot starts moving you get frozen in the "dead" state and unable to pause and restart. The only way out of it is a browser refresh.

If you find any more, I'd appreciate it if you let me know!

Have fun, and be happy! <img src="smileys/smiley4.gif" border="0" align="middle">

Have a private variable dictating which team the weapon belongs to, and for any events dealing with damage make sure the condition for dealing damage is that the weapon's Team ID is different from the defender's Team ID.

I recently posted a bug about platform behavior having issues with positive X movement (Platform / Positive X Movement Bug, received a quick fix from Ashley, thanks!). Seems that it wasn't limited to platforms. There's also an issue with slopes.

Basically, if you try to move the platform sprite to the right from a standstill when next to a slope that angles downward the platform sprite doesn't move until it has "accelerated" beyond a certain threshold. If you're already moving it seems to work fine, and it works fine when moving left or on an upward slope.

https://dl.dropbox.com/u/20459682/slope_bug.capx

This can cause problems while attempting to carefully navigate narrow sloped platforms in games. Hope you can solve it!

If you click on your sprite 2 in the IDE and look at the left hand side of the screen you'll see a number of properties specific to that sprite's instance. At the bottom of that list you'll find an option for "Initial Visibility".

That looks pretty fun. I'm liking what I see so far! Get a better quality vid up quick! <img src="smileys/smiley1.gif" border="0" align="middle" />

Whatever you did fixed the bug I reported. I noticed one other thing, but it's only noticeable at a low resolution, and not as gameplay effecting so much as visual.

When landing in my example, the platform sprite sometimes land about a pixel or a half pixel into the jumpthru tilebg, but when the platform sprite overlaps another jumpthru tilebg it jumps to the proper elevation. I thought it might be dependent on speed, but I tried raising the values to see if there was a notable difference but it appeared to have no effect on the outcome.

Like I said, that quirk there seems rather low priority, and probably will only effect lo-res retro games like mine and only visually really.

The original bug appears to have been squashed though, so awesome awesome awesome! <img src="smileys/smiley4.gif" border="0" align="middle" />

I've noticed a weird issue with the Jump Thru behavior. If a platform sprite is at a standstill to the left of the jumpthru tilebg without overlapping another the platform sprite needs to accelerate to a certain speed in order to move past it, but only if the platform sprite is moving right.

When moving left from a standstill the platform sprite passes through as expected. If the platform sprite is already overlapping a jumpthru tilebg then it will pass through all other subsequent instances as expected. It only occurs when not already overlapping a jumpthru tilebg.

Example Capx

http://dl.dropbox.com/u/20459682/platform_bug.capx

Just get as close to the left side of the either of the teal platforms, and then press right. You'll notice a hesitation followed by a "pop" as you move past it. I assume it's because you're still accelerating even at a standstill, and once the platform sprite hits a certain speed it passes through.

I assume this is a bug due to the inconsistencies mentioned above.

You'd want to set the custom name to a global variable, or a global array object, depending on how many other variables you want to share across layouts.

You can create global variables by right mouse clicking in an event sheet and selecting "Add global variable" from the drop down menu (you can call it "PlayerName" for easy reference). Then, in your events handling name input, once the player gives the OK you can set the global variable "PlayerName" to whatever the player input their name as. Then later on, when you have your dialogue event, you can set the text string as

"Hi " & PlayerName

Global variables are called just as you named them, without any quotes.

Admittedly haven't given this a look yet, but first thought that comes to mind is the condition

System: Compare Two Values

ImgGroup1.AnimationFrame = ImgGroup2.AnimationFrame

While I do recommend an invisible bounding box to be used across the board, one thing you could do (so as to avoid repeating the same control inputs over and over) is to have a broad player class that handles the control input and state handling and all the common features between characters, and then have little subclasses for each individual character. Like....

Player is a sprite with platform behavior

Mario and Sonic are both part of the "PlayerSprite" family

"Player Class"

if player state = "idle"

       if press right

              player move right

              PlayerSprite play anim "walk"

       if press left

              player move left

              PlayerSprite play anim "walk"

       if press attack

              set player state = "attack"

              PlayerSprite play anim "attack"

              PlayerSprite spawn AttackBox at imagepoint "attack"

       if press special

              set player state = "special"

"Mario Class"

if player state = "special"

       Mario play anim "throw_fireball"

       Mario spawn Fireball at imagepoint "fireball"

       if Mario anim "throw_fireball" finished

              set player state = "idle"

"Sonic Class"

if player state = "special"

       Sonic play anim "spindash"

       Sonic spawn AttackBox at imagepoint "spindash"

       if Sonic angle = 0

              Sonic set VectorX = 250

       elseif Sonic angle = 180

              Sonic set VectorX = -250

       if Sonic VectorX is between -50 & 50

              set player state = "idle"

Something like that. Not necessarily EXACTLY like that, but the idea there is how I'd do it.