Hello Guest, please login or register.
Did you miss your activation email?
Login with username, password and session length.

Pages: 1 [2]   Go Down

Author Topic: Horn of Balance - editor  (Read 5852 times)

0 Members and 1 Guest are viewing this topic.
Re: Horn of Balance - editor
« Reply #20 on: October 23, 2010, 10:13:35 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, if you know Java, you practically know c#. I notice some very similar things syntax wise between the 2. I have an image export, because since I don't have actual tiles in a room, I need something to reference where the objects should go. Plus it's also handy to show others the room in an image file.

Quote
I know you are supposed to be able to mirror tiles and sprites by setting xscale and yscale to -1. I have tried it with sprites but still unsuccessful. But if it works it would reduce the number of tiles by a half. I think that 1 tileset per room is fine as long as you can also provide a basic background color for the places where there are no tiles and blend color for varying the tile colors. But then again it would go to Pro functions and the MCS Engine should be able to work with the Lite edition. So maybe multiple tilesets would be nice.

True, the feature doesn't have to be used, it may be handy for pro users.


Quote
Martijn: I have some doubts about some of the variables/data you use. A lot of data is mere true/false setting, like chests/doors opened and other permanent dungeon settings. To me it seems that you also might compact it to a single number, used as a boolean array. Which would allow for a bit of a 3D array. But maybe I should sleep a night on it first.

That is a good idea, this is much how the zfgc flaglist works.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #21 on: October 23, 2010, 10:30:43 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
What I was thinking about permanent stuff is to use a 2D matrix where each row represents a dungeon. The first variable in the row is the number of keys that are collected and not used. You don't really need to use a variable of keys not collected or keys already used, because the flag for the key collection event or the door open is either set or not set. Just like defeating the boss, mini boss, getting the master key, getting the compass, blowing holes, small chest and defeating special enemies and pots for keys. I just think that some boolean variables can be done more generic.

And an example image of a room would be a good thing yes, for examples.

Maybe the editor can have a Pro and Lite setting. With pro enabling some additional features.
Logged
Re: Horn of Balance - editor
« Reply #22 on: October 24, 2010, 06:20:22 am »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1626
What I was thinking about permanent stuff is to use a 2D matrix where each row represents a dungeon. The first variable in the row is the number of keys that are collected and not used. You don't really need to use a variable of keys not collected or keys already used, because the flag for the key collection event or the door open is either set or not set. Just like defeating the boss, mini boss, getting the master key, getting the compass, blowing holes, small chest and defeating special enemies and pots for keys. I just think that some boolean variables can be done more generic.

Could you give a coding example of this suggestion in action?


Edit: Never mind. I read through the sponsored section again.

To me it sounds too much like preference to also implement it into my engine. As I stated in the request: I'm not looking to change the inner workings of my engine just to fit the editor's output. Like for instance changing the way I handle indicators or changing the way the map menu or a textbox is constructed (I suspect our engines will differ there as well). Such things should not be needed to work together with an editor. Handling tiles is an exception because that's new and thus needed. The editor itself can do whatever it wants with it's own mechanics.

I'm not trying to be an ass about this one subject. It may sound like it right now, but I'm really not. It's just that these kinds of differences in approach are bound to happen a lot (with some far more complex) and I want to make clear where I stand.
« Last Edit: October 24, 2010, 08:14:43 am by Martijn dh »
Logged
Re: Horn of Balance - editor
« Reply #23 on: October 24, 2010, 08:50:23 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Well, it is difficult to put in GM code, because I don't know exactly what your code is. Thus I'll do it in semi pseudo code But you have the following:

x -> is the number of the current dungeon.
dungeon[x,0] -> number of keys still available to Link
dungeon[x,1] -> temporary status indications that only last as long as Link visits this room cluster.
dungeon[x,2]-[x,4] -> the permanent status of the dungeon.

This is the code to execute a dungeon achievement with the dungeon number and index
Code: Text
  1. flag = ( index div 53 ) + 2
  2. flag_index = index mod 53
  3.  
  4. dungeon[x,flag] = setFlag(dungeon[x,flag], flag_index);
  5. // Set flag already checks whether it is already set or not.
  6.  
  7.  

This is code that is executed when Link is opening a chest. Note that each chest has a variable denoting the index of the permanent status and a variable to denote whether it is opened or not:
Code: [Select]
if !chest.opened

    chest.opened = true
   
    give Link the contents and if the contents is a small key dungeon[x,0] += 1

    setDungeonAchievement(x, chest.index)


Opening a door is similar. It also has a variable opened and an index. Off course when the door is opened by a switch or dungeon puzzle you don't need to bother with checking keys.
Code: [Select]
if !door.opened and dungeon[x,0] > 0

    door.opened = true

    setDungeonAchievement(x, door.index)

    decrease the number of small keys dungeon[x,0] -= 1


Dungeon bosses are a common element in dungeons, thus it does not need to have an index. Just like a mini-boss. Just put this code where the boss gets destroyed:
               setDungeonAchievement( x, BOSS )


And always when you have to decide when a chest or door is opened, which is mostly in create events:
                if checkDungeonAchievement( x, index )
                          opened = true
                else
                          opened = false

And similar for whether you need to create the Boss
                if !checkDungeonAchievement( x, BOSS )
                           createBoss()

For the dungeon boss door where you need the big key when opening you do the following
                if checkDungeonAchievement( x, BIGKEY )
                            open the dungeon boss door.

Reseting the temporary status values is than something simple as dungeon[x,1] = 0;

I don't know what every array is used for with your code and how much objects play a role in your code and maintain status values about themselves. But I do know that a door that is already opened, cannot take a key again and a chest that has already been opened, a pot that has already given a key cannot provide a key. Thus you don't need to check how many keys are still left or keys that are already spent, because either the chest or door has not been opened.

My point is that with true false status indications, using a single number as a boolean array would be better than having long arrays. It saves in used memory, although PC's have already a lot of memory. When saving this data to a file you only need to save a few numbers instead of an entire array.
Logged
Re: Horn of Balance - editor
« Reply #24 on: October 24, 2010, 10:22:10 am »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1626
Well, it is difficult to put in GM code, because I don't know exactly what your code is. Thus I'll do it in semi pseudo code But you have the following:

x -> is the number of the current dungeon.
dungeon[x,0] -> number of keys still available to Link
dungeon[x,1] -> temporary status indications that only last as long as Link visits this room cluster.
dungeon[x,2]-[x,4] -> the permanent status of the dungeon.

This is the code to execute a dungeon achievement with the dungeon number and index
Code: Text
  1. flag = ( index div 53 ) + 2
  2. flag_index = index mod 53
  3.  
  4. dungeon[x,flag] = setFlag(dungeon[x,flag], flag_index);
  5. // Set flag already checks whether it is already set or not.
  6.  
  7.  

Let's see if I understand correctly.
show_message(string(dungeon[x,0])) would give me "01010001001..."?
dungeon[x,0] would contain the same data as the array Key_Collected[index] with indicators ranging [0-9]?

It seems elegant if so but we'd need to define clear guidelines for what this data means.
flag = ( index div 53 ) + 2
I assume the first two positions have a special function like keeping track of how many variables are effectively stored.
In my own engine I did something simular:
Code: [Select]
// Small chest info
Chest_Last = 9;
Chest_Opened[0] = 0; Chest_Floor[0] = 4; Chest_X[0] = 48; Chest_Y[0] = 60; Chest_Master[0] = 0;
Chest_Opened[1] = 0; Chest_Floor[1] = 4; Chest_X[1] = 30; Chest_Y[1] = 46; Chest_Master[1] = 0;
Chest_Opened[2] = 0; Chest_Floor[2] = 4; Chest_X[2] = 88; Chest_Y[2] = 46; Chest_Master[2] = 0;
Chest_Opened[3] = 0; Chest_Floor[3] = 4; Chest_X[3] = 72; Chest_Y[3] = 14; Chest_Master[3] = 0;
Chest_Opened[4] = 0; Chest_Floor[4] = 5; Chest_X[4] = 87; Chest_Y[4] = 14; Chest_Master[4] = 0;
Chest_Opened[5] = 0; Chest_Floor[5] = 4; Chest_X[5] = 46; Chest_Y[5] = 12; Chest_Master[5] = 0;
Chest_Opened[6] = 0; Chest_Floor[6] = 3; Chest_X[6] = 71; Chest_Y[6] = 23; Chest_Master[6] = 0;
Chest_Opened[7] = 0; Chest_Floor[7] = 5; Chest_X[7] = 95; Chest_Y[7] = 14; Chest_Master[7] = 0;
Chest_Opened[8] = 0; Chest_Floor[8] = 4; Chest_X[8] = 58; Chest_Y[8] = 43; Chest_Master[8] = 1;
Chest_Opened[9] = 0; Chest_Floor[9] = 3; Chest_X[9] = 34; Chest_Y[9] = 61; Chest_Master[9] = 1;
The first variable tells how many chests exist (for this area). This is mainly done for the creation of the map since you need to know how long you array is. In your solution this is constant so it's no issue, but I can image though that you won't want to loop through 53 possible chests when you only have one.


This is code that is executed when Link is opening a chest. Note that each chest has a variable denoting the index of the permanent status and a variable to denote whether it is opened or not:
Code: [Select]
if !chest.opened

    chest.opened = true
    
    give Link the contents and if the contents is a small key dungeon[x,0] += 1

    setDungeonAchievement(x, chest.index)


Opening a door is similar. It also has a variable opened and an index. Off course when the door is opened by a switch or dungeon puzzle you don't need to bother with checking keys.
Code: [Select]
if !door.opened and dungeon[x,0] > 0

    door.opened = true

    setDungeonAchievement(x, door.index)

    decrease the number of small keys dungeon[x,0] -= 1


You only need three core variables per chest (for now). What is it's index? Is it opened? What was it contents? I store the second and third high over and the first as a variable as a property of the chest. The chest object is something that gets reset when you exit and enter a Area/Cluster. I'm talking about the entire object and thus the variable attached to it is also constantly reset.

You only need:
Code: [Select]
if !getDungeonAchievement(x, chest.index)

    give Link the contents and if the contents is a small key dungeon[x,0] += 1

    setDungeonAchievement(x, chest.index)
When you've opened the chest just delete it while leaving the masking. Or turn it invisible, depending on your preference in masking.

Something simular can be said for the locked doors.
Code: [Select]
if !getDungeonAchievement(x, door.index) and dungeon[x,0] > 0

    setDungeonAchievement(x, door.index)

    decrease the number of small keys dungeon[x,0] -= 1

I make a distincion between locked doors and otherwise closed doors, but that's for another day.


I don't know what every array is used for with your code and how much objects play a role in your code and maintain status values about themselves. But I do know that a door that is already opened, cannot take a key again and a chest that has already been opened, a pot that has already given a key cannot provide a key. Thus you don't need to check how many keys are still left or keys that are already spent, because either the chest or door has not been opened.

My point is that with true false status indications, using a single number as a boolean array would be better than having long arrays. It saves in used memory, although PC's have already a lot of memory. When saving this data to a file you only need to save a few numbers instead of an entire array.

I wend about it in somewhat the same way at first with the keys, but it's deceptive. Let's say you break a pot, a key appears and then you walk away. XD
You need to track each key that can be missed and then you might as well track them all. Doors are somewhat simular in that you are working in pairs. Saving that data on the area level saves you some headache as well.

Looking over your explination I'm starting to warm up to your idea, but there are the few issues I mentioned. It is then important that we are both in agreement on how the data needs to be saved. Like a uniform template. We wouldn't want your data to look like A and mine like B.

A.
dungeon[x,0] -> number of keys still available to Link
dungeon[x,1] -> temporary status indications that only last as long as Link visits this room cluster.
dungeon[x,2]-[x,4] -> the permanent status of the dungeon.

B.
dungeon[x,0] -> number of keys still available to Link
dungeon[x,1] -> the permanent status of the dungeon.
dungeon[x,2] -> tracks broken walls
dungeon[x,3]-[x,4] -> temporary status indications that only last as long as Link visits this room cluster.
« Last Edit: October 24, 2010, 10:27:41 am by Martijn dh »
Logged
Re: Horn of Balance - editor
« Reply #25 on: October 25, 2010, 09:00:29 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Your B variation is also possible. And about opening doors and chests. A similar thing is what I thought after I posted it. I was just too lazy to change it.

 I'll come back later on the flaglists, but I can say one thing that it is important to differentiate between status data and just creation data. I know that status information is also used in the room creation, but status information changes over the course of the game and creation information is hardcoded. I just have a question. Do you have all the creation information defined in the creation event of a room or in a script.

Xfixium, how have you dealt with dungeon and overworld data in OOT2D?

About the keys. It is important that you make a distinction between keys as a reward and as collectibles. Rewards are given by chests and NPC's. During creation it is already checked whether the chest has been opened or not. And when Link opens the chest the chest increases the number of carried keys and sets the appropriate achievement flag (this is what I meant with index). With pots and enemies, they are told when to drop the key. At this moment they check if the key has been retrieved and if not they drop a collectible object that is the key and pass the respective achievement flag. Once Link actually picks up the collectible key the achievement flag is set by the collectible key. Or at least that is how I think about it.
Logged
Re: Horn of Balance - editor
« Reply #26 on: October 25, 2010, 09:17:51 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Quote
Xfixium, how have you dealt with dungeon and overworld data in OOT2D?

Haven't yet, still just in basic engine, concepts, resources, and design phases at this point. The only data like that I have dealt with is one lone chest that contains the Kokiri Sword. Also the main equipment menu. Which I have used grid data structures for.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #27 on: October 26, 2010, 08:18:52 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1626
Do you have all the creation information defined in the creation event of a room or in a script.

Object creation is done in the object's creation code, accessable in Gamemaker's room editor. In the Gamemaker's room creation coding there are three variables stored: floor number, dungeon number and background sound. I can image this data will need to be relocated to the area level. About 95% of the remaining creation data is stored in scripts. There are some instances where default object values are just defined in the object's creation event. It seemed silly to create scripts for just two variables.


About the keys. It is important that you make a distinction between keys as a reward and as collectibles. Rewards are given by chests and NPC's. During creation it is already checked whether the chest has been opened or not. And when Link opens the chest the chest increases the number of carried keys and sets the appropriate achievement flag (this is what I meant with index). With pots and enemies, they are told when to drop the key. At this moment they check if the key has been retrieved and if not they drop a collectible object that is the key and pass the respective achievement flag. Once Link actually picks up the collectible key the achievement flag is set by the collectible key. Or at least that is how I think about it.

I'd explain how my approach some more as well, but I don't think discussions like this are the way to go. I've been working on my game for a while now and have created something that, to me, works well, uniform and is pleasant to understand. I image you feel the same about your own work, as it too is something someone can be proud of. We both believe we made the right choices or else we wouldn't have made them. I'm a little further ahead in my engine in that I've got some more featured working together and have run into quite a number of issues because of that already. To change core mechanics on a whim while I have doubts wether or not it's solid enough to handle the issues that I've already tackled... it's not very tempting. Don't get me wrong. I'm not saying your idea's are bad. Maybe you won't run into the same issues I have. Who knows. Just please respect that I build my own engine with care over the last two years and take slight offense when I should alter it after showing just a part of coding. These pieces are part of a larger whole that works together quite nicely. Every engine has points that can be done differently, sure. My game works solid though and thus needs no change. Nor does it lag or have memory issues.

The thing I was thinking of today was that an engine should not have to change to suite the editor. Not mine. Not yours either. If we brought in a third engine it would be completely different from ours as well and the editor might quite possible not be able work for it. So how about the following. We just allow people to edit the editor. The following is obviously also directed to Xfixium.

Let's take the level structure of area/cluster/room as a given. As well as the flag system for stoing groups of indicators/data. The area level holds the variables needed for rooms (position, dimensions, etc), clusters hold some data (cluster indexes for instances) and the tiling data will need to be defined (in combination with a depth system). Think bare minimum here. All engines are eventually the same in that regard. Next we allow the creator to add the variables he/she wishes to the layers and objects used for editing his/her game.

I can imagine an object list (or tree maybe) with a + symbol available. Upon clicking you add a generic object with zero properties and then have the option to add in a variable. Doing so gives you the option to have it be a numeral, string, array, flaglist, flag/boolean or a referencing to (the index of) another object/room/level. After choosing your selection you set a default value. If the variable does not allow change then there needs to be a checkbox for that. Afterwards, when you are doing the actual editing, you get to place the new object on your map having your added variables in it's properties. I'm suggesting the same kind of possibilities for area's, and clusters as well. To be able to add variables to it and choose the type of variable.

Two suggestions might need some more explaining.
- I'd advise allowing the user to add a variable that is a reference to (the index of) another object/room/level for two reasons. One is objects like transition points, where you want to have a reference to a destination. The other is a user friendly interface. I can imagine a dropbox for these kinds of variables showing all possible area's/rooms/clusters by name.
-Second is allowing the user to add a variable that is a flaglist or flag. This may be best explained with an situation. You add a flaglist variable to the area level. Then you define an object with an flag variable. We probably have different idea's on what a flag is, but what I'm picturing right now is a boolean that you can link to a flaglist somewhere (through another dropbox maybe). In this case we link to the flaglist on the area level. So if we add the flaglist chests to area and the flag chest_index to an chest object then we can link those and we'd have found a way of defining and filling flaglists.

------

Bottomline: I'm just thinking out loud here as an idea like this would still need plenty of refinement. Note that I skipped the sprite/mask properties on purpose to keep it simple. We can end a lot of future discussion about how we should handle things with this (by basicly allowing all options). You could then even use the editor for a metroid game if you wanted to.
« Last Edit: October 26, 2010, 08:32:12 pm by Martijn dh »
Logged
Re: Horn of Balance - editor
« Reply #28 on: October 27, 2010, 09:23:46 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
I get what your saying, I started working on it. A lot of extra work it seems, but we can go through the steps of development as usual, until we're all satisfied with what has been created. This would be an upgrade for my project as well, as I have been thinking about maybe finding a way to reduce Team Dekunutz project to about 2 working rooms. A setup room, which would define all the instances, dimensions, and tiles for the "playable" room.
Logged
  • Pyxosoft
Pages: 1 [2]   Go Up

 


Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved



Page created in 0.059 seconds with 56 queries.