Kaelis's Forum Posts

  • 5 posts

  • Maybe one day in future there'll be a full scripting engine, but I don't think it's going to go much further than an extension to the event sheet editor for some time.

    I wouldnt really need such 'advanced' scripting - just a way to write actions for events with actual code instead of putting them together with dialogs.

    Thanks for the feedback, but I think we're looking for different things here

    Well, this wasnt really feedback per se, just me desperately trying to find a solution to my woes I am aware that full scripting engine would be too much to ask for.

    I guess ill just lurk around, following Constructs development, especially since it looks like the current model of Python scripting should provide a lot of what i need, providing that all actions normally available through the event system are exposed to python as well (plus the ability to refer to specific instances).

    In any case, thank you for your responses, and i wish you luck with the development of Construct.

  • OK, well, you could probably learn these in a reasonable amount of time, and it's cool because you're dealing with the nuts and bolts of the GPU.

    But the whole point is - i dont want to!

    Well, I would describe the event system as even higher-level than using languages. Hence as you say, faster, quicker, easier, not having to do the messy work yourself.

    Yes, but i meant the library functions, not the user interface. GMs drag and drop or Construct event system is just a replacement for typing down commands/functions/etc.

    I've heard bad things about the Game Maker event system. I don't think it really has much in common with Construct's event system. I hope you don't assume the Construct event system is as sucky as Game Maker, because the Construct event system is a lot more sophisticated than in any other product. You really can make fairly complex games in it with just events, once you're familiar with the paradigm.

    Of course, but its really not about the level of sophistication (i am sure i could port big parts of my projects to construct), its about the idea of dragging/picking from dialogs vs typing it out.

    You can trigger events, and modify the common properties of all objects (the RunObjectHeaderInfo struct in rundefs.h, which includes x, y, width, height, angle, etc).

    Ah, so you cant modify the properties/variables you add to objects inside IDE, that pretty much rules the idea out. And the fact that it would be really awkward and time consuming to debug games made like that.

    If you're thinking about implementing the entire game by a custom written plugin, you'll probably have a hard time.

    Oh no, i was just thinking about doing events (or rather, actions that happen when a certain event is triggered) through plugins.

    Have a shot at the Ghost Shooter tutorial, and see what you think of the events system then. Please, don't think of it in the same terms as you do Game Maker

    As i said, i already did that. And no, i dont think Construct event system is as nearl as bad as D&D actions from Game Maker. It all really boils down to me wanting to script my events instead of putting them together from predefined blocks.

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

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

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

  • 5 posts