The new Stencylpedia is ready!

Thanks, I've corrected it not to say that. I generally don't like to provide instructions on how to use third party sites because that can change. When  I can, I try to link to their documentation instead or at worst, just point to the location in question.

I've been trying to learn Stencyl for some time, now.  It is not a straightforward process. 

Stencyl is extremely linear by design - meaning that nothing can be done correctly unless each step is followed in order and verbatim, per design standards that are built into the application.

Learn from the tutorials:  Problem:  Tutorials are all written with regard to the 1. versions.  Many things - important things have completely changed - especially the names of things and the order in which things must be performed - making the learning experience frustrating and more than a challenge.

Learn from Stencylpedia:  At this point, the best option - but there is no method whereby a completely new and unfamiliar user can "start from scratch", using basic principles.

I challenge any new, (non-programming) user to try to achieve the following basic functions:

1)  Place 2 actors in a blank scene, both responding to physics - one being stationary and one made to fall from a height - just to see how the 2 objects react.

2)  Place one actor in a blank scene in several different stationary locations, each location displaying a different animation for that same actor.

3)  Place an actor in a scene and assign a basic "platform" behavior to that actor(player) - just to see how that player behaves.

4)  After a player has successfully been added to a scene with appropriate "platform" controls, add a simple behavior that causes the camera to follow the actor, making the scene "scroll" as it does so.

All 4 of these exercises should be "no-brainers" - but, as new users will see and have seen, this is not the case.  No basic examples or tutorials exist that apply to version 2.0.

Reading the Stecylpedia thoroughly, I see snippets of "code" which should work, but no step-by-step, (from the very beginning), examples of actually doing this "from scratch" - as should be the case with any application seeking to establish a broad-based audience.

Now you can tell me that I am, indeed, stupid.


Psmith

these all seem to be things that can be done by following the tutorials for v1 honestly. Im not sure where the problem lies.

Scenario 1) Those two actors can do this by checking the appropriate boxes in the physics section of the actor tabs

Scenario 2) Creating a behavior to change the actors animation depending on the  X and Y of the actor, which would  set using actor attributes in design mode

Scenario 3) there are MANY simple platform behaviors on stencylforge. A simple platform behavior can be made in under 20 minutes using no code. Design mode is your friend. Create a boolean attribute or two to handle the actor jumping/falling and one to determine wether or not the actor is touching the ground. Make sure you enable gravity for your scene.

Scenario 4) Make a scene behavior that tells the camera to follow an actor. The coloured blocks in design mode are your friend. I have zero coding knowledge...Im a pixel artist. Its just a matter of using simple logic, and a bit of trial and error.

I think you may have overlooked the Physics tab in both actors and scenes. If all else fails, just download a similar behavior from the forge, and look at it in design mode. That will give you an idea.




Good luck!

A lot of game development is problem solving, and there isn't going to be a tutorial for everything.  They take time to make, especially the video and interactive tutorials.  The new Stencylpedia has much more information than before, and even the old tutorials can be useful.

Gemini:

I'd be more inclined to accept your word if you would simply try this, (and then document your procedure, step by step):

1)  Create a cube for the "Player", assigning the physics properties to make it responsive to gravity.
2)  Create a rectangle for the "Ground Plane", assigning the properties to make it a platform (not movable).
3)  Test the Scene.

This should work, without a hitch, checking and unchecking a few "Physics" boxes, appropriately.


Thank you,

Psmith

A challenge for Chapter 4 has been added. The challenge is to make a Zelda-style dungeon.

http://www.stencyl.com/help/view/chapter-4-challenge/

I've been trying to learn Stencyl for some time, now.  It is not a straightforward process. 

Stencyl is extremely linear by design - meaning that nothing can be done correctly unless each step is followed in order and verbatim, per design standards that are built into the application.

Learn from the tutorials:  Problem:  Tutorials are all written with regard to the 1. versions.  Many things - important things have completely changed - especially the names of things and the order in which things must be performed - making the learning experience frustrating and more than a challenge.

Learn from Stencylpedia:  At this point, the best option - but there is no method whereby a completely new and unfamiliar user can "start from scratch", using basic principles.

I challenge any new, (non-programming) user to try to achieve the following basic functions:

1)  Place 2 actors in a blank scene, both responding to physics - one being stationary and one made to fall from a height - just to see how the 2 objects react.

2)  Place one actor in a blank scene in several different stationary locations, each location displaying a different animation for that same actor.

3)  Place an actor in a scene and assign a basic "platform" behavior to that actor(player) - just to see how that player behaves.

4)  After a player has successfully been added to a scene with appropriate "platform" controls, add a simple behavior that causes the camera to follow the actor, making the scene "scroll" as it does so.

All 4 of these exercises should be "no-brainers" - but, as new users will see and have seen, this is not the case.  No basic examples or tutorials exist that apply to version 2.0.

Reading the Stecylpedia thoroughly, I see snippets of "code" which should work, but no step-by-step, (from the very beginning), examples of actually doing this "from scratch" - as should be the case with any application seeking to establish a broad-based audience.

Now you can tell me that I am, indeed, stupid.


Psmith

With the exception of the (online) Crash Course (and some of the Appendix info), which were adapted from the old Stencylpedia, can you specifically point out what content (on the new, online Stencylpedia) is 1.x specific?

Having written about 80% of all of the new content myself, I can attest that I was in fact using and targeting 2.0 for everything, almost to a fault (where the instructions won't work at all on 1.0 because something moved or simply doesn't exist in the old version). In fact, in the Crash Course itself, I say this at the very bottom of page 1 in the comments.

We've reformulated the Crash Course for Stencyl 2.0. If you're using 1.4.1 and below, continue to use the one we provide inside the app itself.

I have asked, and I will ask my team again to go over the Crash Course with 2.0 to ensure that, to the very letter, the Crash Course can be completed and understood with 2.0.

As for Code Snippets, the intent of Stencylpedia is for you run through it from top to bottom. By the time you see a code snippet in Chapter 3 or 4, the mechanics of picking out a block should be assumed (taught in Chapter 2), and the only thing you need to know is the key concepts behind the example.

I'd be more inclined to accept your word if you would simply try this, (and then document your procedure, step by step):

Is StencylWorks easy to use? No... not for me anyway... I've been using the software for months and I still don't have a decent game to show for it.

However, I'm not seeing the problem in creating your example. I attached "Block Test.swf" to this post. Here's a step-by-step to recreate it. (I'm using version 2.0)

• Create a scene - I decided to get a little fancy and add a vertical blend.
• Gravity is added with the physics window - 20 vertical down. (85 seemed a bit too much)
• Create the square actor
• I created a white box png file in Pixelmator and dragged it into the actor as a new frame.
• Create the ground actor
• I created a white rectangle and dragged it into the ground actor as a new frame
• Turn off movement with the physics window.
• Go back to the scene. Place the actors on the scene
• Test in Flash

To get fancy, I added a mouse-click event on the scene. Click resets the scene.

Sure, there's room for critique. The physics is kinda bad. The square on the left doesn't fall off while the squares on the right bounce unrealistically. However, I think this shouldn't be too hard for a beginner to get.

The idea for the textbook I've been working on is a linear explanation of StencylWorks. If the software was easier to use, I would be further along on the project. A lot of things don't work like I'd expect them to. But with the dropping of a box, it kinda worked like I expected — not counting the weird physics... and I tried to get fancy with custom polygons instead of using .png images.

I think most people think visually and learn visually.  Thus, the tutorials targeted at ver. 1. fulfill this need for that version.

What the Stencylpedia tries to do is explain things textually, with a small supplement of visuals to clarify the textual points.  Though the Stencylpedia covers version 2.0 - it does not do so in a step-by-step fashion, as is needed by those who have no background in game making, nor in working with Stencyl, directly.

I want to learn by first understanding basic principles, not by reverse engineering a pre-existing game or to be given incomplete Stencyl code snippets - and figure the rest out by trial and error.

You do realize that Stencyl is incredibly linear in its game-making requirements?  Since this is so, the only way to learn is step-by-step and point by point - lest some point be forgotten and left out.  Even one small step, left out of the procedure can cause an example not to work.  Stencyl is unforgiving in this respect.

What is needed is a logical presentation of very small things - Baby Steps - if you will forgive the cliche.  Just as I have outlined, above.  There is no reason a user should be forced to memorize the location and usage of every behavior component before he is able to construct basic game functions.

Now, I've tried using the obvious to make basic things happen, and this simply does not work with the Stencyl paradigm of game making.  One must be precise, at all times, or things do not work.

There is rarely an explanation of Why in the code snippets that are presented in the Stencylpedia.  Nor is there a statement of When (order of applying), and, because the step-by-step process is not present, there is also absent the "How", in its complete form.  Issuing a "Challenge" at the end of an incomplete demonstration of principle only makes the user less likely to understand.

If a step-by-step approach is not taken - using extremely simple game component functions - users will be left in the dark, and probably remain silent - for fear of being thought idiotic.

In the "Ask a Question" section of the forum, I have also noticed that, not only do my questions fail to be answered, but many, many questions fail to be answered - adding to the intimidation factor of asking at all.  People must assume that their questions are incredibly stupid, since nobody is forthcoming with an answer of any kind.

Psmith

There is no reason a user should be forced to memorize the location and usage of every behavior component before he is able to construct basic game functions.

And we don't expect that and never have. 2.0 addresses this in big part by eliminating this memorization by providing several alternate ways to pick out blocks. The search block feature has always been an alternate way to locate blocks.

When referring to where blocks are, we always tell you in a standard notation of CATEGORY > SUBPAGE. It shouldn't be hard to locate a block once you're down to the subpage level.

Any further detail would impede the flow of an article and put the visual at risk of going out of date when things inevitably move around. I believe way more in imparting mastery of the basics, from which we can be briefer in the future when telling you how to discover something.

I want to learn by first understanding basic principles, not by reverse engineering a pre-existing game or to be given incomplete Stencyl code snippets - and figure the rest out by trial and error.

That's exactly what I intend and have intended all along.

Can you provide a specific example (outside the Crash Course)? To you, what is the difference between complete and incomplete? An overly "complete" demonstration can detract from the very principles being portrayed.

That said, if I'm stepping through an example, I'm naturally going to focus on the part that's at hand. A regions article will focus on regions and nothing else.

In the "Ask a Question" section of the forum, I have also noticed that, not only do my questions fail to be answered, but many, many questions fail to be answered - adding to the intimidation factor of asking at all.  People must assume that their questions are incredibly stupid, since nobody is forthcoming with an answer of any kind.

Support is provided by the community, for the community. We're on this part-time, and we only step in on the harder questions that the community is unable to pick up.

If I spent my time answering questions in the few hours I have after work, Stencyl would grind to a halt, not progress at all and die.

Few questions are stupid, and the fact that they're not answered is a function of who's watching, within the volunteers group or the broader community. This is common to every community I've participated in - there's nothing wrong with questions except in drastic cases.

Today's a particularly bad day because it's an international holiday (Easter), and it would be unfair to assess the quality of community support provided based on that. I'm peeking at prior days, though and I'm not seeing as many 0 reply topics as is implied, perhaps a 5-10% unanswered ratio by my eye.

Thanks, I've corrected it not to say that. I generally don't like to provide instructions on how to use third party sites because that can change. When  I can, I try to link to their documentation instead or at worst, just point to the location in question.

Thanks for adding a link instead. Although you guys are not mochi, do I need to fill out any personal info in order to recieve payment? I'd not like to do this since I don't think I know most of the stuff.

I'm pretty sure you do otherwise they wouldn't know where to send the money.

@psmith - Now, separate from all of that, I drafted up an outline to something you may find useful, a second crash course that's very different in its goals and approach from the first one.

Crash courses are expensive to build, something along the order of 20-30 hours minimum between writing, snapping screenshots, editing and testing, and they also get hit the hardest when things change, and then people complain about it. That's why I've been shy to ask for another one.

But it may not hurt to have a second one that, in your same words, takes things from absolute scratch and explains the key concepts along the way and even forces you to make a mistake or two to make a point.

---

Intro - Say what we're making - Space Invaders

Part 1: Start the Game
- Create game from blank

Part 2: Import the Assets
- Import Ship
- Import Bullet
- Import Enemy (this has multi-frames)
- Drag Import the 2 sounds
- Import the Background

Part 3: Set up the Scene
- Create It
(Test)
- Place Actors
(Test)
- Set Background
(Test)
- Loop Music
(Test)

Part 4: Make the Ship (2 way motion)
- Attach an "always" event, explain the logic behind 2 way motion, then tell them exactly how to do one, make them build the other direction.
- Now go over bounds restriction.
- All through this, test, test, test.

Part 5: The Bullets (fire bullets)
- Build the fire cannon behavior. I think that's it for this...
Remember to start naively before you make it "better"

Part 6: The Enemies (get hurt, play sound, die)
- When enemy collides with bullet, play sound, decrement health, die. Mention attributes.
- Lead them on and then say why isn't it colliding? Segue into groups and have them set it up.

Part 7: Winning
- Detecting victory
- Showing you win (how to draw text)

Part 8: Final Touches
- Export as SWF
- Next Steps

Part 9: Challenges
- Make the enemies move.
- Restrict the cannon to X bullets at a time on screen.
- Make the enemies blink when hit.

I'm pretty sure you do otherwise they wouldn't know where to send the money.

Same as with Kongregate. I do not have a credit card so I can't get a paypal account, so I just have them withhold the mooooonies.

When you create crash courses, it would be good to not introduce stencylforge until the end, so that all through the tutorial it would introduce them to tools to create their own art/wounds/whateverelse.

Jon:

As an absolutely new user and a non-programming designer, I want to learn things - one little thing at a time.

Once understood, I would like to add "behaviors" to that little thing, to make it more and more accomplished.

After making my little thing, (an actor/player), do interesting things, I would like to learn how to make him react with:

1)  His surroundings
2)  Other entities that move
3)  Involve my player in interesting action/reaction behaviors.
4)  Make his "decisions" result in consequences.

These things, I believe, are at the heart of every game - and should be learned - one little thing at a time.

Thus, given the very linear nature of Stencyl, I would like to see, in order:

1)  Many examples of how my player can react with his surroundings, step-by-step.
2)  Many examples of how my player can react with other game entities that move, step-by-step.
3)  Many examples of the kinds of reactions my player can have to other things, such as:

   a)  collision reactions
   b)  animation reactions
   c)  physics reactions

Step-by-Step, leaving no clicking "order of things" left out or assumed.

Do this, and I think you will have a workable teaching method that can lead the broadest audience to the adaptation of Stencyl as their game-making choice.

Note:  If we assume that the future of successful, marketable games lies in the hands of "gamers", we seriously underestimate the future of gaming success.

Thanks,

Psmith