Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Fool

Pages: 1 2 3 ... 6
"I think origin point only applies to rotating in-game."

Ah, I see. Wasn't aware. Makes it difficult to determine exactly where I need to place my actor in the scene, relative to it's rotation, so that it ends up at the correct position after rotating during gameplay.

You know if rotating based on custom origin point in the scene editor is planned or roadmapped?

From what I can see thats the case. Sprite origin is set to bottom right for the given actor (I'm having a character 'swing' onto the screen) and when I try to manually set the angle in the inspector panel (and likewise rotate the actor by hand) it simply rotates around the center instead of around the bottom right origin.

What am I doing incorrectly, if anything?

Chit-Chat / Re: Where I've been, and What I've done.
« on: November 19, 2018, 10:50:04 pm »
Hey, glad to see another developer join the Stencyl bandwagon.

They're very much different tools and you can accomplish similar results in both if you're comfortable with code.

Ask a Question / Re: 1 light ok, 4 light = game crash
« on: November 11, 2018, 12:37:02 pm »
Have you considered using transparent masks? This is how I did cheap lighting in my game.

What you do is

1. Create a layer in the scene editor, call it 'lighting' above everything except the ui layer

2. Set the layer background color to some default color, like black. This represents darkness

3. Create a circular sprite, the outer edges that are 'dark', are the same color as the background color for the light layer.
    The 'light' portion is a partially or fully transparent circle in the middle of the sprite

4. Assign the new sprite to your light objects

5. Spawn or place your light objects on the light layer.

I forget which, but be sure to set blending mode (on the layer, or sprite, eh), to either 'add' or 'multiply'.

Might take a little experimentation, but this is what worked for me when I had a lot of lights at once.

In this regard it is more akin to 'fog of war', and in fact, you should be able to do the same thing FOR fog of war.

Chit-Chat / Re: Where I've been, and What I've done.
« on: November 10, 2018, 02:18:27 pm »
Holy hell, your book "Ember In The Wind", is in my reading list.

You're the author?

Chit-Chat / Re: Openfl (and Stencyl) now supports Nintendo Switch.
« on: November 10, 2018, 12:38:30 pm »
This may be Stencyl's first console export, but it's perfectly timed, and it's exactly what is needed.

Pushed me to readopt Stencyl, and move away from the torture device known as GM.

Export options sell.

Chit-Chat / Re: Where I've been, and What I've done.
« on: November 10, 2018, 12:27:30 pm »
Thanks merrak and irock.

I think for me, at the time, dropping from visual editor down into code was a no-go.
I'm coming back from GM and experiments done in Haxe over the last two years, so I have a stronger grasp of what is possible now.

While I won't be inventing all my own tools, if I wanted lower-level access to the filesystem in Stencyl thats now a possibility. Live and learn eh?

Definitely a possibility in GM to implement your own tooling but quality is linearly correlated with pain, which is great if you want predictable deadlines, but working around things like the sandbox is a constant nuisance.

Things I *love* about Stencyl,

1. In-editor layer transparency

2. Distinct separation between events and code. Able to switch a line off with a single click. Draws a good distinction between comments, and code thats been enabled/disabled for testing or prototyping.

3. Proper object types (actors), instead of the headache where every instance is just an integer in GM.

4. Attachable behaviors with configuration per actor type

5. Per-instance behavior configuration in the scene editor

6. You know how painful it was to get a UI that sticks to the camera, doesn't scale wrong, doesn't have a *collision box* that scales wrong, and keeps it's layout when your custom camera code zooms or moves?
Whole hell of a lot harder in GM.

7. Composition through behaviors, all of which can have their own *named* events.

8. Polymorphism through changing out actor types on actor attributes in various behaviors

9. Dead-simple tile data editor and access

10. Built in animation panel, able to set collision shapes, data, per frame animation speed (made animating the lighting effect of a campfire ridiculously easy), and named animation strips.

11. True scene scripts and behaviors, instead of the bastardized practice of putting global objects in scene and spending way too much time debugging why things suddenly break (curse you dynamic object deactivation! When I said target all object types, I didn't mean my scene controllers!)

12.  Lists are great, folders are even better, but it can be a real PITA when your looking through 300+ objects and other resources (not to mention the save time in GM is god-awful). Stencyl is way better about this with grid based resource panels, instead of searching through endless lists.

Chit-Chat / Re: Top-Down Open-World Space Game?!?!?!?!??!
« on: November 09, 2018, 05:00:38 pm »
Some things to keep in mind if you're going for 'open world'. I did something similar in a different toolset, but the same things apply.

1. How fast is your camera scrolling / how fast does the player move/how far does the player move in one tick? You have to ask this because it will help you determine how many objects are deactivating/reactivating on any given tick (assuming the player is moving)

2.  If you implement camera zooming, be aware that as the camera zooms out, naturally, more objects will be on screen than typical, which can and will impact performance.

3. 'Activation/Deactivatin' isn' which I mean, just because something was activated/deactivated, doesn't mean it will be done by the next tick, and bugs with references and collisions may occur because of this

4. Consider adding buffer zones. If the camera moves, and say, an enemy is following you, and interceding obstacles or walls may not stop an enemy before they're deactivated (because the order that intances are processed isn't guarantee). In this case it is best to have two zones, one thats closer to the outer edge of the screen, and one that is further. The furthest is for terrain, and it gets activated/deactivated first, the inner buffer zone gets activated/deactivated *after* the terrain buffer

5. What is your memory budget, if any? What are you aiming for? 2GB, 3GB, 4?
While dynamic activation/deactivation will save you processing, each object thats loaded with a level or scene still takes up memory, and you'd be surprised how fast. Know what you can get away with by stress testing with various variables, datastructures, and dummy objects, and then profile memory usage.

6. If you're planning on loading objects from file at run time, ask how many can be loaded before things slow to a crawl. If you have a fast or modern PC consider going well under any limits you encounter, in order to factor in low-specs. Also, disk read speed will be a factor.

7. Think about the object density on screen with your game. Camera zoom, character movement speed, and world density will all contribute to the limits of activation/deactivation and fileloading/serializing before you start to hit a performance wall. For example, with the resolution I've designed for, and scene sizes, I can afford to put, at most 32 objects in scene (about 0.3 object density per scene), but my scenes are small. This doesn't include actors for eye-candy, such as rain and clouds and UI, which you should add to your instance/actor/object count for safe measure.

8. Know your 'heavy' objects/actors, and your 'light' ones. If you're flush for memory, or designing with higher specs (or don't plan on porting to limited platforms), than you can get away with more. Objects that do very little, you can get away with placing more of them obviously.

9. For stencyl specifically, if you don't need full physics, set every object you can to 'simple physics'

10. Again, for stencyl, always assign an actor to a group, group on group collisions should be cheaper to check for.

11. Events are cheap compared to draw(), always(), and other events that get called every frame or tick. If you can get away with custom events instead of regular events like update, then do so.

12. When all else fails, cut what you don't need. Don't invent new tools or reinvent tools. Instead use the tools you have to the very fullest. An example, early on I made everything an actor, which was a bad move. I realized instead what I could do was use tilemaps as they are intended, and then for lootables, I created an actor with an icon thats only used to identify it in the scene *editor*, a ring with a diamond on it in to indicate 'this is lootable'. This actor was placed on a separate tile layer overlaying the map.
Then I placed this collidable actor over each tile 'container' I wanted the player to be able to loot. During runtime the player wouldn't see these invisible markers used for level design, but if they collided with a container, they'd get rewarded with loot. In the end this was way cheaper than making every single thing an actor just because I wanted *some* of them to be interactive in some way. No matter how big your scenes, you're usually going to benefit from making things tiles instead of full blow objects.

13. Stencyl specific (not necessarily related to open worlds), use the inspector. You can do a LOT of customization for experimentation, in order to get things 'just right'. So if you've already designed a scene or chunks of it, and it turns out you have too much loading/unloading too fast, you could use the inspector panel to tweak and test the players move speed until you find the sweet spot, but thats just one example.

14. Never underestimate the power of swapping things out. In my early builds I created a custom actor for each and every UI iteration. I realized what I could do was create a behavior with an 'actor' attribute. The UI parent actor would control the layout of elements, and the elements would just have events specifically to determine their own state (e.x. hovered, clicked, dragged, etc). This meant if I didn't like the design of something, such as the layout, I could change it with a single swap of an instance or attribute value in the scene editor. This is really just an extension of point 13, but once I realized it it saved me so much trouble.

15. When simulating big worlds, never underestimate the power of simply skipping a loop or two. Using an if-check and a modulo, I had whole sets of objects simulating at half and sometimes a third of my tick rate, and it saved me processing power where I couldn't cut elsewhere. Tricks like this are important when you're dealing with 10k, 20k, 100k+ objects loaded.

Thats all I got for now, but there are people here way more experienced at this. Good thread.

Chit-Chat / Where I've been, and What I've done.
« on: November 09, 2018, 11:04:56 am »
Pardon the narcissistic titling.

First, want to say thank you to people like Hectate and Ceosol, for all the help they provided just a couple years prior.

I ended up switching to GMS because I wanted more access to the file system and I had serious concerns about the state of flash. This was back when I intended to sell my game to flashportals, oh poor nieve me, the trials I was about to go through  :D

A friend told me that if I switched over I'd end up doing exactly what the devs behind Hyper Light Drifter did, building all my own tools in-game. I said he was wrong. Turns out, he was right. I ended up building a system for loading a 100k plus objects into game, completely ignoring tilemap options, dynamically loading chunks and only saving objects if they changed. I had to build a custom system for loading prefab-style level designs, and a dozen other headaches.

Ultimately, because of constraints, I shelved all the work. The game UI had changed a hundred times and now a critical element of the game was time 'passing' whenever the player changed maps, in much the same way resources were used when changing locations in games like 'Out There.'
Lesson learned, don't build tools and systems 'just in case', or because they're 'cool.'  8)

A big part of the original switch was the lower-level access I believed GM would give me. I'm not a tool maker. I didn't start with the intent of making my own tools. And now, the thing I learned is, making your own tools is expensive, so is reinventing the wheel, but I digress.

Cut to the chase, here I am, back in stencyl, implementing a flash an advertisement for my larger game, and here I am like oh my god if I had avoided or cut out the desire for massive open worlds, and moddability, I could have been using stencyl the whole time.

And let me tell you, when you leave stencyl to use gm, and return after two years, it's the difference between night and day, it's a world of less pain you have to deal with.

Stencyl, I'm sorry I ever left you. Can you forgive me?  :'(

Extensions / Re: Some sort of zooming extension
« on: November 09, 2018, 10:53:21 am »
Maybe the field (variable) 'canvas' was removed or changed?

I know the more recent builds of Openfl (in particular 2018 builds), were reintegrated to make lime the universal backend.

Ask a Question / Re: How to implement lighting without shaders?
« on: October 01, 2017, 06:58:50 pm »
Rob and Merrak I owe you guys a debt of gratitude and a six pack.
A lot of times I can't wrap my head around a concept unless I see it implemented.
I didn't know how to use the image api which is what was hurting me.
You have my thanks.

Edit: I wasn't making the leap from "first create an image attribute" to -> "modify it and then create instances before attaching them."

This is gonna open up a bunch of possibilities for me. Again, thank you.

Ask a Question / Re: How to implement lighting without shaders?
« on: October 01, 2017, 04:37:09 pm »
Hey thanks merrak, gonna give this a go.
Rob, tried what you suggested, still getting a black screen.
I'm setting the light actor z index in .created using the 'move self to front/back of layer' block.
Blend mode for the actor is set at creation while blend mode for the layer I set through the layer propery dialog in the
scene editor (instead of through blocks in the scene event .created). In any case I'm still getting the black screen, so I'm gonna resort to the image api method. I'll see how it goes and let you guys know. Thanks again fwiw.

Ask a Question / Re: How to implement lighting without shaders?
« on: October 01, 2017, 03:24:23 pm »
Thank you Rob. Didn't work, but thank you. I currently have four sprites for experimenting with lights.
my 'base' sprite which is black with a transparent circle in the middle, 'black' which is a black circle on white, 'shadow' which is a black circle on transparent, and 'white', which is a white circle on black.

Currently the black circle on white, with layer blending set to 'multiply' acts as a 'shadow' for the given layer, as long as I have no layer fill.

Layer filling now is implemented as some commands in the scene .draw event. I set the fill color to 'black', set draw layer to layer 1, and then fill a square the size of the screen, which is a terrible way of doing it, but I'm just working out the kinks anyway.

Lights are implemented as actors, and the animations are what are supposed to act as the template for the cut out.
I'm currently on flash and using openfl legacy.

I'm not sure what I'm doing wrong but I appreciate your advice.

Ask a Question / How to implement lighting without shaders? [SOLVED]
« on: October 01, 2017, 02:29:10 pm »
For my lighting I can't use shaders. I want to stick to normal, add, multiply, and screen effects. I've tried all of them without much luck.

My fellow stencylers, I ask you to rise to the occasion, and ask you one question: How would you implement lighting in this circumstance?

The way I'm attempting to perform it is by using transparent circles that overlay on a secondary layer above the main game, and the second layer blending is set to 'add', but I'm not having much luck. The lights should 'cut out' the darkness from the layer to show whats beneath, but I can't seem to accomplish that.

 All answers or solutions are welcome.

Chit-Chat / Re: How powerful can Stencyl exe games get.
« on: September 19, 2017, 07:32:01 pm »
Hey thanks for answering. Your process is actually close to the exact one I use. Still can't get to the same level of productivity.
Mostly I end up reimplementing functionality because the performance is always just below where I want it.

I never knew you could be that productive in blender. How many months of practice did you have? Were you already an artist/animator? I don't mean to shower you with questions, just curious.

I had to put it on hold as well. Plus in Unity its much harder to figure things out when a problem comes my way.
Yeah from what I can tell unity is good for 90% of use cases, and the 10% of the time when you want to do something it can be really opaque about the nature of problems that arise. I ended up either asking for help or resorting to the unity marketplace, which is just as well because only fools (no pun intended) and the devil insist on reinventing the wheel. I mean it would be the same thing if you ended up on a team instead, using others code. Just as well we're all standing on the shoulders of giants.

Looking forward to blasting enemies!

As a general heads up, I was reading over some design posts by the guys that made Rust. They were talking about the problems they had with a blueprints model of crafting. You can find the post on their blog, very interesting read as far as flow and game feel go.

Pages: 1 2 3 ... 6