RayKst's Forum Posts

  • I'd greatly like to see Lua scripting too. But that would, i believe, need a major code rewrite. I don't know . How MMF2 even supported scripting at all via plugins ? In the case of C2 i think the engine would have to be coded from the ground up with scripting in mind. The visual scripting would be just a 'frontend' for the script code...

  • An idea to add tile paint features on a non-tile based editor like C2 is something like:

    1.

    <img src="http://dl.dropbox.com/u/2472278/Images/1.PNG" border="0" />

    2. Scene Editor

    <img src="http://dl.dropbox.com/u/2472278/Images/2.PNG" border="0" />

    3. When double click

    <img src="http://dl.dropbox.com/u/2472278/Images/3.PNG" border="0" />

    You get the idea. The brush icon is to emphasize that you paint the tiles. In the painting window of course there must be a tile pallete to pick the tiles just like tiled editor and similar.

    There's several ways to implement that of course , and i believe it's compatible with current C2 workflow. One point that would have to be addressed with this system is collision. Maybe a grid based collision body.

  • I meant something like: If an event sheet is assigned to a specific object on scene the events will relate only to that instance, so single scope. If assigned to an object type, all objects of that type, bigger scope. If assigned to scene, then all objects from that scene, full scope and so on. Don't know if it could go more high level than scene scope... The idea is having total control of picking. Of course that can all be done with current system. It's just harder. It's only an idea that passed my mind, don't know if it would be viable to implement. It's like a picking top level filter.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • In my opinion, and i've seen others with the same opinion is that playmaker connected boxes system is not suitable for coding an entire game in it (moderately complex game) because there's a strong tendency of those boxes and links to become a huge mess fast when their numbers grow too high, unlike c2 which remains maintanable and easily understandable (given proper organization) with hundreds or even thousands of events. So Playmaker would really shine to rapidly define small to mid-small parts of game behavior in a more complex game. In the case of a simple game it would be perfectly adequate to use Playmaker to define the entire game in it. The purpose of PlayMaker then is not to substitute coding, as is the case in C2 but to easily and fastly define specific behavior of levels , actors etc, that require constant tweaking, without having to get to the code all the time, specially for designers, level makers etc. Then again, it'll depend on the game.

  • The idea of specific event sheet for objects (behavior sheet) could work well. Maybe separate the concept of event sheets in global sheet, scene sheet, and object sheet. They would then have different picking scopes. . That would improve C2 immenselly. Huge feature. No more picking problems in some recorrent situations. That's my feeling about it at least.

  • Except that PlayMaker plugin is not suitable for making your entire game in it , unlike C2 :)

  • To change it to a model like Unity (object compositional) uses would demand pretty much some major code rewrite i think. Each approach has it advantages and downsides.

    Of course Unity model is harder to grasp but much more flexible.

  • This happens for me rarelly. Maybe a memory leak/error ?

  • Nice suggestions. About Collision on / off , what you probably want is collision groups. Like groupa A is the Hero. Group B are the enemies. So group A collides with B but B doesn't. So enemies don't collide with themselves only with the hero. This is almost a must in any engine. It can done with Families. But i'm not sure if C2 has Collision Groups builtin.

  • Awesomium guys finished Direct to Window rendering ! :D

  • Awesomium guys finished Direct to Window rendering ! :D

  • Great news !

  • The problem with Awesomium is that there's an indirection in the rendering. Awesomium by default generates a 'pixel buffer' for every rendering frame. An 'image' is then built from this buffer. Then the 'image' is showed on screen. That's overly simplificated but that's pretty much what happens. That really hurts performance. To get an idea in a real world example: If you have a web page rendering. The process runs one time at start to generate the web page frame. If nothing changes, ex.: No animation on page, no button clicked, nothing, there's no need to generate a new frame, no refresh occurs. Then when you move the mouse a refresh happens. In a game, which is highly dynamic most of the time, that process happens every time normally 60 times per second. So you get the idea. Of course that buffer copy can be optimized but it's not always enough. Then again of course there can still be a bug that makes things worse.

  • Oahuahua o my, Tom is a genius :D I can't stop laughing :D LOL

    I liked the lemony water :)

  • Do you mean the Win8 new tablets ? I doubt they'll support WebGL. Win8/Modern is DirectX 11 all the way. So they'll want to put it in the browser too. Is just a matter of time if not already. For now for C2 to target Win8 the only option is plain Canvas. Really bad.