Basic game concepts like collisions, physics, and inputs are already built in to Stencyl. Once a sprite, called an "actor" or tileset is created, it's not hard to give them physical properties, including friction. You can then define behaviors for actors to make them actually do things. Stencyl also allows you to build levels, called "scenes", and place your actors or elements from a tileset. Scenes can also have behaviors, for those things that don't really belong on an actor. You can have as many scenes as you want, and then setup transitions between them using code.
Building a Scene. Actors to be added are shown on the right.
You can easily bring in your own sounds and artwork into Stencyl to make your own unique game. Stencyl will handle evenly spaced sprite sheets, or individual animation frames. Each actor can have multiple animations, each consisting of multiple frames, and then you can switch between then with code. Audio is also fairly easy to import. In both cases, you'll want to use an external image or audio editor to create/edit images and sounds.
Setting up animations for an Actor. We can add frames to each animation, and all the animations for that actor are shown on the left.
Coding is done using drag-n-drop, snap-together blocks, similar to Scratch. (It was, in fact, inspired by Scratch.) All coding is done in "behaviors", which are each triggered by an "event". Behaviors can be shared between actors, and even exported and brought into new projects so you don't have to write things from scratch every time. There are some pre-built behavior, as well as behaviors that have been shared by other Stencyl users. StencylForge allows for the sharing of behaviors, actors, and even complete games.
Coding a Behavior. Each Behavior can have multiple Events, seen on the left. Blocks are on the right.
The ability to export and import behaviors and actors is incredibly useful for collaborative projects. Many of the "easy" programming/game making tools out there don't seem to have thought about collaboration, and are very difficult for students to use in groups. There are still some challenges to using Stencyl collaboratively, but if students do a bit of planning ahead they won't have to rewrite everything to get it into one project.
All the Actors in this game. You can export an Actor using the button on the lower right. (Similar for Behaviors.)
Stencyl does provide learning resources through the Stencylpedia, although I'll admit I haven't used them much. (The weren't really around when I started teaching Stencyl a few years back.) This is really important, as Stencyl does have a bit of a learning curve. Unlike Scratch, you probably aren't going to be able to slap some blocks together and make something work. There are a LOT of blocks, and a lot of ways to put blocks together that don't do anything useful. Stencyl provides you with a lot of flexibility and power, and the cost of that is complexity.
This may raise the question of why Stencyl is better than text-based coding. Of course, whether it is or not depends a lot on what you're trying to do with it, but it still gives you a lot over text coding. The drag-n-drop coding makes syntax errors almost impossible, meaning your code will usually run, even if it doesn't do what you expect. You also have a lot of built in functionality, like collision detection, physics, drawing animations, etc, that you would need to write yourself, or use a library, in a text language. A good game library may give you some of what Stencyl does for you, but it probably won't do it all for you.
All in all, I like Stencyl because it's cross-platform compatible, powerful, exports to an easily sharable format, is free, and allows you to use your own art/audio. Of all the game making tools I've tried, Stencyl has the best tools for collaborative projects, although it still could be better. The one downside is it's complexity and learning curve, but that's the tradeoff you have to make for power and flexibility.
No comments:
Post a Comment