Stencyl 3.4.0 is now out. Get it now!

Useful Tips

NickamonPoppytail

  • *
  • Posts: 325
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.

SadiQ

  • Posts: 1724
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.
Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.

merrak

  • *
  • Posts: 1604
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).

« Last Edit: October 21, 2017, 08:39:52 am by merrak »

yoplalala

  • *
  • Posts: 1412
- 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.


Bombini

  • Posts: 830
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!

Raiyumi

  • *
  • Posts: 193
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.

« Last Edit: October 23, 2017, 11:16:12 pm by Raiyumi »

NickamonPoppytail

  • *
  • Posts: 325
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?

ozz

  • Posts: 450
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.

NickamonPoppytail

  • *
  • Posts: 325
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.