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 - Blacksmith

Pages: 1 2 3 4 ... 8
Ask a Question / Can you export/import tile collision shapes?
« on: March 26, 2014, 08:50:10 pm »
I want to transfer 54 tiles to another project, but the custom collision shapes aren't transferring with the tile images.
I exported the tile set, and also sent it to Stencylforge without success. Suggestions? Otherwise it is many hours of work. 

There's not much practical advice on Newgrounds Highscore. (I have the IDs and a blank table when I play. Not very useful.)
How should you handle certain (potential) error conditions.

1. Can you submit scores if you aren't playing it on the NG's website? (I don't see how you could, but...)
2. what happens if you do submit?
3.  what happens if you submit a score on the NG site, but you aren't logged in?
4. Can you receive scores if you aren't playing in on the NG site?

5. Should you make different flash versions? 1 for NG, 1 for KG, 1 for StencylArcade, 1 for your website, etc.

Sorry for all the questions. The info on the NG site, is quite focused on the traditional programmer. Thank you.

I found a post from 2013 between Jon and Captaincomic that talks about the EXACT slowdown to 48 fps with mouse movement or keyboard press that I reported above. Long standing "problem" with the Flash debugger, has nothing to do with Stencyl.,13617.msg110071.html#msg110071

Beginners: I just gained 12fps by using the browser/player (60 fps) instead of the debugger (48fps). Yes there are a few posts in the forums on this, but I thought some people might benefit from my observations. (Stencyl 3, MacBook Pro 2.3 Ghz i5, 8GB).

In my system, when using the debugger (but not the player/browser):
* Just holding a key down drops by 12fps. (even if you have 0 controls in place). See comparison of event codes in blocks.
* Just moving the mouse around drops by 30fps (even if there are no mouse events/checks).
* I had the same 12fps result whether I ran my full game (50 Mb stencyl file, 6.4Mb Flash) or the super minimalist version (0.5 Mb Flash).

So before spending 12h debugging your code because it's slow, try it in the Flash Player first.
Does anyone know why this is, and/or a way around it?

Ask a Question / Re: Stencyl is super slow?
« on: March 19, 2014, 12:23:11 pm »
Alexin, I think I remember elsewhere, though I can't find it, that in Stencyl 3 it removes the print commands before compiling. Or am I remembering something different?

Quote from: BumbleBirds
I've gone in and removed print from the jump behavior and that seems to have helped things! I'm pretty surprised that it would make such a difference. It was even causing problems before while the log viewer was closed.
Actually, it's pretty normal and there exists the notion of debug and release builds in software engineering. The former provides more information at the expense of performance. Debug builds are used throughout the development process and release builds are used when the software is ready and needs maximum performance.

In this particular case, printing to the console is costly, as any other IO operation. I encourage you to use print blocks to debug your game, even if it slows it down. Later you can simply comment them.

Stencyl Jam 14 / Re: How are your StencylJam entries coming along?
« on: March 17, 2014, 12:04:31 pm »
Hey guys,

Daniel Flores and I (Csaba Nagy aka Blacksmith) are working on a side scrolling game that could be described as single player motocross, but with a truck, and a relentless Alien spaceship that's chasing and firing after you. You are always driving to the right, and the saucer is always chasing you. The challenge is to navigate bumpy terrain while simultaneously aiming and firing at the saucer. It's not easy to do both. Trust me.

Here's a graphic that should give you an idea of some of the elements. Note there is only one truck and one spaceship in the game. I've also attached the pic.

Since we want to put this on mobile (Flash only for the contest), one of the most important design considerations was to have simple, and comfortable, controls. The simplest we could think of is to hold the phone or pad like a console controller allowing each thumb to press one side of the screen. Right side for speed, left side to aim your gun. For the computer you press two keys, like 'z' and 'm.'

So if you press anywhere on the right side, which is the gas pedal, and the truck will speed up. Release the thumb press  and friction and gravity will slow the truck down. The left thumb controls the  roof gun turret allowing you to tilt it smoothly along the arc  starting from 9 and ending at 12 o'clock. Release your left thumb and the turret slowly returns to it's starting position. To keep things simple, the gun fires automatically at a set interval. All you have to do is "just" aim. (You can't lock the gun at an angle, it's always rotating either clockwise or counterclockwise.

As I said above, what makes it tough is to simultaneously watch and handle bumpy terrain on the right while dodging spaceship lasers and trying to aim at a moving spaceship. I've found that it's kind of like the kid's game of trying to rotate your arms in different directions at the same time. It looks easy but requires a good deal of concentration.

I'll do more in a subsequent update, but we have draft physics down for the truck. We have kludged saucer movement. We have animations for the different damaged states of the truck and saucer. We have a random generator for the tiles and terrain which allows every run to be different. I.e. you can't memorize the terrain. And since the tiles are generated on the fly, we are currently working on levels 750 tiles wide (that's 24,000 pixels). We want levels to last between 30-90 seconds depending on the objective. We are also working on different layers for the background, clouds, hills, and closer objects like cacti.

Our to do list is very long. But among our urgent goals is to get the UI down, determine the level objectives (like jumping over the Grand Canyon :-), and of course making the physics of the truck and saucer much more lifelike. In addition we have the other screens to worry about, title screen, level screen, inventory shop/mechanic screen, etc.

We were able to compile a recent version and run it on iPhone 4 (on iOS 6 :-) and iPad 2 (on iOS 7), and we are happy. So we can put the iOS version aside and focus on the Flash version exclusively to get it polished.

1. Do you have any suggestions, or pitfall warnings, regarding games with similar two-button/two-finger controls? Can you suggest any games for us to review.
2. What kinds of in-level objectives do you think would be fun for a side-scrolling driver game?
3. What kinds of statistics would you like the game to present at the end of each level? (Or even in level.) Some of these could be considered achievements you might need to get trophies, bonus points, etc

I think it goes without saying that Jon is at the top of the list of people to thank. Without him I wouldn't be making games at all. There are also many, many other people that we should thank for their help with Stencyl programming. I can't list them all, but Tuo, captaincomic, Photon, Hectate, and Innes all deserve  special mention. And Rob1221, besides answering my questions so patiently, you wrote the tile API without which our game would not be possible.

Best regards,
Csaba and Daniel

Completed / Re: masking in 3.0
« on: March 15, 2014, 11:48:33 pm »
Jon, speaking of masking, I ran into a "bug" on import actor's image through copy from clipboard. I have an image with a white background. On 1.5x, 2x, and 4x, if I click on the white area, white is chosen as the mask. If it's on 1x, then no matter what I click on the mask colour chosen is black.

Couldn't find this mentioned anywhere, and fell on this topic while searching.

Fixed Bugs (3.x) / Re: Stencyl 3.0 IOS SIMULATOR ISSUE HELP PLEASE
« on: March 13, 2014, 10:27:01 pm »
From a quick survey of leading sites, people just seem to prefer the machete approach: delete and reinstall. I would love a more surgical tool.

Fixed Bugs (3.x) / Re: Stencyl 3.0 IOS SIMULATOR ISSUE HELP PLEASE
« on: March 13, 2014, 09:52:41 pm »
Many devs are having problems with this same or related issues, including Corona Labs.

Fixed Bugs (3.x) / Re: Stencyl 3.0 IOS SIMULATOR ISSUE HELP PLEASE
« on: March 13, 2014, 08:37:46 pm »
For what it's worth, I was successfully doing tests on the simulator this afternoon. Apparently Xcode auto updated while I was away from my desk...and I got the same message as above the next time I published to the simulator about a hour ago. Nice.

The XCode currently on my system is 5.1 (5B130a)

Is it better to post a game early for the SJ#14 and get feedback with the hope that you might improve it and post an update before the deadline? Or does that expose you to negative reviews?   I asked a similar question on the NG thread since it's not entirely clear how the scoring works, but I'm not sure I'll get a response. If I do, I'll post it here. Thanks.

Old Bugs (3.x) / Stick joints: Actors move
« on: March 02, 2014, 07:40:36 am »
Essentially, a stick joint and attached actors shift starting locations compared to scene designer. See DEMOS in thread link below.

1) An actor (with a stick joint) that "cannot move" will shift as if its point of origin is bottom right. The joint does not shift.
2) The actor in #1 will also affect the actor it is joined with that has no movement restrictions. In that case, actor #2 shifts as if its point of origin is bottom centre.
3) An actor (with a stick joint) that "cannot be pushed", behaves as expected and does not affect the joined actor.

Topic initially started here:,29494.msg169149.html#msg169149
Topic should have been in this thread instead. Sorry. LOTS more detail and images and demo files in the other thread. Thanks.

Thank you for your excellent suggestions. They are consistent with my initial experiments.

* The bug is fixed when the brick is set to "Cannot be pushed."   <-- CORRECTION
* Changing the wheel's mass has no effect.
* Changing gravity speeds up or slows down the speed of the wheel, as expected per laws of physics.

Additional information:
Brick image shifts but joint does not move
Compare the Stencyl screenshot and the flash game and you'll see that the brick image shifted so that the joint is now set to the bottom right corner. That is, the joint attached to the centre of the brick itself didn't move (likely related to "Cannot move"), but the brick image did.

The wheel, and joint, move straight upward by one actor radius.
The wheel is affected by gravity and can rotate. The wheel image, compared to the brick, moves though in a different direction  (up instead of left up), but only if the brick is set to cannot move. This time, the joint remains at the centre of the wheel. (Likely because the wheel has no movement restrictions.) Notice in the two screenshots that the arc of the wheel is different.

Ask a Question / Stick joint bugs. (Cool demos!)
« on: March 01, 2014, 10:16:08 pm »
BUG: The actors connected by stick joints are in a different location in the published game than in the scene designer.  (See screen shot below showing scene designer and flash output. The 'x' is supposed to be in the centre of the brick.)

QUESTION: The stick joint has three adjustable attributes available in the scene design editor:
1) Should actors collide? Y/N
2) Damping: None (0.0) to Critical (1.0)
3) Stiffness: Stiff (0) to Loose (60)

What do these adjust?
I have spent about 4 hours creating demos with results virtually identical.

DEMO SCENE 1: pendulum with a single joint between a falling weight and a fixed point (the 'x'). The red half-circles are for visual comparison only, no collision. The four examples are the extreme cases for the first two attributes above. Damping seems to have no effect at all. Stiffness seems to have a very minor effect. I checked colliding actors separately with no change either.

PS: Here is the scene designer to show that the brick is in a different place than in the flash output shown above. (The wheel starts in a different place too.) Both actors have their points of origin as centre default.

DEMO SCENE 2: pendulum with a simulated 14 link chain and a weight. This one drops before it starts to swing. I thought the combined effect of 14 joints would show a difference with the Damping and Stiffness attributes. But alas no such luck. I checked colliding actors separately with no change either.

Feel free to modify the demo attached to do your own investigation. I would love to know where I've gone wrong. (I tried changing gravity without luck.)

If you run the Flash file, press R to reload the scene and 1 or 2 to switch scenes. Please let me know if the Flash and/or Stencyl files don't work.

Thanks for your help.

Resolved Questions / Re: Ragdoll sample app missing? [SOLVED]
« on: February 26, 2014, 03:27:17 pm »
Thanks Rob and Photon.  I was able to install v2.2 and Ragdoll showed up in Stencylforge.

Once I closed v2.2 and opened up v3, Ragdoll was in my list of resources. (As expected, it doesn't run in v3, but I can look at the code and blocks which is what I wanted.)

Pages: 1 2 3 4 ... 8