Thoughts on my process?

0 favourites
  • 3 posts
  • Hello everyone. New around here (obviously). Actually, I've been lurking for about a year as I contrasted and compared different engines I wanted to use for my.... 'game'. It's not really a game, more like a linear interactive book/comic. No choices, no branching paths. Very simple really. By simple, I mean this is a long post and I hope I am articulating well.

    It's laid out like so

    ['Static' flat background with natural movements (such as wind blowing), repeating background characters when applicable, with the focus being on the actual characters and sometimes text bubbles]

    [A more active foreground presented like comic book/manga panels that move, shake, spin, whatever fits the conversation and mood]

    [Text bubbles being the top most layer unless I have particles or something]

    Anyway, like most normal stories, it's something that will be divided into chapters. I really just need help wrapping my mind around what I'm trying to do here and if it's possible. I'm sure it is somehow, but I'd love the advice of someone more knowledgeable in the ins and outs of Construct compared to me right now. (and I'm not in the position to purchase Construct just yet, I am still researching the free version/tutorials/videos before I gladly hand over the dough)

    I've just finished setting up a prototype of my Title Menu. It goes as follows

    [Start Reading] (will start from chapter 1)

    [Read latest] (will start from latest chapter I've added)

    [Chapter Select] (a scrollable menu in descending chapter order)

    [Options]

    [Credits]

    Right now, I have it set up to direct each page to a new layout when it is clicked by a mouse. I'm not sure if that's the best way to do a menu, but we all gotta start somewhere. (I plan to have the chapter select, options, and credits only be pop up menus maybe)

    Within my 'game' there are various different environments, locations, and perspectives. Let's say there's one called 'Apartment' and one called 'School'. Right now, I've given them both their own layout and I planned to do this for all the different locations.

    In each location, different things will be happening at different times in different chapters with different characters. These layouts aren't as simple as a static map or level because the panels I mentioned before will do different things or have different sizes and shapes for each chapter. (I am working out how I can reuse panels too, or create templates for them, but that's for another day)

    I soon realized setting up my Title Screen to forward to specific layouts would mean repeating certain layouts over and over again with new characters/dialog/panels for each chapter. This wouldn't work... or rather, it would be wasting a lot of resources and creating unnecessary headaches if there was something I wanted to change in the 'Apartment' location across the board.

    SO, am I correct in thinking that... I can set up my chapters as separate event sheets? Can each chapter be an event sheet? Would I then be able to reuse the layouts and use the event sheets to 'act out' the events of each chapter? If that's the case, I'm not sure how I would tell it to move from "Event Chapter 1" to "Event Chapter 2", for example.

    To summarize:

    • I want to have set locations that can be reused for each chapter instead of repeating certain layouts repeatedly - I do not want to repeat the layouts because they change heavily from chapter to chapter
    • I need to know if chapters can be divided with the use of event sheets, and how to move from one sheet to another
    • If it's not possible to use event sheets as chapters, what else can I do?
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Everything you ask is possible. You just have to get familiar with a few concepts.

    -

    Each layout can have its personal event sheet. You assign a event sheet to a layout in the layout's properties (in the left pane).

    But, and that is interesting, you can have event sheets that are not assigned to a layout. You can 'include' those into an assigned event sheet. So, say, you have a bunch of events that are different for each layout, bring them in an assigned event sheet. You have a bunch of events that are the same for each layout, bring them in a unassigned and include them in an assigned event sheet.

    https://www.scirra.com/manual/82/includes

    -

    Global / local objects

    The property 'global' for an object can be "yes" or "no".

    A global object (some are global by default, an array by example) will be 'just there' once it is created.

    If you create a global object in the first layout, it will be present in every layout. And it wil keep its personal info, instance variables .... etc.

    If you jump to another layout, you just take a global object with you. This also means, if that object is present in the next layout, you end up with 2 instance of that object, that one that survived the layout switch + the one that is already present in that next layout.

    Local objects stay in the layout that they are created in. And they will just forget all their (non default) personal stuff (instance variables) when leaving that layout. Default personal stuff is everything that you have set in the layout editor. Everything that you changed to an object during runtime is non default stuff, so that will be all forgotten.

    This is handy, but not always wanted. To avoid this use the Persist behavior.

    https://www.scirra.com/manual/161/persist

    An object with Persist attached to will not forget its personal stuff. So if you leave that layout, and come back, those objects will be the same as you left them.

    -

    Global / local layers.

    Is a layer property. Every object on a global layer with a certain "NAME" will be auto recreated on a layer with the same "NAME" when switching layouts. Say you switch layouts. In the first layout you have a global layer named "HUD". On that layer you have objects. In the next layout you have also a layer named "HUD", but holding not 1 object. When you switch layout, all objects that are on "HUD" in the first layout, will be auto created on the layer with name "HUD" in the second layout.

    https://www.scirra.com/tutorials/594/bu ... terface-ui

    I really have no words to describe how handy this is.

    -

    Global variables.

    Global variables in 1 event sheet are accessible/up-to-change in every event sheet.

    This also means that, if you give each event sheet its own global variables, you will end up with a big mess.

    Rather, make 1 unassigned event sheet, only for the global variables. Dont even include that event sheet.

    Because the fact that they are global, you can use them to get values from one to another layout. They keep there values when changing layouts.

    -

    Other ways to make values survive a layout change.

    Arrays and dictionaries are global objects by default. They do not suffer from the 'duplication' danger that goes with global objects, because they dont have a 'face' in the layout editor. (you can make instances during runtime, but lets avoid that for now)

    Since they are global, you can store values in them, and those values will survive a layout change.

    Perfect to exchange info between layouts.

    -

    On start/end of layout.

    Those conditions are triggers. They run (only once) when a start/end is detected.

    And yes, they for sure run their actions/sub events when you switch layouts.

    You must think those trough, do you want this too happen ?

    If not, you got to constrain them from running every time you enter/leave the layout. This is typical done by evaluating/setting an instance variable of an object with Persist attached.

    -

    Why use Persist ?

    Well, global sprites are a nice thing. But also a PITA.

    Usually you want to design a layout in the layout editor using instances of an object. Say, you switch layouts. In the first layout you designed a maze using instances of 1 sprite. In the second layout you do the same. If you make that sprite global, you will bring the instances created in the first layout with you to the second layout. And that is a mess you dont want.

    So, rather use 'local' objects with the Persist behavior attached. They only live in their layout, and they keep their personal stuff between layout changes.

    -

    Switching layouts 'offline'.

    That is another history. Got to do some tutorials about 'Local Storage'.

    I hope i covered most of the 'layout switch' issues.

  • Thank you so much for the reply! I will digest this as I continuing developing my project.

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