Alternatively, you call also call level-specific functions by building the function's name dynamically using the current layout's name and some naming convention.

Insert a few of these at key points of the event logic (layout start, layout end, player dead, enemies dead, etc.) and you have a fairly flexible system. You can fill in the bits for levels that require it

Personally I'm going for a hybrid system where I'm putting everything that can be shared into a single event sheet that deals with as much as possible (solo setup, multiplayer coop setup, entity logic, spawners, triggers, gameplay, etc.) with settings to be specified by each scene, and a callback-like mechanism for scene-specific events

Each individual layout logic becomes very simple and looks like :

• apply scene settings (scrolling speed, gameplay flags, etc.)
• include the generic event sheet
• deal with function triggers, e.g. "on PlayerDied()", "on EnemiesDestroyed()", etc. that are called by the generic sheet

This requires abstracting the structure of each scene and making it follow a similar-ish pattern

[quote:yhs8f2x2]I deleated all behaviors of the match 3 objects

I have add events that makes the match 3 objects falling down

That's pretty much it !

Basically, for such a constrained layout, you don't want to rely on complex behaviours ; these are good for platformers, top-down shooters, physics objects where you need the collisions when you can't predict the outcome, etc. but here you'd fight the behaviours to make them do what they're not really good at.

Also, you don't even need the collisions for clicking objects, you can just use "on mouse click" + "if mouse overlap" > action. Actually maybe a "draggable" behaviours would be better, depending on your game.

Anyway, don't use any platform or physics or anything. You can for example have a representation of your grid/board in a 2D array, and run logic on the data in the array to detect when symbols are aligned, when there are holes and other blocks need to move, etc. Then the game you present to the user just becomes a visualisation of the data in the array.

At first, don't bother with sliding symbols, etc. just do simple straight cell swaps on a timer (i.e. symbols instantly "teleport" to the next empty cell when moving down). When you've got that working, you can add some variables and basic math logic to make the symbols "slide"

A Match-3 game can sound simple, but unfortunately with WYSIWYG tools like C2 the built-in behaviour don't help you that much. You can achieve a clean nice result but implementing basic logic yourself.

Hi !

I might get this wrong, but why use physics at all If you have a match-3 puzzle-style game where everything is nicely grid-aligned, you can just manage the board state yourself (arrays, etc.) and write a simple "move" behaviour to get your blocks to fall down. Assuming the blocks have a predictable motion (e.g. all come from the top and fall perfectly vertically, etc.)

This would much MUCH less expensive in terms of computations. You really want to keep physics only for situations that require it, e.g. when you don't control the environment, when you want projectiles or entities with realistic behaviours, vehicles, etc. For a board game, create your own representation of the board.

'Hope that helps !

Same here after working for a long time with C2, the editor becomes unresponsive and slow.

I found a workaround though - when I start to feel the UI is getting sluggish, I change the skin/theme, that seems to force a refresh of the widgets and you're good to go for another few hours !

Saving the project structure works well enough, as long as team members compartmentalise their work and avoid convoluted overlapping changes. I would recommend developing new features on separate prototyping layouts/sheets, and only do a proper "manual" merge if necessary when everything is in place.

Also, I would strongly suggest to use an actual versioning system, e.g. Bit Bucket + Smart Git, or any other good alternative you are familiar with. Just make sure you set it up to ignore all "ui" and backup files, otherwise these will "pollute" the history log when searching for diffs

Hi there !

[quote:o08987nw]I've never seen an game engine where you can implement networking that easy!

I totally agree And it's really easy to understand as well, with the very detailed tutorials explaining the design of the multiplayer module. Coming from a background of low-level programming, that certainly is a change !

Anyway... I don't have much to contribute to the initial question, but I was wondering about the "dedicated server" idea. While I understand the principle (ensuring you're the host by being the first to join the room, etc.), and while I have some knowledge of general networking, I have little expertise of server-side technologies (the typical light-PHP and simple databases).

If I were to do something like you describe, there are some questions I'm not too sure how I would deal with... For example, I guess there's always a risk of the "server" (i.e. host here) crashing or losing connection. Does that mean you need some kind of a daemon process to monitor the session and spawn a new "host" if necessary ? Or maybe there are infrastructures that guarantees your server will always be up (e.g. using some black-voodoo-dark-magic stuff like the popular Amazon AWS) ?

If you have a few minutes, and don't mind sharing some infos of course, I would really appreciate a quick overview of the kinds of technologies / services you need to build something reliable to support this idea.

Regards

Brilliant, I will need to look again at the windows desktop exporter soon, and I read here and there there were issues with the node webkit package ; these instructions will surely prove useful ! Thanks for sharing your process.

I believe layers are not synced ; they shouldn't move if created the same way, but you can force your objects on the right layers locally on each peer, like in the multiplayer pong/shooter examples.

I think productivity of the existing tools should be an obvious priority, if not the priority, for future developments ; time saved by developers creating games can be spent on project-specific needs, e.g. advanced optimisations, integration of 3rd party plugins, getting obscure platform exporters to work, etc. This would be easier for game developers with a technical background, but would benefit the entire community, as it already does.

If we focus only on some of these modules, only a subset of the C2 projects will benefit from the improvements, while at the moment that are still certain aspects of the IDE that are a bit clunky and that are clear "time-wasters"

Personally I think C2 does exactly what it says it does - nothing more nothing less, and it's the right balance between productivity and functionalities.

I wouldn't want C2 (or C3, as people start to talk about C3 which I think would be a bit premature) to become what it's not ; there already are other solutions if I want to target native features, do 3D, actually program, etc.

I think it's all about user expectations, and there are 2 points in particular that keep coming back :

• Multi-platform ; cross-platform development never works easily and perfectly ; all engines or technologies advertising "write once deploy everywhere" have their flaws and specific issues. Targeting HTML5 is a clever choice ; it works at least as well as other solutions and has the advantage of moving a lot of the complexity to 3rd party companies. I see it as an advantage because these companies have a lot more man-power to burn to develop technologies ; it means we depend on solutions we don't fully control, but without HTML5 and theses companies there wouldn't be crossplatform at all in C2.

I have worked with in-house engines used for AAA consoles/PC games, and we always needed dozens of full-time senior programmers just to maintain the platforms. C2/HTML5 has its limitations, but it's not greener on the other sides ; it is viable and is the "clever" choice for a small company, and it will continue to improve in the future as part of the evolution of web-technologies.

• "no programming" ; I'm always wary when a product advertises "no programming required", and C2 falls in this category. Whether we actually write native code to compile, scripts to interpret, or events, it's all the same : programming is about designing solutions, manipulating data and implementing algorithms. That's exactly what we do in event sheets, even if they hide a lot of the complexity (few data types, objects only expose suitable operations in a given context, etc.)

Hiding the actual complexity also means that lots of people rely almost exclusively on the built-in behaviours, and we end up with lots of requests to make new behaviours, or make existing behaviours work like this or work like that, etc. And while these requests all seem sensible in a given project, they usually conflict with each other when looking at the big picture.

I would be in favor of exposing a bit more of the building blocks to let people come up with their own behaviours more easily. It would still be a lot easier than programming, but would require people to actually understand how things work to adapt to their needs.

As a final word, my "only" request for the future of C2 would be to improve the productivity of the editor when writing event sheets ; at the moment manipulating data, using variables, writing small algorithms, etc. is a lot more painful than it should, and there are lots of *small* things that could be done to make it a much more enjoyable experience. That an a real debugger to go with it ! Not being able to trace certain control structures is a real time-waster.

+1

Same issue as previous posters ; working with 8x8 tiles is very impractical, you need the image opened in parallel with a different software to locate the tile you want and then guess where it is in the C2 tilemap window...