I committed the first version of an authoring UI app tonight. It can be run with java mikera.tyrant.author.Designer. It supports loading/saving tiles and things.
I'll post more details tomorrow (and it's still very much in flux).
Here are some of the keys:
r = rectangle mode
l = line mode
c = circle mode
- save map
+ or = load map
t jump to tile palette. Once a tile is chosen focus is returned to the editor.
h jump to the thing palette. Same as above.
z single level undo
If you save your map you can load it in the game via. F5 x.
Feedback welcome. I still have a lot to do on it, but it's usable now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I especially like the map save format - concise yet flexible and human-editable. Good design.
Minor suggestions:
- Click to select on the InventoryPanels would be cool (I half-implemented this in InventoryPanel but haven't figured out a clean way to turn the mousePressed event into a selection action)
- Map resize would be nice
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cool thanks. I saw your drawing mode addition too. I noticed your InventoryPanel changes and fleshed them out so click to select works now.
There are two fundamentally different paradigms at work the game's polling based model and the designer's event based. I made this distinction explicit in my changes.
I also added a fill mode that currently only works with tiles. I'm adding things shortly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the way to take the authoring to the next level is to allow some limited overriding of thing properties.
If we do this, we can customize library objects to allow for a very wide range of possibilities. We could make a particular door indestructible, or give something a different description, make it immune to fire etc.
The we represent this in the .txt file could be something like this:
---Things---
48x47 gold coin
.Number=50
48x48 message point
.Message="You see a big pile of gold coins"
I think that this would amount to only writing the local Thing properties to the file (normally none for a new thing).
What do you think?
And if it's a good idea, what would be the right interface?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK 1st version is done.
I added resize to the Designer.
Created a thing editor.
Added local changes to things.
In the editor to save changes just make the change and press Enter.
As before these maps can be loaded in the real game via F5 x.
There are obviously a number of things I'm still adding but I think it's usable enough now, if only barely, to start using to add content.
As an aside, part of the reason I initially held off on implementing the authoring stuff in the first place is due to my dislike of Swing and the limitations of AWT. I've rolled my own AWT widgets enough times in the past that it's lost all ot its pizazz. <grin>
I much much prefer SWT/JFace and I'm close to throwing in the towel and moving the whole authoring environment to an Eclipse based RCP application. AWT is OK, but going forward the authoring environment is likely going to need more that AWT can provide (I already gave in and used a JTabbedPane). I don't want to move to Swing.
Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not on my coding machine right now but sounds great - look forward to trying it out!
I don't have a big view about how the UI should be built, but I think that the most important thing is to avoid having a big dependency that will make it difficult for players/casual contributors to get involved. Having an eclipse based environment would be great for us devs, but against the spirit of having everyone involved. I'd rather keep everything on AWT, Swing or a small, portable library that we can include.
As a nice to have, it would be good to maintain some level of code reuse between the authoring tool and the game. Doesn't make much sense to different versions of MapPanel for instance. Refactoring so that the components remain suitable for dual-use will probably encourage good design in any case. Duplicated code is painful - witness the ListScreen/SkillScreen/InventoryScreen/SpellScreen split that was clearly a design mistake on my part and remains a PITA to maintain so that they are consistent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree that our goal should be to include everyone, especially non-developers. That said, a pure SWT/JFace application is very much available to everyone. Azureus and RSSOwl being the quintessential example. Another option would be an RCP based application - they aren't that big.
As you know, I'm all about reuse. So far I don't think there's any duplication between the authoring tool and the game. I refactor when I notice any.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I committed the first version of an authoring UI app tonight. It can be run with java mikera.tyrant.author.Designer. It supports loading/saving tiles and things.
I'll post more details tomorrow (and it's still very much in flux).
Here are some of the keys:
r = rectangle mode
l = line mode
c = circle mode
- save map
+ or = load map
t jump to tile palette. Once a tile is chosen focus is returned to the editor.
h jump to the thing palette. Same as above.
z single level undo
If you save your map you can load it in the game via. F5 x.
Feedback welcome. I still have a lot to do on it, but it's usable now.
Awesome start - exactly what we want.
I especially like the map save format - concise yet flexible and human-editable. Good design.
Minor suggestions:
- Click to select on the InventoryPanels would be cool (I half-implemented this in InventoryPanel but haven't figured out a clean way to turn the mousePressed event into a selection action)
- Map resize would be nice
Cool thanks. I saw your drawing mode addition too. I noticed your InventoryPanel changes and fleshed them out so click to select works now.
There are two fundamentally different paradigms at work the game's polling based model and the designer's event based. I made this distinction explicit in my changes.
I also added a fill mode that currently only works with tiles. I'm adding things shortly.
I think the way to take the authoring to the next level is to allow some limited overriding of thing properties.
If we do this, we can customize library objects to allow for a very wide range of possibilities. We could make a particular door indestructible, or give something a different description, make it immune to fire etc.
The we represent this in the .txt file could be something like this:
---Things---
48x47 gold coin
.Number=50
48x48 message point
.Message="You see a big pile of gold coins"
I think that this would amount to only writing the local Thing properties to the file (normally none for a new thing).
What do you think?
And if it's a good idea, what would be the right interface?
:-) Yep I'd already begun work on a thing editor. My initial implementation is using another window. I hope to commit something tonight.
OK 1st version is done.
I added resize to the Designer.
Created a thing editor.
Added local changes to things.
In the editor to save changes just make the change and press Enter.
As before these maps can be loaded in the real game via F5 x.
There are obviously a number of things I'm still adding but I think it's usable enough now, if only barely, to start using to add content.
As an aside, part of the reason I initially held off on implementing the authoring stuff in the first place is due to my dislike of Swing and the limitations of AWT. I've rolled my own AWT widgets enough times in the past that it's lost all ot its pizazz. <grin>
I much much prefer SWT/JFace and I'm close to throwing in the towel and moving the whole authoring environment to an Eclipse based RCP application. AWT is OK, but going forward the authoring environment is likely going to need more that AWT can provide (I already gave in and used a JTabbedPane). I don't want to move to Swing.
Any thoughts?
Try Buoy ?
It makes my life bearable when having to deal with Swing.
http://buoy.sf.net
Cheers,
T.
Thanks for the link Tom. I've followed various Java UI toolkits over the years (going back to IFC) and wasn't aware of Buoy.
Not on my coding machine right now but sounds great - look forward to trying it out!
I don't have a big view about how the UI should be built, but I think that the most important thing is to avoid having a big dependency that will make it difficult for players/casual contributors to get involved. Having an eclipse based environment would be great for us devs, but against the spirit of having everyone involved. I'd rather keep everything on AWT, Swing or a small, portable library that we can include.
As a nice to have, it would be good to maintain some level of code reuse between the authoring tool and the game. Doesn't make much sense to different versions of MapPanel for instance. Refactoring so that the components remain suitable for dual-use will probably encourage good design in any case. Duplicated code is painful - witness the ListScreen/SkillScreen/InventoryScreen/SpellScreen split that was clearly a design mistake on my part and remains a PITA to maintain so that they are consistent.
I agree that our goal should be to include everyone, especially non-developers. That said, a pure SWT/JFace application is very much available to everyone. Azureus and RSSOwl being the quintessential example. Another option would be an RCP based application - they aren't that big.
As you know, I'm all about reuse. So far I don't think there's any duplication between the authoring tool and the game. I refactor when I notice any.