Hello there, let's do a little necro-topic-phily !

I just saw this post, doing some research on illuminated.js and its implementations around the web, and after starting to implement some basic functions of it (finding all the lightblocker segments, corners, some low level intersection functions, ...).

At first, I tried to implement it just by using the lib, but it seemed to block in lots of area, so I started rewriting it a little more.

I had some questions on how people think it would be best :

• for choosing the lightblockers, I went with a small behavior, a little like "solid", that you just add on the objects that should block the light. I then tried to reproduce the way that Pathfinder selects its blockers (custom or solids) but it isn't entirely working for custom yet. Do you see any other ways of selecting the good light blockers ? Should there be any other type of light blockers ?
• for displaying the light effect in the end (I haven't got into this point yet), I thought about asking for a base frame (just like the sprite), and cut it according to how the light polygon will be drawn. The alpha radius will then be prepared directly in the sprite, and a multiply should then be added to the "lightCaster" sprite. I'm still having hard time finding a good way to apply the frame correctly...

As this library is now up for some times, and surely somebody tried this before me, I would like to know if anybody had any advice or thoughts on how it would be best. Of course, if and when this is good, I'm planning on releasing it on the forums.

Well, you can always post a sample capx, duplicate of the original with everything removed but what you need help on.

If you just add a condition "once while true" on your event 43, your problem will be solved though. The problem right now is that you don't have a trigger for the portal to appear, you just check if the time has passed. But as once the time has pasted, it has passed every tick, your condition is always true, thus the once while true.

If you spawn the portal at +1000, the portal then should keep its X, not changing it with the players X.

It depends on how you did your wrap, but mostly I don't understand why you change the X of the portal to player.X+1000... Spawning it at this X won't "link" it to the player, the player.X variation won't interfere with the portal.X.

Could you post your capx for better help maybe ?

It's normal, your subevent won't ever trigger, as it will check if the spacebar has just been stroke only 1 time, this time being just after (like 0.01 ms after) the ball has been destroyed.

What you may want is to take your subevent out of its uper-event, so it can trigger on its own. You may also want to add a condition "spr_ball.count = 0" if what you want is to spanw a new ball after the previous one has been destroyed, once the player hits the space bar.

The free version is enough for your first month of discovering C2, at least. You won't have that time though if you plan on the steam sales.

You can do whatever you want on C2, but it's optimized for games, not apps, meaning it will be more intuitive to make a game than a calculator. It's won't be hard or impossible to go for a calculator though, just less intuitive.

The "limitations" are that C2 is made of javascript, and all exporters will use JS to run your game, making it a little slower than a native app on Android for example (not that much though, but you know how that works). On the other side, what you develop can directly be exported to multiple supports with very little efforts.

And I'm all with California's first remark : any prototype is about 1 hour work in C2, where it could be 2 to 3 days in jQuery, PHP, ...

Love the style of your map :)

Hey Paul,

Happy my tuto was useful.

About your problem, providing a sample capx could help understand what isn't working right now.

In doubt, I tried this capx where left click makes a bullet going through the wall, and right click makes it bounce on it. Not sure this is exactly what you needed though, but the events logic can then easily be changed, it was the collision detection that was your problem if I understand well.

Btw, when you're waiting for an answer from someone, or talking to someone in particular, try to add "@name_of_the_person" in your message so he gets notified ;)

The best practice in this field is to make your game framerate independant, as you cannot manage every type of computer. This tutorial can show you how to do it.

This way, people with low config won't suffer from it playing your game, and people with higher will enjoy it too.

If you still want to slow down the rendering, I'm not sure there is a way. It would be in the project properties I think, and I can't see anything like this.

Edit : ninja'd ^^

Put in your program big bad loops that slows the runtime ?

On a more serious note, why would you do so ? It will lag on the screen.

I'm all for optimization too, and you can find my thoughts and some techniques in this tutorial, but as Ashley pointed out in this blog article, events logic won't be a problem in most cases, as the rendering is usually the limiting factor of framerate.

For the typical case you described (+1 every X seconds, do once this event when hitting a fixed goal), I prefer to go with recursive functions. They give you a good control over the situation, and they are trigger-based, meaning they won't be evaluated every tick for the rest of the runtime.

Here is an example of how I usually do it.

Hey,

It's something you didn't understand, not a bug.

You have added a "variable", not a key to the dictionary.

In this capx, you'll find the right way to store a key in a dictionary, and to retrieve it after. I also commented a line showing how to get the variable you had set in the first place.

xeed

As said before, the pathfinding can't do "all" the work here. It can help a lot though.

When you regenerate obstacle map, it doesn't work because you have some moving obstacles (other tanks) and the obstacle map cannot use those.

Instead, remove the other tanks from the obstacle map completly.

In fact, the pathfinding is correct, it founds a good path. It's the "move along path" that doesn't do it correctly for you. Instead, you should code your own movement, making the overlapping tanks stop moving maybe (so they wait for the road to be open again). If you go down this road (haha), take a look at the "Pathfinding.capx" example in C2, as Ashley displays all the nodes on the road found by the pathfinding. It will be useful to build your movement.