[Waxy's Rocket Party]

Hi TIGSers,

We've just finished Waxy's Rocket Party v1.3; it's been given a complete overhaul of a lot of the interface and balancing, and is now a good deal prettier, and better, than before.

It's a gravity game where you press the Left and Right keys to fire the thrusters on a falling rocket, and try to reach the goal without smashing it up. If you like casual or arcade titles and fancy a decent challenge, this may be for you. Hand-drawn, too.

Download (8Mb)

There's also a Mac version which is almost free.

Give it a try, and let us know what you think. Thanks!

[Overall]

Neat game. Grid-based puzzles are always a good thing!

Feedback... went a bit overboard on this so take or leave at will...

- The early outside areas are a bit slow, as some players have mentioned. The long walk to the sword and back on Floor 3, for example. Floor 7 is where it feels like it starts to pick up, and there's hardly any 'dead' space.

- The controls are a little frustrating, given the real-time tasks you throw at the player early on, dodging monsters etc. It feels far too easy to hold the direction key for a fraction too long and end up walking into an enemy, or even a static hazard like water. At the same time, the player often pauses for a second before starting to move onto the next tile, which is jarring, since it feels like walking into an invisible solid. The patrolling blob near the key on Floor 5 in particular.

- The character animation (though much improved!) still feels a little jumpy, in that it's difficult to visually anticipate the timing of cross-tile movement when it happens as large jumps rather than smooth motion. 4 frames isn't really enough here.

- Also, it's possible to 'start' moving towards a wall/solid when up against it, which locks the player until the 'move' (which doesn't go anywhere) is complete.

- Floor 8 gets a bit long - when you pass the buttons, diamond gate, water trap, and then get killed by a mouse... frustrating. Checkpoint system? You seem to have corected this for some other levels already, which is good, but particularly early stages are sensitive to this.

- Graphical suggestions:

• Decrease the outline/contrast on things like flowers which can be walked over
• Increase the outline/contrast on anything which can't - these really need to stand out as separate
  
• Similarly when you get into the Tower, the floor and block textures are very similar in tone, makes it difficult to see what's what instantly
• Consider stitching tiles together when they cover a large area - for instance, when there are lots of trees, the inside region they contain could appear as a canopy of leaves, instead of individual block trees.
• The inbuilt textbox for 'level complete' and options clashes quite a bit with the rest of the game. Is it possible to grab the data from these functions and draw them yourself on something better-looking?
• It would be nice if buttons and blocks were colour-coded to show what button lowers what blocks - the beginning of Floor 8 is ambiguous between the two buttons and two rows of blocks, not that it makes a difference here, but it would be more intuitive... or, in later Floors, it might well matter.
• The green tentacle trap would be nicer animated.
• Ditto for the diamond dispenser. It doesn't look or feel good when things just appear without any feedback - you could try fading in the newly-created diamond, or having it appear from the dispenser position.
• The tiles on e.g. Floor 9 which seem to serve only as a decoration (e.g. table of drinks, large beaker thing, grass patch, etc) look out-of-place and odd since there's so little decoration everywhere else. They stand out in the way that an interactive object should. This is related to the separation comment above - make your non-interactive things melt into the background, and make the interactive ones stand out hard. When you're introducing new switches, buttons and blocks nearly every floor, you can't get away with having such visually distinctive decorations which don't actually do anything.
• The water blocks look like glass - it wasn't immediately clear that they were elemental blocks at all.

- Floor 10 could do with a brief explanation note; it's safe to go without one for minor variations, but for introducing a whole new set of blocks, you need some exposition. The show-don't-tell is generally good, but occasionally needs a little support when you introduce multiple new targets at once.

- Similarly Floor 11 isn't clear on how elemental blocks transform tiles. e.g. why does adding fire to fire-water make it a solid block? Why does pushing wood onto fire-water not burn the wood?

- When you first push a block onto ice, it seems to 'jump' ahead 1 position, ie. it skips its first frame of motion on the ice.

- The spike-patch blocks in Floor 9 which disappear when you walk on them... there were some similar blocks near the water trap in Floor 8, but they didn't disappear. Is this right? If so, why? If the Floor 8 blocks were just decoration, they looked too much like an object to be that similar to these tiles, which now do do something. In fact, compare them to the similar pattern on the green area in front of the ladder. Those tiles look almost identical to the disappearing ones but do nothing.

- Similarly again, Floor 10 introduces water which looks identical to previous water, but can't be walked into. If it's different, it needs to look different.

Overall, every floor seems to introduce some new and exciting mechanic, like the player-only blocks or the eye monster... the pacing is just right - it keeps things interesting without being overwhelming. BUT the communication is poor - often it's unclear (until you walk on something) what's solid and what isn't, or why things react the way they do sometimes. Visually, the background and the objects need to stand out much more, and some later floors could do with a bit more of the deliberate explanation that the early floors had too much of. Finally, the feel of the control/movement and general polish isn't quite there yet, but these things are easily fixed. The core is solid. Very nice game!

(Also, please make sure your title-header post always contains a link to the latest version! Saves us the time of playing it through then deleting half the post, losing progress and starting again. Good sign that we did though. )

Finally, if you're looking for sound effects, http://freesound.org is brilliant.

Good point - we'll add a line to the .ini file to unlock all levels if the user wishes. Technically it's out of beta... and clearly, totally bug-free... hmm. Something like that, anyway.

The available symbols already do have static positions (both within the box and on-screen, since the box position doesn't change), but the box itself scales to not display rows with nothing in them. We left in the option to have the box always display full-size even when many of the symbols weren't present, with the instruction to apply it if anyone suggested they preferred it (we were 50/50 on it ourselves) - so does this mean you'd prefer the symbol box to be a constant size regardless of how many symbols it actually contains?

The left/right suggestion is valid too, we'll update the order to put them adjacent in both boxes. Good point.

[Update! v1.3 - 140611]

Update! v1.3 - 140611

As usual - get it here (29.5Mb .ZIP)

Changes
{

• 'Streamline selection box' settings option (screenshot, bottom-left)
• Cancel button on selection box
• Back button on menu screens
• Keyboard 1-4- shortcuts for programs
• Tooltip within-screen-boundary display limit
• 'Read message again' button - top-right, near the objectives tick
• Reduced UI flicker intensity, especially when alt. selection box option checked
• Unintended solution on Metronomics now supported
• All-start and multiple-symbol tutorial texts improved

}

Interesting and fun game.
I found a bug: Devil and the Details, level 2...

This is very clever - we originally thought the only way was a (more complex) solution in which you use R1 to destroy R2 to stop the metronome, but this works too. The level will now end as soon as R1 reaches the exit safely. Good find, thank you!

* When I am programming, I'd rather have a menu (horizontal or vertical) open just by the program element I've clicked on...
* Scrolling the mouse should move through programming commands...
* Please put the description of the command in the tool-tip...
* Having a 'cancel' command (to leave command as it was previously) would be nice...
* Push the command tool-tip up if it would go off the bottom of the screen...
* When playing a level, if I restart it, I can't work out how to re-read the instructions
* Perhaps point this out more clearly in the tutorials...
* 1-4 as short-cuts to the programming groups, please...

Done.

* I found the continual flickering of the interface quite distracting...
* The scrolling code window draws my attention while I'm playing.

The interface flickers slightly less now, and much less when the streamline option is checked. The symbol box also appears over the code scroller, hiding it from view.

* Quitting a level should at least give me the option to go back to the main menu or go back to the contracts screen in the campaign I am in.

Sadly very difficult! We might take a (another) shot at this but everything broke horribly last time we tried. The menu builds itself dynamically as you open folders, so going backwards from another place is... just, horrible.

* The button-group lights might be improved if they had a progress bar (or multiple lights) underneath them that light up as each button is pressed. Not too important though.
* Clicking on one of a robot group entries on the map, should switch to that program on the left.
* I got a bit confused by hold buttons being upside-down toggle buttons. 'T' works for Toggle, but upside-down-T for Hold doesn't work for me. 'H' instead?

Not implemented, because:
* Counting total switches as progress suggests the switches-on state is more important than switches-off or mixed states - also difficult to make this consistent across levels with different numbers of switches
* We prefer the total separation between the interface and the grid; this is otherwise a good idea, but it muddles the idea of remote control a little
* A little far-fetched, but T and ⊥ are the logical symbols for tautology and contradiction, so we pretty much have to keep them in a robot game.

Thanks again for your help - if you have any more ideas, let us know.

The same goes for anyone else who might like to give the game a spin. You guys have already made this game a whole lot better than it first was. Thank you, TIGSource!

How do you externally load a background as a tileset? background_add doesn't have options, and AFAIK there is no tileset_add(...), at least not in the manual.

You don't have to - all the tile controls are handled by the tile scripts. The idea of a background 'being' a tileset is only internal to GM and its room editor. As a resource, it's identical to any other background. It's when you create tiles with tile_add() that the carving-up is done. You can specify any background here and any tile dimensions, they don't have to match up to your declared offsets or sizes.

If you wanted to keep things more regular, you could add a wrapper script which translated tile coordinates into locations on the background image by using a known tile size (e.g. 1,2 to 40,80), or placed them at a pre-defined depth, etc., to stop you having to write those values out every time. If you want to load tilesets externally, you can definitely do it, but you then have to add the tiles themselves with code too.

[this]

I made this fuckin ssiiiiiiiiick animation of a closed portal being blasted open, and then closed back up.

Spent far too long clicking that multiple times to watch it open and close. Very pretty, and a good sense of 'Pow! Portal!'.

As for us; bursts and leaps and bounds of progress on this. Today was good.

Totally original and not-at-all recycled graphics. Maybe.

Thank you, Spooner! You've given us lots to think about - some of those suggestions are excellent. We'll start procesing them at once!

But:

* I found the continual flickering of the interface quite distracting, although I accept that it fits in with the art style. I'd like to be able to turn that effect off, or at least vastly reduce its frequency, in the options.

Do you mean the code scroller specifically, or the general buzzing of all the lit-up areas? Is there anywhere specific which you'd most like to soften, or just everything?

* The button-group lights might be improved if they had a progress bar (or multiple lights) underneath them that light up as each button is pressed. Not too important though.

We don't understand what you mean here - what progress would it signify? You mean the four lights under the program window and central ring on the interface? They don't do anything when you press them... you must mean somewhere else but we can't tell where. Sorry!

Thanks again. We'll have an update for you soon...

Paul - yes, when referencing global variables that have been defined with 'globalvar', it goes the other way and the global takes precedence. You'd need to supply an object id (or for self - "id.") to touch the local variables of the same name. As you say though, it's unlikely to come up.

Anything in GML.

Hijacking instances to run code snippets, cross-inheritance of completely unrelated objects, passing objects as instances and vice-versa, referencing script arguments outside scripts... endless list.

^^You might also want to include move_outside_solid() or move_contact_solid() somewhere - and note that changing 'speed' will affect the object's horizontal speed too, if that's desired, otherwise only change 'vspeed'. And it's also safer to have the object check for a minimum speed and then stop, or it may bounce forever at infinitely smaller speeds.

move_outside_solid(90,abs(vspeed))
if abs(vspeed) > 0.2{
   vspeed = -vspeed*0.8
}
else vspeed = 0

...or something.

How does GM's scope work?  Does it look for variables in children first and then in parents, or visa-versa?

Inheritance scope is treated as if all code were executing locally in the current instance (which it is) - i.e. a call to event_inherited() can be thought of more or less as if you just copied all the code from the parent to that point and ran it.

So if you've declared a variable in, for example, the Create event of an object, a child object which wishes to reference it must call event_inherited() at some point in its own Create event to 'run' the parent code and define that variable for itself. If not, you need to manually define the same variable name again.

[News]

Chevy's site and ours are both fine - the problem is our own foolish inability to remember where we've put direct links to files we then update... sorry! Fixed.

Interesting and fun game.

I found a bug: Devil and the Details, level 2...

That's odd - sounds like a victory condition is missing. We'll check it out. Thanks for your feedback!

News for anyone who tried v1.1/1.0 and found the interface difficult: try v1.2. Nearly everything is different - and better.

[Pragmatica]

Hello!

After about 9 months of devtime and a few last-minute post-release... tweaks (totally not emergency bugfixes. at all. nope), we've finished Pragmatica.

Get the demo:
here

Glad you like it.

[Coming up:]

Hmm... that's true. That map was designed before the robot<->crate crash behaviour was updated to destroy the crate too, but we don't have the solution noted since we didn't design it. Will find out for you - can you find a solution by lifting the crates and crashing the robots somehow? That would be what was intended. Thanks for the spot!

Coming up: Bugfixes (lots; in-house tester = fired), UI improvements, some extra content with harder maps. Soon.

The graphics are gorgeous and I'm a sucker for these sorts of puzzle games.

Thanks, they're all hand-drawn, although it's not so obvious this time round... forgot to mention that.

- Why do I have to click on the programming screen to program, then right click out of it? That seems extraneous.

Originally because the function of the central button needs to change depending on whether you're inside the program or not, to display the selected symbol instead of the program index... it would indeed be better without this step but it may be prohibitively difficult to change now. Will have a look though...

>> On reflection, this is worth the effort. We'll try.

- It would be really nice to have the options for a condition/action where they can be all seen at once, instead of having to click the left or right button a dozen times until I find the proper one.

It's intended to ease the transition for new players, but for clever people like yourself who grasp the thing immediately... yes, we need something better. We'll look at putting in an overlay/toolbar which pops up where the tutorial texts were (docked to middle-bottom) when you edit the program. Thanks for the suggestion.

- Having programs 1, 2, 3 and 4 for robot batches 1, 2, 3 and 4 is a bit confusing. Maybe change one of those to A, B, C and D?

Yes! Good idea. Next version.

Thanks everyone!

Now, I don't know about other people's game-making methods, but I compile and run my games really frequently ... with a workflow like mine, I just can't put up with each run taking minutes to start up.

We had the same thing towards the end of Umbrella Adventure, for obvious reasons, it's huge - there are three sort-of solutions we've been using on and off with varying degrees of frustration/success:

• Develop two games at once. If one of them is much smaller/simpler, or you have some tasks which require a lot of GM-time and no running (e.g. room-building) in your second game, consider having them both open at once and make small steps of progress on one while the other's compiling. Worked to a degree with us but it's difficult to always break tasks down into small enough pieces that you don't end up ignoring your supposedly-main project, or that don't require running to test. Dubious.
• External content-loading. Being able to reload the room and see your changes instantly is great - but you've probably already considered this if it applies or is remotely possible, and even if it does, it won't work for tasks other than content-building. Reject.
• Change your development style. Surprisingly effective in some cases - you may find that thinking ahead and making several changes at a time, i.e. 10-15min of development rather than 3-4 between each test, results in a more efficient workflow even with the slow-loading delay. The latter gives you a brief opportunity to check your targets for the test and reflect on what the next stage should be. But again, it's not for everyone... nonetheless it's worth considering. Recommend.

;

Helpful? Or switch to Flashpunk. Increasingly tempting... :/

We actually tend to deliberately, aggressively avoid expectations of any kind - the only short- or long-term goal is whatever's written on the to-do list. If it gets done, it gets done, if not... it gets done, just later. In a way, it's liberating, if you're the sort of developer/team who worries overly about failing your own or others' expectations and targets etc.

Actually, this is also what's called "terrible progress management". Hmm.

Oh yeah, also have a family, house, meet cool people, maybe start an 8-bit rammstein cover band, and run a few marathons.

And, variously, some of these. But not all.

Lots and lots of separate, opportunistic sheets of paper. Recommended? No.

That said, one very useful layout is to arrange all your game's progress checkpoints (i.e. player progress) as a directed graph, like a circuit with AND and OR gates, especially if you're working on a more open-ended, multiple-paths type of title. It helps enormously to be able to tell in an instant if one event requires another (or several, or which...), or what the relative complexity (depth from starting node) of different events are, or if any events suffer from a much easier 'exploit' alternative path to them... that sort of thing. Boxes and lines!

Although again, that would probably be better on digital media than pulped tree, it tends to go spaghetti very quickly. Depends if you like spaghetti.

Great idea for a thread, harnessing the power of social oppression. Brilliant.