Developing a Game as Separate Modules

This forum is currently in read-only mode.
From the Asset Store
five golem elements Sprites Sheet.Best for enemy or villain game characters.
  • Hi,

    First of all I like thank all the developers of Construct for creating such a wonderful tool. I have tried several game creation tools, but I still didn�t find a tool that has the WYSIWYG capabilities AND rapid development facilities, which Construct has.

    I have created few small games individually and now I am planning to create a game with some of my friends.

    We wanted to develop the game with several levels. And each of our friends wants to work on "separate levels". Because my friends are in several locations and they want to create their level individually.

    When we plan to integrate our levels, we faced a problem. We couldn�t find a way to integrate separately created games in to a one game. We tried to copy layouts and event sheets between application and failed copy event sheets between different applications.

    One method we tried was,

    1) Create each level as separate .exe files.

    2) At the end of level 1, it is saving the current state/ variables etc in a file (say myFile), and calling level2.exe and closing level1 application.

    3) Level.exe loads state/ variables from myFile.

    4) At the end of level2, it saves current state in myFile, calls level3.exe, closing level2.exe and so on.

    With the above method we made it possible to work in separate levels as separate exe files.

    I understand that this is not the way to have to several levels in a game created with Construct. But we want to work on levels as separate units and integrate them in a later stage of the development. In other terms, I want to modularize this game and develop it with bottom up approach.

    Can someone please help us with suggestions to develop a game as separate modules and integrate later?

    Thanks in Advance.

    • Ramesh
  • What I would do is create a level editor, and let your friends make levels with that. Plan out how you are going to save your level data into an array, and make your events accordingly. I have already done such a thing in Multimedia Fusion, and I don't see why the same thing can't be done in Construct.

    EDIT: Now that I think about it, it would probably be easier to do in Construct, since Construct allows you to create objects by name. Less busy work, more useful eventing.

  • Someone has already requested that copying levels/events between applications and I think it is definately a very important thing to add. So hopefully that will be added soon and you'll be able to use that

  • There should be other collaboration features too, like exporting single layouts or event sheets, or consisting projects of many .caps. But they are not that important that they couldn't wait past 1.0...

  • Copying and pasting layouts is not yet implemented which is a bit of a problem - hopefully once that's added it'll become a bit easier for you. Until then, unfortunately I think the best option is to send around one .cap file to each other...

  • Copying and pasting layouts is not yet implemented which is a bit of a problem - hopefully once that's added it'll become a bit easier for you. Until then, unfortunately I think the best option is to send around one .cap file to each other...

    Thanks Ashley. I didn�t know that this feature is not implemented yet. I thought that it is currently possible and I was thinking that I didn�t find the correct way to do that. Anyway we are going to continue with the currently available features of Construct. We hope see this useful event copy/ event export feature in future releases of Construct.

  • What I would do is create a level editor, and let your friends make levels with that. Plan out how you are going to save your level data into an array, and make your events accordingly.

    Yes, I agree with you. The method you are specifying is a good way to develop levels. But at the moment we are trying to develop the game only using the features available with Construct 0.96.4 release. Therefore I am looking for a already available technique/ trick to modularize the game without modifying the source code of Construct.

  • Yes, I agree with you. The method you are specifying is a good way to develop levels. But at the moment we are trying to develop the game only using the features available with Construct 0.96.4 release. Therefore I am looking for a already available technique/ trick to modularize the game without modifying the source code of Construct.

    You wouldn't need to modify the Construct source-code to make a level editor.

  • I was working on a proof of concept *.cap for you yesterday, however several bugs with the Layout object halted my progress. The level editor can still be done, but the GUI would be alot different than what I had in mind. I probably can't finish it before I leave for seattle though (going to the Penny Arcade Expo)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ramesh, I believe something like this is the solution you're looking for:

  • Ramesh, I believe something like this is the solution you're looking for:

    Thanks deadeye. This is really interesting.

    But my actual requirement is bit different. I will describe it using a sample game concept.

    Let�s say we have a game with 3 levels. And we will name our main character as �Rider�

    Level 1:

    This is like a "platform game" (E.g.:- Mario). Rider is moving through several obstacles to search for his car. After passing through a given number of obstacles Rider can complete Level 1. And he receives his car as a reward for completing Level 1.

    Level 2:

    Now Rider is driving the car which he received after completing the Level 1. But this time this is not a "platform type" game. Now this becomes a driving game with "top-down view style". And a car will be displayed instead of Rider and the "car behavior" will be applied for that car.

    The car has to move through a city. And the player should move the car to an end point within a given period of time. If the car can come to end point within that time period, we can say Level 2 completed.

    After the completion of Level 2, Rider leaves the car and going to visit a friend. The friend suggests Rider to participate for a sport festival which involves playing a pong like game. This is the start of Level3.

    Level 3:

    The main objective of this level is to win a series of pong like games. This level will mainly involve physics behavior of a ball. At the end of this level the total score earned by all 3 levels will be displayed and stored in a file. At the beginning of the game a High Score list will be displayed and other users can try to beat the highest score.

    Above game is just an example to describe my requirement. Please note that these 3 levels are different in game genre and view style. Also note that each level has different game logic. If all of levels are in same game genre, and if they have same game logic, it will be easy to create a level editor.

    Also this will be easy if only one developer is developing all 3 levels in a one .cap file. But our problem is several friends of mine (in different locations) want to work in several .cap file. That means level 1, 2, and 3 will be developed by 3 developers in 3 .cap files. And we have to use different game logics in different levels. Finally we need to integrate these levels. In that case we are facing difficulties.

    You wouldn't need to modify the Construct source-code to make a level editor.

    Yes, I agree with you in the context of developing a level editor for a game which has similar game logic throughout all levels. But in our case game logics/ event sheets are very different in each and every level. We want to store not only the static aspects (sprites etc.) of the game, but also the dynamic aspects of the game (events etc.) to separate level files for separate levels.

    I was working on a proof of concept *.cap for you yesterday, however several bugs with the Layout object halted my progress. The level editor can still be done, but the GUI would be alot different than what I had in mind. I probably can't finish it before I leave for seattle though (going to the Penny Arcade Expo)

    This is good news. And if you are thinking about a new approach for a level editor, you can also think about the points I described in this mail as some design issues.

    Thanks,

    • Ramesh
  • > I was working on a proof of concept *.cap for you yesterday, however several bugs with the Layout object halted my progress. The level editor can still be done, but the GUI would be alot different than what I had in mind. I probably can't finish it before I leave for seattle though (going to the Penny Arcade Expo)

    >

    This is good news. And if you are thinking about a new approach for a level editor, you can also think about the points I described in this mail as some design issues.

    Thanks,

    - Ramesh

    My plan was to make a level editor that was easily adaptable to any game... but it seems every time I try to work on this, I uncover some show-stopper bug before I make any significant progress. First it was the layout object. I figure it may take some time to get that fixed, so I decided to scrap my other layouts and hack together some other kind of UI... when I came across that bug where objects on deleted layouts remain in the application... somewhere... That bug has been fixed, but now the debugger doesn't work at all.

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