Graal Development Suite Concept

In order to best support the future of Graal development, development
needs to be simplified and accessible for everyone. Especially now with
Windows 10 becoming more and more popular Graal is losing its already
small pool of developers as tools such as GraalEditor cease to work with
newer operating systems. Without replenishing this development tool
Graal will eventually come to a grinding halt as servers no longer have
developers to support the mobile servers.

In its prime of developer support, developing on Graal was never simple
nor easy. It was a frustrating but rewarding process. Even when the
level editor was still being updated you still had to deal with cumbersome
processes when creating levels, such as having to restart the client every
time you edited an image as the new version of the image didn't show.
Eventually as Graal was expanded tools were band-aided together instead
of new features being fully realized and implemented into with its fullest
potential.

As Graal grows in popularity we're not properly utilizing this growth to
replenish the developer pool. Developers are moving on with their lives
and the tools are too broken and too out-of-date to bring in new developers
as fast as we're losing them. Even with updated tools, it's all such a slow
and broken process that it's hard to pull in new interest when they have to
go through so many loops to see a result. It's not uncommon to see new
users who get frustrated with "I can't see my image in Graalshop!" and
"How do I make a Zone level??" And having to give them complicated
multi-step instructions on how to fix their images so they're compatible
with 15 year-old tools and how to add scripts to their level so they can
simply make a level for Zone.

Combining all the tools into one so developers can develop nearly all the
content within a single program will greatly simplify the entire process and
ease the headache many new users often get frustrated with that risks
pushing them away forever.

-----

All-in-One development tool for the following:
  - General
    - All tools are loaded/edited from within this one program. No individual
      programs for each resource. File > New would open a window letting you
      pick what new file you wish to create:
      > NW
      > Gmap
      > GANI
      > PNG/GIF/MNG
    - Each resource is managed as a tab at the top of the window. Some way to
      differ each tab type(NW vs Gani for example) would be beneficial.
      Maybe icons or color?
    - Server Profiles
      Some people work on different servers, and it's important for them to
      isolate specific images/ganis/files. Server Profiles will be a way to
      change your development environment to support the server you are
      currently working on. If you are working on say, Era instead of Classic
      you could set your server profile as Era. Obviously you could create your
      own profiles(such as a new project you want to work on for fun). Profiles
      will create a folder and structure for images/ganis/tiledefs and similar
      things and prioritize loading these resources before any other. Maybe even
      have these profiles load in default tilesets for their respective servers.

      Example structure:
      + Profiles/
        + Classic/
          + Images/
          + Ganis/
          + Tiledefs/
          + Classes/
        + Era/
          + Images/
          + Ganis/
          + Tiledefs/
          + Classes/

    - Class support. Classes are an integral part of any organized server and
      thus essential to overworld development. Classes can be loaded from a
      folder(using the same text/file format as servers use for class files)
      and act as supplemental NPCs when a script in an overworld has joined to it.
      This would also work with the above server profiles so you don't need to
      worry about what classes will load for the specific overworld you're
      using(for example having an overworld load the Classic "tree" class
      instead of the Era "tree" class when you're working on the Era overworld.
    - Because all the tools are combined, this single program can control and
      manage its own file cache as files are created within in, no longer
      needing to scan folder structures for updates(though maybe an option
      for those who want to use an external image editing tool).
    - Designate the MAIN resource folder(c:/Program Files/Graal) as well as
      add more resource folders to also cache.
      (For example if I want to add a folder on my desktop it will also
      load/cache/scan changes this folder as well).
    - Live update of resources. As images and ganis are edited their new
      versions are loaded so you can see changes on-the-fly.
    - Server Flags? Maybe necessary for cosmetic script parsing, but seems
      like a stretch.

  - NW Editing
    - Updated image support for all image formats the client support
      (png,gif,>8bit images,jpegs).
    - Shortcut to create new image in the NPC editing window(Browse|New).
    - Tiledefs are managed with a tool instead of with scripts. Possible
      to maybe support loading them from scripts if found, however
    - Basic GS1/GS2 parsing. Since we can no longer play-test levels, 
      we need to be able to load as many cosmetic functions as possible.
      For example, setting the gani of an NPC via this.ani = "idle" or
      setCharAni("idle",null). Should parse onCreated first, then onPlayerEnters
      secondary. As well, serverside is parsed first and then clientside.
      May be necessary to parse through paths of functions to enable the most
      amount of compatibility as possible. For example:

      function onCreated() {
        updateImage();
      }

      function updateImage() {
        this.image = "block.png";
      }
      
      As well as cosmetic, basic modifiers should be parsed as well since
      Graal does not support loading floating-point NPC positions. So support
      of things such as this.x += .5;this.x++; and this.x = this.x+.5; are
      necessary to get the fullest extent of support as it is a common method
      of placing NPCs in server development.
    - Light Effects should also be supported, and with the above cosmetic
      parsing display the fullest emulation possible. This includes
      different modes.
    - Vertical tabs on the right will leave much room for expansion of
      new tabs as needed. These tabs will work similar to the radio 
      buttons of the current editor, changing the tool categories
      (tileset, predefined tiles, etc...).
    - It will be impractical to support old Control-NPCs maybe some
      basic built-in tools like path generator, tree placing and so on.
    - Layer support is mandatory, including a layer manager similar
      to Photoshop with thumbnails of each layer.
    - NPCs with setShape and no image should have some sort of visual
      representation of the area they block. While clicking on their
      shape should allow selection detecetion like current GraalEditor
      it should be lowest priority under all other NPCs. It's annoying
      trying to click character NPCs while they are obstructed by a
      setShape() NPC 20 tiles to the left.
    - Adding character NPCs like GraalEditor should be simple. It doesn't
      need to be as complex as the old method, but allowing simple
      things like adding a character and setting their look and gani,
      and placing the script with new GS2 instead of GS1.
    - Being able to toggle visibility of all level aspects, such as
      links, signs, npcs(should be divided into categories:
      character npcs, setshape npcs and regular npcs)

    
  - GMap Editing
    - Instead of loading gmaps via scripts instead these should be
      treated as levels themselves, similar to how servers handle
      them. You simply open the gmap file and it will load the gmap
      as a large level in the editor.
    - Create a low-resolution render of the gmap on loading, and
      update this "thumbnail" every time a change is made to the
      render buffer.
    - The horrible + cursor should be removed as it's counter-intuitive 
      and always in the way. Scrollbars should be visible no matter
      the size, and instead navigating will be assisted by a "map" pan tool.
      Holding space will overlay the current thumbnail preview of the
      entire gmap and the camera position. You can navigate by
      dragging the camera box around.
    - A way to modify the layout of the gmap.
      - Expanding the gmap should be easy. You should be able to change
      its size with a simple window interface that lets you input the
      width and height(in levels). Photoshop has a useful tool when
      modifying canvas size that lets you designate which direction old
      content should be "pushed". For example if you start with a 5x5
      gmap and resize it to 7x7 you can tell it to push the old content
      to the bottom-right and the newly created levels will be added to
      the top and left sides of the gmap.
    - Ability to export the gmap as a whole image, at various
      resolutions(100%, 50%, 35% and so on).

  - Gani Editing
    - Visual-assisted sprite addition(see Jerret's GSPro tool)
    - Panning should now be changed to SPACE+drag
    - Dragging will now default to selecting multiple sprites at one time,
      allowing you to move, cut/copy/paste and other functions to
      multiple sprites at one time. Shift+LMB will add an individual sprite
      to the selection and Alt+LMB will remove the sprite from the selection.
    - Support of ROTATESPRITE/STRETCHX/STRETCHY and other already supported
      gani functions by the client should be supported visually within
      the Gani editor.
    - Just like the NW support, light effects should also be supported.
      Perhaps clicking/selecting these light-effect sprites should only
      detect it as a valid click if the post-render alpha value is > 150
      to avoid selecting a light effect because you clicked on a portion
      of the image that is hardly visible.
    - A separate window for managing ALL of the ATTR/PARAM values.
      Common values should be visible on the main interface as current
      GraalShop works, but extented support is necessary as many servers
      utilize all 30 Attributes.
    - Support for modifying all default player values, such as body colors.

  - PNG Editing
    - Simple and intuitive like MSPaint, easy for new users.
    - Layer and transparency support.
    - Alpha support for loading and maintaining alpha channel, but not
      editing(too complex, ruins the simplicity). This is for
      compatibility reasons, so images loaded with alpha values are
      not broken if saved.
    - Create blank canvases or templates(for example the hat template)
      that serves as a background and not part of the image.
    - Palette support. Either remember palettes for individual images,
      or load the palette from the image itself when the image is loaded.
      Images that match the constraints of the body image should have
      appropriate tooltips/indications in the palette for their respective
      color-swapping functionality(skin, coat, etc...)
    - A preview function for player resources(heads/ganis) that shows what 
      the image looks like when animated in default ganis, such as
      walk.gani and sword.gani