gmerriment's Forum Posts

  • 7 posts

  • Which is kind of sad... the only thing preventing Construct from being a feasible Mac program is its reliance on DirectX for its effects�which seems to me rather unfortunate, since visual effects are just fluff.

    All of the variants of C are usable on Mac through Mono, and OpenGL and OpenAL are supported by all platforms. Using Mono would also make Construct accessible on Linux.

    In short, the answer isn't "no"�the answer is "the developers don't want to".

  • Making a low res sprite takes a few seconds, making a 3d model with good textures takes a day of work.

    First of all, I'm not equating HD with 3D. I'm suggesting that 2D games should be made with high-resolution art, ala Braid, Earthworm Jim HD, BlazBlue or King of Fighters XII. Essentially, I'm talking about using a 128x128 character instead of a 16x16 character.

    Also, ambiguous graphics work in much the same way as an abstract messy brushed painting, your mind fills in the details.

    While that may be true, It's... conveniently true, and not really applicable to the medium. I'd like to use an example above and compare two graphics from an old, 16-bit game and it's modern, HD counterpart:

    <img src="http://img833.imageshack.us/img833/6396/earthwormjimremakescree.jpg">

    Apologies that it gets a little cut off in the forums, open it up in a new tab to view it in full. What you should notice from left to right is that the character is drawn in the same stylized way he was drawn in the first game, just in higher fidelity thanks to a higher-resolution display. The level design aesthetic is largely retained as well.

    In his book Understanding Comics, Scott McCloud addresses the same property of art you're talking about: that stylization allows a person to project onto the character because the character is intentionally vague. This is what allows for comics like Sin Titulo. But resolution of image is a system limitation, not a stylistic choice: it is an artistic challenge, not an artistic medium.

    Take this image from the first page of Sin Titulo, downgraded to approximately old-school resolution:

    <img src="http://img254.imageshack.us/img254/2724/sampledowngrade.png">

    You cannot possible argue that it is "just as good" as the original despite the resolution change. It isn't. Details are lost, expression is lost, the text isn't readable and has to be replaced with a font that doesn't fit as well, et. al.

    The underlying fact of the matter is that low-resolution art resources are easy to create. It is easier to program an engine for low-resolution resources because sloppy programming will not be as noticeable in the frame rate. It is easier to script for low-resolution art because it's easier to predict motion with less pixels on screen. In short, low-res is easy?but again I say, it isn't a stylistic choice.

    There's a reason Megaman 9 and 10 were sold at bargain bin prices on Xbox Live Arcade despite being manufactured by a major industry giant: they were retro, requiring little effort or money to make. They recognize that the graphic choice tweaks our nostalgia-bone, and that the gameplay is still fun. But they also recognize that you can't possibly market a never-made game from 15 years ago as worth the same money as a modern game. After all, I dare say most of the users on this board could create a new Megaman game that is faithful to the originals using Construct. Had they made new, HD Megaman titles, they would have sold them as disc titles like they've been doing with the Megaman X series, if only because the initial investment would have been higher.

    Ultimately it comes down to this: it is more difficult to tell the quality difference between Gods and Super Metroid than it is to tell the difference between This Game is Hard and Braid. We are no longer in an era where sellable games can afford to have their art created by programmers instead of artists, because even Joe Shmuck can tell when the art is poorly made.

    Look, for example, at Cave Story and Spelunky: both games are either available or "coming soon" to consoles, and both featured low-resolution art. Notice I say "featured": now that they've got some funding, both are getting a graphical overhaul. This isn't a coincidence. Low-resolution art is sellable only for nostalgia value: it isn't now, it isn't valuable.

  • In the Variable Height Jumps section, should this:

    > create an event in the Controls event sheet with the conditions "Player is jumping" and "Control is pressed", and add an action to set Player[Platform].VectorY to 0.

    >

    be "Control is not pressed"?

    Yes it should, I'll change that. Thanks!

  • Is it possible to have multiple controllers control the same character? For example have the keyboard and joystick both control the player, so that a special option to switch schemes is unnecessary?

  • I don't understand why anybody would shoot down supporting gamepads in a game engine. To be honest, I don't know why any game released wouldn't support gamepads. I agree wholeheartedly that making sure gamepad support is flawless and thorough should be a top priority.

    That said, perhaps more gamepad-related conditions? Obviously the engine has analog support for the joysticks on the 360 controller, so maybe the ability to track it? To give an example of where this would be useful, suppose you want to have two speeds for a character. Joystick 50% - 100% = high speed, 0% - 50% low speed. Etc. Most controllers have analog support so being able to track this data is potentially useful, because at the same time most players don't need an infinite variety of speeds.

  • With all due respect, if you want to promo an engine, you should be thinking in the now, not the 90's.

    Super Mario Bros., Megaman, Sonic the Hedgehog, Final Fantasy VI, Chrono Trigger, Earthworm Jim, and a whole lot more are definitely great games, and well-polished, but they are by no means advanced. Their AI was rudimentary, their gameplay was two-dimensional, their display was great for their time... but their time was 15-25 years ago. Games made with "8-bit" graphics (kind of a misnomer, really, since the SNES that they typically emulate was a 16-bit console) serve only as nostalgia anymore and are part of the reason nobody takes 2D games seriously. Again, doesn't mean they're bad games. But I would hardly call them advanced.

    2D isn't dead, it just got buried when everyone got excited about 3D. But it's going to stay dead unless it advances to where 3D is now. Instead of focusing on games that emulate the world gone by, why not focus on games that have new ideas, artistic vision (and skill), and a look to the future? That's the kind of game I'd call advanced.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I've noticed a lot of people in the help section looking for assistance with controlling their jumps in platformers. I thought I'd put together a quick lesson (not tutorial, a tutorial is a walkthrough, while a lesson is to help you learn something) about jumping and include a few events I use that help me a lot. So without further ado:

    PERFECTING JUMP CONTROL

    Note: This lesson is based on much of the same environment as in Deadeye's Platform School. To simplify, I'll assume you're using that as a starting point and just add the jump control functionality to it.

    Note: If you are using the latest version of Construct, and you are loading up Deadeye's tutorial, you will notice that a lot of it doesn't work. To fix most of this, simply open up the Animation and Controls event sheets and find every condition that references "Player % 1", open the condition, and click "Finish". This will replace "Player % 1" with "Player 1" and solve those pesky problems.

    Final note (I promise): If you decide to skim the lesson because you aren't interested in the theory, just do the things written in italics. They're the most important elements.

    Overview

    Each platformer is different. The size of the character in relation to the environment, the character's movement speed, the nature of the action element (are the challenges platform driven, melee combat driven, ranged combat driven, etc.), and various other factors combine to determine what jump mechanics look---and more importantly, feel---best for the game. This is why you're here, presumably: the default jump mechanics, no matter how much you tweak them, look or feel wrong, and you want to make them better.

    The lesson goals are:

    • Set up text events to debug, or observe, the relevant data generated by jumping
    • Set up key events to modify properties during gameplay
    • Set up condition events to add more controllable variable-height jumps

    Debugging

    The term "debugging" usually refers to the process of removing bugs from your code, but it has become synonymous with keeping an eye on your code's execution to see what's going on and manage it. Our first goal involves creating a debug gui that will show us important data, in this case vertical speed and jump strength. We need to be able to see these variables because in the next goal we'll be setting up keypress events that can change them.

    First, you should relegate the debug gui elements to a layer that can be hidden or shown at runtime, because this makes it easy to remove it from the playable game while keeping it available to you for testing. Create a new layer on top, and in the layer's properties set the name to something descriptive like "Debug Gui", and set the Scroll X Rate and Scroll Y Rate to 0%. You'll use this layer to create your text fields.

    You need text fields to write variable data to, so on the Debug Gui layer, create two Text objects and call them "DebugTextVectorY" and "DebugTextJumpStrength". If you want to tweak even more options, you can add a text field for each option you want to view. Format these text fields however is convenient for you---they won't appear when you compile the game so don't worry too much about it. I find that bold, white text with a transparent background is most unobtrusive.

    Now we need to create the events that will spit out variable data to the debug fields. Create a new event sheet and name it "Debug". Complex debugging routines can bog down the system so it's important to keep them separate from the rest of the game so you can easily disable them when it comes time to compile the game.

    We're going to want to know vertical speed later, so we're going to want to know the player's VectorY value, so create a new event with the System->Always condition. Add an action to the event: Select the DebugTextVectorY object and add the Set Text action, setting the value to 

    "Player.VectorY: " & Player[Platform].VectorY[/code:3895go0j][/i] (note: if your player object is named something other than player, you should[i] change Player[Platform] to [i]YourObject[/i][Platform])[/i]

Take note: the "&" symbol means you're concatenating, or adding, the variable to the end of the text.

If you run the game now, every time you jump you'll get a ridiculously long floating point number.  Cripes!  Let's fix that: [i]change [code:3895go0j]Player[Platform].VectorY[/code:3895go0j] to: [code:3895go0j]Round(Player[Platform].VectorY)[/code:3895go0j][/i]  Now you'll be given a less accurate, but more usable number (since you're never going to set your VectorY to 158.1736495717794381).  These sorts of functions are invaluable (and not just for debugging), so you'll probably want to keep [url=http://sourceforge.net/apps/mediawiki/construct/index.php?title=System_Expressions]this list of them on the Construct Wiki[/url] bookmarked.

You're done setting up your debug screen...

[h2][b]In-Game Adjustments[/b][/h2]

Or next step is to set up events that allow us to change the player's jump strength on the fly by adding to or subtracting from the value in increments of 10.  This functionality will allow us to fine-tune the jumping so that the height is precisely what we want (we can also set up similar functionality for gravity and so forth to allow even more precision).

[i]Add another event, this time with a keyboard/mouse "On key released" condition and choose a key from the list that will serve as your "increase jump strength" key[/i].  I prefer Numpad Add.  [i]Now add two actions: first, select your Player object and set its Jump Strength to [code:3895go0j]Player[Platform].JumpStrength + 10[/code:3895go0j]  Second, set the text of DebugTextJumpStrength like you did with DebugTextVectorY, this time setting the value to: [code:3895go0j]"Player.JumpStrength: " & Player[Platform].JumpStrength[/code:3895go0j][/i]
This event can be duplicated and modified so that it responds to a different keypress (as implied, I prefer Numpad Substract) and subtract 10 instead of adding 10.  You now have a functional jump tweaking system!  Run your game and try it out.  Now it's very easy to change the mechanics of your jumps and see instantly what those changes do.

[h2][b]Variable Height Jumps[/b][/h2]

Construct has a built-in system called "jump sustain" that allows you to apply different gravity to a jump for a specific length of time as long as you're holding the jump key, which supposedly lets you set up variable-height jumps.  I find this system to be very unsuitable for jumping---in my opinion, it feels more like my character has a jet-pack on than that I'm controlling jump height.

In typical platformers like Mario Brothers or Megaman, you can stop jumping in mid-air by releasing the jump button, and that's the functionality we're going to emulate here, because it is what the players expect, and we must always remember the golden rule of interface design:

[b]If the players are used to a convention, unless you have a good reason to change that convention, use it; likewise, if players are not used to a convention, unless you have good reason to implement it, leave it out.[/b]

The initial concept behind setting this functionality is actually very simple: we want to stop the player's vertical motion if the jump button isn't being pressed.  [i]So, create an event in the Controls event sheet with the conditions "Player is jumping" and "Control is not pressed", and add an action to set Player[Platform].VectorY to 0[/i].  Now if you run the game, you'll that if you let go of the jump button before you reach the apex of your jump, you'll stop and drop to the ground.  Excellent.

But it's a little sudden, and it doesn't look as smooth as a natural jump.  This is where the VectorY debug field we made earlier will come in.  As our character jumps, we can see his vertical speed and get an idea at what speed the crest of his jump starts.

What we're going to do is set up a private variable that will determine the minimum speed the character must be going to allow for an early crest---if the character is going slower than the variable, he's already cresting.  [i]Under the player's properties tab, create a new private variable called "Jump Cap" and set its default value to something that seems reasonable like 50[/i].  You could also set up a debug event like we did before to change Jump Cap on the fly and tweak your settings.

Next, [i]modify the jump event you made earlier by adding a new condition: in this case we'll use System->Compare to find out if: [code:3895go0j]Player[Platform].VectorY is less than Player.Value("Jump Cap")[/code:3895go0j][/i](upwards motion is expressed in negative numbers, so lower numbers mean faster upwards movement)

[i]Now modify the action, changing 0 to Player.Value("Jump Cap").[/i]  [b]IMPORTANT NOTE: Wherever possible, when creating custom behavior, use private variables instead of hard-coded values!  This allows you to make changes (in this case, change the designated "crest speed") in one location, instead of having to wade through all of your events and change every instance.[/b]

With this set, your player will crest every jump instead of just sharply falling off.  If the value of 50 is still too sharp, you can continue to tweak it until you have what looks like a nice smooth crest.

[h2][b]Conclusion[/b][/h2]

I hope this will help some of you!  I'd like to say in closing how important a good, solid control scheme is.  I'll paraphrase an article written by Ben Cousins in [i]Develop Magazine[/i] (August 2002):

[quote:3895go0j]Hit games with well-received gameplay have level lengths clustering around 1 minute 10 seconds, characters that jump have elapsed time in the air clustering around 07 seconds, and the elapsed time to perform three combat moves in succession clusters around 2 seconds.  These should be considered constants for good gameplay.


Of course, there are always exceptions, but you should always consider the impact every element of your game has on the player, right down to the jump strength.

Good luck!
  • 7 posts