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 5948 times)

0 Members and 1 Guest are viewing this topic.
Horn of Balance - editor
« on: October 19, 2010, 06:35:34 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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 ;) )
Logged
Re: [Recruiting] Programmer
« Reply #1 on: October 20, 2010, 12:05:49 am »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Sounds interesting. Not sure what you plan on accomplishing with it though.
Logged
  • Pyxosoft
Re: [Recruiting] Programmer
« Reply #2 on: October 20, 2010, 05:34:03 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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).
Logged
Re: [Recruiting] Programmer
« Reply #3 on: October 20, 2010, 08:10:26 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Hmm, funny to see that you are bootstrapping the editor. But if I read it right you want a room editor that can do what gamemaker does plus some additional stuff:

  • Have a minimap of where the view is in a room.
  • An instance tree that list all the instances in a room and groups them by object type.
  • When adding an instance of an object you want to have part of the window display property fields of variables and that you can change the initial values.
  • This property list should also pop up when you click on an instance in the instance tree.
  • And you might also want to limit the type of the property fields and not just by number and string, but by sprite_id, instance, object, sound, background and scripts, etc



Xfixium, weren't you working on a room editor with Gmare?
Logged
Re: [Recruiting] Programmer
« Reply #4 on: October 20, 2010, 10:10:23 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
I see, well that's quite an idea. I say the hardest thing to overcome will be how you deal with tile data. For instance: My current tool for my dev team is called GMare. When the user is ready, they can export the tile data to a binary file, directly to a GM project, or an image file. More than likely you'd want it exported to a binary file to be read in by your project. This is the area that gets painful. If the room is big enough, using the built-in GM method "tile_add" can be really slow, and noticeable by the player. Another way to tackle it is to read in the data, and draw the tiles yourself. Which kind of creates it's own set of performance issues if the room is pretty big, and most likely require you to change your project for that purpose. If you want to try an alternative IDE for Game Maker. You could try Lateral GM. http://www.ismavatar.com/lgm/download.php It offers some things that the Game Maker IDE doesn't. Like a list of instances.

Quote
    * Have a minimap of where the view is in a room.
    * An instance tree that list all the instances in a room and groups them by object type.
    * When adding an instance of an object you want to have part of the window display property fields of variables and that you can change the initial values.
    * This property list should also pop up when you click on an instance in the instance tree.
    * And you might also want to limit the type of the property fields and not just by number and string, but by sprite_id, instance, object, sound, background and scripts, etc

Oddly, my first builds of GMare were going to do exactly that (Except the mini-map), before I realized I only wanted to edit the room tiles, not everything else.
Logged
  • Pyxosoft
Re: [Recruiting] Programmer
« Reply #5 on: October 21, 2010, 05:25:16 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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).
Logged
Re: [Recruiting] Programmer
« Reply #6 on: October 21, 2010, 10:52:15 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Quote from: Martijn dh 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.

That's quite a solution, and could work nicely. Very clever! I would love to work on such a tool. However my own project halts that idea. I could work on it here and there, when I need a break from OOT2D stuff.
Logged
  • Pyxosoft
Re: [Recruiting] Programmer
« Reply #7 on: October 23, 2010, 08:08:23 am »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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.
Logged
Re: Horn of Balance - editor
« Reply #8 on: October 23, 2010, 12:55:33 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
I don't know if making the editor in game maker is the best idea. GameMaker is better suited to build games and not applications. I think it is best to use a language and IDE better suited for applications.

Anyone know a good source on how GameMaker saves rooms and its files.
Logged
Re: Horn of Balance - editor
« Reply #9 on: October 23, 2010, 02:44:46 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Alright sounds good. I already put some minor framework together for the tool. Which is going to be a modded GMare. Taking some good suggestions from Niek on instance organization options. I'd like to make it as generic as possible for others to use.

Quote from: Niek on October 23, 2010, 12:55:33 pm
I don't know if making the editor in game maker is the best idea. GameMaker is better suited to build games and not applications. I think it is best to use a language and IDE better suited for applications.

Anyone know a good source on how GameMaker saves rooms and its files.

I think he was referring to how he was going to handle using the tile data from editor output, within Game Maker Niek. Are you asking how Game Maker saves the editor data to a project file, or how the editor compiles the editor data to a game .exe? I pretty much know every detail for project files.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #10 on: October 23, 2010, 04:18:51 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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.
Logged
Re: Horn of Balance - editor
« Reply #11 on: October 23, 2010, 05:42:09 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
So everything works like a node. The Area is the parent node, while a Cluster buds from an area, and a Room buds from a Cluster. Every node level has it's own set of variables. With the parent node (Area) holding the tile data. When instances are created, they have their own variable specifying on what node (Level) they have access to. A project from this tool would hold as many Areas the user wanted to create. 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.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #12 on: October 23, 2010, 06:22:39 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Quote from: Xfixium on October 23, 2010, 02:44:46 pm
I think he was referring to how he was going to handle using the tile data from editor output, within Game Maker Niek. Are you asking how Game Maker saves the editor data to a project file, or how the editor compiles the editor data to a game .exe? I pretty much know every detail for project files.
My reference to GM was more about the gmk in the OP. I was mostly referring to the project files, but any information is welcome. And I am also really interested in working on this project, because I think the MCS Engine could benefit from it as well. 4Sword has been looking into Rooms within Roomclusters, but it was mostly focused on how to deal with the view shifting.

Xfixium are you making it in C#?
Logged
Re: Horn of Balance - editor
« Reply #13 on: October 23, 2010, 07:18:23 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
The project formats are described by a person by the name of IsmAvatar. Which it was through those texts that I was able to create GMLib. Thus why it took so much time to get through most of GMare. GMLib is a library that can read and write GM project files from 5.0 to 7.0. That project can be found here: http://www.pyxosoft.com/forums/index.php?topic=99.0 I'll attach the latest information on the project file format. I still need to include GM8 within GMLib. I'll get to it eventually.

As for programming, it will be written in c#, but I think I'll include WPF this time, mainly cause I've been wanting to use it for awhile now, and I think it's a good fit for this project.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #14 on: October 23, 2010, 07:22:16 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
Oops, I forgot the floor level XD 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?
« Last Edit: October 23, 2010, 07:30:18 pm by Martijn dh »
Logged
Re: Horn of Balance - editor
« Reply #15 on: October 23, 2010, 07:45:22 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Thank you for the detailed information. I wouldn't mind Niek helping out. The main thing I want to accomplish is to make this app as user friendly for you, as well as making it generic enough for it to be used by others. When I say output from the editor, I'm talking about binary output. Meaning you probably would have to make, or get a pre-existing lib that reads binary data. (I use SuperBinary) Why did I choose that? So it's not easily readable, very lean file size wise, and quick to read in. Text is lengthy, and can be read by anyone, also changed easily, but I could output in various forms if need be. The current GMare exports to binary, an image file, or a GM project file.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #16 on: October 23, 2010, 07:55:44 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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:
Quote from: Xfixium on October 23, 2010, 05:42:09 pm
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.
« Last Edit: October 23, 2010, 08:15:30 pm by Martijn dh »
Logged
Re: Horn of Balance - editor
« Reply #17 on: October 23, 2010, 08:39:45 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Posts: 728
Well, if your engine uses text, you'll just use the text export. One tileset per room (Cluster) is fine. I plan on using different methods for output so that's why I asked. Ore used a single array for tile ids, and I'd like to continue having options like that for users. As well as how GM defines tiles.
Logged
  • Pyxosoft
Re: Horn of Balance - editor
« Reply #18 on: October 23, 2010, 08:55:13 pm »
  • *
  • Reputation: +16/-0
  • Offline Offline
  • Gender: Male
  • Posts: 1633
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.
Logged
Re: Horn of Balance - editor
« Reply #19 on: October 23, 2010, 09:47:28 pm »
  • *
  • Reputation: +9/-0
  • Offline Offline
  • Gender: Male
  • Posts: 3725
Quote from: Xfixium on October 23, 2010, 07:18:23 pm
The project formats are described by a person by the name of IsmAvatar. Which it was through those texts that I was able to create GMLib. Thus why it took so much time to get through most of GMare. GMLib is a library that can read and write GM project files from 5.0 to 7.0. That project can be found here: http://www.pyxosoft.com/forums/index.php?topic=99.0 I'll attach the latest information on the project file format. I still need to include GM8 within GMLib. I'll get to it eventually.

As for programming, it will be written in c#, but I think I'll include WPF this time, mainly cause I've been wanting to use it for awhile now, and I think it's a good fit for this project.
Thnx, Xfixium. I shall take a look at that. I don't know C# yet, but I do know C, C++ and Java, thus it wouldn't be to hard for me to learn it.

I think a Binary or GM project file are good options for an output. An image in this case is not that good. However I am not to sure about a plain text output. I know GM has capabilities to read INI files, but I think I would prefer an XML format over that.

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.

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.
Logged
Pages: [1] 2   Go Up
« previous next »

 


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


Page created in 0.028 seconds with 77 queries.