Release 0.1.0: Map Mode/Editor Feature Changes

For discussion of the code running behind the game

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Thu Sep 25, 2014 5:00 am

Status of Map/Editor Changes

General Map
  • Separate map files in two files: data and scripting (COMPLETE)
  • Support a custom number of tile layers for maps (COMPLETE)
  • Allow each tile layer to be configured so that it's collision data can be chosen to be included (COMPLETE)
  • Figure out a way to improve code sharing in map scripts, similar to map_sprites_stock.lua
  • Change the way contexts are stored in the map data file to a better format (COMPLETE)

Map Mode
  • Support a custom number of object layers for maps (COMPLETE)
  • Consider adding a new map event type that performs an operation on multiple sprites at once
  • Consider adding a sprite event type where the sprite "follows" a target until it is reached

Map Editor
  • Remove sprites/object layer support (COMPLETE)
  • Remove skill editor (COMPLETE)
  • Change graphics rendering from using game's video engine to using native QT rendering (COMPLETE)
  • Separate out data model and view classes for better software architecture (COMPLETE)
  • Add support for map context inheritance (COMPLETE)
  • Add support for naming of tile layers (COMPLETE)
  • Add support for naming of map contexts (COMPLETE)
  • Change editor layout to mimic VT, with the tile layer list and tileset info on right (COMPLETE)
  • Change top menu to include: File, Edit, View, Select, Tools, Help (COMPLETE)
  • Add support for making custom shape selection areas
  • Add support for changes to selection area to apply to more than one tile layer
  • Add support for changes to selection area to apply to more than one context
  • Add support for cut/copy/paste from one layer to another
  • Add support for cut/copy/paste from one context to another
  • Add support for cut/copy/paste across multiple layers
  • Re-enable undo/redo action support
  • Re-enabled autotiling feature

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

As I mentioned here, there are a few ideas that I want to borrow from Valyria Tear that involve changes to the map code and map editor. These are large, disruptive changes so I think that now is a good time for me to do them while there's no other active developers. Here's a summary of what I'm planning to do and why, in the order that I plan to do it in. I might get started on this as early as this weekend.


1) Separate map files into two files: a map portion and a scripting portion
Currently our map files contain both the static map data (tiles, layers, etc) and the scripting portions. We'd separate these two into individual files and a map would now require both to function.

Why: There are two main reasons why we should do this. First, it is somewhat cumbersome to edit map files when writing the scripts because of the large amount of text that the editor generates at the top of the file. Second, and more importantly, this would allow us to re-use map data more efficiently. For example, if we have a forest where a set of events occurs when the player first visits it, then a different group of events when the player revisits this area, we simply switch out the script file and there's no need to reduplicate all of the map data.

How: I think what I will do is keep the map files where they currently are located (dat/maps) and put the scripting files in a new directory, perhaps dat/scripts/maps. I'd rather not enforce some file naming convention and keep both map files and script files in the same directory, as that will just be difficult to sort through once there are a large number of files. Since scripts are what drives the maps, the MapMode will load the script files. The script files will contain the name of the map file that the script should take place on, so the map file data will be loaded after this data is retrieved.


2) Support a customizable amount of tile and object layers
We currently hard-code three tile layers and three object layers to all our maps. No map is allowed to have more or fewer layers than this, although they can choose not to populate some layers with tiles or objects.

Why: There's really no technical or design reason for us to have this requirement. I don't know why I made this restriction in the first place (I guess it was just easier to think about maps in this way back then). By allowing us to have any number of tile and object layers, and to arrange them in any order, we no longer need to restrict ourselves, and this may help implement certain other features such as terrain (like bridges) that a sprite can both walk on and walk under.

How: The map file will define the tiles and tile layers, but not define the order of these layers. The script file will, during the map load process, define all object layers and the objects that exist on those layers, then arrange both tile and object layers in the order that they should be drawn. The map editor will require some changes to support this as well (already done in the VT code).


3) Map Editor Layout Changes
The map editor is greatly improved in the VT code. The layout is cleaner and it seems easier to use.

Why: Who doesn't want a better map editor? The time spent on this should quickly pay for itself if it helps reduce the time to make maps as I'm hoping it will.

How: Pretty much going to go through the VT code and pull it in a chunk at a time. I can't do a direct pull because VT doesn't make use of map contexts like we do and seems to have completely removed that feature from it's editor. Also they use a slightly different code styling that isn't consistent with our standard.



There are a lot more map features than this that I'd like to add for the release, but for now I'm only focusing on these three since they are the most disruptive of the changes. And while this work isn't necessarily a high priority, I feel like completing it now will result in fewer headaches in the long term, as all the existing map files will need some heavy editing to support these changes. If you have any comments/suggestions/protests, feel free to leave them. I'll update this thread with any important progress updates or design questions.
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby nemesis » Thu Sep 25, 2014 10:52 am

1) Separate map files into two files: a map portion and a scripting portion


That is definitely the right way. I saw it in VT and it makes going through the scripts for the maps much easier.

2) Support a customizable amount of tile and object layers


Yes why not. If you think, the overhead of programing work to get this feature running is not large, go ahead. I'm interesting if there will finally be maps, using more than three layers.

3) Map Editor Layout Changes


:approve:
rujasu
Developer
Posts: 758
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby rujasu » Thu Sep 25, 2014 2:46 pm

As long as it makes maps easier to develop it's probably a good idea.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sat Sep 27, 2014 8:20 pm

Roots wrote:1) Separate map files into two files: a map portion and a scripting portion


I'm nearly finished with this and will likely commit it soon. As I was working I had some thoughts about how we should name our map data files and map script files. Generally speaking, I think the map data files should describe the location while the map script files should describe the event. I also think that we should prefix the script files with the release module that they occur on. For example, "01_" would be prefixed to all file names for the 0.1.0 release. But not all script files would need this prefix, as it may be an optional event or something that can occur in more than one release module. Using this convention, it will be much easier for us to search for and find the scripts that correspond to the events in a particular chapter of the game.


Currently the combined map files are named "opening_scene", "river_access_cave", and "harrvah_city". Except for opening_scene, these file names work well for the map data file because they describe the location. Following the conventions I proposed above, this might be how we separate these files out:

Data Files (lua/data/maps)
harrvah_desert_cave_path.lua
harrvah_underground_river_cave.lua
harrvah_city.lua

Script Files (lua/scripts/maps)
01_opening_scene.lua
01_unblock_underground_river.lua
01_return_scene.lua
01_city_attack.lua
01_city_aftermath.lua


Notice that there are more script files than data files. Right now the opening_scene map handles scripting for both going to the cave and returning from it, so it's kind of a mess. With this new feature, it's really easy to separate the scripting into two different files, where both would make use of the harrvah_desert_cave_path.lua map data file. I think this is a pretty good naming convention to go by for our map files, so I'm going to go ahead and do things like this.
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby nemesis » Sun Sep 28, 2014 9:34 am

Sounds generally okay. Having several script files handling specific events will make maintaining easier, since one does not have to handle with the large files anymore.

However, I fear using this naming convention it will become quite hard to find certain events in the script files. What I mean is, that there are several scripts for the maps (i.e. creature generating, areas for events and so on), that cannot easily be connected to certain events (although names as 'opening_scene' are okay). But what if one is walking in a map and is not happy e.g. a specific enemy party. Finding the correct map-script can become hard if the project is increasing.

Thus, what I propose is having a script file for the maps having the same name as the map (but e.g. being located in a different directory). In this files, the general settings for the maps are included, while events are saved in a form you have proposed. A directory structure can be:

/lua/data/maps -> map-data from the editor (as already is)
/lua/scripts/maps -> general settings (files, with the same names as in /lua/data/maps)
/lua/scripts/events -> Episode related events for the maps

What do you think?
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sun Sep 28, 2014 4:31 pm

I made a slight change to the convention last night to prepend 'a' to every chapter map, so instead of "01_..." we have "a01_...". The reason for this change is because our Lua tablespace names are based on our filenames, so a filename of "01_mymap.lua" has a tablespace name of "01_mymap". But a Lua identifier can not start with a number, so I was forced to put a letter prior to the namespace name. In turn, the global event group name uses the tablespace name, so file "01_mymap.lua" with tablespace "a01_mymap" would have an event group name of "map_a01_mymap". Thus it got pretty easy to confuse when you needed to have the "a" and when you didn't in the scripts, so I just made it all consistent so everything is prefixed with 'a'. If anyone asks, the 'a' stands for Allacrost. :heh:

nemesis wrote:However, I fear using this naming convention it will become quite hard to find certain events in the script files. What I mean is, that there are several scripts for the maps (i.e. creature generating, areas for events and so on), that cannot easily be connected to certain events (although names as 'opening_scene' are okay). But what if one is walking in a map and is not happy e.g. a specific enemy party. Finding the correct map-script can become hard if the project is increasing.


I think I get what you mean. For example, say there's a forest map that is revisited throughout the game in several chapters, so we have four different map scripts that use that map. Let's suppose that the event in question is a sidequest and is not directly tied to any particular event, but depends on if certain criteria have been met such as if the party has a certain item in their inventory, they bump into a strange figure.

nemesis wrote:Thus, what I propose is having a script file for the maps having the same name as the map (but e.g. being located in a different directory). In this files, the general settings for the maps are included, while events are saved in a form you have proposed. A directory structure can be:

/lua/data/maps -> map-data from the editor (as already is)
/lua/scripts/maps -> general settings (files, with the same names as in /lua/data/maps)
/lua/scripts/events -> Episode related events for the maps


I like this idea and I think it's something we need to keep in mind, but we shouldn't need to worry ourselves about this much right now since we won't run into this case for quite a while (I imagine we'll have to have a few chapters out before it becomes an issue). I want to keep all map scripting in lua/maps, so I'd want /lua/scripts/events to be /lua/scripts/maps/events instead. But I absolutely agree with your proposal that the general settings for maps should have the same filename as the data file for the map (although we'd need to be careful about name collisions since the two would then have the same namespace).

TL;DR: Yes, I approve. :approve: Although I think we don't have to worry about this right now, and when the time comes we can decide exactly how we want to organize our event map scripts and our general map scripts.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sun Sep 28, 2014 4:43 pm

In a somewhat similar discussion to the topic just above, yesterday I found that it would be a worthwhile effort to investigate how we can improve code sharing between map scripts. For example, many map scripts implement the same small functions for their event scripting. Functions that do things like: make a sprite face a certain direction, increase movement speed, stop the music that's playing, etc. Rather than implement these little functions over and over, we need to find a better way.

We already do this somewhat with the map_sprites_stock.lua file, which contains the definitions of all our different sprites so that each file doesn't have to setup those settings itself. I believe we load this file on boot and keep it in the global data, then export it to Lua from C++. Not sure if this is the most efficient way of doing things (it seems like we should just open Lua files from Lua when we need them), but we can see. This isn't an urgent priority, but it's something I'm going to casually investigate and see if I can figure out a good way for maps (and other scripts, for that matter) share common functions and data easily.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sun Sep 28, 2014 11:26 pm

Roots wrote:2) Support a customizable amount of tile and object layers

3) Map Editor Layout Changes


I'm going to switch the order that I do these two tasks. The reason being that the editor layout changes include support for multiple tile layers in the design, and it would be more difficult for me to pull in all the other changes without adding the custom layer support. These are both large tasks, and I don't expect to do either of them in a single commit. Existing maps will not work in the new editor for a while during this process, and any new maps created by the editor will not work in the game. Not that I expect anyone to be using the editor to make maps right now. I hope I can get both of these tasks finished within a couple weeks.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Mon Sep 29, 2014 4:52 pm

One big change incoming in the editor is that it's going to be using a QT rendering instead of our own video engine to render all the tiles. This is something that I talked about with gorzuate a couple years ago, because I wasn't sure if our original decision to use the video engine in the map editor was a good idea. He strongly agreed with me, and seeing as how VT removed it and showed us a clear path to how to do it, I'm going to go ahead and implement this change.


A few miscellaneous thoughts I had last night as I was going to bed related to coordinated sprite movement:
- In certain events, such as the opening scene, we have a large number of sprites moving together as a single unit.
- Scripting each sprite individually is really tedious and a pain
- Might want to consider creating a new MapSpriteEvent class that performs operations on multiple sprites at once (current classes only process a single sprite)
- Might want to consider a type of event called "follow", where a sprite is told to follow another sprite until they touch the target. That way you can have one sprite lead and have a group of other sprites follow it around.
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby nemesis » Mon Sep 29, 2014 7:42 pm

Both things sound good. Especially the the stuff regarding the event for multiple sprites can really become handy. BTW, I have some thoughts about the opening scene at all. I will put the ideas down later, once I have a little more time.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Mon Sep 29, 2014 10:31 pm

nemesis wrote:Both things sound good. Especially the the stuff regarding the event for multiple sprites can really become handy. BTW, I have some thoughts about the opening scene at all. I will put the ideas down later, once I have a little more time.


I welcome your ideas. Even though the opening scene is currently okay other than missing the walking animations for the hounds, I really want to polish this short scene to the fullest since it's one of the first impressions that we make on our players, and you can only make a first impression once. Some ideas I had about it this weekend:

- Add some soft "clanging" sounds to mimic the sounds of the knights shuffling through the desert sand as they march.
- Add some more distinguishing features (vegetation, rocks, etc) to make the first portion of the march a little more interesting
- Change up the animation starting points for the knights walking so that they don't look like they are all marching in a synchronized fashion
- Have the troops move a little up or down to avoid obstacles along the march, since continually moving to the right the whole time is uninteresting
- Add flashes of lightning (it might already have this...I can't remember)
- Possibly add little puffs of sand being kicked up by the wind and a few different points
Image
nemesis
Senior Member
Posts: 157
Joined: Fri Apr 29, 2011 7:53 am
Location: Sachsen/Germany

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby nemesis » Tue Sep 30, 2014 7:21 am

than missing the walking animations for the hounds


Yepp. Although this might be a good starting point for some artists without much experience, since the hound itself is available. To be honest, this is something I would like to work once I started over again working on the project. (I don't have much experience in graphics, but I want to try, even if this means to fail completely. :angel: )

- Add flashes of lightning (it might already have this...I can't remember)


It is already there.

It seems for me, the knights are floating above the ground, i.e. the ground is moving faster than the knights walking animation implies. It might not be a big issue but is something that - at least for me - looks worth. Adjusting some speeds should help here without much work.
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Wed Oct 01, 2014 5:31 am

A few notes on the ongoing editor work:

1) Removal of sprites and skill editor
There's currently some non-functional code that was supposed to allow you to place sprites on a map and edit skills. I am going to delete the relevant files and code in my next commit. It's pretty clear now that we won't have sprites or other map objects in the map data file (that will be added by the map scripts). And while having a skill editor is neat to have, I think that with our very limited resources, we should focus all our efforts in the editor on how to improve maps. Skills can be written/defined by hand as we have been doing.

The editor will only have code supporting the creation of map data (tiles, tile layers, and map contexts) as well as tileset definitions.

2) Incoming Changes
I'm currently working on grid.h/.cpp, which is going to take me a fair amount of time to complete. This file handles the data representation of the entire map as well as the loading/saving code. So this is a huge piece of the work right here. Importing the changes from VT is not an easy task because we have to structure our data a little differently since we use map contexts and VT removed that feature. I'm still shooting to get this work completed by the end of the weekend, but it may take longer.


3) Map contexts
A while back, we added the ability for a map context to "inherit" from another. What this means is that a context grabs all the tile's from it's parent, and then paints it's modifications to the parent on top of that. So if we had a house in the middle of a forest, for example, the house interior context may inherit from the base, and only the tiles that make up the house are changed so that we can still see the outside of the home. Right now in the map file, we store each inheriting context as a list of tiles that changed and we have to manually add to our map data files the list of what contexts inherit from what.

I'm trying to figure out the best way to handle contexts is, because it's not apparent to me. Ideally, when in the editor and my active context is an inherited one (like house_interior), I want to be able to see the inherited context tiles as well so I can make sure that the house interior tiles line up with the exterior properly, perhaps by drawing the inherited context first and overlaying a dark transparent filter before drawing the active context's tiles. And I'm also unsure if the way we store contexts in the map file is the best way to go about things as well.

The best solution might be to allow two types of contexts: base contexts and inherited contexts. Here's the difference:

A base context stands on it's own. It defines a value for every tile in every tile layer, and all tile layer data is stored in the map data file. A map is required to have at least one base context.

An inherited context must inherit from either a base context or another inherited context. Thus you can have an inheritance chain like: context_05->context_03->context_01(base). An inherited context stores it's data differently, and only has a list of what tiles were painted in what layer.


I think I'm going to skip working on contexts for this next commit, as there's too many questions I still need to think about in regards to the best way to process contexts in both the editor and map mode, and how that data is stored in the map data file. Consider the above to be mostly out-loud thinking. There are still other issues and features regarding contexts to consider that I didn't discuss.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sat Oct 04, 2014 5:45 pm

A couple other ideas for new features that popped into my head during this work:

1) Painting a tile, then holding shift and painting another tile on the same row or column on the first paints all the tiles in a line that lie between the two points. Note this would only worth for orthogonal lines; not diagonal ones

2) When selecting the fill tool, instead of automatically filling the whole layer when clicking a tile, we can instead paint adjacent tiles that are the same tile as the selected tile. So for example, if we have a rectangle of no tiles (empty space) surrounded by other tiles, using the fill tool would paint all of those tiles.


I also want to make the marquee selection tool much, much more powerful. Specifically, I'd like it to be able to do the following:
- Select areas that are not rectangular (by using shift while using the tool to add on rectangular sections to the selection)
- Select multiple areas at once that are disjointing (selecting a house and a nearby fountain together, for instance)
- Allow selection across multiple tile layers
- Allow selection across multiple map contexts

Why do all this? Well imagine this scenario: we're building a city in the map editor and add a small house. Naturally, the house is composed of numerous tiles across multiple layers, and the house is not completely rectangular in shape (has a chimney, etc). Additionally, we have tiles representing the interior of the house on another context. The house is mostly completely and looks great, but we discover that we need to move it to another location on the map. Currently, doing this would be extremely tedious and difficult. But if we had all the features I listed above, one would only need to select the area, the tile layers, and the map contexts that the marquee move should affect, then drop it down wherever. Or maybe we could even use this tool to make a copy of the house and place it elsewhere on the map, greatly reducing the amount of time needed to build each building on the town. That would be SO HOT!!! :D I absolutely believe this is worth the effort, and I will be adding it on my to-do list. It will take a while for me to get around to it, however.


Current Editor Status
Things are going well, but it's taking me longer than I expected (map contexts -really- complicate map editing, but it's worth it). I've had to come up with a way to split the Grid class (that does most of the tile data management and editing) into multiple component classes because it's really sloppy. VT's editor is serving as a guide of sorts, but I'm mostly writing new code at this point and not just copying VT code, since VT does not use map contexts and we require a very different design.

I expect to make a commit of my current changes in the next couple of days. There are some file changes, so I'll be updating the Linux build files. Windows and OS X builds will be broken until someone fixes them, if they aren't already broken.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Wed Oct 08, 2014 5:25 am

I added a feature list to the top post of things discussed so far and some additional features I'm about to describe. The list is not absolute and I may not do all of those tasks, but there have been a lot of ideas discussed in the thread so far and it has become difficult for me to keep them all straight in my head. Note that I didn't include any changes about specific map scripts, since the main focus of this thread should be changes to the general map code. As you can see, a lot of these features are currently in progress, as it is practically impossible to separate them out cleanly and do them one at a time.


Anyway, here's my next set of ideas.

Changes to top menu bar
We currently have a kind of sloppy top menu bar, with options like Tileset and Map containing only one item. I wanted to make it a little more clean and standardized compared to similar applications. So I'm proposing we change it to the following:
  • File - same as before
  • Edit - contains undo/redo, cut/copy/paste (new feature explained below)
  • View - similar to before
  • Select - contains options that make the marquee selection tool much more powerful (discussed in above post)
  • Tools - contains all the tile painting/moving/deletion actions
  • Help - same as before

This is easy to change around, so even if we make the changes and find we don't like them so much, we can add/remove/modify menus until we're happy.

Cut/Copy/Paste
Using the select tool, I'd like to be able to perform these common sort of operations. This will be very useful when trying to populate a town with buildings, as you can make one rather generic building, copy/paste it everywhere, then go to work on modifying the building exteriors and interiors to make them noticeably different from one another. This will save a lot of time as opposed to having to construct each building from nothing. This will work in tandem with the select tool, as it's not really useful to do these operations on a single tile.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Tue Oct 14, 2014 2:25 am

Editor Update

Still making good progress on this, but it's taking me a lot longer than I thought it would. Particularly because pretty much all the existing code has to be refactored to provide full support for the features that we need. Plus the existing design is just kind of...well, sloppy. There are way more friend classes than there should be, essentially breaking encapsulation. I'm renaming a lot of members and methods as well as they were rather poorly named ("_ed_tabs" is the tileset widget, for example).


I have a good understanding of the editor code though, and I know what needs to be done. There's just a lot of changes and the next set of changes have to come in bulk due to the interconnected nature of everything. I'm trying to get to a point where we have a basic functioning editor (or at least one that doesn't crash) to checkin so I have a reference point moving forward. In the meantime, there are some features that I'm temporarily disabling because reimplementing them can be done in a future commit. Those changes include:

  • Undo/Redo function
  • Autotiling support

I'm going to be updating existing editor documentation and adding new docs at some point as well. I have to say I'm kind of glad that there's no one presently working on the maps or map code, because these changes are extremely disruptive and it helps me to know that I'm not going to be screwing up anyone else's work. The existing map files will all have to be converted to the new map file format (that I'm still deciding on), but that should hopefully not be too difficult and can be done manually rather easily.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sun Nov 02, 2014 8:38 pm

Another quick update. I decided to take a break from this work last week to catch up on other things in life. Back to work as of yesterday. Still coming along steadily, its just a slow process because this is such a large refactoring/renaming/redesigning of the major components of the editor. My goal is to get it to a state where you can create a new map and draw tiles around on it, then make the next commit. The load/save map feature will not be enabled in the next commit because both the editor and map code will need to be modified to handle the changes made to the map data file format.


I'm starting to get the point now where I wish someone else was around to help with this work, so I might start looking around for a developer to join us. There are plenty of features that I can offload to others as I work on the more critical components. But I do want to wait until I've committed something that works and that isn't going to go through many more major changes. Eventually, I want someone else to take ownership of the editor and add all the features listed in this thread (the top post has been updated, BTW). That will allow me to work on creating the maps for the next release, while the editor is still being improved to make map editing easier to do. I'm not unopposed to working on the editor myself, its just that I want to start seeing real progress on the release again. I can't work on both the editor and the maps by myself (well, I can...it will just take me forever). Although if we can find someone who wants to work on the maps rather than the editor, that would be equally awesome (and then I could focus on working on the editor myself without worry).


Also FYI, I spoke to gorzuate about the editor around a year and a half ago and he said that he was pretty much done with it and Allacrost in general, so I'm not planning to contact him to take it up again.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Sun Nov 16, 2014 6:11 am

I've been busy with building and setting up a new PC in the last couple weeks, so I haven't been able to get much done here. I'm back to working on it now though. Taking a break has made it even more difficult, because there's so much change and I'm not sure exactly where I left off. My next commit will likely just be a checkpoint for me where it compiles and the build files are all updated accordingly. I don't expect the editor to work in the next commit though. I need to get to this checkpoint first, then I'll focus on making the editor work again. I also updated our Roadmap on the wiki with the editor tasks discussed here.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Thu Nov 20, 2014 12:36 am

Status Update:

Things are progressing quite nicely once again. The Editor class is all I have left to go through before I'm reading to begin trying to get everything to compile. Once I have something that compiles, even if it doesn't work completely, I'll be making a commit as all of the new/renamed classes and files should be stable from that point forward. My goal is to get to this point by the end of the month at the latest.

Once I reach that point, I'm going to take a step out of the editor for a while and focus on the changes that need to happen in MapMode and the map data files. This will include overhauling the format of map data files to support the changes in the editor and better represent layers and map contexts. In MapMode, I'll be adding support for multiple tile layers and custom layer draw ordering. I don't think these changes will require too much work (I hope), and I'll make sure to test these changes so that the game is still playable.Once this is done, then I'll turn back to the editor and get it working again so that we can create new maps and edit our existing ones just as before.

I will say that this editor work is a lot more difficult than I initially thought it would be. I guess I'm partly to blame, as I didn't really need to overhaul it like I've done, but the architecture was just so...wrong and cumbersome and I hate working with poorly designed code. Even though the changes you'll initially see will look like a step backwards in some ways (for example, undo/redo support is being disabled and won't be available again for a while), in the end this will make the editor easier to maintain and grow as we need it to. Plus I want the editor code to be as kick ass as the rest of Allacrost is. :) I am enjoying doing this work though, so I won't mind sticking with working on the editor for a while if that's where I'm most needed.
Image
User avatar
Roots
Dictator
Posts: 8665
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Release 0.1.0: Map Mode/Editor Feature Changes

Postby Roots » Mon Nov 24, 2014 12:29 am

There's one ancient feature of the editor that I've been debating on whether or not it makes sense, and that is adding music files to the map. As you know, map files are now separated into data and script portions. Data file created by the editor, and script file written by hand. Because multiple map scripts can make use of the same map data, it doesn't make much sense to put the map music in the data file since it may not get played. Of course, a script can always add the necessary code to load/play different music files than what is available in the map data file. So originally I was thinking of keeping map music as an item that will still be defined in the map data file and contain the "common" music that you would hear on this map.


But after thinking about this some more, I think its a better idea to just strip music out of the data file (and hence the editor) entirely. It is very easy to add the appropriate music files in the map script file. So I'm going to strip the ability to set map music from the editor completely. If for some reason we decide to re-enable this ability in the future, it shouldn't be too difficult to do.
Image

Return to “Programming”

Who is online

Users browsing this forum: No registered users and 3 guests