Porting from Gamemaker

The organisation of gamemaker's interface and workflow is cleaner and better than Construct, IMO. You have sprites, objects and rooms - draw a sprite, assign it to an object, give the object actions and events, put it in a room, and hey presto - a game! Every component of the game is available in an organised tree structure on the left hand side - sprites, objects, rooms, fonts, sounds, backgrounds, timelines, paths and scripts.

How does that differ from having a layout, and inserting a sprite, then drawing an image into it?

Everything to do with an application is found in the Project tab on the ribbon, and settings can all be changed in application settings, also. I wouldn't call it 'spread all over the place', though if you do have a good idea on how we can make it more intuitive, we'll definitely consider it.

I was only referring to the organisation of things - all game elements visible and available on the left hand side, double click to open an edit window. In Construct, some things are in the project window, others in the object bar, or the properties window, etc. As far as the general UI goes, I think GM has an absolute pig of an interface. The frequently over-strict modality is a real pain to work with (e.g. only one script window can be open at a time, and you can't do anything else while it's open!).

I don't agree with your statement that everything can be found in the project tab. There are times that I have had to go through several steps in order to do something simple. I'll try to do some annotated screenshots to show what I mean, but I need to go to work now, so I'll have to sort them out later.

Regarding my suggestion of a library - how about extending the project panel to include all objects in the project, not just layouts and event sheets? Then you can give them a right-click menu to choose any of the options related to them (edit graphics, open event wizard, show properties, etc.). Every element of the project would then be available from one centralised location, like in gamemaker and many other software.

I think maybe combining the resources bar and project bar in to one might help. Is that what you're talking about?

If we had one Project bar which had the following folders:

• Layouts
• Event sheets
• Objects
• Sound effects
• Music
• Fonts
• Icons
• Menus
• Binary

...and things could be sorted in to sub-folders within that. Then there'd be a single place to organise the entire application. Sound good?

Well, I ceratinly like the sound of that, but you guys are the developers and it's your baby. It's still beta software and I'm sure you have your own plans of where to take it. I do think a centralised project library is a good idea - from a project management point of view it's almost essential.

I just realised I may have derailed this thread a little. I believe the question being asked was "where does construct lag behind gamemaker?". I'd like to emphasise my earlier point that the lack of a proper tilemap system is a pretty big deal when it comes to developing traditional 2D games. I know things are moving away from fixed tile grid restrictions these days, but tilemaps are still relevant for 2D development. I hope some form of tilemap system can be added to construct one day.

Well, I ceratinly like the sound of that, but you guys are the developers and it's your baby. It's still beta software and I'm sure you have your own plans of where to take it.

I really like the idea of a centralised project bar. I'm not afraid to make fairly major changes to keep Construct moving. The more it evolves the more streamlined it'll get. And our users are an important source of ideas, I don't think it's useful for any developer to shun community feedback and take the project their own direction.

[quote:1ej9wabd]I'd like to emphasise my earlier point that the lack of a proper tilemap system is a pretty big deal when it comes to developing traditional 2D games.

That's a good point. I believe David had been working on some kind of tile system, but I think other things got prioritised over it and it's not quite finished yet.

If you really want to improve things, I would suggest incorporating the image editor into the object layout. This would get rid of that modal window, and you could possibly incorporate a zoom for objects.

Heck why not include the animation bar as well, you've already got frame selection built into the image editor, which is pretty much a redundancy.

That's a good point. I believe David had been working on some kind of tile system, but I think other things got prioritised over it and it's not quite finished yet.

He was, I have the alpha plugin . It's pretty buggy right now though.

I think maybe combining the resources bar and project bar in to one might help...and things could be sorted in to sub-folders within that. Then there'd be a single place to organise the entire application. Sound good?

YES!

Hi, I'm new to Construct so many of the considerations you can read below may be influenced by my unexperience with the software.

GameMaker seems to be an outdated application compared to Construct, but in many cases I had the impression that GM gives you much more flexibility.

For example in GM there are few events, but they are very flexible and their use seems to be more "logical" than the events in Construct (to me obviously); in general in GM I think it's easier to integrate drag and drop actions and code.

I've experienced many difficulties in the porting of a GM work to Construct; for example I've not been able to find an event similar to the "create" event in GameMaker (where the corresponding actions take place only at the creation of an object).

On the other side Construct is graphically excellent and has a very good layout editor compared to the room editor of its counterpart.

In particular layers are awesome and the possibility to use a png file with transparency directly in the layout is very useful.

I've experienced many difficulties in the porting of a GM work to Construct; for example I've not been able to find an event similar to the "create" event in GameMaker (where the corresponding actions take place only at the creation of an object).

"Spawn?"

Or "System: Create?"

When you spawn an object, any actions performed on that object in the same spawn event will only be applied to that object. For instance:

+On mouse click
   ->Player.Sprite: Spawn object Bullet.Sprite
   ->Set Bullet.Sprite angle towards MouseX, MouseY
[/code:iv2kt4su]

This will only set the angle of the bullet that just spawned, not any other bullets that might already be on the screen.  It has to do with object picking.  Any objects that you define specifically by any particular conditions will be the only ones affected by the action in the event.  Spawning is a special case because it automatically picks the object for you, you don't need to define a condition.

I think the difficulties you're experiencing just have to do with unfamiliarity with the program... once you get into it you will see that it's actually quite logically organized.

[quote:287ykzz7]I think the difficulties you're experiencing just have to do with unfamiliarity with the program... once you get into it you will see that it's actually quite logically organized.

Yes, you are probably right, but at the moment I'm still a little bit confused about events.

Here it is a little example of my actual situation:

I place some isometric walls in the layout editor.

At the start of layout (runtime) I wish that every wall creates an invisible sprite used for

collision detection (instead of placing them manually in the editor).

Ok, I can choose the event "start of layout" to let the wall spawn the collider sprite and this is good,

but how can I achieve the same behaviour if a wall is created, for any reason, at runtime after the start of the layout?

In Game Maker this is easily achieved by selecting the object "wall" and, in the "create" event for that object, typing something like: "instance_create(x, y, collider)"

In this case the corrisponding action takes place only once, at the creation of the calling object.

With Construct I've tried selecting the event "wall is visible -> wall spawn object: collider" or "wall is on screen -> wall spawn object: collider", but colliders seem to generate at every frame (tick) instead of only once at the creation of the wall object.

I've tried a lot but I've not been able to find a solution yet.

Thanks!

There is no "on create" condition in construct, at least not yet. It sounds pretty convenient, though. Maybe devs could implement it? You can currently use some workaround, like testing if a value of a sprite is 0, and if it is, do something and change the value to 1. This way the event will perform once and only once per instance of an object right away when it's created, be it on the start of frame or at some point in runtime.

but how can I achieve the same behaviour if a wall is created, for any reason, at runtime after the start of the layout?

Check out the wiki entry for "Containers."

Basically, but your wall sprite and your collision mask sprite in a Container to link them. That way when you create one, the other will be created automatically (you still have to set the x and y though).

I cover some of what Containers can do in one of my Platform School tutorials... I don't mean to toot my own horn or anything but it might be beneficial to read them. You should go through the Ghost Shooter tutorial first, though.

It seems like a lot of people are coming from Gamemaker (I was one of them) to check out Construct. Maybe it would be good to have "Construct for Gamemaker Users" tutorials. I know I had a lot of problems trying to do things in Construct that seemed easier to do in Gamemaker. Most things are just as easy if not easier in Construct, but the workflow is much different.

Ok, thanks for the suggestions!

I will try to make my own creation event with containers and/or value checking; it should not be difficult.

Concerning the Platform School I've red the first lesson for now.... very good tutorial!

[quote:2n340lj1]Maybe it would be good to have "Construct for Gamemaker Users" tutorials.

Agree!