a)email to me and I'll stick it on my site (with permission)
b)when it's posted on goofans I'll stick it on my site
c)both of the above
d)don't worry about it
6. Using an external program to do en/decrypting is redundant.
Well, for a beta version, this is understandable. I personally don't have any clue how en/decrypting works, and it'll probably take a lot of effort on Enchanter's behalf to be able to integrate this into his own program...
Thank you! People don't understand that I still have a lot to do before I add to this function.
MOM4Evr wrote:
1. Don't use MEGAUPLOAD, but MediaFire instead (no waiting time and it's faster)
..Or email it to me and I'll stick it on my site and post a direct link here. No ads!
Other ones: good points, GMMan.
Whatever. Keep up the good work, Enchanter!
I used Megaupload because, from experience, I have learned that Mediafire deletes the download a lot faster than other share websites to save bandwidth.
If I might weigh in... {Get comfortable... this got longer than I planned}
The single biggest thing that's going to make / break this is how simple it makes designing a level, and that's all going to be down to the GUI design. So that should be your core / sole focus initially.
I just Dl'd the Beta...
and before you go too far down that road... (sorry)
I realise that some of this will re re-iterating some of what GMMan (and you) have said.. But looking at the Beta I don't think you're taking the Drag and Drop thing far enough.
Generally, regardless of what program you're writing... aim for
Fewer Clicks
Fewer Popup Forms
"Intelligent" Mouse Pointer
Selection-Appropriate Toolbars or Options Panels
Drag and Drop / Select from "Palettes"
Allow Multiple Selections and perform same action on all.
Allow Undo
Right-Click for common actions (beyond cut,copy,paste,delete)
The original WoG editor has some good design elements, and some terrible ones...
I'd suggest building on the good ones...
Good Things in the Original GUI Design
Multiple Document Interface
Good because you can load another level to look at what was used to do something, switch between them easily, and Copy and Paste between levels.
Side Panel
This can be very useful if done well.
Object Properties Panel
The panel itself was the good idea, the implementation wasn't great.
Bad Things in the Original
Select Mode or Move Mode is always terrible.
Right click a "Tree item" to Add an object - Yuk
Extremely Poor resource management.
The basis of my thinking.
The vast majority of the objects used in any level are either GFX, Geometry or GooBalls.
So the addition and manipulation of those things should be made as absolutely as simple,easy and quick as possible.
All the other stuff... that you set once per level or is hardly ever used can be "not quite so easy".
My key ideas
Side Panel
The top half is a Drag-Drop source for all the common stuff, and possibly "everything".
It would have several Tabs (Goo, Geometry, GFX... see Resource library below)
You just pick up a thing, and drag it into place on the level and most of the time.. your done.
The bottom half of the side panel is the Full Properties window.. like the original... only better!
Resource Library
This is one of the "BIG" things.
I find one of the most annoying things making a level in the original is finding and handling the resources. OK, I like the "Update Resources" thing.. so if you add a new graphic to your folder it shows it.. but...
It would be great if from the point of saying "New Level" you had simple access to all the GFX, Effects, Sounds and stuff from the original game.
There'd be "A LOT", so probably wise to tag / categorise it (Trees, Bushes, Cogs, Walls, Backgrounds etc), perhaps split it up by chapter etc...
But then you'd have it all available in the side panel, and when you drag something into your scene the program automatically puts the entry into the resource file for this level.
You could also include GFX and stuff from other custom levels... although then you'd either have to have something that tracked the "depends" ...
or easier ... An option to "Localize" the resources i.e. Copy any file that's used into "My Folder"
Mouse Pointer
Should be able to select and move and "other stuff" without changing mode.
Should also be able to select multiple objects.. hold shift and click another.. draw a rectangle around a group.
Then you can move them all at once, or set the same property of them all or whatever.
Other "Essentials" / "Niceities" I've thought of.
Strands can be easier
Rubber-band maybe... click goo#1 rubberband to goo#2 click
or maybe a strand "mode", or drag a strand into the scene
then it automatically detects Goos in range of the Mouse Pointer and shows a strand between the closest 2... click or drop to add...Similar to how the game works.
Offset pasted items
If I copy something then paste it with the mouse (right click prob) it should appear where the mouse is.
If I use the keyboard and I paste a bunch of them offset each one so they aren't all sitting exactly on top of each other.
Auto-Handling of Text resources for signs etc
User drags a Signpost into position, sets Text = "Blah Blah"... and the program does the rest... and creates the text.xml for the goomod would be useful!
Easier Tag / Filter interface
Drop-Down list is OK but when more than one is needed, it'd be better to have tick boxes or something, rather than the user having to enter a comma separated list of names where only the first one appears automatically.
One-shot assignment of things like Music.
Drop down list of all available music files from the library, or just Drag the music file over to the Music "box" and that's that.
Ability to create the goomod
Why not put an addin.xml in the level folder, and then you can set / edit stuff like author, description, version, OCD etc in WOG Editor... and leave the un-encrypted xml files there too...after which making the goomod is pretty simple.
Combine / Uncombine Geometry
Goes along with multiple seletion, if I select multiple geometry objects it'd be nice to have an option to combine them. If I select a combined object, be nice to be able to uncombine them.
Mouse Wheel Zoom (per the original)
But could be improved to centre the point where the mouse is,
or even more "natural"... keep the point where your mouse pointer is in the same place on the screen after the zoom.
I realise the above is a lot to take in, but it's all just suggestions.... and much of it based on things I find annoying in the original... I'm just highlighting them here so (hopefully) you don't fall into the same traps.
I hope some of it will prove useful.
Agreed on pretty much everything Daft as Brush said. Having not tried the beta there's only one additional thing I can think of right now: a mirror function that can, well, mirror the current selection either vertically or horizontally.
Yeah, I thought of a "strand" mode idea eariler, but forgot to post.
Maybe click on one goo and drag to the other to create a strand, that would be really really useful. Or Daft as Brush's idea, whichever works better.
And as thB said, I also agree on pretty much everything Daft as Brush said.
You have definitely given me a lot to think about, and I think I am going to model this VERY differently. All you said is true, especially making it as easy as possible for someone to make a level. I think I have a new idea of how to structure this program...
I will use a mixture of several different programming languages: one for the GUI, one for the encryption/decryption, and one for simple commands.
THIS time, the GUI will be a big factor, and I will definitely need to use an easier language for it. I will still use VB for the copying and moving of certain files, but python is easier for encryption. The third programming language will remain a secret, but will be easiest for the GUI to be structured on it.
Err... Yes!
I had just a couple of extra "thoughts" / "niceities" to add to my previous...
But I've just read your latest posts and now it looks like I'm going to "go off on one".. again.
Thoughts first...
User should be insulated from file structure
The user doesn't need to know anything about scene / level / resources.
The program needs to know which objects go in which file, and which properties are for the scene and which for the level, but the user doesn't.
Locking / Freezing elements in the level
This wasn't so much of an issue with the original, because selecting and moving stuff was such a pain... but once you've made it really easy to select / move / rotate / resize stuff, you'll find people start making lots of mistakes and click and move the wrong thing.
Would be nice to be able to lock things in place (like the background graphic, wall geometry, even goos) so once you've got them positioned and sized correctly, you can't move / rotate / resize them accidentally.
Off on one....
Enchanter wrote:
I will use a mixture of several different programming languages: one for the GUI, one for the encryption/decryption, and one for simple commands.
I'm with GMMan... this sounded bad when it was 2 languages.. now it's 3 and one of them's "secret"
But I'm also with MOM4Evr...
There's no point in getting bogged down in the encryption right from the start. So use the existing python util to get you going, but don't rule out the possibility of doing it "native" later.
In fact... I reckon the encryption should probably be the very last thing to think about... not the first. Just decrypt a couple of test files with GooTool and forget about it... all the "real" work will be dealing with the unencrypted XML.
Cross-Platform
The game is, GooTool is, making another level editor that isn't seems "daft".
Open Source
Don't get me wrong, I'm not one of these Open-source nuts.. but in this case I think it would be beneficial. Not so much from the side of, other people can make changes, add features and customize it later. More from the side of... this is quite a big project, and you're probably going to need help (read on).
Road Map
I've had a look at your "To Do" list, and I think you've missed a few things... here's my thoughts...
1. Prototype GUI
But it doesn't need to be anything like complete. A menu bar, and MDI area (with a single form), a mostly empty side panel should suffice.
2. Decide on internal programming model and data structures.
3. Load a set of XML files and put the info in the internal structures
(As I said above, don't worry about doing the decryption... just decrypt "Going Up" or something with GooTool and use those)
4. Display the Level
(Zooming / Scrolling / Panning optional)
5. Ability to click the display to select an object and display its properties.
.... To be continued ...
My suggestion, forget about all the "frilly stuff", the wish lists and what people would like to see in a program...
If your next "beta" can even get to step 4 I'm sure we'll all be happy!
And even happier if it only uses one language and can do it on PC, Mac and Linux!
Hmm, well, it would be easier for others (and yourself) to edit if it only used one language, true, but some things may possibly be easier with multiple. I would think that this would only complicate things when you try to link everything together into a single program...
Other than this, I wish I could have thought of all those ideas. Good points, DaB!
Hmm,using different languages is a really bad idea.To understand Python you need to download it.It may really lag the computer.Then the proccesor is forced to understand 3 programming languages at a time,not to mention that it has to read from Python,then understand the code.If you have a question about C++ google it or ask here
Trust me all of you. MOM4Evr is right when he says that using multiple languages will allow more to happen. Trust me, they will call upon each other. (the GUI lang. will call on separate VB exe files to do certain tasks and will call on Python exe files for encryption)
PS Python is the only language in which MULTIPLE people have posted source code for wog-encryption. Nitrozark used one of these sources for WoG Editor. As for the cross-platforming, the GUI language (I think) has been ported over to mac. Now, it is a matter of the VB/Python to be ported. If someone can research this for me, that would be great.
Thank you all for your comments. Feedback is what will make this program great!
Wow! I actually got something right!
Anyway, good luck on the program, Enchanter.
Joris: All compilers that compile to .exe's compile to binary format, and the languages used have no effect on how the programs run. So the processor will see several programs running in binary format, and won't say "oh, no, I have to run 3 languages at a time!" It'll all be in binary format, like the computer likes it.
Enchanter: good idea for having seperate .exe's for each task. Nifty! I thought you meant you wanted to compile all 3 languages into one .exe file. That would take a whole lot of work with different compilers!
good idea for having seperate .exe's for each task. Nifty! I thought you meant you wanted to compile all 3 languages into one .exe file. That would take a whole lot of work with different compilers!
Well, I didn't even know that compiling into one .exe was possible.
Yes, the GUI .exe file will call upon other .exe files to do certain tasks that its programming language can do.
Yep. Some high-end programs that need to run really fast (like 3-D games) will code some of the time-intensive stuff in assembly (which compiles to fast-executing code), and the rest in C++ or something like that. Of course, you need an assembler and a compiler made by the same company, whose object files can be linked together...
It takes a lot of work. Your way is easier. Good luck!
Yep. Some high-end programs that need to run really fast (like 3-D games) will code some of the time-intensive stuff in assembly (which compiles to fast-executing code), and the rest in C++ or something like that. Of course, you need an assembler and a compiler made by the same company, whose object files can be linked together...
It takes a lot of work. Your way is easier. Good luck!
Thanks for the luck!
So far, I already have the basic mechanics for the palette.
I will DEFINITELY be able to release this sooner if I remove a few things...
This level editor will actually be able to CREATE levels, but not EDIT them. Well, there will be a special editable format for levels created with the program, but otherwise they are not allowed to be edited. I was also thinking that this program should only be allowed to make levels with objects found in the game. (if anybody is desperate, they can re-edit the level in WoG Editor for custom sounds/images) Trust me, if I do it this way, a LOT will be pushed off my chest. I expect to be able to publish this in a month or so from now (if not sooner).
Thank you all once more for your support. Happy Travels!
On the other hand, not supporting custom content seems to be a relatively dirty, hard-coded approach. This looks like a great deal of additional work will be necessary to include custom content later.
Well, with the GUI language I'm using, it is hard to include functions such as resource additions, but it's possible. Possible, but hard. I chose this language so that I could create an easy-to-use interface with colors and pictures unlike the screenshot above. If I added those functions, it would take me at least a month longer to finish it. Besides, if it becomes a huge problem, I can add the features later once EVERYONE has a basic (easy) level creator.
@thB: Actually, it will be LESS work to add additional content later, after the level-building engine is done.
decision time!!!!!!!
a)email to me and I'll stick it on my site (with permission)
b)when it's posted on goofans I'll stick it on my site
c)both of the above
d)don't worry about it
My profile of awesomeness | Me on skype: pokelucas2000 | My drop | Me on...umm....I forgot
Well, for a beta version, this is understandable. I personally don't have any clue how en/decrypting works, and it'll probably take a lot of effort on Enchanter's behalf to be able to integrate this into his own program...
Thank you! People don't understand that I still have a lot to do before I add to this function.
1. Don't use MEGAUPLOAD, but MediaFire instead (no waiting time and it's faster)
..Or email it to me and I'll stick it on my site and post a direct link here. No ads!
Other ones: good points, GMMan.
Whatever. Keep up the good work, Enchanter!
I used Megaupload because, from experience, I have learned that Mediafire deletes the download a lot faster than other share websites to save bandwidth.
If I might weigh in...
{Get comfortable... this got longer than I planned}
The single biggest thing that's going to make / break this is how simple it makes designing a level, and that's all going to be down to the GUI design. So that should be your core / sole focus initially.
I just Dl'd the Beta...
and before you go too far down that road... (sorry)
I realise that some of this will re re-iterating some of what GMMan (and you) have said.. But looking at the Beta I don't think you're taking the Drag and Drop thing far enough.
Generally, regardless of what program you're writing... aim for
Fewer Clicks
Fewer Popup Forms
"Intelligent" Mouse Pointer
Selection-Appropriate Toolbars or Options Panels
Drag and Drop / Select from "Palettes"
Allow Multiple Selections and perform same action on all.
Allow Undo
Right-Click for common actions (beyond cut,copy,paste,delete)
The original WoG editor has some good design elements, and some terrible ones...
I'd suggest building on the good ones...
Good Things in the Original GUI Design
Multiple Document Interface
Good because you can load another level to look at what was used to do something, switch between them easily, and Copy and Paste between levels.
Side Panel
This can be very useful if done well.
Object Properties Panel
The panel itself was the good idea, the implementation wasn't great.
Bad Things in the Original
Select Mode or Move Mode is always terrible.
Right click a "Tree item" to Add an object - Yuk
Extremely Poor resource management.
The basis of my thinking.
The vast majority of the objects used in any level are either GFX, Geometry or GooBalls.
So the addition and manipulation of those things should be made as absolutely as simple,easy and quick as possible.
All the other stuff... that you set once per level or is hardly ever used can be "not quite so easy".
My key ideas
Side Panel
The top half is a Drag-Drop source for all the common stuff, and possibly "everything".
It would have several Tabs (Goo, Geometry, GFX... see Resource library below)
You just pick up a thing, and drag it into place on the level and most of the time.. your done.
The bottom half of the side panel is the Full Properties window.. like the original... only better!
Resource Library
This is one of the "BIG" things.
I find one of the most annoying things making a level in the original is finding and handling the resources. OK, I like the "Update Resources" thing.. so if you add a new graphic to your folder it shows it.. but...
It would be great if from the point of saying "New Level" you had simple access to all the GFX, Effects, Sounds and stuff from the original game.
There'd be "A LOT", so probably wise to tag / categorise it (Trees, Bushes, Cogs, Walls, Backgrounds etc), perhaps split it up by chapter etc...
But then you'd have it all available in the side panel, and when you drag something into your scene the program automatically puts the entry into the resource file for this level.
You could also include GFX and stuff from other custom levels... although then you'd either have to have something that tracked the "depends" ...
or easier ... An option to "Localize" the resources i.e. Copy any file that's used into "My Folder"
Mouse Pointer
Should be able to select and move and "other stuff" without changing mode.
Should also be able to select multiple objects.. hold shift and click another.. draw a rectangle around a group.
Then you can move them all at once, or set the same property of them all or whatever.
Other "Essentials" / "Niceities" I've thought of.
Strands can be easier
Rubber-band maybe... click goo#1 rubberband to goo#2 click
or maybe a strand "mode", or drag a strand into the scene
then it automatically detects Goos in range of the Mouse Pointer and shows a strand between the closest 2... click or drop to add...Similar to how the game works.
Offset pasted items
If I copy something then paste it with the mouse (right click prob) it should appear where the mouse is.
If I use the keyboard and I paste a bunch of them offset each one so they aren't all sitting exactly on top of each other.
Auto-Handling of Text resources for signs etc
User drags a Signpost into position, sets Text = "Blah Blah"... and the program does the rest... and creates the text.xml for the goomod would be useful!
Easier Tag / Filter interface
Drop-Down list is OK but when more than one is needed, it'd be better to have tick boxes or something, rather than the user having to enter a comma separated list of names where only the first one appears automatically.
One-shot assignment of things like Music.
Drop down list of all available music files from the library, or just Drag the music file over to the Music "box" and that's that.
Ability to create the goomod
Why not put an addin.xml in the level folder, and then you can set / edit stuff like author, description, version, OCD etc in WOG Editor... and leave the un-encrypted xml files there too...after which making the goomod is pretty simple.
Combine / Uncombine Geometry
Goes along with multiple seletion, if I select multiple geometry objects it'd be nice to have an option to combine them. If I select a combined object, be nice to be able to uncombine them.
Mouse Wheel Zoom (per the original)
But could be improved to centre the point where the mouse is,
or even more "natural"... keep the point where your mouse pointer is in the same place on the screen after the zoom.
I realise the above is a lot to take in, but it's all just suggestions.... and much of it based on things I find annoying in the original... I'm just highlighting them here so (hopefully) you don't fall into the same traps.
I hope some of it will prove useful.
duuuuuuuuuuuuuuuuuuuuuuuuuh
this is very confusing.....
My profile of awesomeness | Me on skype: pokelucas2000 | My drop | Me on...umm....I forgot
Agreed on pretty much everything Daft as Brush said. Having not tried the beta there's only one additional thing I can think of right now: a mirror function that can, well, mirror the current selection either vertically or horizontally.
my gooey profile | my video channel | author of Hazardous Environment
Yeah, I thought of a "strand" mode idea eariler, but forgot to post.
Maybe click on one goo and drag to the other to create a strand, that would be really really useful. Or Daft as Brush's idea, whichever works better.
And as thB said, I also agree on pretty much everything Daft as Brush said.
IRC | Chapter Tutorial | Reference Guide
@DaB: ...I am seriously BLOWN away...
You have definitely given me a lot to think about, and I think I am going to model this VERY differently. All you said is true, especially making it as easy as possible for someone to make a level. I think I have a new idea of how to structure this program...
I will use a mixture of several different programming languages: one for the GUI, one for the encryption/decryption, and one for simple commands.
THIS time, the GUI will be a big factor, and I will definitely need to use an easier language for it. I will still use VB for the copying and moving of certain files, but python is easier for encryption. The third programming language will remain a secret, but will be easiest for the GUI to be structured on it.
Alright, I will start on the new GUI immediately.
New GUI is already in the process of being built.
This should take no time at all (of course it will take time, but it will definitely be easier)
Any comments/questions?
Err... Yes!
I had just a couple of extra "thoughts" / "niceities" to add to my previous...
But I've just read your latest posts and now it looks like I'm going to "go off on one".. again.
Thoughts first...
User should be insulated from file structure
The user doesn't need to know anything about scene / level / resources.
The program needs to know which objects go in which file, and which properties are for the scene and which for the level, but the user doesn't.
Locking / Freezing elements in the level
This wasn't so much of an issue with the original, because selecting and moving stuff was such a pain... but once you've made it really easy to select / move / rotate / resize stuff, you'll find people start making lots of mistakes and click and move the wrong thing.
Would be nice to be able to lock things in place (like the background graphic, wall geometry, even goos) so once you've got them positioned and sized correctly, you can't move / rotate / resize them accidentally.
Off on one....
I'm with GMMan... this sounded bad when it was 2 languages.. now it's 3
But I'm also with MOM4Evr...
There's no point in getting bogged down in the encryption right from the start. So use the existing python util to get you going, but don't rule out the possibility of doing it "native" later.
In fact... I reckon the encryption should probably be the very last thing to think about... not the first. Just decrypt a couple of test files with GooTool and forget about it... all the "real" work will be dealing with the unencrypted XML.
Cross-Platform
The game is, GooTool is, making another level editor that isn't seems "daft".
Open Source
Don't get me wrong, I'm not one of these Open-source nuts.. but in this case I think it would be beneficial. Not so much from the side of, other people can make changes, add features and customize it later. More from the side of... this is quite a big project, and you're probably going to need help (read on).
Road Map
I've had a look at your "To Do" list, and I think you've missed a few things... here's my thoughts...
1. Prototype GUI
But it doesn't need to be anything like complete. A menu bar, and MDI area (with a single form), a mostly empty side panel should suffice.
2. Decide on internal programming model and data structures.
3. Load a set of XML files and put the info in the internal structures
(As I said above, don't worry about doing the decryption... just decrypt "Going Up" or something with GooTool and use those)
4. Display the Level
(Zooming / Scrolling / Panning optional)
5. Ability to click the display to select an object and display its properties.
.... To be continued ...
My suggestion, forget about all the "frilly stuff", the wish lists and what people would like to see in a program...
If your next "beta" can even get to step 4 I'm sure we'll all be happy!
And even happier if it only uses one language and can do it on PC, Mac and Linux!
Hmm, well, it would be easier for others (and yourself) to edit if it only used one language, true, but some things may possibly be easier with multiple. I would think that this would only complicate things when you try to link everything together into a single program...
Other than this, I wish I could have thought of all those ideas. Good points, DaB!
IRC | Chapter Tutorial | Reference Guide
Hmm,using different languages is a really bad idea.To understand Python you need to download it.It may really lag the computer.Then the proccesor is forced to understand 3 programming languages at a time,not to mention that it has to read from Python,then understand the code.If you have a question about C++ google it or ask here
Crazeh man!
Trust me all of you. MOM4Evr is right when he says that using multiple languages will allow more to happen. Trust me, they will call upon each other. (the GUI lang. will call on separate VB exe files to do certain tasks and will call on Python exe files for encryption)
PS Python is the only language in which MULTIPLE people have posted source code for wog-encryption. Nitrozark used one of these sources for WoG Editor. As for the cross-platforming, the GUI language (I think) has been ported over to mac. Now, it is a matter of the VB/Python to be ported. If someone can research this for me, that would be great.
Thank you all for your comments. Feedback is what will make this program great!
Wow! I actually got something right!
Anyway, good luck on the program, Enchanter.
Joris: All compilers that compile to .exe's compile to binary format, and the languages used have no effect on how the programs run. So the processor will see several programs running in binary format, and won't say "oh, no, I have to run 3 languages at a time!" It'll all be in binary format, like the computer likes it.
Enchanter: good idea for having seperate .exe's for each task. Nifty! I thought you meant you wanted to compile all 3 languages into one .exe file. That would take a whole lot of work with different compilers!
IRC | Chapter Tutorial | Reference Guide
Well, I didn't even know that compiling into one .exe was possible.
Yes, the GUI .exe file will call upon other .exe files to do certain tasks that its programming language can do.
Yep. Some high-end programs that need to run really fast (like 3-D games) will code some of the time-intensive stuff in assembly (which compiles to fast-executing code), and the rest in C++ or something like that. Of course, you need an assembler and a compiler made by the same company, whose object files can be linked together...
It takes a lot of work. Your way is easier. Good luck!
IRC | Chapter Tutorial | Reference Guide
It takes a lot of work. Your way is easier. Good luck!
Thanks for the luck!
So far, I already have the basic mechanics for the palette.
Palette is coming along nicely. I'm currently working on building it all the way and then turning all the objects into drag/drop buttons.
I think I have an idea for this program:
I will DEFINITELY be able to release this sooner if I remove a few things...
This level editor will actually be able to CREATE levels, but not EDIT them. Well, there will be a special editable format for levels created with the program, but otherwise they are not allowed to be edited. I was also thinking that this program should only be allowed to make levels with objects found in the game. (if anybody is desperate, they can re-edit the level in WoG Editor for custom sounds/images) Trust me, if I do it this way, a LOT will be pushed off my chest. I expect to be able to publish this in a month or so from now (if not sooner).
Thank you all once more for your support. Happy Travels!
YAY...but WILL you make a version that has these capabilities?
InfernoFans | Chest full of porkchops
I am working on it right now! (passively, of course. In other words, whenever I have the time)
not very good idea..
New levels usually have new images / sounds..
and how will this new format be compiled to bin or xml files?
last.fm
facebook.
.
Well, for now, it's a good idea to keep it as simple as possible. Later, he can add all this stuff.
IRC | Chapter Tutorial | Reference Guide
On the other hand, not supporting custom content seems to be a relatively dirty, hard-coded approach. This looks like a great deal of additional work will be necessary to include custom content later.
my gooey profile | my video channel | author of Hazardous Environment
Well, with the GUI language I'm using, it is hard to include functions such as resource additions, but it's possible. Possible, but hard. I chose this language so that I could create an easy-to-use interface with colors and pictures unlike the screenshot above. If I added those functions, it would take me at least a month longer to finish it. Besides, if it becomes a huge problem, I can add the features later once EVERYONE has a basic (easy) level creator.
@thB: Actually, it will be LESS work to add additional content later, after the level-building engine is done.
I'd like that ou release it to all platforms, not only windows.