Switching from GM - big projects in construct?

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Casino? money? who knows? but the target is the same!
  • 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.

  • [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.

    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

  • 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.

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

    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?

    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.

    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 http://www.scirra.com/tutorials - 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

  • 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.

  • Thank you for your responses.

    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.

    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.

  • Well it is open source.

    Then again it is still in beta.

  • After eight years with C++, it seems to me like an awkward and unnecessarily laborious way of developing applications.

    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)

    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?

    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

  • 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.

  • 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.

  • Because Construct is OPEN SOURCE, the"coders" will like it too. They can make modifications to make more and more for a special game or application they want.

    So Construct is good for artist, level designer, Construct is good for teacher who want amethod to learn logic to students and Construct is good for coders too for the reasons i explain before... and another point...

    MERRY XMAS ASHLEY ! an Merry xmas to all of you !

  • 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....

    Hey KniteBlargh

    Good to see you here. Soon we TIGSource members will take over

  • Kwarn: Good point. See, that's how totally NOT brainy I am; I didn't even think of the fact that it's open source. LOL

    Deadeye: Thanks for the welcome.

  • Actually kwarn reminded me of another point; using the plugin SDK you can design behaviors and plugins in C++, so you can do more advanced logic and code via C++ code and custom-built plugins for your game. For me being a C++ coder, I know if I come across something Construct can't do easily, I can design a plugin to solve that problem in C++, as well.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Well, why not write your games in C++? (...)

    So if you know C++ even with more years experience than me what are you going round using IDEs for?

    Because it takes a lot time, and i dont have much of that resource. Not to mention i have absolutely no experience with DirectX, and very little with Opengl. But i think theres a misunderstanding here, so let me explain.

    If it wasnt for Game Maker, i would focus on using one of game/graphics framework libraries, like SFML, HGE or even Ogre. So why am i using GM, if its so slow and doesnt have advanced graphical features like shaders? Because GM is even higher level than those libraries. Which means it does even more work done for you. Ive been experimenting with various libraries for years now, so when i recently got around trying GM, i was amazed how fast it is to develop in. And not only that, but its also an IDE (albeit rather simple one) - it lets me easily manage objects (and their events), resources and rooms. But even if it was without the IDE, just a C++ library, i would still use it, because of how high level it is.

    Now, Construct looks alot like GM in that it is a game engine/library with an IDE. Its big advantages over GM are speed and more advanced graphics engine. However, the downside is that it doesnt let me to access its 'library' functions through scripting, like Game Maker does through GML. Instead, it 'forces' me to use this event system akin to GMs action drag and drop system, which i always abhorred. This is why am i so... well, disappointed, i guess, although thats a bit too strong of a word.

    Actually kwarn reminded me of another point; using the plugin SDK you can design behaviors and plugins in C++, so you can do more advanced logic and code via C++ code and custom-built plugins for your game. For me being a C++ coder, I know if I come across something Construct can't do easily, I can design a plugin to solve that problem in C++, as well.

    Hm, thats interesting, ill have to look into that. For a quick question, does the SDK allow access to Construct functions (actions, basically), properties and event/condition triggering? Would it let me to basically write event sheets through C++?

    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.

    Oh, im not saying Construct is a bad piece of software. Actually, on the opposite - as far as i can tell, its very good, if only because one of the few fully-featured user friendly game development tools. Im just saying the workflow it uses (event system) is simply awkward for me to work with, especially if i were to do something bigger than just a simple platformer or top-down shooter.

    Also, i did in fact look at the downloadable examples, tutorials and templates.

    Because Construct is OPEN SOURCE, the"coders" will like it too. They can make modifications to make more and more for a special game or application they want.

    Ah, yes. I have looked into Construct source, and must say its far over my head. For example, the IDE is (obviously) full of windows programming, about which i know very little, so i would basically need to learn it from scratch to be able to at least understand the source. Yes, ive been coding for 8 years, but this was mainly a matter of hobby for me, i never wrote anything as huge and/or advanced as Construct.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)