- What you want in C2 for 2015 -

Hmmm, it sure would be nice if we could get someone who has made an "advanced" 2d game to compare C2 to what they used.

Not to be any more rude than usual, but it would be nice to get some speculation from success, rather than wherever this is coming from.

michael

Q3D plugin for c2 is good for you?

Integrate a 3D engine like unreal for c2?

An unreal licence for one game is/was very expensive for a studio (over 100000 Dollar). To many people work on so an engine that's why it isn't possible. An applink from c2 to 3D engines should be possible!

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.

My advice is to focus more on 2d games not 3d, The idea is to make C2 the engine number 1 for 2d games.

There no way to make engine like Unity without spending huge amount of money.

Hmmm, it sure would be nice if we could get someone who has made an "advanced" 2d game to compare C2 to what they used.

Not to be any more rude than usual, but it would be nice to get some speculation from success, rather than wherever this is coming from.

Agreed entirely.

IMO we should drop the 3D requests already. I can totally agree with the users who posted these kind of opinions: C2 is for 2D and if you want to do 3D development, you should move to a different engine (like Unity, Unreal, Godot, etc..). If you really want to stay with C2 and do 3D, then try the Q3D plugin. 3D is complicated, way more complicated than 2D, and also, it takes up way more time (just think about creating the models). I'm not saying that 3D game development is not a good thing to do, but it's not for C2.

I think C2 is one of the best 2D game engines, and using HTML5 is rather an advantage than a disadvantage. I can think several ideas that I'd love to see integrated into the engine, but I only stick with the one I think is the most important: Hire more people! If you want to be able to keep the pace of the game engine market, and also if you want to satisfy the community, you'll need more people. Scirra stated before, that it's not an easy thing to do, because C2 is a pretty complicated software. Ok, I can agree with that, but the market and the community demands the bigger updates and redesigns of various parts of the engine. I'm not saying Scirra should hire 10 programmes instantly, but 1 or 2. Don't think too long on this. It's a step I think you must make very soon.

Just to note: I tried the Airsape Steam demo, and it works just fine.

For the developers who say you can't make any serious game with C2: Yes, you can. The engine is fully capable for that, even with the use of wrappers. And don't forget, the overall game depends more on the developer, than on the engine.

1) I don't understand these people who understimate casual mobile games. If you want to make big desktop game - it's okay. Good luck. But making games cost lots of money (i.e. professional design) and casual games are the best option for begginers. Someone can make casual game -> gets money from ads etc. -> have money for more serious game.

2) Scirra could make some deal with rojohound and add some new plugins in Construct 2.

3) As for now the biggest issue is that both exporters recommended by Scirra - Node-Webkit (PC) and Crosswalk (mobile) are not good for something bigger than simple game. You can make advanced game, but you should be able to play this game without serious issues (i.e. jittering).

4) Fortunetly there is still CocoonJS, so I hope that they will implement native AdMob ads soon.

1) I don't understand these people who understimate casual mobile games. If you want to make big desktop game - it's okay. Good luck. But making games cost lots of money (i.e. professional design) and casual games are the best option for begginers. Someone can make casual game -> gets money from ads etc. -> have money for more serious game.

I think there is a little misunderstanding indeed. Just because you aren't primarly targeting mobile devices doesn't mean you are going for AAA production values or a game with a huge amount of content. A simple 8bit retro platformer is still inherently a core game.

You really make it sound that if you aren't going for casual stuff, you are automatically trying your hand at creating the next Mass Effect.

My advice is to focus more on 2d games not 3d, The idea is to make C2 the engine number 1 for 2d games.

There no way to make engine like Unity without spending huge amount of money.

It's baffling that this is being brought up again and again. Or maybe it's more annoying than baffling really.

Construct 2 is for 2D games. It would be silly and costly to try to compete with the likes of Unity, UDK etc. If you still want to dabble with 3D within C2 I believe Quazi's plugin is a very cool way to do so by now!

new Zoom Behaviour and a new ability to specify 2 instances (UID or IID) within an object type to check for collision

Can't you already do the collision thing by using a family?

I wish Construct 2 would be more Metroidvania-friendly. As it is right now, it's incredibly hard to make.

Also, I want layouts to be fixed. I have a global player and here's what happens if I move between layouts with different heights.

Example:

I have 3 layouts, starting layout that is 768x224, the next layout is 256x672, the third layout is 256x224.

Now, my player starts the game in the starting layout, and moves from that layout into the second layout, transition is fine and everything is good. The player then goes to the bottom of that layout and enters a door, that door at position "8, 640", upon colliding with that door, the game changes layouts as per normal and sets the player on the target x,y position. However, when switching from layout 2 to 3, the player is always stuck in the lower left corner of the layout, clipped into the tilemap.

It turns out that if you're moving objects from layout to layout, if an object was in a x,y position that can't be present in the next layout, even if you set the position the object is going to be in via events, the engine bugs out and just clips him into nowhere.

It basically goes like this; Player starts in layout 1, enters door in layout 1 at 208y, switch layout from 1 to 2, player is currently in layout 2 at 208y and correct position that are set via events, player jumps down to bottom of the layout and enters door in layout 2 at 640y, switch layout from 2 to 3, player is currently in layout 3 at 640y even though the events told the game to set the player to the same y position as the door in the next layout.

I don't understand how the engine cannot simply set the player objects there. The only work around I've thought of is to have each layout contain the entire game world which is stupid.

Any ideas if that can actually be fixed?

[attachment=0:1zxlicq2][/attachment:1zxlicq2]

Those are the events set up, the position the player is set to in the next layout is taken from instance variables unique to each door.

In most cases the PlayerOffsetY is zero, but if I need the player to be above or below a door I can change it. I tried using this to fix the player getting clipped into the tilemap hundreds of pixels below the door but it didn't help.

Nesteris You got to set player position to the doors on start of the layout i think.

> Can't you already do the collision thing by using a family?

>

No,it can't. Within same object type is much more specific than within family.

Let me clarify what I meant: if you want to test for a collision of two instances of the same object that you pick by UIDs, you can do this with a family.

Pick the first object by UID and then use the condition of the family that contains the object to pick the 2nd one. Then simply use the overlap condition "Object overlapping Family" and you're good.

So unless I'm misunderstanding what you initially asked, this does work fine.

1) I don't understand these people who understimate casual mobile games. If you want to make big desktop game - it's okay. Good luck.

Mobile has touchscreen controls only. I have zero interest in touchscreen games. And that's why I'm creating for desktop. You don't *have* to go the AAA route for desktop you know.

megatronx

That screencap I showed you is a sub-event of a "At start of layout" event condition. So it is at the start of the layout.

[attachment=0:y10aesfi][/attachment:y10aesfi]

Thus my problem.

Just my 2 cents

I can say this much after using Construct 2 for 2 years. My first attempt was what I thought to be basic, and ended up being a performance hog. After many attempts, each game got better and better in terms of performance, and the way I handled events. I have learned that there are many ways to achieve things in any game engine, and with that said... just cause you got something to work, doesn't mean it's an efficient way of doing it in relation to your game, and the game engine.

The 3D request seems pointless. C2 is a 2D game creation tool. Period. I feel like if you want 3D, than use Unity.

I will however say that I am displeased with the 3rd party exporters / wrappers. I didn't begin to use construct for mobile development, I came because 1) I'm a visual guy, and 2) saw that it specifically states "Build Once. Publish Everywhere. True multiplatform support. Build your game in Construct 2 and publish it to all these platforms." and Win/Mac/Linux is on that list. Desktop publishing was the deal breaker, for me at least... And doing so currently, is glitchy with Node, and a process for linux and Mac. I feel the request for better desktop publishing is a much needed one. I also really like the spread sheet array idea! Lighting/Shadowing as mention earlier is basically pointless. I feel the ability to establish an actual radius of how far the light/shadow is casted is needed for them to be at all useful.

Really though, everything else is great and getting better. The only REAL issue for me, is the desktop publishing / third party BS. (that isn't Scirra's fault)

megatronx

That screencap I showed you is a sub-event of a "At start of layout" event condition. So it is at the start of the layout.

[attachment=0:25nuf9th][/attachment:25nuf9th]

Thus my problem.

ok, try positioning the objects "on layout loaded" , then set wait:0.1 and then fade in.

StormHo Would be equivalent of For each loop with Stop Loop action within the event of object meeting it's condition.