Messages

Hey Lee,

Given that our utility is intended for use by the GM who only needs to keep track of key bits of Character information directly related to the game, what do you think of the following idea for a Character screen? We use the entire frame for the Character sheet, allow the GM to choose which stats he wants, and let him take a lot of notes. We may not even need a second page.

Related to the color frames around the tabs, what if we only light up the active tab(s) with color, and do the rest of the tabs in the style from your first screen, but with a line using a very dark shade of the tab color drawn along the bottom of the inactive tab? Just a thought. 

Welp! I'm off to a late lunch. Cheers!

-CW

Don't forget that this is a GM program & not a player program. ...a GM may make some notes on the players in the campaign (like who's alive, their health, where they are if not in the group & so on). I have never played a campaign where the GM has a full copy of every players stats etc as that is not really the GM's role.

Good point, good point. Then I think if we give the GM an ability to choose an icon, keep track of health, record some basic stats, and allow him to easily make notes to himself about a character; then the character sheet is doable and a nice feature to have. Regarding stats, looking at the sheets today showed me that we need to keep track of the original stat and the modified stat. Such as IQ: [current]/[original]. With creatures and units drawn from the library, the units are disposable and more can be called up from the library. But with a character, stats get modified as effects are imposed and are restored as the effects wear off or the character heals up.

I was thinking of a two page format for each character unit sheet, one sheet containing a stats and brief notes at the bottom, and the other for extensive notes should they be needed. (Could help the GM maintain continuity for characters across a campaign.

I'll mock something up in the morning so you can see what you think. Tonight, I have a DVD to watch. Mad Men Season 2. = )

Talk to you soon.
-CW

Thanks Erico! It's fun to put together a dream project and then see how far you can go to make it a reality.

Hey Fuzzy: I've been reading different types of character sheets and I am finding that this is going to be more of a challenge than I expected. RPG's have become more complex over the years from when I used to scrawl a few stats on a blank sheet of paper and called it a character. I blame the growing sophistication of computer games raising the expectations of table game players.

Some of today's sheets have dozens of stats and modifiers and go one for two or more pages; while we have, at best, a half-sheet size to work with. Still, I think we can do a utilitarian character sheet of two or three pages, with the first sheet being major stats, the second being secondary stats and the third being notes. I'll have a look at more sheets, play around with some sketches, and see what I can come up with.

We may need an array of arrays to hold it all and allow customization. There are base stats, and then four or five modifiers in some cases. Oh boy.. 

-CW

RE: Array of types. Sounds good. I'll consider a character sheet design with the assumption that we can customize equipment.

RE: Stats. Because the utility doesn't actually do anything with the stats (other than 'hit points'), it doesn't matter what they mean. All we need is a list, however long, of Label$, Value#, allow the GM to name them and set them however he likes, and allow the GM to modify the value as he pleases in game. They just won't have a health bar unless they are destructible. Anything  not fitting that format can be placed in the unit text. We can do some pre-configured character sheets for specific and popular games, but there will always be other games to be set up by the user any way he likes.

Icons are great, so we definitely want to incorporate them, but we need to allow the user to import their own creations, or use none at all. Maybe we should also include a library of icons drawn from that public collection of yours. They look great.

I don't see a problem with game compatibility for most RPG's. Our challenge is style and accessibility.

Ok! I'll start looking at Char. Sheets tomorrow and start playing with layouts.
Maybe we can do a couple of Char sheet types. A generic 'paper sheet' type, and one with a body-outline showing the location of equipment? Hmm.. that could get involved and it wouldn't work with non-humans. Still, we could manage even that if we treat labels and equipment as objects, allow the user to import his own screen-sized figure, and place the the objects anywhere on it. Oh my imagination is running away with me.  Ah well. Let's not worry about that for now. We can save it for version 2.0. lol

-CW

BTW: I LOVE  the neon look of the color pinstriped tabs and your use of color gradients on the health bars. They look imbedded in the frame. Very nice! You have an eye for this sort of thing. I noticed that you ghosted the background page under the unit popup stat screen. It looks fantastic, but how difficult is that to do graphically? Can that be done with a sprite-grab of the frame and a tweak to Alph?

I'm going to have to think on that. It's been years since I've actually played a live RPG game. I may have some ancient character sheets here, from my D&D days, but there have been so many RPG's since then. It's hard to say what design a character sheet should take today. Hmm..

We have a local Game Store with a room for gamers. Why don't I pay them a visit tomorrow, do some poking around on the net, and see what I can come up with. I'm sure we can hit upon a nice RPG format which would fit will on our unit sheets and will work for most games as a quick reference. See if you can noodle one up on your end and I'll do the same.

Question: how difficult do you think it would be to associate loaded gear with a character, and save the entire configuration? I'm a bit intimidated at the potential complexity, but if you feel comfortable that we can do it, it would make for a much more useful character sheet than a mere 'creature' sheet with static attributes.

-CW

It looks really good! 
Do you do your own graphics? The horse is spectacular, and the icons from your first example were very well done too.
I think we are on the right track for miniature units. What shall we do for an RPG character roster sheet?
-CW

I'm not wedded to colored tabs. It is just another visual cue for the GM. Maybe we can do the sort of black and elegant tabs you have with a color pin-stripe on them so the active frame matches the tab? What is kerning? Is that another term for proportional fonts? I have the feeling that I will learn a lot from you. (I like it!)

I'm heading out to get some sun and chum. 
Talk to you later!

-CW

Hi Lee. Here are the mock ups as I imagine the project, with special attention paid to the second-tier unit pages.

Oh! Rather than buttons displayed at the bottom of the tablet, how about pop-up menus on a right click? I tried adding scroll buttons to the mockup roster, and it just looked clunky. I think we should avoid buttons where we can.

Without farther ado, here are my mockup sheets reflecting how I'm imagining the project. I can't wait to see yours. But no hurry. I may take another crack at writing a better input routine and that can keep me busy for days. = )



The first is a roster snapshot from an imaginary American civil war miniature game, supporting troop factions from the North and the South. This would work just as well with a Napoleonic scenario. This sort of layout would also work extremely well with lists of npc monsters, traps, and other creatures. Notice that I am using a slightly smaller font for the tabs, which allows five of them. If we go even smaller, we can get six full tabs on the low-rez screen, except the small fonts become hard to read. Woops! I just noticed that the pop-up frame should be green, to match the tab. Pretend it is.

The second is a roster snapshot from a space-battle type of game where each unit has several destructible components (shields, armor, hull, weapons banks, crew quarters and such.) This type of roster would work very well with WarHammer 40k, with WoddenShips and Iron Men miniatures, with Car Wars, with StarFleet Battles scenarios, or even with a building being explored which has destructible components such as doors, walls, windows and floors.

If we can implement the ability to add weapons, gear and other components to the second-page stat list, this sort of layout is ideal for customizing units and supporting rosters of adventurers in a solo game. (In a multi-player game, each player would want his or her own character sheet, either on paper or on their own tablet running our utility.)


-CW
PS: How is that little laptop doing?

Once I get a look at your coding style I'll adapt to things like proper indentation and such. Most of my framework code was written before we decided to collaborate, which is why the comments are sparse. (Mostly notes to myself.) I'm finding during my mockup that the use of two shades of color, one active and one passive, isn't working out as I had hoped. The colored line around the frame is good, but the tabs just lay there, and (even when the color shade changes) it is not at all obvious as to which tabs are active and which are passive. So that is a problem. I like how you display your tabs, my only concern being with the ability of the GM to identifying at a glance, each tab when their text is hidden under other tabs. But maybe the team-color would serve for that. Hmm..

I liked the look of your round tabs so much that I stole the idea for my mockup. It looks great.

I tried a smaller font and (after a minor bug squash) the program scaled to a different font size very well. (You will see how the slightly smaller font looks in my mockups.)
A slightly smaller font size allowed for five tabs on the small screen, a much smaller font allowed for six tabs but started getting hard to read.
If we do some form of tab stacking, we may be able to get twice as many tabs. But then, how many rosters will a GM ever need?

I actually slept in today. (I needed it too.) It's time to get in the tub, get myself together, and head to the library to work on my mockups.

Talk to you soon, Lee!
-CW

-The only warning most of us get is, "Mind that bus, what bus? SPLAT!" -Rimmer of the Red Dwarf

Sounds good. Get that little lap top cared for!

Right now I'm all excited for the project; but this is going to take some time, so don't put yourself under any pressure on my account.
Let's take it at an easy pace. That being said, I'm about half way through my mockup and I should be ready to post tomorrow afternoon.

Cheers!
-CW

Here is the framework code so you can see the action of the tabs as I have them written.  I've tidied up the code and tied up the loose ends which were bothering me.

Don't worry about the programing methods I've used. I am more than willing to revise or scrap and start over. We can discuss the best approach to use in due time. I just want to give you a better feel for the mechanics I've envisioned. This is a huge diamond in the rough. (Or a huge rough in the rough..)

For now, the framework routine adds tabs to either side of the screen, can identify which tab is clicked on, and will remove the small tabs when the max number is reached. (I've limited the maximum number of tabs to four, for the small tablet screen.) Nothing else happens with color changes, highlighted frames or anything else as of yet. I can also easily add the ability to delete tabs, or cause tabs to swap screen sides, should alliances in a game change. From the tabbed framework, all of the roster functionality depends, so we need to get it right.

I haven't tested it yet, but the tabs and other formatting should scale with a font change, if we go to a smaller font than what I'm using now.

I was impressed by your last post, particularly when you were talking about the pixel boundaries. It does not shame me to admit that you are obviously the more experienced programer, so I am willing to let you lead the way in coding, doing what I can, and seeing how it is done. I suspect I will learn a lot. 

As for your life-bar ideas, I like both the one about the unit text riding on the life bar, (I'm envisioning something like how the download status button fills with color on my toolbar as the download advances) and I like the idea about the color of the bar changing from green to yellow to red as death draws near. We will have to pick a font with care.
Tomorrow, woops!, I mean Monday, I will begin work on my mockup ideas, with particular focus on what I imagined for the unit stat sheets.

The input routine works, but I'm not very happy with it. It leans on Inkey$ (blech!) and is slow as death. I plan to strip that out and replace it with a much superior mod that uses K=Key(), just as soon as I can hammer a better process out. The important thing for now is that this routine will not overrun the field, and it is designed so that I can later go back and add in a flashing cursor (which is already written.) The replacement module will be easily expanded to allow input of multiple lines of text.

I likely won't be back on until late tomorrow night or Monday morning. And don't worry about odd hours. I keep them myself. I go to bed late, my cat gets me up early, and I sometimes nap during the day.

-CW

PS. When we begin to focus on polishing the art, I definitely want to go with the rounded tabs, and maybe give the frames surrounding the rosters a bit of a 3D feel. That would be nice!

I really like the style of the rounded tabs and of the icons you used. My frames looks too boxy. I've been focused on the mechanics of the tabs. But as Steve Jobs showed us, style should not be ignored. Maybe we need a third person who can focus on the style and the art; and maybe code a way to easily stamp icons out of .png images. I definitely think you are on the right track. My only concern with the tabs as you have them displayed is with how well the text can be read when part of the tab is hidden like that. On the other hand, what you have is instantly obvious to the GM as to which tabs are active and which are not. (See how I thought to handle that below, where I comment on colors.)

I also envisioned a 'life bar" displayed on the roster page, next to each unit, maybe in green. Then you can tell at a glance the health state of each unit.

Something like:

                 Carrier:   60%   [//][//][//]
             Destroyer: 100%  [//][//][//][//][//]
                  Cruiser:   30%  [//][/]
       Mine Sweeper: 100%  [//][//][//][//][//]
              Battleship:    0%

Question, should we try for a compact roster or enjoy the luxury of spacing? Too compact and things can look cluttered. Too much space and it gets unwieldy for large rosters (of say, 30, 40 units or more in, say, a civil-war miniatures game.) How much spacing should we allow?

Also, when a tab is selected, the color of that team should be drawn around whatever frame the roster is in. I have set the tabs up to use two shades for each color. A bright shade when a tab is active, and a dark shade when a tab is passive. I want it to be instantly recognizable to the GM as to which team tab is being displayed on which roster. So maybe an elegant line of the tab's active color can be drawn around the frame.

Why don't I see about getting you a copy of the frame code as it stands now. (Well, after I tie up a few loose ends.) You can see how it currently functions and get a feel for it.
Tomorrow I'll be occupied with a social group I'm in, so look for my mockup on Monday or so. Then we can see about fusing our visions into an overall whole.

-CW

Oh, I had children once; but I had to get rid of them. The cat was allergic.

The idea was to separate the layout into two screens, one for each of two currently interacting teams. It seemed more intuitive to me to let the Game Master be able to choose an attacking unit from one roster frame, and a target unit from the other roster frame. But on a small screen, there may not be room for two rosters on display. The pop-up window for any given unit will be moveable anyway, and a GM may even want to select two units from the same team, for healing/repair purposes, perhaps.

So picture this, an NPC mage, (which is miniature #23 on the game table) wants to cast a fireball on one of the thee archers in team Blood Raiders (say, miniature figure #9 on the game table). So the GM goes to the team 'NPC' tab (which happens to be on the right side of the screen) clicks on it, causing the roster to load in the right side frame, he locates the unit #23 on the roster (also identified as type "mage"), clicks on it, and its unit window pops up on the right side of the screen over the right frame. Now the GM clicks on the "Blood Raiders" tab, if it isn't already active, (that tab is on the left side of the screen), which loads the Blood Raiders roster into the left frame. He selects the target archer's roster entry from the left side roster (unit #9), clicks on it, and the archer's full stat window opens on the left side of the screen.

Now the GM has two windows, side by side, one for each unit. Looking at the text notes for the NPC mage, the GM sees he has a base hit chance of 30% at that range, looking at the archers dexterity, the GM calculates a final hit chance of 25%. He rolls the dice, CRITICAL! The mage does 27 points of damage to the life of the archer unit! The GM then clicks on the archer's life bar and reduces it by 27 points, killing the archer. (The health stat of the archer now stands at -6) The archer's roster entry is now grey. The GM can either remove the dead archer from the roster, or leave the entry there in case of resurrection at some future time. The GM topples the archer figure (#9) on the game board. The game goes on!

To call up two units from the same team, you would click on one unit, move the window over to uncover the team roster, then click on the next unit.

That is what I had in mind. If we go with one roster window, it will mean more flipping back and forth between pages for the GM, which could be a distraction from the game. But if the small screen format doesn't allow for two roster windows, we may not have much choice. I just don't want the utility to get in the way of the game. Our focus as programers, naturally, is on the utility. But the GM's focus needs to stay on the game, and the utility should be as fluid and intuitive and as transparent to the real game as is possible.

What do you think?
-CW

PS: Ok, I'm heading to the library now. I'll check back in later. -Cheers!

That sounds good. I'll need to adjust the size and layout of my tabs and frames. Right now I'm working at the screen size of my laptop, which is 1366X768, which allows for eight tabs (with up to 13 letters for the team name) and two frames. (The screen is divided in half.)

Scaling up rather than scaling down makes a lot of sense, and a tablet is easier than a laptop to use for a GM. So perhaps one frame and a series of tabs across the top is the way to go. I'm not sure how many tabs that will allow us, but we will need to use fewer tabs, fewer letters in team names, or both. That isn't a big issue. And because the program is still so young, I can easily modify down to an 800/600 rez.

Let's each do our mockups and decide where to go from there. Take your time. I'm busy Sunday with a social group, so you can expect my mock-up early next week. If I have the time I may even make the 800/600 modification before then.

Talk to you soon!
-CW

Edit: I just tried the tab framework at the lower resolution and it scaled without a hitch. Have a look! (Screenshot_1)
(Note that the "Add Tab" tabs, though shown here, will vanish when the maximum allowed number of tab have been added.)
I'm thinking we can code this thing to run on any of three screen resolutions, 800/600, 1366/768 and for the home gamer with a large screen, 1766/992. Plus the PAL equivalents for Europe. (Do European screens still have more scan lines than US screens? That used to be the case in the days of Amiga.)
All we need to do is set the number of allowable tabs and roster items on display to match the user-chosen resolution. We may want to code our popup windews and menus to fit the smallest resolution for ease of coding though.

Sounds good. 
I'll begin work on my graphic mockup tomorrow. (DDgui can wait for Monday to be explored.)

Cheers!
-CW