big/large projects

Are there right now difficulties or obstacles in using Construct that makes working on big projects (games) difficult or not smooth?

For example: re-creating the SNES version of Zelda, a remake of Larry 1, a Sam & Max adventure, Fallout 2 (didn't play that one) or Sim City.

I think the limit of the size of a game is set by the computer's hardware the game is supposed to work on, or the Construct user.

Correct?

I believe I have read improvements will come in later versions to oversee projects in a better way and that V-ram control will be enhanced, so perhaps this topic is not about these 2 "issues" I already know of.

(using the search-function I found someone saying a tile-editor is missing and: the 2 topics: "Switching from GM - big projects in construct?" and "buG?")

It can be done if you plan carefully.

Making a custom level builder with repeated resources (IE: what most games do)

can go a long way to saving VRAM. even if you have 100 trees, if they are all the same tree they take the same small amount of VRAM as the single tree.

The only hindrance I have come across is the inability to copy/paste code or layouts into another cap

Again, careful planning can avoid the problems that come with this.

Making a custom level builder with repeated resources (IE: what most games do)

Should I create a Construct Application for this?

>

> Making a custom level builder with repeated resources (IE: what most games do)

>

Should I create a Construct Application for this?

Probably not. A level builder will require the use of sprites which the application runtime doesn't support.

The only problem I've encountered on my RPG (aside from the vram issue, which is taken care of in the next version) is how long it's starting to take to load/save/run files. I've got about 1/10th of the graphics in for my game, and it's already starting to take a while. Loading/saving/running when it's nearing completion could take minutes.

Should I create a Construct Application for this?

n easier way is to just use construct's nice layout editor as a level editor, and export the built levels using events. depending on the way you choose to export your levels, you could then load them from files or copy the levels to clipboard & paste them into an appropriate object in your game.

> Should I create a Construct Application for this?

> n easier way is to just use construct's nice layout editor as a level editor, and export the built levels using events. depending on the way you choose to export your levels, you could then load them from files or copy the levels to clipboard & paste them into an appropriate object in your game.

Yep. This is exactly what I'm doing with Vert. I make a level in the Layout, then run the game, hit a button, and it exports the level as an INI file. Then I copy the contents of the file and stick it in a text object in the game. The level loading sequence can use the text object to, well, load the level.

Once you get the level building/loading sequence done it's pretty easy to build levels. It takes a lot more prep work than just making a bunch of layouts for individual levels, but for a larger project it'll save you a lot of hassle in the long run.

I'd really like to see an example of that method you are mentioing..

>

> >

> > Making a custom level builder with repeated resources (IE: what most games do)

> >

> Should I create a Construct Application for this?

>

Probably not. A level builder will require the use of sprites which the application runtime doesn't support.

I don't think he ment an "Application" in that sense.

http://en.wikipedia.org/wiki/Application_software

It would help you if you built it directly into your game so you can hit a button to go into "Developer Mode" to edit a level.

an INI file can be created to save your level (you could also use a list, hash table, etc.)

I don't think he ment an "Application" in that sense.

Blah, you are probably right. Anyways, the way I save/load my levels is using a list box object. Essentially, each piece has it's own line and the data for each piece is split up like this, separated by commas:

ObjName, X, Y[/code:uonku4i1]

When I load it up in a list box I can simply use the box's "For each line" action to read through each line and have each piece created by name(ObjName).  Of course, if you wanted to add more values for things like width, height, and angle it requires some special object picking to make sure the values are given to the correct object.

I'd really like to see an example of that method you are mentioing..

I may just do that.

You can simplify that by using Text Manipulator's 'load line by line'.

Yep. This is exactly what I'm doing with Vert. I make a level in the Layout, then run the game, hit a button, and it exports the level as an INI file. Then I copy the contents of the file and stick it in a text object in the game. The level loading sequence can use the text object to, well, load the level.

Once you get the level building/loading sequence done it's pretty easy to build levels. It takes a lot more prep work than just making a bunch of layouts for individual levels, but for a larger project it'll save you a lot of hassle in the long run.

And the long way around is to make a level manually (addings sprites), on another layout, so that every layout holds 1 level?

..but for a larger project it'll save you a lot of hassle in the long run.

Why would it save time? I guess it just depends on the type of game you're making.

I didn't say time, I said hassle. Do you really want to have to deal 100+ layouts in your game?

I don't know, I can see that it's saving me a hassle. I guess it might be different for other people. But it was maybe three days of work or so to create the level editor and now I don't have to worry about it, so... yeah. Make one or don't, I guess.