This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1161

Updates / Re: Nominations - October 2010

« on: October 31, 2010, 08:51:15 pm »

Yeah, sure. If you want.

1162

Updates / Re: Nominations - October 2010

« on: October 31, 2010, 07:42:20 pm »

Wow I've been nominated. I'm so motivated to get Gismor done now as a thanks to whoever nominated Chiming Bell again so I can release the next boss screenshots

Thanks to whoever nominated my project

No thanks needed. I just browsed through the topics and noticed you recently posted some interesting screenshots.

Voting can now begin. I'll start with two votes for now.
First is Ocarina of Time 2D because the (rare) screens that come out look very well made. There is a large team working on it for a while now and that gives me confidence that it'll be around long enough to deliver on the promise of a nice first demo.
My second vote goes to Leduardo's Custom Tiles. It's been around a while as well and the sprites just look very well made in my eyes.

1163

Updates / Nominations - October 2010

« on: October 31, 2010, 07:31:11 pm »

Sorry about the delay. It's still october so we should be okay .
Let's go over the rules again real quick.

Rules:
- Projects to vote for will still be pre-selected as usual. Your project will be pre-selected if it has shown some form of relevant progress during the current month. Think along the lines of a new demo, screenshot, video etc.

- Normally selection only applies to the projects in the topics: Sponsored, Completed, WIP, WIP other and Concepts. We now expand the range to also include projects from Templates, Graphics and Audio. The projects also need to have shown some form of relevant progress. There are added rules for them though: they will need to contain more then just one sound/picture or template (whichever applies). It may not be a request topic. Basicly the aim is to only nominate continued projects.

- You now have the option to vote in the poll. (If one is not yet present when you read this, then one will be added shortly). Posting a comment explaining why you voted for one project over another is no longer needed, but it is still highly encouraged. I will obviously do creator's good to read some friendly feedback, but it will also make the difference in case of a tie. If there is a tie and no relevant comments are present then I'll have to favor one over the other personally and I'd rather avoid that.

- Every project to get votes in a month will have earned a place in the Sponsored section for the month that follows. If a project does not get any votes during month then it will not be in Sponsored in the following month. This also happens if the project was not nominated due to lack of progress. The project with the most votes is crowned Project of the Month. The creator will receive a message from me in regard to a short interview and the creation of a PotM topic.

- You all gets the option to vote for multiple projects a month (if they so please). As each voted project moves to Sponsored you could use your votes for moving various interested topics as a sign of support. Or you could vote for just that one topic you really favour for PotM. And if you're always torn up between multiple topic then this is the sollution for that too. Just vote for both. Just remember that each vote hold equal weight. If for you vote for more projects, but really only favor one in particular for PotM then you can always add a comment and explain. It'll make a difference in the case of a tie or it could convice others to vote for your favourite as well.


New rule:
- Attempts at faul play (like having lots of outsiders come here just to vote for your game) will result in your project getting disqualified. Do it more then once and you are risking a ban.
- Voters must have made a minimal of 10 (meaningfull) posts for there vote(s) to be considered valid.


This month's nominations (you have 5 days to cast your vote):
Tech demo - Horn of Balance
Surface
Ode to GB Zelda
Sprite Builder
The Legend of Zelda: Black Crown
The Legend of Zelda: The Sage Knight
Zelda Engine with MC graphics
TLOZ: Chaos Rising
Ocarina of Time 2D
LoZ: The Awakening of a Shadow
The Myth of Heroa
[Alpha] Map Editor 0.7a
Super Smash Bros - ZFGC
The Legend of Zelda: Heart of the Master Sword
The Legend of Zelda: The Hylian Phoenix
The Legend of Zelda: Chiming Bell
Leduardo's Custom Tiles

1164

Other Projects / Re: [Demo] Tech demo - Horn of Balance (working title)

« on: October 31, 2010, 11:38:23 am »

Just a little post to mention I'm still working on it, as always.
I've basicly finished the mechanic behind getting shocked several days ago. The visual screeneffect that accompanies it is a completely different story though. It's not too hard to think up a solution. It's hard to do it with a minimal drop in framerate (it currently still drops to around 15fps on my pc). These two goals work together very badly it seems. The presence of uneffected sprites (in between layers of tiles) is especially hard to mimic with low costs.

When I'm more or less done (or giving up trying to further improve the speed) I'll post a crude demo for people to test the performance themselves.

1165

Discussion / Re: Horn of Balance - editor

« on: October 26, 2010, 08:18:52 pm »

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.

1166

Discussion / Re: Horn of Balance - editor

« on: October 24, 2010, 10:22:10 am »

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.
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.

1167

Discussion / Re: Horn of Balance - editor

« on: October 24, 2010, 06:20:22 am »

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.

1168

Discussion / Re: Horn of Balance - editor

« on: October 23, 2010, 08:55:13 pm »

Oops. I meant it differently. If my engine can receive numeric values in one way, shape or form then I'm happy. Forget the rest of my comments (it's been a long day so I may be getting a little sloppy in my wording).

As for the tileset. I meant one tileset per in-game room instead of per Cluster/Gamemaker room. Though I'm not sure how much of an advantage will be left between that and just using multiple tilesets everywhere. There'd still be the same issues I mentioned if done per cluster.

1169

Discussion / Re: Horn of Balance - editor

« on: October 23, 2010, 07:55:44 pm »

Okay, so should I consider it as a "textfile" containing a bunch of numbers/values/stats (only then in binairy format)? Man, I feel like a total noob right now. Hahaha. I'm just trying to get an idea for how much I'll have to edit my engine. I'm also interested in knowing what happens when gamemaker v9.0 comes out someday.

Niek: I was kinda already thinking your project might benefit.

Edit:

Am I safe to assume that only one tileset is needed per area? Could do things like flipping tiles within the editor. Since tiles can be scaled.

I almost skipped reponding. One background per area would work for dungeons, but I'm not sold on the overworld. If you use one tileset per area the result is that you have to switch gamemaker rooms to be able to change the scenario. And that means building in delays to mask the inability to scroll property. Considering they the scenery every few screens in alttp ... One tileset(index) per room would give the creator more options.

Tiles in gm only have the following options (sorry, no rotation):
background. The background resource from which the tile is taken.
left, top, width, height. The part of the background that is used.
x,y. The position of the top left corner of the tile in the room.
depth. The depth of the tile. You can choose any depth you like, making tiles appear between object instances.
visible. Whether the tile is visible.
xscale, yscale. Each tile can be drawn scaled (default is 1).
blend. A blending color used when drawing the tile.
alpha. An alpha value indicating tile transparency. 1 = not transparent, 0 = fully transparent.

1170

Discussion / Re: Horn of Balance - editor

« on: October 23, 2010, 07:22:16 pm »

Oops, I forgot the floor level I'll make things simple. Consider the cluster to also be a floor when talking about a dungeon area.

It's probably best if I only talk in terms of the engine for a bit. This is what is stored at the area level at this time (for a dungeon):

Code: [Select]

// Dungeon map
for (i=0; i<11; i+=1) {Dungeon_Map_Floors[i] = 0};
Dungeon_Map_Floors[3] = 1;
Dungeon_Map_Floors[4] = 1;
Dungeon_Map_Floors[5] = 1;

// Hero position
Dungeon_Map_Hero_Floor = 0;
Dungeon_Map_Hero_Room = 0;
Dungeon_Map_Hero_X = 0;
Dungeon_Map_Hero_Y = 0;
Dungeon_Map_Hero_Sprite = 0;

// Boss position
Dungeon_Map_Boss_Floor = 3;
Dungeon_Map_Boss_Room = 1;

// Part of item menu
Equipment_C1 = 0;
Equipment_C2 = 0;
Equipment_C3 = 0;

// Number of keys + Collectable keys
Key_Value = 0;
for (i=0; i<=3; i+=1) {Key[i]=0}; // 0 = not collected / 1 = collected

// 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;

// Locked Doors
for (i=0; i<=7; i+=1) {Locked_Door[i]=1}; // 0 = open / 1 = closed

// Dungeon resetable values:
// > Conditional Doors
// > Pressure Plates
// > Crash Switches
// > Temp_Dungeon_Condition
// > Fragile Floors
script_Reset_Variables_Dungeon_1();

// Dungeon entrances on map
Last_Entrance_Index = 0;
Entrance_Direction[0] = 90; Entrance_Floor[0] = 5; Entrance_X[0] = 58; Entrance_Y[0] = 100;

// Room info floor B2
Last_Room_Index[3] = 8;
for (i=0; i<=Last_Room_Index[3]; i+=1) {Room_Visible[3,i]=0}; // used for dungeon map
for (i=0; i<=Last_Room_Index[3]; i+=1) {Room_Visit_Count[3,i]=0}; // used for respawning enemies
Room_Sprite_X[3,0]=0; Room_Sprite_Y[3,0]=24; Room_Sprite_W[3,0]=8; Room_Sprite_H[3,0]=8; Room_Sprite_Location_X[3,0]=4+8*3+4; Room_Sprite_Location_Y[3,0]=4+8*7; Room_Xa[3,0]=0; Room_Ya[3,0]=0; Room_Xb[3,0]=320; Room_Yb[3,0]=320;
Room_Sprite_X[3,1]=8; Room_Sprite_Y[3,1]=40; Room_Sprite_W[3,1]=8; Room_Sprite_H[3,1]=8; Room_Sprite_Location_X[3,1]=4+8*3+4; Room_Sprite_Location_Y[3,1]=4+8*8; Room_Xa[3,1]=0; Room_Ya[3,1]=320; Room_Xb[3,1]=320; Room_Yb[3,1]=640;
Room_Sprite_X[3,2]=0; Room_Sprite_Y[3,2]=88; Room_Sprite_W[3,2]=8; Room_Sprite_H[3,2]=8; Room_Sprite_Location_X[3,2]=4+8*3+4; Room_Sprite_Location_Y[3,2]=4+8*9; Room_Xa[3,2]=0; Room_Ya[3,2]=640; Room_Xb[3,2]=320; Room_Yb[3,2]=960;
Room_Sprite_X[3,3]=8; Room_Sprite_Y[3,3]=88; Room_Sprite_W[3,3]=8; Room_Sprite_H[3,3]=8; Room_Sprite_Location_X[3,3]=4+8*4+4; Room_Sprite_Location_Y[3,3]=4+8*9; Room_Xa[3,3]=320; Room_Ya[3,3]=640; Room_Xb[3,3]=640; Room_Yb[3,3]=960;
Room_Sprite_X[3,4]=0; Room_Sprite_Y[3,4]=80; Room_Sprite_W[3,4]=8; Room_Sprite_H[3,4]=8; Room_Sprite_Location_X[3,4]=4+8*5+4; Room_Sprite_Location_Y[3,4]=4+8*9; Room_Xa[3,4]=640; Room_Ya[3,4]=640; Room_Xb[3,4]=960; Room_Yb[3,4]=960;
Room_Sprite_X[3,5]=0; Room_Sprite_Y[3,5]=16; Room_Sprite_W[3,5]=8; Room_Sprite_H[3,5]=8; Room_Sprite_Location_X[3,5]=4+8*6+4; Room_Sprite_Location_Y[3,5]=4+8*9; Room_Xa[3,5]=960; Room_Ya[3,5]=640; Room_Xb[3,5]=1280; Room_Yb[3,5]=960;
Room_Sprite_X[3,6]=32; Room_Sprite_Y[3,6]=0; Room_Sprite_W[3,6]=16; Room_Sprite_H[3,6]=8; Room_Sprite_Location_X[3,6]=4+8*6; Room_Sprite_Location_Y[3,6]=4+8*4+4; // AL  -- under construction
Room_Sprite_X[3,7]=32; Room_Sprite_Y[3,7]=24; Room_Sprite_W[3,7]=16; Room_Sprite_H[3,7]=8; Room_Sprite_Location_X[3,7]=4+8*8; Room_Sprite_Location_Y[3,7]=4+8*1; Room_Xa[3,7]=320; Room_Ya[3,7]=0; Room_Xb[3,7]=960; Room_Yb[3,7]=320;
Room_Sprite_X[3,8]=32; Room_Sprite_Y[3,8]=32; Room_Sprite_W[3,8]=16; Room_Sprite_H[3,8]=8; Room_Sprite_Location_X[3,8]=4+8*8; Room_Sprite_Location_Y[3,8]=4+8*2; Room_Xa[3,8]=320; Room_Ya[3,8]=320; Room_Xb[3,8]=960; Room_Yb[3,8]=640;

// Room info floor B1
Last_Room_Index[4] = 29;
for (i=0; i<=Last_Room_Index[4]; i+=1) {Room_Visible[4,i]=0}; // used for dungeon map
for (i=0; i<=Last_Room_Index[4]; i+=1) {Room_Visit_Count[4,i]=0}; // used for respawning enemies
Room_Sprite_X[4,0]=0; Room_Sprite_Y[4,0]=8; Room_Sprite_W[4,0]=8; Room_Sprite_H[4,0]=8; Room_Sprite_Location_X[4,0]=4+8*6+4; Room_Sprite_Location_Y[4,0]=4+8*11; Room_Xa[4,0]=1120; Room_Ya[4,0]=3520; Room_Xb[4,0]=1440; Room_Yb[4,0]=3840;
Room_Sprite_X[4,1]=48; Room_Sprite_Y[4,1]=16; Room_Sprite_W[4,1]=16; Room_Sprite_H[4,1]=16; Room_Sprite_Location_X[4,1]=4+8*6; Room_Sprite_Location_Y[4,1]=4+8*9; Room_Xa[4,1]=1050; Room_Ya[4,1]=2880; Room_Xb[4,1]=1510; Room_Yb[4,1]=3520;
Room_Sprite_X[4,2]=48; Room_Sprite_Y[4,2]=32; Room_Sprite_W[4,2]=16; Room_Sprite_H[4,2]=16; Room_Sprite_Location_X[4,2]=4+8*6; Room_Sprite_Location_Y[4,2]=4+8*6; Room_Xa[4,2]=960; Room_Ya[4,2]=1920; Room_Xb[4,2]=1600; Room_Yb[4,2]=2560;
Room_Sprite_X[4,3]=48; Room_Sprite_Y[4,3]=32; Room_Sprite_W[4,3]=16; Room_Sprite_H[4,3]=16; Room_Sprite_Location_X[4,3]=4+8*6; Room_Sprite_Location_Y[4,3]=4+8*4; Room_Xa[4,3]=960; Room_Ya[4,3]=1280; Room_Xb[4,3]=1600; Room_Yb[4,3]=1920;
Room_Sprite_X[4,4]=24; Room_Sprite_Y[4,4]=16; Room_Sprite_W[4,4]=8; Room_Sprite_H[4,4]=16; Room_Sprite_Location_X[4,4]=4+8*5; Room_Sprite_Location_Y[4,4]=4+8*6; Room_Xa[4,4]=640; Room_Ya[4,4]=1920; Room_Xb[4,4]=960; Room_Yb[4,4]=2560;
Room_Sprite_X[4,5]=16; Room_Sprite_Y[4,5]=32; Room_Sprite_W[4,5]=8; Room_Sprite_H[4,5]=16; Room_Sprite_Location_X[4,5]=4+8*5; Room_Sprite_Location_Y[4,5]=4+8*4; Room_Xa[4,5]=640; Room_Ya[4,5]=1280; Room_Xb[4,5]=960; Room_Yb[4,5]=1920;
Room_Sprite_X[4,6]=024; Room_Sprite_Y[4,6]=0; Room_Sprite_W[4,6]=8; Room_Sprite_H[4,6]=16; Room_Sprite_Location_X[4,6]=4+8*8; Room_Sprite_Location_Y[4,6]=4+8*4; Room_Xa[4,6]=1600; Room_Ya[4,6]=1280; Room_Xb[4,6]=1920; Room_Yb[4,6]=1920;
Room_Sprite_X[4,7]=0; Room_Sprite_Y[4,7]=48; Room_Sprite_W[4,7]=8; Room_Sprite_H[4,7]=8; Room_Sprite_Location_X[4,7]=4+8*8; Room_Sprite_Location_Y[4,7]=4+8*6; Room_Xa[4,7]=1600; Room_Ya[4,7]=1920; Room_Xb[4,7]=1920; Room_Yb[4,7]=2240;
Room_Sprite_X[4,8]=0; Room_Sprite_Y[4,8]=40; Room_Sprite_W[4,8]=8; Room_Sprite_H[4,8]=8; Room_Sprite_Location_X[4,8]=4+8*8; Room_Sprite_Location_Y[4,8]=4+8*7; Room_Xa[4,8]=1600; Room_Ya[4,8]=2240; Room_Xb[4,8]=1920; Room_Yb[4,8]=2560;
Room_Sprite_X[4,9]=8; Room_Sprite_Y[4,9]=80; Room_Sprite_W[4,9]=8; Room_Sprite_H[4,9]=8; Room_Sprite_Location_X[4,9]=4+8*10; Room_Sprite_Location_Y[4,9]=4+8*4; Room_Xa[4,9]=2240; Room_Ya[4,9]=1280; Room_Xb[4,9]=2560; Room_Yb[4,9]=1600;
Room_Sprite_X[4,10]=8; Room_Sprite_Y[4,10]=72; Room_Sprite_W[4,10]=8; Room_Sprite_H[4,10]=8; Room_Sprite_Location_X[4,10]=4+8*10; Room_Sprite_Location_Y[4,10]=4+8*5; Room_Xa[4,10]=2240; Room_Ya[4,10]=1600; Room_Xb[4,10]=2560; Room_Yb[4,10]=1920;
Room_Sprite_X[4,11]=8; Room_Sprite_Y[4,11]=8; Room_Sprite_W[4,11]=8; Room_Sprite_H[4,11]=8; Room_Sprite_Location_X[4,11]=4+8*10; Room_Sprite_Location_Y[4,11]=4+8*6; Room_Xa[4,11]=2240; Room_Ya[4,11]=1920; Room_Xb[4,11]=2560; Room_Yb[4,11]=2240;
Room_Sprite_X[4,12]=0; Room_Sprite_Y[4,12]=64; Room_Sprite_W[4,12]=8; Room_Sprite_H[4,12]=8; Room_Sprite_Location_X[4,12]=4+8*10; Room_Sprite_Location_Y[4,12]=4+8*7; Room_Xa[4,12]=2240; Room_Ya[4,12]=2240; Room_Xb[4,12]=2560; Room_Yb[4,12]=2560;
Room_Sprite_X[4,13]=64; Room_Sprite_Y[4,13]=0; Room_Sprite_W[4,13]=8; Room_Sprite_H[4,13]=36; Room_Sprite_Location_X[4,13]=4+8*9; Room_Sprite_Location_Y[4,13]=4+8*4-2; Room_Xa[4,13]=1920; Room_Ya[4,13]=1280; Room_Xb[4,13]=2240; Room_Yb[4,13]=2560;
Room_Sprite_X[4,14]=64; Room_Sprite_Y[4,14]=36; Room_Sprite_W[4,14]=8; Room_Sprite_H[4,14]=36; Room_Sprite_Location_X[4,14]=4+8*4; Room_Sprite_Location_Y[4,14]=4+8*4-2; Room_Xa[4,14]=320; Room_Ya[4,14]=1280; Room_Xb[4,14]=640; Room_Yb[4,14]=2560;
Room_Sprite_X[4,15]=24; Room_Sprite_Y[4,15]=16; Room_Sprite_W[4,15]=8; Room_Sprite_H[4,15]=16; Room_Sprite_Location_X[4,15]=4+8*3; Room_Sprite_Location_Y[4,15]=4+8*6; Room_Xa[4,15]=0; Room_Ya[4,15]=1920; Room_Xb[4,15]=320; Room_Yb[4,15]=2560;
Room_Sprite_X[4,16]=8; Room_Sprite_Y[4,16]=48; Room_Sprite_W[4,16]=8; Room_Sprite_H[4,16]=8; Room_Sprite_Location_X[4,16]=4+8*3; Room_Sprite_Location_Y[4,16]=4+8*5; Room_Xa[4,16]=0; Room_Ya[4,16]=1600; Room_Xb[4,16]=320; Room_Yb[4,16]=1920;
Room_Sprite_X[4,17]=8; Room_Sprite_Y[4,17]=24; Room_Sprite_W[4,17]=8; Room_Sprite_H[4,17]=8; Room_Sprite_Location_X[4,17]=4+8*3; Room_Sprite_Location_Y[4,17]=4+8*4; Room_Xa[4,17]=0; Room_Ya[4,17]=1280; Room_Xb[4,17]=320; Room_Yb[4,17]=1600;
Room_Sprite_X[4,18]=0; Room_Sprite_Y[4,18]=104; Room_Sprite_W[4,18]=48; Room_Sprite_H[4,18]=8; Room_Sprite_Location_X[4,18]=4+8*4; Room_Sprite_Location_Y[4,18]=4+8*3; Room_Xa[4,18]=320; Room_Ya[4,18]=960; Room_Xb[4,18]=2240; Room_Yb[4,18]=1280;
Room_Sprite_X[4,19]=0; Room_Sprite_Y[4,19]=96; Room_Sprite_W[4,19]=48; Room_Sprite_H[4,19]=8; Room_Sprite_Location_X[4,19]=4+8*4; Room_Sprite_Location_Y[4,19]=4+8*8; Room_Xa[4,19]=320; Room_Ya[4,19]=2560; Room_Xb[4,19]=2240; Room_Yb[4,19]=2880;
Room_Sprite_X[4,20]=32; Room_Sprite_Y[4,20]=8; Room_Sprite_W[4,20]=16; Room_Sprite_H[4,20]=8; Room_Sprite_Location_X[4,20]=4+8*8; Room_Sprite_Location_Y[4,20]=4+8*2; Room_Xa[4,20]=1600; Room_Ya[4,20]=640; Room_Xb[4,20]=2240; Room_Yb[4,20]=960;
Room_Sprite_X[4,21]=0; Room_Sprite_Y[4,21]=24; Room_Sprite_W[4,21]=8; Room_Sprite_H[4,21]=8; Room_Sprite_Location_X[4,21]=4+8*8; Room_Sprite_Location_Y[4,21]=4+8*1; Room_Xa[4,21]=1600; Room_Ya[4,21]=320; Room_Xb[4,21]=1920; Room_Yb[4,21]=640;
Room_Sprite_X[4,22]=0; Room_Sprite_Y[4,22]=24; Room_Sprite_W[4,22]=8; Room_Sprite_H[4,22]=8; Room_Sprite_Location_X[4,22]=4+8*9; Room_Sprite_Location_Y[4,22]=4+8*1; Room_Xa[4,22]=1920; Room_Ya[4,22]=320; Room_Xb[4,22]=2240; Room_Yb[4,22]=640;
Room_Sprite_X[4,23]=32; Room_Sprite_Y[4,23]=16; Room_Sprite_W[4,23]=16; Room_Sprite_H[4,23]=8; Room_Sprite_Location_X[4,23]=4+8*4; Room_Sprite_Location_Y[4,23]=4+8*2; Room_Xa[4,23]=320; Room_Ya[4,23]=640; Room_Xb[4,23]=960; Room_Yb[4,23]=960;
Room_Sprite_X[4,24]=0; Room_Sprite_Y[4,24]=72; Room_Sprite_W[4,24]=8; Room_Sprite_H[4,24]=8; Room_Sprite_Location_X[4,24]=4+8*4; Room_Sprite_Location_Y[4,24]=4+8*1; Room_Xa[4,24]=320; Room_Ya[4,24]=320; Room_Xb[4,24]=640; Room_Yb[4,24]=640;
Room_Sprite_X[4,25]=16; Room_Sprite_Y[4,25]=48; Room_Sprite_W[4,25]=8; Room_Sprite_H[4,25]=16; Room_Sprite_Location_X[4,25]=4+8*5; Room_Sprite_Location_Y[4,25]=4+8*0; Room_Xa[4,25]=640; Room_Ya[4,25]=0; Room_Xb[4,25]=960+24; Room_Yb[4,25]=640;
Room_Sprite_X[4,26]=32; Room_Sprite_Y[4,26]=8; Room_Sprite_W[4,26]=16; Room_Sprite_H[4,26]=8; Room_Sprite_Location_X[4,26]=4+8*6; Room_Sprite_Location_Y[4,26]=4+8*2; Room_Xa[4,26]=960; Room_Ya[4,26]=640; Room_Xb[4,26]=1600; Room_Yb[4,26]=960;
Room_Sprite_X[4,27]=24; Room_Sprite_Y[4,27]=32; Room_Sprite_W[4,27]=8; Room_Sprite_H[4,27]=16; Room_Sprite_Location_X[4,27]=4+8*7; Room_Sprite_Location_Y[4,27]=4+8*0; Room_Xa[4,27]=1280; Room_Ya[4,27]=0; Room_Xb[4,27]=1600; Room_Yb[4,27]=640;
Room_Sprite_X[4,28]=0; Room_Sprite_Y[4,28]=24; Room_Sprite_W[4,28]=8; Room_Sprite_H[4,28]=8; Room_Sprite_Location_X[4,28]=4+8*6; Room_Sprite_Location_Y[4,28]=4+8*1; Room_Xa[4,28]=960; Room_Ya[4,28]=320; Room_Xb[4,28]=1280; Room_Yb[4,28]=640;
Room_Sprite_X[4,29]=0; Room_Sprite_Y[4,29]=16; Room_Sprite_W[4,29]=8; Room_Sprite_H[4,29]=8; Room_Sprite_Location_X[4,29]=4+8*8; Room_Sprite_Location_Y[4,29]=4+8*0; Room_Xa[4,29]=1600; Room_Ya[4,29]=0; Room_Xb[4,29]=1920; Room_Yb[4,29]=320;

// Room info floor F1
Last_Room_Index[5] = 5;
for (i=0; i<=Last_Room_Index[5]; i+=1) {Room_Visible[5,i]=0}; // used for dungeon map
for (i=0; i<=Last_Room_Index[5]; i+=1) {Room_Visit_Count[5,i]=0}; // used for respawning enemies
Room_Sprite_X[5,0]=8; Room_Sprite_Y[5,0]=64; Room_Sprite_W[5,0]=8; Room_Sprite_H[5,0]=8; Room_Sprite_Location_X[5,0]=4+8*9; Room_Sprite_Location_Y[5,0]=4+8*1; Room_Xa[5,0]=0; Room_Ya[5,0]=0; Room_Xb[5,0]=320; Room_Yb[5,0]=320;
Room_Sprite_X[5,1]=0; Room_Sprite_Y[5,1]=64; Room_Sprite_W[5,1]=8; Room_Sprite_H[5,1]=8; Room_Sprite_Location_X[5,1]=4+8*10; Room_Sprite_Location_Y[5,1]=4+8*1; Room_Xa[5,1]=320; Room_Ya[5,1]=0; Room_Xb[5,1]=640; Room_Yb[5,1]=320;
Room_Sprite_X[5,2]=0; Room_Sprite_Y[5,2]=64; Room_Sprite_W[5,2]=8; Room_Sprite_H[5,2]=8; Room_Sprite_Location_X[5,2]=4+8*11; Room_Sprite_Location_Y[5,2]=4+8*1; Room_Xa[5,2]=640; Room_Ya[5,2]=0; Room_Xb[5,2]=960; Room_Yb[5,2]=320;
Room_Sprite_X[5,3]=32; Room_Sprite_Y[5,3]=0; Room_Sprite_W[5,3]=16; Room_Sprite_H[5,3]=8; Room_Sprite_Location_X[5,3]=4+8*6; Room_Sprite_Location_Y[5,3]=4+8*11; Room_Xa[5,3]=0; Room_Ya[5,3]=960; Room_Xb[5,3]=640; Room_Yb[5,3]=1280;
Room_Sprite_X[5,4]=24; Room_Sprite_Y[5,4]=48; Room_Sprite_W[5,4]=8; Room_Sprite_H[5,4]=16; Room_Sprite_Location_X[5,4]=4+8*7; Room_Sprite_Location_Y[5,4]=4+8*6; // AS -- under construction
Room_Sprite_X[5,5]=48; Room_Sprite_Y[5,5]=48; Room_Sprite_W[5,5]=16; Room_Sprite_H[5,5]=16; Room_Sprite_Location_X[5,5]=4+8*6; Room_Sprite_Location_Y[5,5]=4+8*4; // I  -- under construction

// Is digging possible in this room
for (i=0; i<=Last_Room_Index[3]; i+=1) {Diggable[3,i]=0};
for (i=0; i<=Last_Room_Index[4]; i+=1) {Diggable[4,i]=0};
for (i=0; i<=Last_Room_Index[5]; i+=1) {Diggable[5,i]=0};

// Permanent dungeon conditions
for (i=0; i<=2; i+=1) {Permanent_Dungeon_Condition[i]=0};
// [0]: 0/1 = chest in room 21 [B1] has (not yet) appeared
// [1]: 0/1 = stairs in room 1 [F1] have (not yet) appeared
// [2]: 0/1 = master chest in room 3 [F1] has (not yet) been opened yet

// Breakable walls
for (i=0; i<=1; i+=1) {Breakable_Wall[i]=0}; // (0 = invisible / 1 = visible / 2 = broken)
I'll go through the groups of variables:
Dungeon map: These variables are only used for building the map. They indicates what floors the dungeon consists of. There is no direct link between this and the number of clusters. One floor can be seperated in multible clusters.
Hero position: More data for the dungeon map.
Boss position: More data for the dungeon map.
Part of item menu: Stores what dungeon items have been collected (=map/compass/m.key/treasure)
Number of keys + Collectable keys: Collecting a key is a one time event. Each key gets an index and an indicator records when it is collected.
Small chest info: Opening a chest is a one time event. Each chest gets an index and an indicator records when it is opened. There are also variables that store it's location on the map.
Locked Doors: Opening a door is a one time event. Each door gets an index and an indicator records when it is opened.
Dungeon resetable values: Various event have a temporary status and those also monitored at the area level.
Dungeon entrances on map: The dungeon entrance(s) on the map get stored
Room info floor B2 (etc): Here you have the main bulk of data right now. In the area level you can find a room's location and dimension in it's cluster. This a variables to track if it has been visited yet and there is one to tell how long ago that was. Finally the locations of the room on the map are stored.
You can see that the room data is grouped per floor. This is done because you track various things only on one floor. The map also requires data grouped per floor.
Coming to the tiledata. That will be placed here as well. I figure it will look something along these lines:

Code: [Select]

// Tiledata
Translate_Room_Index[floor#, room#] = room2#
Room_Tile_Bg_X[room2#, tile#] = ##
Room_Tile_Bg_Y[room2#, tile#] = ##
Room_Tile_Bg_W[room2#, tile#] = ##
Room_Tile_Bg_H[room2#, tile#] = ##
Room_Tile_X[room2#, tile#] = ##
Room_Tile_Y[room2#, tile#] = ##
Room_Tile_Depth[room2#, tile#] = ##
Room_Tile_Finished[floor#, room#] = ##Gamemaker can only handle two dimensional arrays so I'll have to use a workaround. Which is where the translation comes in. Basically tiles are stored per room in the area level.

Is digging possible in this room: Stores which rooms allow digging.
Permanent dungeon conditions: Stores permanent dungeon conditions (like killing the boss).
Breakable walls: Breaking a wall is a one time event. Each breakable wall gets an index and an indicator records if it is broken.

-------------------------

Neither the Cluster or Room level have corresponding objects. They do not hold data either. There is an object behind the area layer though. When the character moves from room to room the object behind the area layer checks out the data belonging to the next room. So when I talk about the Cluster or Room level, I'm actually talking about data that needs to be grouped to that level. Like the tiledata. It get's stored in arrays per room so it will need to be tracked in the editor that a tile belongs to a room (as well as the which floor and area - not so much the cluster). Another example is a room's dimension. That needs to be grouped per floor/cluster.

-------------------------

I'm a little confused about the output possibilities from the editor Xfixium. What kind of output should I be thinking about? Will it be textfiles I read or something altogether different?

1171

Discussion / Re: Horn of Balance - editor

« on: October 23, 2010, 04:18:51 pm »

Yes, I was talking about using the editor's output within Gamemaker.

Xfixium: Please keep in mind that you'll probably want the user to have define areas and rooms before working on the actual tiles and objects. I'll explain my concept of rooms and areas using definitions and then I'll refine those definitions over time.

"Area" = Combination of rooms and roomclusters that make up an area. A single dungeon is one area. The overworld(s) is also one area, but will probably be broken down into multiple areas (like the forest area, desert area and so on) due to it's size. Each area can be seen as an object in that it has variables attached (like an indicator to determine if it's a dungeon or a list of the rooms it contains). Currently each area has a separate persistent object to hold the data. In the future these will likely be grouped together to conserve memory (though it should not effect the engines input requirements).

"Roomcluster" = What gamemaker considers a room. An area should be broken into as many clusters as possible/practical. Some data is cluster specific. An example of this is the creation command for an object that stays active across multiple rooms.

"Room" = The in-game rooms. Each room has a large number of variables attached to it, but this data is saved at the area level. Like the tiledata, which will need to be grouped per room. Some external data is not stored at the area level but is communicated directly between the external source and the engine instead.

Bottomline: The editor will need to track variables for all three of these levels. Instances will need an additional variable to keep track of the level they are attached to (cluster or a specific room). I'll work on showing an input/output example later this weekend.

1172

Discussion / Re: [Recruiting] Programmer

« on: October 23, 2010, 08:08:23 am »

That suits me just fine. I tend to look at the long term anyway. Hence the request to take construction one step at a time and working open sourced.
I'll just move this topic over to concepts and occassionally post some information on the required engine input, idea's/suggestions concerning the buildorder and so on.

Concerning the adding of tiles. I added the following piece of coding to the entering of a room (= not Gamemaker's room).

Code: [Select]

// TESTCASE: tile creation
for (argument[13] = 0; argument[13] < 320/8*9; argument[13] += 1)
{
    for (argument[14] = 0; argument[14] < 320/8; argument[14] += 1)
    {
        tile_add(tileset_Dungeon_01,0,0,8,8,900,900,-99999);
    };
};
It results in a barely noticable delay in Link's movements so I do not believe creating tiles in a more realistic scenario will be much of an issue. This coding represents taking a room consisting of 9 320x320 pixeled blocks and adding a new tile in every 8x8 subsection. All in a single step. Since this is an exaguration of the reality I believe tiling a room of around 16 320x320 blocks in a single step should not be a problem. I was planning on limiting the rooms to something simular anyway.

Building the dungeon continuesly during each step does not seem like it is needed at this point. We can just tile each room as we enter it, as oppossed to filling an entire room in gamemaker. I also plan on adding an array of variables to keep track if a room has already been succesfully tiled (to prevent repeating actions).

I'll take some time this weekend to document what properties an area and a room will need inside my engine.

1173

Discussion / Re: [Recruiting] Programmer

« on: October 21, 2010, 05:25:16 pm »

Yes, I figured tiling would be a big issue. Maybe it's best if I first try out some things this weekend to size up the problem. One possible solution that comes to mind is building rooms continuesly. When you start you only load in the bare essentials (during the black screen between areas) and then you sneak in adding a little bit more during each of the steps. It's just an idea, but I can tinker around with it to see how viable it is.

I like where the rest of the conversation is going btw. If you guys are interested in helping, I could start by describing what an area or room means in my game (= what data the engine needs to define an area or room).

1174

Discussion / Re: [Recruiting] Programmer

« on: October 20, 2010, 05:34:03 pm »

There are several usefull goals that will come out of this:

1. Easy use for me - a dedicated user interface is more pleasant to work with then working with Gamemaker. Maybe this varies per situation, but creating certain elements require multiple actions which could very well be automated. For example: adding a doorway makes it that the space between doors has a depth in front of Link. This can be automated.
Another example of what could be done to help ease development is splitting the room creation process up into is segments. In Gamemaker you have one room to create everything with. Walls, enemies, grass, doors, switches, bridges, shadows etc. It gets a little crowded at points. This isn't a big deal, but I image it'll be better with an editor all the same. (Some game aspects might be too complicated/specific to fit nicely in the editor, but I'm not expecting a miraclecure so that's fine)

2. Easy use for people helping me - since the editor is open for anyone, others can take a room in the game and mess around with it. Move a wall, change up some enemies, tweak collectables etc. It would help others help me when they wish to contribute. Currently, if someone wants to edit/create an area they'd have to do it in a private Gamemaker, paint or other program of choice. In order to implement it into the actual engine I have to recreate what they have done (building the backgrounds, objects and adding in the actual gamecomponents as well). With an editor at their disposal someone else can create a full new room in the editor, try it out in their own version of the game for direct feedback, send over the editor's output and I simply copy over the relevant pieces of code to implement it.

3. It allows me to sneak in some improvements more easily - the hardest to fully explain, so I'll try it with an example:
Let's say I have containers and have placed them in the game. I then wish to improve the collisions with enemies, which requires that I add a new variable to each individual container object. I have to go past every single container already in the game, check out their personal creationcoding and make the adjustment. When doing this for a couple of dousand objects one is bound to miss one and then the hunt starts for that one missed troublemaker. Meaning I have to go through all the objects again or I have to create some coding so the troublemaker reveals its position while playing.
In the editor (depending on how well it is set up obviously) I can imagine you'd have a (far) easier time to implement the change. I don't think I have to really explain this further.

4. The rest can use it as well - not an advantage for me, but it doesn't bother me either. If others can also use the editor they can do whatever they want with it. Small kids have the option to edit my game and create their own super awesome ultimate Zelda variation on it. More serious creators might be able to use it for more serious edits. This point can best be considered as spin-off for the long run.


So all in all it would have great some benefits. I'm helped because I'd be able edit my game in a more user friendly manor. Others will have a far easier time if the wish to contribute. That would help me A LOT. I have more options to implement change efficiently, which is always nice. And it opens up the door for others to be able to do edits (eventually).

1175

Discussion / Horn of Balance - editor

« on: October 19, 2010, 06:35:34 pm »

Like the title says: I'm looking for someone to build an editor to compliment the Horn of Balance game I'm building.

The game can be found here: http://www.zfgc.com/forum/index.php?topic=33701.0

My own attempt at an editor is in the attachment.
Don't mind the messy programming in it as it's not finished. I had planned to add save/load in the upper left corner, tabs in the upper area and scroll bars on the sides of the grid. Also, the 3rd and 4rd buttons (of the four) haven't been programmed either.

Since I'm giving up on building the editor myself, I'm opening up the opportunity for someone else to give it a try. The engine is already being build so you can see what it is getting used for. The editor creates files with data that are input for the engine. Programm it in whatever language you like. Take as long as you like. Give it your own spin if feel it would benefit. We'd obviously need to get more indepth but this is the jist of it.

I do have a couple of requests to the creator though. I want it to be decent and get programmed in well defined segments. It will take time to implement and I too want to know my efforts will be well spend. I want it to be open sourced so I don't have to worry about progress ending abruptly. Finally the editor obviously comes second to the engine in that the editor supplements the engine and not the other way around. (Just something I wanted to mention to scare off young kids thinking grand schemes )

1176

Other Projects / Re: [Demo] Tech demo - Horn of Balance (working title)

« on: October 19, 2010, 05:00:52 pm »

Hhhmm. Maybe I was a little too testy (right word?) yesterday. Sorry. Deadlines and stuff wear me down every once in a while.

I've decided to make a recruitment's topic for the editor. Seems a shame to flat out end it before going others a go at it. I'm not sure anybody has any interest though, but that's another story .

1177

Other Projects / Re: [Demo] Tech demo - Horn of Balance (working title)

« on: October 18, 2010, 08:23:21 pm »

Ooh, you red it like that. Nope. You'd be right in finding that dumb.
I was just talking about external maps, enemy placement, chest locations etc.

1178

Other Projects / Re: [Demo] Tech demo - Horn of Balance (working title)

« on: October 18, 2010, 08:11:54 pm »

And what do you want me to do then? Stop using GM, switch to a different language, get set back two years for no real benefit and finally quit after another two years due to real life with no finished endresult? Silly Mamoru. You should know far better then to suggest a switch in language to someone making a fangame.

Besides. You don't need another language to effectivly create an alttp fangame, as you should have already noticed.

Building a scripting language for a scripting language would have been a service to the little kids who keep asking me if they can use my engine. Too bad it's far more of a (boring) pain to build then I imagined.

1179

Other Projects / Re: [Demo] Tech demo - Horn of Balance (working title)

« on: October 18, 2010, 06:23:05 pm »

The editor's ultimate goal was to gradually phase out Gamemaker as the editor. Gamemaker would hold the engine, the editor would create it's input. I planned on breaking the creation up in a large number of sections. For example:
Step one would be to define areas and rooms within those areas and be able to alter various stats per room/area like it's dimensions, number, name etc.
Step two would be to define the floors / walls per room and have the program auto fill in the visuals and solids if possible. In other worlds: create the most basis backgrounds and solids.
Step three would be the creation of doorways between rooms.
And so on, going over to added features like adding doors/switches/enemies.

While doing this I had planned to also gradually replace the ingame's hardcoded room creation with the editor's output. This would then also have been a nice opportunity to make some large engine changes like updating the depth / floor mechanics, the handling of solid objects and grouping the area control objects further.

I started making it in Gamemaker as a proof of concept. (I choose Gamemaker because it was more accessable to others). I can definatly say vb now has my preference. (Other people would probably have other preferences).

1180

Updates / Re: Project of the Month - September 2010

« on: October 18, 2010, 05:26:20 pm »

Sorry about the delay this month. My bad.