Over the past few months, I've noticed three important camera-related features that Stencyl is lacking. Some of these are more common than others, but all three combined would put Stencyl further ahead of some of the other game-making software.
0. BasicsI know I said there were only three things in this list, but before anything else here is implemented, I believe that these minor things should be changed first.
- Actors that are anchored to the screen (on the GUI layer) still have their drawing events run on their original layer. This makes anchoring actors to the screen useless if, i.e., a button needs text, unless it has the text pre-drawn onto it.
- All of the scene drawing, including the GUI actors, will need to be run AFTER the features listed below are applied. Otherwise, we'd have zoomed-out, rotated text/shapes drawn inconsistently across multiple cameras.
Now, onto the good stuff.
1. ZoomingZooming is a somewhat common feature in game engines, and can often be simulated in those that don't have it with pure code, including Stencyl. However, the workaround scales
everything, including the text and shapes that are drawn on the screen, which is not helpful when trying to create GUI.
My geeky idea: Render a larger section of the screen, then scale it down (using the Image API or similar) to the screen size.
2. RotationLike zooming, rotation is a feature that is somewhat common in game engines, and can be simulated in those that don't have it. For Stencyl, there are two workarounds that I'm aware of:
1. Rotate the entire Sprite object that makes up the screen, or rotate the image using the Image API. The problem with this is that the space outside of the rendered area is an ugly black, which does not fit in well with most games.
2. Make the screen size larger than needed, then use the Image API to rotate it and crop it down. However, another (usually black) shape will need to be drawn around the border to hide the remaining parts. I have not personally tried this method, but from the split-screen experimentation that fillergames, letmethink, and I have been doing recently (more on that later), it seems like it could work.
However, neither of these are going to be satisfactory if a sponsor buys the game, whether the problem is the ugly black triangles or the extra-large black border. So it would be nice if a proper way to do this was integrated into Stencyl.
My geeky idea: Render a larger section of the screen, then rotate it and grab a rectangle out of the center (using the Image API or similar).
3. Split-screenNow
this feature I didn't even remotely think was possible with a workaround. That is, until
fillergames proved me wrong. letmethink and I worked out a solution so that it doesn't flicker, but it still only works at ~30 FPS. So, it is somewhat possible as a workaround, but not good enough to run smoothly.
Thus, it would be truly awesome if this could be directly integrated into Stencyl. I know, I know, it would be a ton of work, but in my eyes, it would be worth it. Here's my detailed explanation of how it could be implemented:
There would be 5 split-screen modes:
1.
Single-screen - the default mode; only one camera
2.
Horizontal - the screen is split horizontally into two equal sections
3.
Vertical - the screen is split vertically into two equal sections
4.
Variable - the screen is split into two sections; the angle of the line between them can be changed
5.
4-way - the screen is split both horizontally and vertically into four equal sections (for 3-player, the fourth screen could manually be set to be black, or show highlights of the players, like Mario Kart Wii)
There would then be blocks to switch between the different modes, determine which mode it's in (a boolean block would probably work best), get/set the angle in Variable mode, and change the size/color/opacity of the inside borders. All of the existing camera blocks would need to be updated to include a 1st/2nd/3rd/4th camera dropdown, so it may work out best if there were a button in the palette which activated the split-screen blocks.
________________________________________________________________________________________________________________
It may be better if we were able to simply
grab a section of the scene as an image, no matter where it is or how large. (Everything in that image would need to be simulated as if it were on-screen.) Then
all three of these features could be done manually by the user, and behaviors could be shared to Stencylforge to accomplish them. Now that I think about it, this actually opens up a whole new range of possibilities. Along with the aforementioned features, there could be in-game security cameras and similar mechanics.
Finally, it would be great if we could have a set of
camera tweening blocks. At the moment, this would only be one block, to tween the camera to a set x/y location. This can be done without modifying the core code; I got it working in an extension by tweening x/y variables, then repeatedly setting the camera position to those variables.
Thanks for taking the time to read this really long post. I hope that these suggestions are helpful for the future of Stencyl.
Show Posts
