TheRealDannyyy

Thanks, that helps a lot.

With NW.js is there a way to check for parameters. For example "nw.exe console-on" where a param can enable a console.

I would consider that the stages for game development go like this

Prototyping: Core mechanics

At this stage there is no game fluff. It's only testing out the basic mechanic and find out it it's fun. It's also the stage that let's you find out the hurdles of designing the mechanic. This is also the stage to try out the mechanic with friends to get an opinion on their experience. That way you can also fine tune the mechanic. Also try out multiple mechanics separately if the core idea isn't alone in the game concept.

Pre development

Plan out how the core mechanic will be designed know that you know the complexities. Find simpler ways to build the core mechanic for being used in a flexible manner. Also start planning out how the fluff interacts with your game. It's a good idea to document this for reference.

Alpha Development

Grey box the UI and Meta features

A lot of people will go from mechanic prototype and then wrap around the meta/ui and other features. This is a bad idea. Start by building up your menu's, and game design flow.

Build up your data model and data interaction

Some games require changing data. Such as persistent leveling. Level information whatever it might be. Make sure this is designed. You can go back and make changes as required.

Rebuild your core game mechanics into the the system

That old version you prototyped. Scrap it. learn from it. As your building your new one you know are integrating it into the rest of the game. You have laid down everything else. So now the actual game mechanic can be built on a solid foundation.

Integrating graphics and audio

Once all of this is in place start implementing the graphics, audio and other stuff.

Beta Development

At this point start having people test your game. get feed back. Make changes to improve the game. Release when done.

Also scene graph objects would help a million. Which is part of the prefab system.

I've been saying this for 3/4 years now, weeks after I joined. Objects should be based on scene graph, use Unities prefabs and scrap PIN and Containers. They just don't have the same versatility, and they are so much more straight jacketed. I still use them, but rarely.

C2 could do the manipulation now, the problem is that C2 doesn't offer any good widget tools. So any manipulation needs to be made by some other form of data. Which means using a file, or running in run time exporting the data, and loading it by file. It's really not very good.

As for C3 no idea.

I'm more concerned that it seems development is being done with no direct community input. One of the reasons that Unity and UDK are such good engines is because development is based around community behavior with direct community feedback. What works, what doesn't work, what is working. So far C3 has been developed in what appears to be a vacuum environment. Now of course it's not. Ashley comes to the forums often, but no from what I have heard has been in discussion with Ash in regards to what would be useful.

While I'm waiting patiently the longer silence, and the dread that the community comes in second+ place in regards to design is concerning. I would love to hear some news, details, screen shots. I suspect because of the isolation C3 will be a better IDE, but we will end up with these still locked out issue because there isn't enough different minds and though directions to give a good flexible direction for C3.

That's crazy. That's incredibly crazy. Can you provide a capx. I would like to see this. I'm not not believing you. But wow. yeah. I've come across other performance hitting issues that stand out in C2. I'm just surprised that Function does. But you know what. I'm not actually surprised thinking about. I spend 1/4 of day tracking down when and where the Function call finally executes. And the function call is extremely nested down in the data referencing. Possibly 10 references and a number of loops deep. And in this case because of how C2 is constantly dumping unused CPU cache data by doing this. I could see this actually happening.

I knew C2 was GPU memory optimized, but I've called for CPU cache optimization a few times. Which I think is what's directly hurting C2 performance in relation to every other engine, and my mobile is such and issue. In a case like Function that numerous nesting is probably doing many, many cache misses and burning a lot of wasted CPU cycles. However its' speculation of what the exact cause is. But having sat down to C2runtime.js CPU cache misses are all over the place.

http://gameprogrammingpatterns.com/data-locality.html

my suggestion. Create a CAPX of this performance difference and file it in the bugs list.

I agree with Blurrymind. I did a tech request list a while ago. Having C3 operating from a V8/HTML powered engine such as NW.js was one of the big suggestions.

The reasons were for this

1. NW.js or whatever runs on all major development OS

2. Reyling on a DOM HTML front end means that the HTML/JS/DOM layer is exposed to the community to make custom IDE plugins of any kind

3. C3.x or C4 could be potentially hosted by a server and accessible by tablets for simpler design elements

I would suggest using Lunarays LiteTween. Make your work super easy.

—

2 Players, 4 Players 8 Players. once you go online play that initial multiplayer hurdle is the same. Developing for MP requires a large shift in thinking on how to handle networking. And that's what he is saying. A lot of people come in wanting to make a MP game. And thinks it's brain dead easy. And while C2 is one of the simplest networking systems for games so far. it still a hurdle that most still find complicated.

Your controls are not relevant to the networking complication. Once you deal with the first hurdle then 1 input and 32 input are pretty much the same. I suggest learning how to do a chat client and then move from there.

Dictionary.Load is immediate. It's not technically "loading" from a stream. It's taking the already stored JSON string in memory and then converting the JSON into the Dictionary storing mechanism. So there is no need for when Dictionary is finished as it's finished the moment the action is done. you can start using data in the same event.

So

Start -> AJAX.Load( file )

AJAX.OnLoad -> Dictionary.Load( Ajax.lastdata )

-> Dictionary is ready to use.

Nope, if you studied the performance one. Then I think your good.