Collectible Card Game Headquarters

Alright folks,

In case you might skip reading this one, there's a bounty on the bottom. So I urge you to read on.

The time has come for you to out your friends who are interested in Magic and UI Development (not just Design) and volunteer them to our project. In the last year or so we've made some huge strides on the Engine, AI, and Supported Cards side of the project. But we've made mostly nominal gains on the UI side. Sure, the Quest code got a revamp, and the primary Deck Editor got a facelift, but those are just peanuts.

So here it is, I know you guys love playing Forge as much as I do. And I love adding new cards and new features. I might be the "most inclined towards UI" of the devs, but mostly all of that has been Web Development, and it's not really a preference of mine. Still, it's cool to be in the middle of a Quest and run into something that was added recently and think "Man just last year, we couldn't even dream of doing this" But it's time to get the UI up to speed with the rest of development. There are a ton of UI screens that are all screaming for major upgrades. Now I know a lot of you might not think you know many people who would be interested, but you'd be surprised. Hell, most of the dev team are even from a Java background, so your friend should be able to manage.

What's in it for you, you might ask? Do you need something besides major UI Improvements? So be it. I, FriarSol, hereby declare a bounty. If you find us someone to help revamp the UI, and they are able to actually help out and do a reasonable amount of work (or more) I shall figure out a way to code up a game mechanic, or a feature of your choosing, ahead of all the features that I'd like to see and have on my ever-growing todo list. Feel free to ask around, or check the ChangeLists with all the things I've added in the last year.

And now for the caveat, before you get too excited there are some things I won't do, such as Multiplayer or Networked Player vs. Player. I'm going to grant myself some veto rights on what the actual mechanic/feature is. However, if I think there's a fathomable way to do your request I'll do it. It might take some time (hell it took me a month to rewrite how Phases worked, and things were still broken for a week or two after that), since I do have a full time job. But I do enjoy coding on the side, so as long as I'm not completely swamped at work, I'll be able to work regularly on your suggested task.

So there it is. Forge gets a UI dev, you get someone to code up a task that you've always wanted to see, without waiting for it to fit into the long-term schedule.

should we impose some sort of requirements on this? i'd hate for forge to suddenly have a fancy {3d} ui that i can't use because of my outdated hardware. getting rid of that "no netbook" restriction would be good, and could be done with adjustable font sizes. what about increasing the separation between the UI and the game logic? somebody experienced in a separation methodology like MVC would be good.

I just found a nice little graphics library for java. It isn't specifically designed for videogame development but it can draw images and respond to the mouse. It also has 23 demos so you can jump in and start using it.

I know that learning a new library isn't fun but this seems pretty good. It also "works with Swing" so you can use Swing for some of the gui. The graphics library uses Canvas as seen in the first demo source code, link.

G Homepage - "G is a generic graphics library built on top of Java 2D in order to make scene graph oriented 2D graphics available to client applications in a high level, easy to use way."

Seeing as there don't seem to be any takers on this, perhaps I can suggest an interim solution. Sol's request supersedes this suggestion, but I thought a small step might at least help. It depends on whether clickable 'hotspots' can be programmed though. I don't mind making some background images like the one attached that the interface can be placed on.


I don't think the changes should be too difficult, but I don't have the programming experience to give that as an educated guess.
- 'Game Type', 'Library' and 'Settings' titles fall away for graphic representations.
- 'Deck Editor', 'Settings' and 'Start' would need to have clickable hotspots.
- Library choices would now be pop up boxes rather than drop down lists, and would need to be placed in a fixed position.
- I moved 'Quest Mode' into game type selection list (It seems to fit well here, but can be made a separate button). I would love to see the basic quest mode options (ie. fantasy/normal, length/difficulty etc) appear to the on the scroll instead of a new frame, but that's a pipe dream. At this stage I'm more interested in making it look better rather than redesigning the UI navigation, thought I'd just throw in my vision of how it might develop.
- One fairly big change I did assume for this design was that the various options under Menu and Options in the taskbar, could be added to those listed under Settings. There would only be one place to adjust all the prefs then. These would be listed over the scroll region as a fixed popup I guess.
- Last thing I did was include a text region that could update the version number from a preferences file or something similar.

I don't expect any bounty for this (if it can even be done), as I'm barely doing any work, but I am happy to offer a bounty of my own to anyone that can make this work. I'll create your very own theme for the start screen. Its not much but its all I can offer. If anyone takes this on and needs the various elements as separate png files rather than as one big graphic let me know.

An implementation of the UI like this allows more user content creation, as long as a template is followed. If anything happens with this I'll supply a template if there's interest. And If there's a better looking interface, we might just attract an extra programmer or two that can help with the actual GUI programming that Sol initially wanted.

Edit: Just realised that the icon next to 'Select Human Deck' would have to be added with the popup, so makes life difficult and can be ignored. And as an extra note, I left all WotC symbols and references off the design as it needs to be part of the distro. Other downloadable themes can get all the mana symbols etc

Edit 2: Support elements could also be created for various themes. The card back/morph card could use elements from the theme, and tileable artwork used for the battlefield and other resizeable elements.

This looks awesome moomarc!

I really hope we find a kind soul to implement this.

Wow, that is impresive indeed!

Sloth wrote:This looks awesome moomarc! I really hope we find a kind soul to implement this.

Chris H. wrote:Wow, that is impresive indeed!

Thanks! I'd meant it to be a simple case of moving the text boxes and making the bounding boxes transparent, but in typing up the changelist I realised that I did a bit more than that Still, if even hotspots can be done I can rework the design to work with what's possible within the current devs' skill set.

moomarc wrote:

Sloth wrote:This looks awesome moomarc! I really hope we find a kind soul to implement this.

Chris H. wrote:Wow, that is impresive indeed!

Thanks! I'd meant it to be a simple case of moving the text boxes and making the bounding boxes transparent, but in typing up the changelist I realised that I did a bit more than that Still, if even hotspots can be done I can rework the design to work with what's possible within the current devs' skill set.

`
I do not have much experience with swing but it may be possible to implement your idea. A Swing button can display both text and/or an image. A JList in a scroll pane without the JComboBox might be able to handle the right side of your pic.

Currently, Forge uses swing to implement it's layout of elements. The defaults look like a business app rather than a game. Then again, your pic might be doable with swing.

We would need to consider how much heap space memory is needed as we currently are trying to reduce the heap space memory that is used.

Chris H. wrote:We would need to consider how much heap space memory is needed as we currently are trying to reduce the heap space memory that is used.

I'll separate the interface into the elements that I think you'll need, keeping sizes as small as possible. Then you or whoever wants to try can see what's possible.

This is definitely doable with much our existing UI architecture. Adding the background to the New Game screen didn't affect much. I think the trick will be to keep the image data as light-weight as possible.. Like reduce them to 256 colors..

I really like the Forge logo top-left. The F running into the bottom of the anvil seems a little forced - from thin line to thick.. Maybe make the F bigger to compensate? My inner Star Wars geek likes it when letters become outlines... so it's a really cool look, just seems a bit off.

Eclipse Indigo comes with a GUI builder, that's how I designed the Bug Reporting screen. It's almost as good as VB for UI design. I think I could take a shot at a new New Game screen with some of these elements....

what about resizing the screen? do these images scale well? do we need to store them as vector graphics instead of 2D images so that resizing looks correct?

Rob Cashwalker wrote:
Eclipse Indigo comes with a GUI builder, that's how I designed the Bug Reporting screen. It's almost as good as VB for UI design. I think I could take a shot at a new New Game screen with some of these elements....

Regarding Eclipse's Gui builder (AKA WindowBuilder), I have been slowly refactoring the windows so they can be parsed by WindowBuilder. Basically, WindowBuilder does not like when a class uses an inner class. I have been refactoring the inner classes into anonymous classes and they can now be parsed in WindowBuilder. There are still many to go (particularly the more complex Gui's).

Rob Cashwalker wrote:I really like the Forge logo top-left. The F running into the bottom of the anvil seems a little forced - from thin line to thick.. Maybe make the F bigger to compensate? My inner Star Wars geek likes it when letters become outlines... so it's a really cool look, just seems a bit off.

The actual font I used went from thin to thick like that. I just extended it a little. But I've broadened the top bar of the 'F' so let me know what you think. (anyone who wants to see will have to grab the elements zip attached).

Rob Cashwalker wrote:This is definitely doable with much our existing UI architecture. Adding the background to the New Game screen didn't affect much. I think the trick will be to keep the image data as light-weight as possible.. Like reduce them to 256 colors..

All the elements as full colour jpegs come to 162kb which is smaller than 1 HQ card. Is that really too much of a burden on heap seeing as it shouldn't need to be redrawn like the cards do?

The attached zip contains a folder with the various elements as jpegs and pngs, and a template with all the pixel dimensions and positions in case that helps. I created the elements so that there's no space between. This will hopefully make it easier for you. Let me know if you need something done differently.

Pre-post edit: I just tried creating a 256 colour gif and that turns out to be a bigger file in the end.

Edit: (@Braids) I designed it at 600x600 so that it would fit the netbooks when that resolution is supported, and shouldn't need to be scaled. If we need to make it scalable, then the png files will need to be used instead of the jpegs. The holding block for each element would have to scale proportionally as well. Let me know what I need to do from my side.

jendave wrote:Regarding Eclipse's Gui builder (AKA WindowBuilder), I have been slowly refactoring the windows so they can be parsed by WindowBuilder. Basically, WindowBuilder does not like when a class uses an inner class. I have been refactoring the inner classes into anonymous classes and they can now be parsed in WindowBuilder. There are still many to go (particularly the more complex Gui's).

Yeah I just noticed that, the Import Pictures screen had an error after pulling the repo this morning, about not returning jButtonStart. So I looked at the history and noticed that change.

The original GUI's were built by Rares with some ancient version of JBuilder. So at one time they were parseable by some sort of GUI Designer. I assumed that WindowBuilder just expected a certain format to parse the window, and JBuilder did it differently.

Thanks for fixing this, so that they can be easily modified.

I have Marc's elements and started playing with it in a new gui screen. I don't know how far I'll go with it just yet, but it does look promising..