Is Construct ready for a major game?

New releases and general discussions.

Post » Sat Jun 12, 2010 4:00 pm

Myself and a few others are prepared to make a full length game which will be similar to Castlevania: Symphony of the Night. I've been evaluating Construct and Game Maker for the last two months and have reached an impasse. While both are very good tools, I have been unable to ascertain how well Construct will hold up against a large scale project (it handles small games very well). I know Game Maker is up to the task, but I dislike the vague license and its lack of greater than directx 8 support.

Which brings me back to the question: can a full length game (which may have commerical potential) with all the fixings feasibly be made in Construct v0.99.85?

Thank you.
B
17
S
6
G
6
Posts: 113
Reputation: 4,161

Post » Sat Jun 12, 2010 4:10 pm

i don't think construct is ready for a full length game, when the size of a construct project increases it becomes vulnerable to unpredictable bugs which are almost impossible to remove. Phenomenon32 was a big game, but major problem with it was random crashes, save files getting deleted etc. The developer had taken every step to remove the bugs, but still many of them were not fixed.

So, if you want to make a game right now, you can try GameMaker but if you can wait, then surely go for construct 1.
B
9
S
3
G
3
Posts: 366
Reputation: 2,301

Post » Sat Jun 12, 2010 8:48 pm

I'm trying to put together a large scale project, so we'll see how that goes. If Construct can't hold up, it'll at least help the developers fix problems for future large projects...

It's holding up well so far, although loading and saving times are longer. But it doesn't feel particularly more unstable than with a smaller project-- just a bit slower.

I'd recommend keeping a lot of backups, though, since it is, of course, beta software.
B
8
S
3
G
5
Posts: 72
Reputation: 1,774

Post » Sat Jun 12, 2010 8:56 pm

I think Construct is and has been ready for a major game. The unpredictable bugs that abhilash2863 speaks of are random crashes of the editor that seldomly occur (at least for me). Save often as this is advisable for any computer program to prevent loss. The runtime however is very stable so you needn't worry about your game crashing.

I for one appreciate every new version of Construct, but I am not waiting for version 1.0 before I start a big project. I just haven't come up with one yet.

-cheers
B
79
S
24
G
54
Posts: 4,746
Reputation: 40,755

Post » Sat Jun 12, 2010 9:19 pm

I think Construct is ready for a major game. I don't think Game Maker is. This isn't a random attack because I like Construct more. I moved to Construct because Game Maker is very slow. You don't want to discover how slow by making your game reach the complexity threshold gradually and then figuring it out. To test this, write a program in gamemaker that adds 1+1 over and over in a loop. Test how many times this can loop per frame before it begins to slow down.

Save frequently like everyone else says, and do it with iterative filenames, i.e. yourgame.cap, yourgame2.cap, etc

Aside from the beta aspect, if you ever want to undo a large portion of game, it's convenient.

I'm working on a commercial title in Construct, this is only after torturetesting Construct with insanely complicated tasks, and it's proven to be stable for me. If there's anything I would be concerned with it's the aforementioned longer and longer loading times. I only found this when attempting to put huge animations into Construct, or insanely huge images. This problem isn't Construct exclusive, however, there's a reason why even most modern 2d games don't have screen-sized sprites, and when they do, they're usually bone animated.
Spriter Dev
B
87
S
21
G
12
Posts: 3,240
Reputation: 16,461

Post » Sat Jun 12, 2010 9:23 pm

I think construct is ready, by making a game you will suffer with bugs in all engines, thats a normal problem programming.
With construct you will make your game much easier than with GM, and will be easier to find bugs and handle with it because of that.
Im making a Zelda game, for now i have found only one bug with changing layouts. And i fix it by changing the code.

[quote:3vmtqbh8]I moved to Construct because Game Maker is very slow. [/quote:3vmtqbh8]
I agree, i tested many games with GM and mostly of then are laggy. With construt you can put thousand of events and objects and will not laggy. Only avoid effects and huge pictures Oo.
B
22
S
7
G
5
Posts: 90
Reputation: 3,430

Post » Sat Jun 12, 2010 10:28 pm

For the most part, I say that Construct has pretty much all of the worst bugs taken care of. I've been using it since.... well, forgot when, but It's really came along.

I used to be a former user of MMF and Gamemaker. Back in those days (coupla years ago) I would have preferred those over Construct, but NOW, considering how far Construct has come along over the years, I greatly prefer Construct over either software.

And as for commercial projects, they are allowed. I believe there is a forum topic addressing that matter.
B
4
S
1
G
5
Posts: 98
Reputation: 1,648

Post » Sat Jun 12, 2010 10:32 pm

I'm still sitting on this performance killing bug that prevents me from working on anything big. Might be a function of looped engines or something -- I have no idea. Sadly this all came up when the construct team started losing steam and it's gone unfixed for several months.

Not that I can blame a free effort, but I am slightly skeptical over the SAFETY of working on such a game in construct. Though honestly that is the only thing thats ever outright crippled me.
B
12
S
4
G
4
Posts: 238
Reputation: 2,426

Post » Sat Jun 12, 2010 11:33 pm

I've been working on a major game in construct for about a year and a half. It currently has about 5000 events and the game is about a hundred megabytes of data. Here's what I can tell you:

Construct is very, very close to ready for a major game, but what's holding it back from ready status is stuff that can be worked around. There are two things standing in the way:

1. Copying and pasting between .caps is an unfinished feature, and will mess up whatever .cap you paste to (copying and pasting within the same .cap is fine). Therefore, construct is currently only suitable for a game made by one programmer. If one person is coding the whole game, or at the very least only one person is working on it at a time, that's not an issue.

2. There's a memory leak involving the expression/picture editors and how many objects are in a layout. Every time the expression and picture editors are opened, construct will use more memory. Eventually, it will cause construct to crash. The length of time that it takes for construct to crash depends on how many objects are in a layout. This bug is probably going to go mostly unnoticed until you have about 100-200 objects in a layout. Then it gets really annoying. I've had to find ways around opening the expression editor in layouts with lots of objects whenever possible. If this one bug were fixed, then construct would be ready for a major game.

One way to combat this is to make objects be multipurpose when possible by defining different behaviors for the objects based upon variables, so one object can perform multiple tasks. This obviously doesn't work in all circumstances, but it does work for quite a few.

As for the speed of the editor, when you have lots of graphics, it takes longer to save, load and preview, but from what I've noticed, large background images seem to effect the saving/loading/previewing speed the most. I got around this by loading backgrounds at runtime instead of including them in the .cap. It makes it MUCH faster. Doing this reduced the amount of time it took to save, load and preview by about half, maybe more.

Having lots of events mainly makes opening the event editor and previewing take longer, it doesn't seem to affect saving speed much. My battle event sheet is about 2000 events and it takes about 30 seconds to open the first time, and about 10-15 seconds subsequent times.

Even with the issues I've mentioned, it's still doable. It just gets a little awkward trying to avoid opening the expression editor.
Moderator
B
88
S
32
G
33
Posts: 3,005
Reputation: 27,432

Post » Sat Jun 12, 2010 11:39 pm

[quote="Arima":2ibiammt]but from what I've noticed, large background images seem to effect the saving/loading/previewing speed the most. I got around this by loading backgrounds at runtime instead of including them in the .cap. It makes it MUCH faster. Doing this reduced the amount of time it took to save, load and preview by about half, maybe more.[/quote:2ibiammt]

This interests me, care to elaborate or show a thread where the implementation is discussed? Because the idea I have for a game will require large BG images indefinitely.

~t
B
4
S
1
G
2
Posts: 61
Reputation: 997

Next

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 5 guests