Useful Tips

Hello,

I was wondering, what are some good tips for using Stencyl, simple or advanced, or mistakes to avoid.

I thought that this would be helpful to any Stencyl beginners, or just anyone reading this.

Simple:

 START SMALL.  Don't try to make a huge game when you first start out.

 DON't use premade behaviors. You can NOT make a proper game using only premade behaviors alone. Use them as
 learning material only. Always make your own behaviors.

 DON'T make (or use) a behavior without properly understanding the code behind it. You will have to tweak it
 eventually and you'll waste a lot of time in the process.

Medium:

            Start learning how to code. Add code blocks in your behaviors. Start making small  code mode behaviors (and keep expanding  them).
            Start making your own extensions.
            See if you can add things to the stencyl engine or modify it to fit your needs.

Advanced:

            You still have waaay to many things to learn. Go back a step and keep learning.

Starting out: There are some pre-made behaviors I still use, but otherwise I agree with SadiQ's advice on them.

I don't like the advice that's sometimes given to avoid other people's behaviors, extensions, and other code. For one thing, it's contrary to modern software development principles. You don't start from scratch. You use libraries and engines. You're using Stencyl, aren't you? That's someone else's code

But I understand why that advice is often given. A lack of understanding of programming will be a significant, if not the most significant, limiter of how far you'll get developing games on your own. Working in a team? Then the limit is how much the best programmer on the team knows their programming and their ability to communicate with everyone else on the team.

You can do a lot with pre-made behaviors, even if they're not always enough to make a complete game. But have a good attitude about them. At the start, keep the scope of your projects small and make learning a priority.

Making the transition from beginner to intermediate: Learn to write re-usable code. Don't cram all your code into the actor's events; write behaviors that can be used across multiple actors and scenes. Better yet, write behaviors that you can also import into your other games.

Learn how the kit behaviors work--even the complicated ones. Unless you plan to start your game from scratch (as in using no engine at all), you need to learn to dissect other people's code. Everyone has their own approach to things. When you're able to interpret other people's code, the kit and pre-made behaviors become a lot more useful--because you'll be able to modify them when needed to suit your specific needs.

Extensions: Learn how to use the extensions that are available and how to write your own.

Math: Algebra and trigonometry are very useful across multiple types of games. Most people learn these in high school, so if you've graduated make sure you're on top of them. If you are still in high school then take these subjects seriously.

Making the transition from intermediate to advanced: You need to learn how to analyze algorithms. How do you measure timing and storage requirements? Learn what 'Big O' notation is. Learn how to write efficient code. This will save you unnecessary worry about whether your code will lag, and help you write complex code that still runs at 60FPS.

A large, complex program can be thought of several smaller programs working together. Even as a beginner working on a first, small project this is true: you're letting the Stencyl engine do almost everything and only a small bit of the code is yours to worry about. Working on a larger-scale project puts more code as your responsibility and less as Stencyl's. It only takes one poorly designed procedure to bog down the entire system, so knowing how to analyze code for efficiency is a must.

Learn to use a debugger and analysis tool (like hxScout).

Learn how the Stencyl engine works and how to modify it.

Math: Vector algebra and linear algebra are a must if you want to do advanced work in graphics or physics. Discrete math is a must if you want to build complex AI for your game. Calculus is a must if you want to write a physics engine that models motion and gravity like Box2D does (or understand how Box2D works and how it is limited).

- Don't only save  _Export_ your game often to save it.

- I'm not sure you need to code to use Stencyl well , depends on what you need. Liberado seems to do great things with blocks.
- If you want to understand well the different blocks.. View the source code in stencyl with the right click. And look for the code for the function in https://github.com/Stencyl/stencyl-engine/tree/master.

Super great advice!

On very small thought: Try to emulate your performance at start. Will you need a lot actors? Will you need a lot scrolling backgrounds? Just put in the amount of placeholders you might need and see how it performs. Nothing worse then building a game and figuring out that it becomes too slow...

Cheers!

Here are some tips which caused me problems in the past.
- Box2d: Collisions only detect the edges of tiles(same goes for actor sensors, it only detects edges).

- On Mobile: Drawing on anchored actors won't be anchored, unless using "screen space" and "moving pen to x/y of self."

- Simple Physics: Setting origin point other than "center" will make actors not stimulate correctly(Unless always active).

- Never set sound volume in "always", it will glitch and cause other sounds not to play. Only do this if you have an attribute to check when it's done and not needed anymore.

I know I started this page, but ere is a trick I have been using to make The Poppytales (link below) that can save a lot of storage space.

In The Poppytales, there is a pause menu that is a different scene from the overworld. In the code, I have a text attribute that is set to the current scene's name before the transition occurs.

Switching to "scene with name <Text Attribute>" is not only helpful for returning from a pause menu back to an overworld/battle in an RPG or <Insert game genre here>, but when using doors, this can be useful.

When creating a scene, set the text attribute to the next scene/level's name when the current scene is created, and setting a collision for a door or region to "scene with name <Text Attribute>" can save a lot of time when making a game and it means you get to use much less code than if you were doing otherwise.

Btw, thanks everyone for posting in this forum page* (I don't know the proper terminology)! I hope that people other than just me can read this and get some useful information other than from Stencylpedia or the Blocks Guide.

Happy "Stencyling*"

*What is the proper terminology for this?

Avoid some of the more resourse intensive physics options when ever possible, for example don't use "Continuous Collisions" unless you have to.  Also the "Simple Physics" option is your friend, experiment with it and see what still works when it's used.

Another tip from me is for beginners, because I have made this mistake many times. Know the difference between attributes and game attributes. For those who don't know, attributes are temporary statistics that only exist when an actor type, scene etc. exists. Game attributes stay around for the entire game, and can be used at any time.

When creating an attribute/game attribute, think of how long you need this attribute to exist. If it's something that's going to be in one scene or only when an actor is around, use an attribute. If you need something like a text attribute that saves your current scene's name as text that will be needed for saving and loading, use a game attribute.

Also, saving and loading only works for game attributes, and don't forget when loading a save file to switch to the scene with the name of the location game attribute.

I just found out something that I was worried was going to make one of my games glitchy: collisions stopped working properly. This has happened in some of my games, and I've had to leave them like that and find some possible explanation for why this happens other than a Stencyl glitch.

In the physics tab, sometimes when the "Cannot be Pushed" option is selected, collisions stop working. Enabling debug draw the collision shapes exist but don't work.

A lot of the games I make rely on collisions, as you can see in Poppytail, where for the player it can be the difference between not only beating or losing a level, but changing what secrets the player can find.

So, if this has happened to you, you may have to find an alternative method for whatever you're doing.

This really confused me and I hope that this post helps some other people who have no idea what they're doing half of the time.

One of the colliding objects must always be set to "normal" to register a collision.

One of the colliding objects must always be set to "normal" to register a collision.

Thank you

few tips from me too
-   very and very usefull block is - set actor value to XX / get actor value XX
you can set app properties and get it fast anytime from any place in the game
Sometimes it is much better than normal attributes, because with normal attributes you always got to refer to the exact behavior and actor got to have this behavior and attributes in this behavior got to be initialized, a lot of trouble if shortly
-    use text values in the list attributes instead  of number, because number values sometimes makes errors.
But when you are using this attributes for math or compare actions you got to use it as number (block - converter in the number section)
-    make long and complex lists in the text files, than place it incide list attribute.
for games like RPGs, for characters and items properties, make table in word than save it as .csv format with commas as separators, than you can easy to separate values in stencyl by comma
-    when make FXes like emitters, don't create and kill particles, better to create needed number of particles, place it it inside list, than use this list to  reuse this particle actors, it will save you a lot FPS.
example.
repeat --- times
create actor at x of self y of self
add last created actor to list
do every --- sec
for each item in list
set x of item to x of self
set y of item to y of self
-  MAKE BACKUP OF THE GAME NOT LESS THAN 1 TIME IN A WEEK
BETTER EVERYDAY OR BEFORE ANY BIG AND RISKY CHANGES  (like attribute, behavior, actor deleting)

-  MAKE BACKUP OF THE GAME NOT LESS THAN 1 TIME IN A WEEK
BETTER EVERYDAY OR BEFORE ANY BIG AND RISKY CHANGES  (like attribute, behavior, actor deleting)

If you have something like Carbonite it would be a good idea to save files as .STENCYL files (since Carbonite doesn't back up .EXEs). If you didn't know, it automatically recovers nearly all files on your computer that you can later access, so I'd recommend this in case something happens.

For example, while making PT2 all of my tilesets and actor types disappeared. Luckily I had a back-up, but lost a session of progress, making the game unplayable. This is why making back-ups is important. You never know when an accident may happen.

DO NOT MAKE THE SAME MISTAKE AS ME OR WORSE!