-In a previous thread Lee and I began discussing plans for a spread-sheet style program which can manage up to eight rosters of units (eight players, or teams if you will) for use in live games such as D&D or Warhammer. Any game in which the players must keep track of a large number of units, their attributes and their health.
Lee wrote:
=======
Btw one little tip I can give you is read up on the basics of databases, things like different tables etc as believe me it will help with regards to data management as I'm sure your aware RPG's can be very heavy on data storage with various weapons/armor etc. Not only that but a well organised data structure makes retrieving what you need easier & more efficient on storage as well as access. A flat database like a spreadsheet becomes a nightmare to maintain when you start getting more data.
I used to use MySQL to handle my data but am looking into the sqlite wrapper that is posted elsewhere on this forum. Setting up a database with multiple tables requires a bit more setting up & planning but it rewards you afterwards with easy access & maintenance.
Obviously I don't know your experience with regards to databases but if you need an example of what I mean please let me know =D
Lee
Thx Fuzz.
I don't have any formal training in databases. I once wrote a set of utilities for use with a de-clawed cue-cat bar code scanner, to search, reference, alphabetize, add and delete items from a master list based on the bar code.
My current project will be a step above that, involving multiple and user-creatable libraries with entries of variable sizes. Every entry would have the same form and be separated by a "|" token. The form would be thus: four fixed attributes, UnitName$, UnitDescription$, Unit_Health%, and Unit_PNG$ thumbnail path, followed by a series of attributes; StatName$ and StatValue, for however many stats a given unit needs. A set of these unit types forms a library, weather it be a Warhammer library, a D&D player library, a Creature library or so on. Units from any given library can be loaded into any of eight rosters, and thereby form a player army. So it isn't enough to simply look up units from a library, they have to be copied over to form player rosters which can then be modified as damage is done to a given unit. Rosters units must be deletable (when dead) or not (so they can be 'healed' or rezed.) In many ways managing the rosters will be more challenging than managing the static library lists.
Including weapons as items with their own stats would be problematic, for then we need some way of chaining a weapons 'unit' to a creature 'unit'. Hmm.. We could include a simple descriptions of any weapons and damage potential in the text of the Unit description, or even display, in a very simple way, a given weapon as an attribute with its own health bar as one of the Unit attributes; but the ability to call up a library of weapons to pick and choose from for a given unit is an entire level of complexity, the implementation vision of which eludes me. But now that the seed is planted, I'll have to chew on it. Maybe that can be a goal for version 2.0.
The program itself will be fairly inert towards any given roster, unit or attribute. No animation, no automated updating of stats. Nothing taken for granted. The program largely won't know what a stat is or means. So any changes must be made by the GM. (Maybe I can grey a unit when it's health bar reaches zero.) The program will simply show a list of units on a roster with a 'health' stat bar next to it. Click on a unit and a detailed description including the full set of stats and a thumb-nail (if present) will open in a window. Up to two windows (for two units from up to two rosters) can be open at the same time. To change a stat, simply click on the desired stat and a set of buttons will appear by which the stat can be changed by +/- 1, 5, 10, 100. This will modify the stat, even taking it to a negative value. Very easy for a GM to modify on the fly in the heat of a game.
The real challenge isn't in the libraries, which will be very simple text file lists. The challenge will be in formatting all of this on the screen and keeping track of each stat location on the roster and in the pop-up windows so they can be clicked on and modified. Throw list scrolling in there and things will get very complicated very fast. That is what scares me about this project. I may be over my head. lol
Anyway, as a data-base, the libraries will be very bare-bones and simple things; which is all I can really handle.
I've never heard of MySQL. Do you think it might be of help given what I have in mind? I would love it if you can give me a link or two to check out.
I'm not worried about efficiency of library file sizes (at least for version 1.0), but the data must be in a format which can be easily fed into my Unit TYPE structures.
That being said, anything which can make the job easier will be very welcome, so I am eager to take advantage of any advice you can give.
Cheers, Lee!
-CW
MySQL (http://www.mysql.com/) isn't really an option here since that is a server you need to install and talk to with network commands. Makes installing your program a pain :-)
For the scrolling lists and so on, have a look at DDGUI that comes with GLBasic:
http://www.glbasic.com/forum/index.php?topic=2663.0
Cool Moru. Thanks!!
-CW
You dont need to install mySQL there are also portable versions, so include this with your program, start the mySQL server from program and be happy, would be possible. - But I think better way would be to use the SQlite port or use InIs, your own file format, etc...
I did say that I used Mysql in the past & will be taking a look at the sqlite wrapper that's posted in the forum.
Sqlite should be enough to handle the data but until I have a closer look at it I can't really say at the moment. Also depends on the amount of data involved, my previous programs had around 7 or 8 tables with close to 2000 records total (and I hadn't entered all the data lol).
@CW, I will post some more info in the next couple of days with more details. Don't worry to much about learning databases as only a small amount of things need to be learnt as you won't be building an enterprise solution ;D
Lee
Sent from my HTC Wildfire using Tapatalk 2
I will work on something more concrete when I get some info on D&D, Warhammer etc as tbh they are games I have not played around with in a very long time. GURPS was the last dealings I had with regards to RPG's and the major strength of that system was it was not tied to Classes or genres like D&D etc, so you had a common framework for any style campaign be it SCI-FI/Fantasy etc all bound by a common combat/stats system.
Reading your post yesterday was not so easy as I wasn't at home & the small screen on my mobile made it difficult for me to understand the context of your post fully.
It should be possible by looking at what you are attempting to do to skip the use of SQL and such & just stick with TYPES, but using the TYPES in a way similar to how a database would be organised. I/We would need some help from the members here probably as my GLB TYPE knowledge is OK but not fantastic, mainly because I'm so used to other implementations of TYPES that I sometimes get confused with GLB ones (not hard but think my age has something to do with it :D )
Attached is an image (very rough) of what I mean with regards to splitting up the data. In code it would be something like the following
TYPE Tcharacter
name$
chr_class
str
agil
intt
dex
mainhand
offhand
ENDTYPE
TYPE Tclass
idxkey%
class_type$
ENDTYPE
TYPE Tweapon
idxkey%
weap_type$
stat%
ENDTYPE
TYPE Tweapstats
idxkey%
weap_stat%
description$
ENDTYPE
Don't forget the code & the pic are just a very simple example of what I mean & created purely for explanation purposes.
Lee
I remember GURPS! Are you old enough to remember the wonderfully simple game which inspired it? Actually, two complimentary pocket games which were part of The Fantasy Trip. They were Wizard and Melee. I still have both games in their original plastic envelopes, along with half a dozen or so solo adventure modules for them.
In Melee, your character had just three stats: Str, Dex, and IQ. Each character was allowed two weapons, one ready and one slung. The rules booklet for the entire game were only 21 pages long, and each page was smaller than half a sheet of paper.
The expansion, Wizard, brought spell-casters to the arena, but the rules booklet to add Wizards is shorter still as half the booklet are lists of spells the magic users can learn.
Ah, those were the days! The roar of the crowd! The clang of weapon on armor! The gnashing of teeth! The spilling of precious cheese-curls! Yes, those were the days.
-CW
My friends where the major RPG/gamers, one of which still works or even runs a game publishing company I believe. I am more than likely old enough to know the games you mention but they don't sound familiar at the moment :D
GURPS is still going strong, 4th edition is the current I believe with a huge catalogue of expansions & campaigns. I have not played a pen/paper RPG for ages due to the main crowd of us who used to group are are now spread far & wide across the UK.
With regards to pc RPG's I played trough the Blizzard line up of Diablo, Warcraft etc where I ended up severely hooked on World of Warcraft to the point that I spent 8 years of my life on that game :D.
Lee
Ah yes, Fuzz.
I see what you are thinking, but I'd like stay even more generalized than that.
The program should be so general that it can be used equally well with games from D&D, to Battle in the Pacific, to Civil War miniatures, to Car Wars. I have a space-feet combat game, sort of like what you would find with a Star Trek combat game, called StarFire. There are literally dozens of different ships with different destructible components such as Hull, Cargo, Crew Compartment, Engines, Torpedo rooms, and so on. (The parallels to War Hammer 40k are obvious.)
To be able to accommodate all of the different types of games and all of the different types of stats a GM may want stat bars for, we can't hard-code ANY specific stat into the Roster program except for one: 'Health.' Be it a hell-cat in D&D or a Hell Cat in the air, the concept of 'health' still applies. A lot of non-changing specific stats for a unit, such as movement allowance or IQ, could be listed in the text description portion of a unit.
Now what you have done with the weapons is interesting. Maybe we could adapt a type of library which would load individual stats, each with a comment of its own. Than a GM could pick and choose among weapons for a unit, be it a mace or a Class II phaser. Hmm.. I'll have to think on that. But I like it!
Examples are better than descriptions, so give me a few weeks to hammer out a rough framework for what I have in mind and we can go from there. Over the next few days I'm going to study Kitty Hello's DDgui toolbox and see what I can draw on for our program.
-CW
I forgot to mention that with regards to the layout on screen of the data I used to base mine on the character sheets from the game. Practically all can be downloaded for free from the publishers website or some fan made ones.
It doesn't have to be an exact replica but it helps the GM relate to the data in format they are familiar with. If ever there was a good use for a tablet then something like this is it, tablets didn't exist when I made my tools so laptops where used.
Lee
WOW! You got bit harder with War Craft than I did. I only spent 5 years on that. And most of that time I played but a single character, a Shadow Priest in the BattleGrounds.
I LOVED PvP. I still do. My serious distraction today is Team Fortress 2. For fantasy, I'm actually thinking of giving the computer a rest and getting back into board gaming. I am seriously eyeing the game Mage Knight, which, according to the reviews, is supposed to have one of the best solo-play systems around. If only the rules book weren't such a hot mess. That is the only thing putting me off.
-CW
Hmm.. maybe we can do that format in the popup screens once a unit on the roster is clicked on. We can leave the labels definable by the GM, so he can lay them out similar to what ever unit/character sheet he likes; all savable to a library, of course. I'm warming to the idea. :)
-CW
With regards to keeping it as generic or flexible as possible that is not going to be an easy task due to the differing systems the games use.
One possible way is like I mentioned but expanded to include different games, for example all the different types of stats from the range of games could be in a TYPE (i.e some have INT some have IQ). Then make a TYPE for the gametypes (Warhammer,D&D etc) that only uses or references the stats it needs from the STATS TYPE. That is pretty much the way it would be done in a database in that you group all common data (i.e repeatable data) in a table of its own & point to what you need.
I have simplified it with my description above but hopefully you get the general idea.
The advantage of having it split & in TYPES keeps the data count lower by removing any duplication & also helps if you want to created a drop down list as only have to iterate through the required TYPE you want listed.
Again, if this is doable or not with GLB TYPES I'm not 100% sure but it would give you an extremely flexible & powerful system that is not tied to a particular game. It is pretty much the same as databases in that more thought & effort goes into the design, and if the design is solid & well laid out the implementation is made easier.
Lee
Quote from: CW on 2013-May-31
WOW! You got bit harder with War Craft than I did. I only spent 5 years on that. And most of that time I played but a single character, a Shadow Priest in the BattleGrounds.
I LOVED PvP. I still do. My serious distraction today is Team Fortress 2. For fantasy, I'm actually thinking of giving the computer a rest and getting back into board gaming. I am seriously eyeing the game Mage Knight, which, according to the reviews, is supposed to have one of the best solo-play systems around. If only the rules book weren't such a hot mess. That is the only thing putting me off.
-CW
I have not played WoW for just over a year due to a change in circumstances (i.e being un-employed) & just don't have the spare cash to play it.
With regards to chars I have a Death Knight (dual spec DPS/Tank), Priest (dual spec Heal & Shadow), Paladin (Dual spec DPS/Tank), Hunter, Warlock, Mage. All the previous are maxed out LVL85 (I have not got round to the latest Pandera expansion) as well as a Druid & Shaman which are in the mid lvl 50's I think :D.
PVP is awesome I have to admit =D
Lee
You have almost the full collection! I have an 80 ally shadow priest, a Horde 80 shadow priest, an 80 death-knight I never played after getting him leveled, a 70 Pally, and a lvl 12 fire mage I never really warmed to. Of them all, melting faces with my shadow priest was by far the best. The only drawback with my shadow priest was that he was way.. too squishy for the 3v3 arenas, so I missed out on the very top-tier goodies. Still, Themender could hold his own in a fight and I regularly finished near the top of the heap when we won in the Battlefields.
Which char. was your favorite to play? Did you get heavy into raids? I did for a short while, but I found that I didn't care for the sort of questing schedule you had to keep up in order to participate. Nope. I would much rather join my mates in The Tram Pirates guild to raid the Ally tram and try to hold it for as long as possible against all comers. We sometimes all dressed in pirate garb, complete with bird pets, took it over, and held it. Arr..!! Thar be some fun!!
I even found a glitch in the game which allowed us to sneek into the Ally city without going through either the front or the back gate. You had to levitate/climb up a certain mountain to reach an area where only the wire-frame of the game existed, then drop through a pond which caused you to fall through the game and into the Mage Tower inside the Ally city. (They have fixed that glitch now.) We almost got busted by a GM once, when one of our party got hung up in the rafters where the bug dropped us. Fortunately, the rest of us had logged, just before the GM showed up, and our buddy wouldn't tell the GM who it was that showed him how to use the exploit. Wheew! From then on we did it the hard way. -Storming the front gate, making a dash for the tram, and then summoning the rest of the party in. :good:
-CW
Hunter was def my favourite char to play, also def one of the hardest to master. Managing key bindings for traps, pets & also attacking with the character took a lot longer to master than my other chars. Only classes that made pvp harder against my Hunter was rogues & druids lol, the rest used to crumble easy enough.
Raiding was an on/off experience until a regular solid group could be found & even then not something that tickled my fancy so to speak.
One thing I can say is I was seriously a profession whore lol. Every profession maxed out, even getting the rare or quest recipes was a major thing for me & had to be done.
Lee
Sent from my HTC Wildfire using Tapatalk 2
So you didn't have a Druid? Yeah, I hated elite hunters and their pets. They suck for any sort of priest.
It appears we are going off topic again lol
Lee
Sent from my HTC Wildfire using Tapatalk 2
Ah yeah, but this is our thread so WTH. LOL
True ;).
Have a lvl 50 something druid, only started it up a week before I stopped playing due to my change in circumstances.
With regard to the main topic of the GM program I may have got a bit carried away with what exactly is required. Just because English is my native language doesn't mean I'm very good with it lol.
I have a better idea of what's required now (after reading it 50 times to make sure) so I will make a simple graphical mock up of what I think the goal is, that way you can confirm that I am on the same track as you. I always do a graphical mock up of anything that requires the presentation of a lot of data as it helps me see what's required.
I think I was getting mixed up with your requirements & a program I wrote a long time ago.
Lee
Sent from my HTC Wildfire using Tapatalk 2
That is a great idea. I have a set of working tabs, so with a little creative photo-shopping I can do a graphical mock-up too. (Not that I can actually achieve what I can dream in photo-shop. But it is a target to aim for.) And don't worry about throwing ideas out there. I'm find it stimulating and you are already causing me to improve on my vision. I look forward to seeing your ideas, sharing my own, and fusing the best of both worlds within the scope of what I can actually code. If you are interested enough to do some coding, maybe we can share that part too. No pressure though. No obligations. Consider it an invite.
But if you are interested, and once we hammer out a draft vision, I could focus on the tab and roster framework in the near term, get that into a stand-alone modular state, and then turn you loose with it to take it in whatever feature direction you choose while I focus on another feature. Programing by committee! What could go wrong? lol
Worst case, we wind up with two roster programs covering two visions and there would be nothing wrong with that. Anyway. Let me know what you are game for. I'm flexible. And weather you choose to be a suggestion person or a hands-on coder, this is a project I'm excited to do.
-CW
"Of COURSE the laundry is clean. The cat is sleeping on it, isn't she?"
Seems you now have a partner in crime lol.
Am pretty sure that between us we can hammer out a good & viable result. Anything that is beyond either of us or problems that we have trouble resolving one of the many skilled coders in the forum will surely point out the errors of our ways :).
Oddly enough I tend to write more of tool/app style programs than games. No idea why but I think it changed during the 16/32bit era when computers allowed a more diverse spectrum of what could be created/programmed.
Not saying that old micros where game only or that game writing now is a bad thing, but my direction & focus changed.
Lee
Sent from my HTC Wildfire using Tapatalk 2
Sounds good. =D
I'll begin work on my graphic mockup tomorrow. (DDgui can wait for Monday to be explored.)
Cheers!
-CW
I will make a start after I get home & have some sleep lol. I have a few ideas with regards to the mockup.
Lee
Edit: I will Target my initial mockup to be 800x600 & see how I get on. Main reasons are a lot of devices can handle that res (think tablets/netbooks) & I find it is always easier to move up resolution if it works out to small than it is to work the other way round & try to decrease it.
Sent from my HTC Wildfire using Tapatalk 2
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.
Just a quickie, is there a reason you split the screen into 2 parts. Only asking as am about to start my mockup & wondered if there was something I missed lol.
Lee
Edit: With regards to European screens, PC's etc have always been the same worldwide only TV's are different with broadcast signals & consoles (non HD of course as thats a set standard).
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!
Makes perfect sense to me =D
Perhaps I shouldn't have read your last post so soon after waking up lol. BTW I have to mention that I live in my own time-zone that is separate from everyone elses. I may be up & awake for anything from 12hrs to 72hrs thanks to a wonderful sleeping disorder & when I am on one of the long awake stints obviously concentration sometimes is difficult so please bear with me.
You are 100% correct in that ease of use for the GM is the main priority & is something that I'm trying to incorporate into the UI mockup, it may cause some extra programming to implement but nothing that cannot be solved. One of my initial ideas def won't work with a 2 frame layout but other ideas are trickling in =D.
Lee
Very rough quick draft to see if I am going along the right lines lol. Obviously got to do the character details page but had a day of interruptions but will be on it =D
Lee
p.s time for a food break :D
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.
My dinner has nearly done cooking so after consumption I will be right back on it =D
As it stands I can fit 16 units per half screen without things getting cluttered or 2 small to see or select, and was toying with the idea of dropping the last line (so 14 total) to allow buttons, for example a "Players" button & a "Vehicles" as more often than not the vehicles belong or are used by that party.
With regards to the life bars I have 3 ideas which I will implement all 3 on the next edit (1 example on each of the 3 chars I have shown). First is like it is at the moment, Second is a coloured bar behind the health text similar to how a progress bar looks & the colouring would be say green for 75%-100%, yellow 40%-74% & red 0%-39%. The third would be like the second but the colour would change the icon, not sure if the icon itself or the icons background until I try both to see what they look like.
The tabs have not been fine tuned as yet to check for possible hidden text but it is on my to-do list =D
Adding a coloured frame is no problem to do either.
The way it is laid out is that everything falls on a 16 pixel boundary & are multiples of 16. That makes the math & layout a lot easier to manage and/or update.
Once I implement the changes we will have something more solid to work on & figure out what works & what doesn't.
If you could give me more info on what you would like displayed on the details screen that would be appreciated & I will see what I can come up with.
Keep the suggestions & even criticism coming (don't worry I don't bite :D).
Lee
EDIT: Just a thought, To me to much eye-candy in a program like this is a very bad idea as it distracts from the functionality if the person can't see the whole picture at a glance. Not saying we are going down that route but thought I should mention it just in case either of us starts down that route & gets tempted by the "Dark Side" :D
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. :good:
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!
Had a little set back with my desktop PC in that the gfx card fan is on the way out & when it overheats the pc resets & have to wait for it to cool down lol.
At the moment am bringing my laptop up to spec with regards to software & updates so normal service shall be resumed shortly, basically something I should have done ages ago but never really got round to it. I will order another fan for my desktop or a new gfx card depending on what works out financially better for me but it's not a major rush as my laptop is pretty much a similar spec to the desktop.
Lee
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
Updates are still on the go & then a massive defrag lol.
I downloaded your attachment & still get zip errors with 7zip but all extracts fine. One thing though is it doesn't compile under v11 beta but no problems with v10, but that's not a problem & can be sorted later.
Going to have a quick sort out of the code as there are variables assigned as floats when they should be integers & do a general tidy up. I'm not saying there is anything bad in your code as everyone has their own coding style & after a quick sort out it will allow me to follow it better.
It's mainly little things like indentation & such, something I don't pay to much attention to myself until I have a bulk of code or functions etc that are complete lol.
Lee
Sent from my HTC Wildfire using Tapatalk 2
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
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. = )
(http://www.glbasic.com/forum/index.php?action=dlattach;topic=9240.0;attach=6025;image)(http://www.gettysburgsoldiers.com/images/splash_forum.gif) (http://www.glbasic.com/forum/index.php?action=dlattach;topic=9240.0;attach=6027;image)(http://thumbs1.ebaystatic.com/d/l225/m/m9gcdUqAr0KQZd4paaMTpUQ.jpg)
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?
Very nice CW :).
Your mockups give me a better idea of the info that needs to be displayed so that gives me more to work on & I will probably use the info you have presented on yours on mine so we have a common output so to speak.
I have to admit the coloured tabs do not work for me, can't quite put my finger on it but the text is hard to read the way they are, might be an idea to use a font with a black outline so as to separate the text from the tab background colour. Also that text is not kerned which might also be a problem visibility wise.
Other than that it's coming on very well :)
Last update (he says hopefully lol) is downloading as I type this, 1.5gb of Adobe updates seemed to take for ever & no idea if it was my internet or the Adobe servers, I blame the Adobe servers as all other updates downloaded at a quick pace (even microsoft ones but they took longer to install lol). I then have the joys of a good defrag as know from experience all that installing/downloading/updating does no favours, although I will run just a quick defrag & save the fully optimised one to run when I go to bed.
Lee
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. 8)
Talk to you later!
-CW
Sort of, kerning basically just the spacing in-between chars, more noticeable on an 'i" being the thinnest character ("W" being the widest character normally.
Lee
Latest draft attached, still needs a fair bit of tweaking though.
Lee
It looks really good! =D
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
The icons are a download from opengameart.org, got a set of about 1000 rpg icons (although where some of them would fit in an RPG I have no idea lol), the rest is all done by me in Fireworks.
Tell me what you want on the character roster (or draw a rough) & I will see what might need adding, also will style it the same as what I have done so far obviously to keep consistency :)
Lee
Edit: An RPG one should be the same (minus the ID part) I think as the GM only has to call up the details of the character in an event like combat & such. The left hand side could be for players & the right for NPC's, say 1st tab for the players, 2nd tab for vehicles, 3rd Buildings etc.
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
Data would probably be stored in an array of types, so should hopefully be a simple case of dumping the array to a file. It's a little bit more involved than that but will spare you the details until we get closer to that phase.
With regards to character sheets practically every one of them can be downloaded, either from the game creators site or a fan site. Obviously they are free (only the rule books etc have a fee), gone are the days of disgusting photocopies & hand drawn ones lol.
Storing stats is going to be interesting as different game systems use different stats, plus it would be impossible for us to cover every game so a level of user customization will have to be implemented & I have an idea of how that can work.
Lee
Sent from my HTC Wildfire using Tapatalk 2
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 <3 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?
This conversation is really nice! :good:
I don´t have much to add really, for lack of experience, but my 2nd next project will be a little roguelike just to get the hangs, very simple one.
Keep it up! Let´s see the outcomes! :)
EdIT: this all have been very instructive to me :)
Edit2: without intruding so much on a topic I don´t know much, sometime ago glb guys posted this:
http://donjon.bin.sh/
There could be stuff there useful to you guys or maybe not, but it is on the subject I guess.
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.. :whistle:
-CW
Sorry, have been a bit sidetracked with other projects & getting Linux on my laptop to see my file server :rant:
Don't forget that this is a GM program & not a player program. Players will have their own sheets with all the stats/equipment etc written down, 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. The main details a GM keeps in any sort of detail would be NPC's & even then it is rarely as detailed as a player character otherwise the GM would be severely bogged down in paperwork & such & the game would crawl along.
The GM's role is (put very simply) referee & story teller, they have enough on their plate doing that & referring to the rulebook for combat/equipment etc without having to know the players full stats & specs :D.
Like I said a customisable sheet where the GM picks what stats, class, equipment etc they want to keep note of (& if the player is still alive lol) is more than good enough I think. Something along the lines of my 1st mockup with a big icon with any notes appearing if they click on it might be more than sufficient.
BTW the ghosted look would be done with a simple DRAWRECT with the alpha changed so as to darken the output, makes seeing the overlay details easier as brings it into focus & dumbing down the details below it. The tabs on top I think may change to being all white with only the current active tab coloured, I done all of them coloured in the mock up mainly just to show the range of colours than anything else. The health bar "Inner Shadows" should be straight forward & done with lines & alpha otherwise a serious amount of sprites would be needed :D
An array of types should be more than good enough if the types are planned properly to store the info & allow flexibility in what is stored. As you have discovered there is a huge range available from different games & one of the reasons why there are quite a few programs for a particular game but very few (if any) generic ones due to the differences in data. Any one can write one for a specific game as the data is a known quantity, but most shy away from a generic one as they are unsure about how to implement it. If you can make the data storage flexible then a generic one is not that much more difficult than a specific one, basically it goes back to what I said about databases & planning of which I'm pretty confident I can emulate that with types.
@Erico: Glad you like it & if you learn something from it then alls good =D
Lee
QuoteDon'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
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
Yep that seems to work well =D.
I will have a look at different "Unselected" tab options, i.e plain white, coloured text & your suggestion & you can pick what you think looks best.
Am doing some stuff in linux at the moment so no access to Fireworks, the thought of installing a VM & the Adobe software (with all those lovely updates :puke:) sends shivers down my spine lol.
Lee
Sounds like a plan!
No hurry on your various projects. I'm going to take another crack at my user input routines. That should keep me busy for a while.
Cheers!
-CW
Still working on my set-field K=Key() input routine with cursor, which has turned into a project in its own right. This is giving me some trouble. The problem seems to be that I was thinking too small, so I'm going to scrap it and take a fresh run at it. I will post when I have something to show or have given up on the effort. Another week should tell. -CW