| Dusty |
02-14-2017 01:53 PM |
Even as an experienced dev, developing is a pain. It's no wonder Graal is running out of developers fast. Something I conceptualized a while ago:
HTML Code:
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
|
