RhapsodyInGeek's Forum Posts

  • This is a pretty cool game. Only things that really bug me are some parts of the stages you need to know ahead of time what's the obstacles are, making the deaths in those spots feel very cheap. It's not generally good game design to have players lose through no real fault of their own. You should allow players to have a little time to know what they're getting into, to allot them enough time to react, rather than having to know the layout by heart. The other thing that bugs me a bit is how sluggish jumping feels. That one might just be a personal preference thing though.

    Either way, I do like this a lot. It's really cool, and I look forward to more updates! Soundtrack is kickin'.

  • I'm just glad it was found! Thanks for the update! <img src="smileys/smiley4.gif" border="0" align="middle" />

  • So I ran into a problem where all of my games stopped working when attempting to play them. I'd try to test them out, but I'd get a blank screen. I'd upload them to dropbox and same thing.

    After some experimentation and a little luck, I've narrowed the problem down to Event Sheet Includes.

    Capx!

    Include Sheet Bug

    Try to test it out, and you get a blank screen (if the game's fullscreen mode is set to 'off', it shows the gray border with just gray inside). If you go into Event Sheet 1 and delete the Include Event Sheet 2, another test attempt will show that the game runs fine.

    This is probably pretty problematic for complex games. <img src="smileys/smiley17.gif" border="0" align="middle">

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • You do not have permission to view this post

  • 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.