I so know that feeling. I was once told that it's the dummy model. Where just talking about a problem out loud will help you solve the problem. These days I know talk out loud. I find my self requiring a lot less to ask on forums

JSON Dictionary is some what a pain in the ready. But I can help out with a work around I found. I can't remember the EXACT pre and post fix, but you can find it easier.

create a c2 dictionary

var script = "{""c2dictionary"":true,""data"":"

script var add your json code

script var add "}"

Dictionary.loadJson(script)

I found this work around by mandatory requiremetns. Strangly enough you can embed a natural JSON code into a C2 Dictionary JSON by doing it in the above way. Makes life with JSON so much easier.

However there is one rule to keep in mind. Dictionary can only support 1 level deep. So you can embed data inside an internal object.

good

{

"data"; 0,

"foo": 1

}

bad

{

"object" : {"goo", 2}

"foo" : 1

}

object won't be allowed.

choose() in the manual is under system expressions. an expression in the white box that requests an input value. there are a lot of excellent and helpful expressions listed in the manual

System.setvaribale

[variable box]

choose(var1, var2)

Ashley

This is purely theoretical and by no means have I ever seriously delved into the V8 engine. But since Chrome V8 has this compile system to some form of machine code. Would it in fact be possible to embed the V8 compiler into C2 instead of relying on the browser itself at run time. If V8 is meant to compile to to machine language couldn't this allow in fact C2 to compile to a machine language? If this were the case. then that would mean that an abstract API layer would be required between V8 compiled code and the device in question. Giving this direction to the community to write fill in the device layer could offer alternative exporting models and put some development responsibility on the community(which I think Scirra as a 3 man team could use a break for doing such a wonderful job <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> ).

https://developers.google.com/v8/embed

ashesh

There has been a growing number of people that have been voicing a growing demand. I among them have been voicing that we want a C2 IDE for modularity and plugin repositry. I want it that C2 can install these plugins without restarting the software.

Maybe after the Multiplayer.

I can give you an answer on this, but it's probably not really going to answer it that easily.

There is no theoritical cap to the number of players can be in any given game world, instance or whatever. There is however latency, memory and CPU caps and that's what's going to get you. This will be determined by the following factors

1. How much memory your game can allocate from the system mem

2. Your internet connection quality and bandwidth

3. CPU

4. Your capability at writing logic handling

5. The rate of play(turns are low cost, intense realtime ala Street Fighter are high cost)

From what I gather based on hearing gamers playing on Shards of MMO's. The common on a standard good US broadband internet is likely capable of supporting apx 200 players on medium intensive action(ie World of Warcraft). Where as the average computer on an intenseive game say like the Showdown Effect, probably can't handle more than 8 to 12. While the common FPS can probably support 16-64. All depending on your coding skill.

Now of course you should probably notch all of this down a little for it all running in JS.

Now will there be a hard cap on the plugin?

possible, but that doesn't determine a potential. A lot of online games actually are run across a series of comptuers and your game connection is usually shuffled around internally and a lot of invisible and disconnects and re-connects. Those times you zone and get an image on the screen. That's usually the player getting disconnected and then reconnected to another computer; all managed by a more complicated structure.

rex is a great coder, but he does divide his plugins an aweful lot for modularity.

First rex has a repository tool you can install. It's not hard to google rexrainbow repository

My next piece of advice. Don't bloat your plugins. Only Rex can help you with his plugins and some of them are obsolete. Be selective. Also not all devs on the forums will help if they have to install more capx than they feel needed for their own use.

I think I recall a mention of Helium on another forum, but long lost track of that posting.

newt is right NodeWebKit is pretty good, and personally most big games have DLL and many small indie games have DLL. This is just a small subejctive matter. Though personally I don'tthink your post sounds like spam

I agree with Mathew overall for sub famillies, but more importantly I would open families. Where I can mix sprites, TileBG, 9Patch. I want this desperatly because I tried to make a UI with a common behaviour of such example

OnEnter

OnExit

OnClick

OnRelease

Params

......

unfortunatlly because I have Sprite for Buttons and other graphical widgets and have 9Patch for the panels because obviosly using 9patch border and internal scaling makes sense. This has led to two different objects that cannot share the same event code.

So there is a very good reason to have mutual object families. Also as a complain I would like TextObject and SpriteFont to have a collision object. That way I can compare if these objects are over my panel(9patch) so I can auto pin to the overlapping panel... which again leads to the silly thing that I need to numerous families with Pin and extra actions and events conditions to do this.

Also yes we can use variables, but since building and SOL requires itteration through the Object/Family in question. Large object lists that can be the result of large projects as the OP is posting in theory will result in longer SOL building times. Where as if Families could have sub Families could allow for faster SOL building; especially for EveryTick situations.

Family Inheretence and Open Families are just over all good OOP design. Actually it's very common for other OOP languges to support such design as

class goo{

public function(){ do stuff };

}

class foo extends goo{

public function(){do foo stuff};

}

class doo extends goo{

public function(){ youknow what};

}

class bada extends foo{

public function(){ yeah}

since this extends foo it also get's the featues of goo

}

this is common in good OOP design. Something that C2 doesnt' let us do. Working around situation doesn't make the work around good. Heck anyone remember the days before Function?

edit:

I also requested this many months ago and got the reply from Ashley that I could just use variables

Ashley, I read your last question on what I meant, but I didn't have any time to reply until now. But I read you previous post here and that's actually what I meant about what I wrote.

I'm not saying that C2 is inherently slower, I'm saying that because the ES are based around inserting code in to the game loop on per layout sheet; and how new developers aren't used to OOP design. It's easy to fall into the example above of inefficient design.

now GMS can do same thing, but GMS really pushes that code and behaviours results are triggered based on conditions. This leaves that GMS builds and reorganize for efficiency. While dev's can still do poor design it's less natural to do so. As another analogy it's C or C++ in comparison to Java's OOP only design.

So it's not that I believe that C2 gameloop design is inherently slower; working with C2 just requires more diligence and know how. If it seemed that I said C2 was inherently slower then I failed communicate what I was saying.

The only element that could/would/does make C2 slower is the JS. So after debating supporting my iTouch4g(and deciding not too), I checked out the common hardware and found that Tegra2 and the A4 chips(and equivalent qualities of both) are becoming obsolete. The Tegra3/4+ and A5+ are the most common chips out there; and for the most part they run JS games pretty darn well.

So as a general guide for everyone. Learn efficient code design, test on your weakest device often(if not your primary test device) and if your using an old device; get something newer(I also suffer the same budget constraints).

Invlude the file in the files for C2.

Use Execjs and stadard JS called to insert a new script into the document.head

then use execjs to call the api

Arima

good catch. I do find this amusing on the groups