Switching from GM - big projects in construct?

New releases and general discussions.

Post » Sat Dec 20, 2008 4:50 pm

Greetings.

I am a C++ coder and user of Game Maker. I really like GM for the fact that it makes 2d game development really fast, easy and convenient, however, lack of shader support, bad performance and slow loading with big projects are huge disadvantages for me. So when i heard about Construct, i was pretty excited - not only it looks really efficient, but also supports shaders, a dream come true for me.

Unfortunately, upon closer scrutiny there seem to be a few issues with how workflow in Construct is shaped, which are pretty much deal-breakers for me. Its mainly about how Construct doesnt seem to be suited for big projects.

For example, managing objects. There is this object pane attached to layout editor, on which objects are always displayed as icons, you can scroll it up or down and... thats it? You cant switch from big icons to small icons, you can arrange them in groups or put into a treelike structure. My projects usually have tens or even hundreds of different objects - for example, 50 weapons, and for each weapon there is a different bullet object, and almost all weapon/bullet objects have different properties, logic and drawing routines. It would quickly become an awkward and arduous task to manage big numbers of objects.

Another example is that of event sheets. I am used to class methods and functions from C++ or object events and scripts from GM. In Construct, there are event sheets, in which any actions triggered by events/conditions for any objects are placed. Imagine you have tens or even hundreds of objects, and for each objects you have a few events and conditions that trigger specific actions - so you either need a huge number of event sheets, one for every object, or you get long, hard to read and manage sheets.

I must also admit that im used to coding stuff (writing down) myself instead of 'building' code with blocks. In GM, i never touched the drag and drop actions - i used its resources pane to manage objects, but all actions were coded purely in GML. Thus, im not too keen on using Constructs event systems and would have preferred python scripting. However, python scripting in Construct seems to be really rudimentary - scripts can be inserted only as actions, there seems to be no way to create global python functions (with arguments and return values) for use in all objects, and i couldnt find any solid documentation regarding properties and Construct functions accessible via python or writing python scripts in Construct in general. There also seems to be no way to refer and modify specific instances directly (or rather, through pointers), but im guessing i must be missing something here, since it would be rather silly thing to do not to include such functionality in a full-blown game making IDE.

I am aware these 'issues' i have with Construct might originate from simple lack of knowledge - actually, i am hoping it is so. It would be a great shame for all that potential go to waste just because of small things like object management or inability to write globally accessible functions.
B
1
G
4
Posts: 5
Reputation: 1,035

Post » Sat Dec 20, 2008 5:14 pm

[quote:2blmujvm]For example, managing objects. There is this object pane attached to layout editor, on which objects are always displayed as icons, you can scroll it up or down and... thats it? You cant switch from big icons to small icons, you can arrange them in groups or put into a treelike structure.[/quote:2blmujvm]

Organization of objects into folders has been discussed as a feature for future builds.

As for the event system and event sheets... the modularity of event sheets and groups and such should allow you to organize your events any way you like. Regarding Python, it's not going to be able to do anything that events can't do... it's there for people who are more comfortable with scripting certain parts of their games. There may be support for using Python only in the future, I'm not sure what the devs have planned for it exactly, but the event system will remain the primary system for creating game logic. It's meant to be comparable to similar game creation tools like GM (sans GML), MMF, Alice, and the like. In short, Construct is a tool, not a language, so if you're looking for a more script-oriented development environment then you're kind of stuck there.

As for documentation, yes, there is a lack of documentation at the moment. It's a work in progress, by the time Construct gets out of beta there should be more solid documentation :)
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sat Dec 20, 2008 5:31 pm

50 weapon with unique bullets, properties, logic and drawing routines? Even in programming language that'd be hard to maintain. Construct allows to organize objects in "families", you can think about it like a container of all instances of classes included within it (kinda "base class").

Construct eventsheets are based on events rather than scripts, I like actual functionality of it. Before getting into eventing you can prepare a pseudocode.

As for using methods I recommend getting to know "Function Object". It fully includes the idea of making methods with returnable value. Construct documentation describes it.
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Sat Dec 20, 2008 6:02 pm

Hi there, I'm one of the Construct developers.

[quote="Kaelis":1nwu0wr9]There is this object pane attached to layout editor, on which objects are always displayed as icons, you can scroll it up or down and... thats it?[/quote:1nwu0wr9]
I agree it's hard to use - what actually annoys me most about it is that it doesn't sort anything alphabetically, which does make it pretty useless for finding stuff in large projects! (Right now I'm sticking to just locating it in the layout editor!) The object bar is a relatively recent addition - it isn't quite "there" yet in terms of what it should be doing. Ideally in the next build or two it will also have:
- Alphabetical sorting (!)
- Filter like the event wizard (eg. type 'Tank' and get all objects with the string 'Tank' anywhere in their name)
- Small icons, list, icons only, text only, listview with details views (set by right click menu)
- Folders
- View only global objects, only layout objects, all, etc
These additions will hopefully make it much more useful for large projects, because right now it's really only useful for (very) small projects. Also, I don't know if you noticed, but the bar can be undocked and docked anywhere, or resized bigger for multiple columns, so if you have a multimonitor display or something, you could put it there with a bigger view to see more objects.

[quote:1nwu0wr9]In Construct, there are event sheets, in which any actions triggered by events/conditions for any objects are placed. Imagine you have tens or even hundreds of objects, and for each objects you have a few events and conditions that trigger specific actions - so you either need a huge number of event sheets, one for every object, or you get long, hard to read and manage sheets.[/quote:1nwu0wr9]
In Construct, things work significantly differently to languages - at first it might seem primitive, but you can actually very elegantly express code once you understand how object picking works, using subevents, for-each (and for-each ordered), containers, families and behaviors. It's a completely different paradigm to languages, based around manipulating lists of 'picked' instances, as opposed to sequences of explicit commands (which is all most languages really come down to).

Construct isn't really a scripting tool - Python was intended to be a way to get around some of the limitations of the event-based structure (eg. highly algorithmic processing with many variables and lots of data). I don't think we intended Python to be used solely to develop entire games, although you could - frankly I'm not very interested in programs which work like that either (they don't seem to go much beyond a gaming API for a programming language, like Allegro with a UI) - the event system is what makes Construct special. Right now I don't think Python in Construct actually works at all, it was broken a few builds ago! (Some users have noticed but I think most of us shrugged and carried on with the event based system) We do hope to have it fixed soon though.

Construct is still in beta (and will be until 1.0) and is only just recently emerging as a fully featured and stable piece of software. As a result, I don't think many people have attempted such large projects as you describe. That's probably why there aren't mature features for large projects yet, but I do hope we get that sorted for 1.0, especially since I'm planning some large projects myself!

As for event sheets, it also works a bit differently in Construct. Since it's a very high level programming system, event sheets tend to be ordered by what they do rather than what they are coding for. Instead of event sheets for each object and lots of functions, I think most people (including me) go with event sheets by their purpose, eg. events relating to "User interface", "Movement & Animation", "AI" etc. The main idea behind events is you can express ideas very compactly and briefly, so these event sheets shouldn't be jammed with thousands of events - just short fragments of events sorted by groups (basically event folders), and commented. This seems to work very effectively for everything I've done.

Try out the Ghost Shooter tutorial and Deadeye's Platform School at [url:1nwu0wr9]http://www.scirra.com/tutorials[/url:1nwu0wr9] - it might seem a bit simplistic given your experience with C++, but it should give you a rough idea how things are generally set up in Construct. Generally the whole functions/file-per-class/statement-based paradigm isn't applicable to the event system.

Thanks for the feedback though, and I hope this helps explain things a bit :)
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,554

Post » Sun Dec 21, 2008 1:54 am

Somehow I'm also having issues about the eventing itself. Well, I guess it's a matter of what you got used to. I would also like to see a functional python just for the sake of that type of scripting, you see, even to make a simple matching game, I'd rather script than do it with events(which seems to be easy to do in events) it's because I could handle it more than what construct gives like the event.

Now, if I really like that kind of programming why would I still use construct instead of the python/pygame or whatever language? Simply because Construct has a very good editor and stuff..
It's like using GML to make games in GM that could be done in GM eventing as well. I do't know, it's just like that.
B
16
S
10
G
5
Posts: 255
Reputation: 3,934

Post » Sun Dec 21, 2008 1:52 pm

Thank you for your responses.

[quote="Ashley":1g4s243a]Construct isn't really a scripting tool - Python was intended to be a way to get around some of the limitations of the event-based structure (eg. highly algorithmic processing with many variables and lots of data). I don't think we intended Python to be used solely to develop entire games, although you could - frankly I'm not very interested in programs which work like that either (they don't seem to go much beyond a gaming API for a programming language, like Allegro with a UI) - the event system is what makes Construct special. Right now I don't think Python in Construct actually works at all, it was broken a few builds ago! (Some users have noticed but I think most of us shrugged and carried on with the event based system) We do hope to have it fixed soon though.[/quote:1g4s243a]
Ah, this is what i was afraid of. Construct is for people who like building they code from predefined blocks instead of writing it down. After eight years with C++, it seems to me like an awkward and unnecessarily laborious way of developing applications.

What made Construct special in my eyes was not the event system - it was the fact that its fast, has shaders (not many 2d game making libraries can provide those), and all that while being a proper IDE (object and resource management, properties and building rooms/layouts) and handling every aspect of game development (so not just graphics, but also sound, file i/o, physics, particles etc).

I guess what i really want is Game Maker interface with Construct engine and functions/constants/properties instead of their GM equivalents. Or just a C++ library (i suppose i could code my own interface for construct). So it looks like im stuck with GM nevertheless. This is a real shame.
B
1
G
4
Posts: 5
Reputation: 1,035

Post » Sun Dec 21, 2008 2:51 pm

Well it is open source.
Then again it is still in beta.
Image Image
B
161
S
48
G
90
Posts: 7,348
Reputation: 66,751

Post » Sun Dec 21, 2008 5:43 pm

[quote="Kaelis":2s9ftelp]After eight years with C++, it seems to me like an awkward and unnecessarily laborious way of developing applications.[/quote:2s9ftelp]
Well, you would think that, coming from C++ or another scripting language, because you know how already in languages. For you and I, coding pong in C++ is a triviality, because we know exactly how to do it, and any other way seems to be a waste of time. Firstly, Construct is partially aimed at people with no language experience whatsoever, so they can, for example, make pong without having to learn about pointers, memory, structures, classes, code design, functions, the old C-backwards-compatible little bits that really you ought to be avoiding but sometimes you can use, and so on and on. Or, in other languages, all the syntax and structure can be hard work to learn for the first time. Because coders already know all of that so it comes naturally, it's not an issue in development, but it is for some.
Secondly Construct aims to do it much quicker. I know how to make Pong in C++ code, or some other scripting language, but to get the basic engine down, especially if I want shaders and all that, would take even a seasoned developer the best part of a day. In Construct you can click it together in moments, partly because you can code something much quicker in events (when you know how). So although its "just predefined code blocks" it's actually a big timesaver.

[quote:2s9ftelp]it was the fact that its fast, has shaders (not many 2d game making libraries can provide those), and all that while being a proper IDE (object and resource management, properties and building rooms/layouts) and handling every aspect of game development (so not just graphics, but also sound, file i/o, physics, particles etc)[/quote:2s9ftelp]
Well, why not write your games in C++? You already know how, and assuming you've worked with DirectX before, it's easy to have a custom engine set up and working in no time, even with shaders (which are surprisingly easy to support in C++ with D3DX). XAudio2 can do your sound, the C runtime library can do your file i/o, Box2D can do your physics, and particles are a lot more flexible to code in C++, and the whole thing will run faster than anything else by a long shot. I guess the IDE helps you sort out your level design, but if you design a level editor as in-game using the game engine, it's not much work either. So if you know C++ even with more years experience than me what are you going round using IDEs for? :P

I'm in the same position where I could easily sit down and code an entire game in C++, but I don't want to. Construct is designed as a time-saver, so I can make the same game I could in C++, but in one tenth the time.

Maybe Construct isn't the tool for you, but don't knock it till you've tried it ;)
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,554

Post » Sun Dec 21, 2008 5:51 pm

Kaelis, Construct is a good software and the team's work hard to finish the 1.0. And it is a good team too. ;)
You have the time before the 1.0, like Ashley said, to try all the tutorials to understand that it is the best way to make pc game in few times.
B
2
G
4
Posts: 26
Reputation: 1,102

Post » Sun Dec 21, 2008 6:02 pm

Well, I'd just like to say, though I'm really only just getting in to Construct, that I think the program is great so far for someone like me. I'm an artist, not a coder, and somehow this program almost seems familiar to me as if it's just another digital media art application. Though some may think that Construct can't do as much because of having precoded features or whatever, so far I'm finding that it can do exactly what I want it to do, and do it well. To me it's kind of like writing a book, or a story, in plain simple terms, in my own language.

For someone that needs more brainy mathematical stuff in front of them in order to create something, maybe this isn't the tool for them, but for people that need something a little more visual and down to Earth, this is it. And it's going to get better every update, I'm sure.
B
2
G
4
Posts: 40
Reputation: 1,130

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests