What kind of technical limits does Stencyl have?

gamegirlxl

  • Posts: 716
Stencyl is based off of Flixel...which is why they don't let you do vectors (except maybe for shape drawing), if that's what you mean by "swf animations".

I don't know if there is a way to bypass this in Stencyl, so it's a limitation imposed by Flixel.  It also means that you can't use 3D images.


It would be possible to load images off the internet to reduce file size at the expense of loading time, which I see in several ios games.  I'm not sure how you'd do that in Stencyl.

Innes

  • *
  • Posts: 1963
Stencyl 2.2 is based on Flixel, but Stencyl 3.0, which is based on OpenFL, is so close to release that I would not recommend basing any development decisions on the current version (2.2).
Visit www.TheStencylBook.com - the only published book for learning Stencyl.

gamegirlxl

  • Posts: 716
Stencyl 2.2 is based on Flixel, but Stencyl 3.0, which is based on OpenFL, is so close to release that I would not recommend basing any development decisions on the current version (2.2).

:D
Is it out?  The website, in addition to all the other changes says 3.0 has soft-launched or whatever.

twotimingpete

  • *
  • Posts: 1667
It's definitely possible to make a big game in stencyl. just depends on what you want to do and how much you learn the best way to do things in the program.

I made a pretty good portion of my metroid-style game using stencyl, and then successfully kickstarted it with the purpose of making a higher res game using Unity. All the game footage you see in the project listing there is from stencyl.

for my part, I'm not really interested in flash development or mobile development, my main purpose is always to either make a big game or make a prototype for a big game. I'm still playing around with Stencyl to come up with ideas and so on, and in particular I've been testing the stand alone export using 3.0 with open FL. I have to say that what I'm finding so far is very promising, you can make a higher res game than you'd normally make in flash and have it run very smoothly.

« Last Edit: February 21, 2014, 05:56:09 am by twotimingpete »

gamegirlxl

  • Posts: 716
...I made a pretty good portion of my metroid-style game using stencyl...

This game is the main reason I believe that 3.0 is more efficient than previous versions, although I'm still not how it's being optimized.

Unfortunately, the code for larger games gets very large and ugly quickly, especially considering the fact that few people bother to use functions.  Functions are awkward in Stencyl, anyways.

If you want to see a bunch of other limitations Stencyl has, look at the suggestions forum.

dripple

  • Posts: 748
Honestly, how big or limited the game will get is not only related to the tool you use, it's mostly limited by your own skills and imagination

Look a the 80s and 90s, we made great games, big games, spawned 100s of sprites (but technically we had only 8 or 16 available) on machines with 1 Mhz!  We created 3D WireFrame space trader games with thousands(!) of planets in only 48 KB (Elite on the C64).  Later we created platform games (think of the great Splinter Cell-Series) on Nokia S40 Mobiles , the 50KB application offered 150 levels of game play on this 110MHz mobile phone running Java! And think of Prince of Persia... Amazing animations over all devices, and about 90kb in size!

This is not comparable to modern days, but this is still true for the most games we intend to build with Stencyl.

(F**k,  I am feeling old now :) )
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

gamegirlxl

  • Posts: 716
Honestly, how big or limited the game will get is not only related to the tool you use, it's mostly limited by your own skills and imagination

Look a the 80s and 90s, we made great games, big games, spawned 100s of sprites (but technically we had only 8 or 16 available) on machines with 1 Mhz!  We created 3D WireFrame space trader games with thousands(!) of planets in only 48 KB (Elite on the C64).  Later we created platform games (think of the great Splinter Cell-Series) on Nokia S40 Mobiles , the 50KB application offered 150 levels of game play on this 110MHz mobile phone running Java! And think of Prince of Persia... Amazing animations over all devices, and about 90kb in size!

I've never played any of those games, but I realize how wasteful modern technology (although I'm pretty sure we still use those archaic C languages) lets us be.  I remember reading how economically they had to plan out Pitfall (or whatever that Atari game was) to keep down its size, because I read it in a magazine.  I think that Stencyl encourages wastefulness somewhat because when you just want to render an image on the screen, you have to have an actor and all that stuff.

I often think that many of today's games (excluding the graphical side, maybe) don't need the great specs that you find on today's systems.  While these specs allow devs to work harder and create more complex games, they also allow devs to not work as hard because there's room for bad programming.

I can't stand when I see people abusing the "Always", or when I see "if var=true...otherwise if var=false".   There are a lot of disappointing coding (not just in Stencyl, but also with people who should know better) happening despite all the progress the systems made.

SadiQ

  • Posts: 1778
@gamegirlxl: You have to consider the fact that players expect the game to be playable, and if that happens they will never complain. So if bad code gets the developer further into finishing a game then no player will ever care.
Optimizing code is usually the last thing the developer should care when creating behaviors, and if badly coded behaviors don't lead to frame drops they will usually remain as they are.
Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.

gamegirlxl

  • Posts: 716
@gamegirlxl: You have to consider the fact that players expect the game to be playable, and if that happens they will never complain. So if bad code gets the developer further into finishing a game then no player will ever care.
Optimizing code is usually the last thing the developer should care when creating behaviors, and if badly coded behaviors don't lead to frame drops they will usually remain as they are.

Unfortunately, the same carelessness that you see in poorly optimized code often affects the actual game, especially when the devs are coincidentally as careless with the rest of their game.

Bad coding doesn't only affect the frame-rate.  It affects the loading time to various degrees, especially when you happen to be loading from a server.  If you were making a real time multiplayer thing, poor coding like that might be fatal.

dripple

  • Posts: 748
Sorry, I have to drop in here.
The general rule of thumb with software development (and that's game dev, too) is
"Make the right things first, then make the things right"

Means: first deliver something the end-user (player) will accept. Then you can start to optimize. I do know so many devs who tend to optimize every bit during development that they never finish their work.

 Don't get me wrong, I do not vote for poor coding, but what I want to say: the best performing game doesn't count if the player doesn't like it.
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

Hectate

  • *
  • Posts: 4643
Premature optimization is the root of all evil.

But I take a slightly different tack; "If you fail to plan, you plan to fail." (Ben Franklin, supposedly).
Basically, I think through how my behavior will interact with other behaviors (even if they do not exist yet) and structure my design around that. From that point forward, if it works it stays - until it no longer works (when design changes, so do the needs).
:
:
Patience is a Virtue,
But Haste is my Life.
Proud member of the League of Idiotic Stencylers; doing things in Stencyl that probably shouldn't be done.

gamegirlxl

  • Posts: 716
Premature optimization is the root of all evil.

But I take a slightly different tack; "If you fail to plan, you plan to fail." (Ben Franklin, supposedly).
Basically, I think through how my behavior will interact with other behaviors (even if they do not exist yet) and structure my design around that. From that point forward, if it works it stays - until it no longer works (when design changes, so do the needs).

Clearly that book was written by someone who hadn't heard of Flappy Bird...

But I do try to account for things that I want in the future when I write code.  Which can easily clutter up code, unless you realize that a function of your own making would eliminate the need for many of the repetitious parts, and shorten it down.

That guy said that you need to think in different levels of abstraction.  And I feel that I'm very good with this with all the levels until you get so small that you're at the mercy of the computer.  Computers have little quirks like floating point errors and memory issues that can cause issues on a larger scale, so I'd really like to learn more about how to work with computers at more basic and abstract levels.

I'm pretty manipulative and coercive (damn C++ wont let me change data types), so that might explain why I feel the need to learn about these things.  It also might further my agenda to move to software programming.  Because you can make computers do even more things when you make software.

dripple

  • Posts: 748
My favorite cite is:
Only a lazy programmer is a good programmer.  :-)
Sure, my games won't get better with all the new features of Stencyl.
But I do have more fun creating bad ones.


MayazCastle Keeper

SadiQ

  • Posts: 1778
My favorite cite is:
Only a lazy programmer is a good programmer.  :-)

That's a good one:)
Bill Gates said  “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it".
That's a good programming advice for anyone starting to make a game :)
Proud member of the League of Idiotic Stencylers! Doing things in Stencyl that probably shouldn't be done.