Plan for Ted Southard
by Ted Southard · 12/17/2004 (7:45 pm) · 5 comments
The GUI's are coming along nicely, even though they insist on putting up strategically placed fights here and there ;) Fought a bug yesterday and today that cost me a good 10-12 hours in all, but basically came down to some changes I made a good long time ago to make the GuiHealthBitmapCtrl draw horizontally instead of vertically. The upside of that is that I now know that control very well, and in addition to changing it so that it can be hooked up to any generic value (instead of pulling the player's health), I'll be trying to fix it for stretched drawing as well, after which I'll post it as a sequel to the original resource.
Here's what it looks like in action as part of my skill GUI, where you can increase your skills and whatnot:
That GUI still has a couple of hours of scripting behind it before it can do everything it needs to for gameplay purposes. I'm learning that the functionality behind it is a bit tricky in order to fake the scrolling and "page flipping", as well as get and set all the skill values and do validation on the server, etc. But when it's done, it's a big part of the GUI puzzle done, and it will be done this week. <- That's me holding myself to the promise, hehe...
Another piece of the GUI that's almost "there" is the main Inventory panel here:
Here, I also do the "fake paging" thing, to get around scrolling for both myself and the player ;) Information is shown on the right-hand side (might be a bit hard to see in the jpg here), and the drag and drop icons are on the left. This brought up the interesting problem of left and right clicks on the icons, and I think I'm going to redo the rest of the GUI's to execute actions on right-clicks instead of left-clicks, to better facilitate "examining" items without accidentally using them.
As a matter of fact, it was around yesterday when I realized just how much of a persistent world's functionality is contained in the UI itself, because of the player's interaction with the world and the functions to support that through the UI. After the Skill GUI is done (probably Sunday), the Equip and Tradeskill GUI's are next, as well as the database functions that they entail. What this means is that by mid-January, I should be in a position to have 80% of my UI done, and I should be able to concentrate more on the core gameplay rules behind it. That means more time for content, and an open Alpha for load testing!
Of course, there still won't be much to do in the game, since the task generator has been neglected so I could get the UI done, and content is still very hard to come by with my animation famine still going strong. If there's any animators out there willing to put some time in, email me at Ted@DigitalFlux.com I do have a coder now, so hopefully I'll have something to work with as far as the character customization code soon :)
But, for those who want to log on and "play" when that open Alpha goes, you get to try and crash my game server in addition to whatever quest generator I have up and running- wait, crashing the server can be a quest! ;) Here's the target's specs:
DSL 1.5/256k
Athlon64 3400+
1 Gig PC3200 Ram
(2) 80GB SATA in RAID 0
The drill is to find out:
1) How many players can fit in a zone before the server pukes.
2) How many players/zones can fit on the server before it burns my house down.
3) At what point does the DSL line shrivel up like a Cheese Doodle(tm).
Those numbers will help me gauge network traffic and what kind of servers I need to support the game. Off the top of my head, if I can get to 50-100 players sustained without the DSL line snapping like the underwire in Anna Nicole Smith's bra, then I'm in good shape. On the other hand, even if it does, I have some tricks up my sleeve that I'm looking to use to trim down the network bandwidth for the game(thanks to Alex Swanson telling me about the RTS pack's "lighter" Player class).
And I'll need it, because this game will be pretty heavy on the bandwidth even after the optimizing, given the amount of data that will potentially be slung back and forth. And that means that in early January, this Access database I've been using for testing has to migrate to MySQL. Access already complains if TGE talks to fast for it on simpler things, much less rapid-fire requests for dozens of players, but I never expected it to hold up to that, just to be easy to set up while I get the GUI and main queries in place. Exporting to MySQL shouldn't be that much of a headache, though I'll miss working with the tables visually ;)
Here's what it looks like in action as part of my skill GUI, where you can increase your skills and whatnot:
That GUI still has a couple of hours of scripting behind it before it can do everything it needs to for gameplay purposes. I'm learning that the functionality behind it is a bit tricky in order to fake the scrolling and "page flipping", as well as get and set all the skill values and do validation on the server, etc. But when it's done, it's a big part of the GUI puzzle done, and it will be done this week. <- That's me holding myself to the promise, hehe...
Another piece of the GUI that's almost "there" is the main Inventory panel here:
Here, I also do the "fake paging" thing, to get around scrolling for both myself and the player ;) Information is shown on the right-hand side (might be a bit hard to see in the jpg here), and the drag and drop icons are on the left. This brought up the interesting problem of left and right clicks on the icons, and I think I'm going to redo the rest of the GUI's to execute actions on right-clicks instead of left-clicks, to better facilitate "examining" items without accidentally using them.
As a matter of fact, it was around yesterday when I realized just how much of a persistent world's functionality is contained in the UI itself, because of the player's interaction with the world and the functions to support that through the UI. After the Skill GUI is done (probably Sunday), the Equip and Tradeskill GUI's are next, as well as the database functions that they entail. What this means is that by mid-January, I should be in a position to have 80% of my UI done, and I should be able to concentrate more on the core gameplay rules behind it. That means more time for content, and an open Alpha for load testing!
Of course, there still won't be much to do in the game, since the task generator has been neglected so I could get the UI done, and content is still very hard to come by with my animation famine still going strong. If there's any animators out there willing to put some time in, email me at Ted@DigitalFlux.com I do have a coder now, so hopefully I'll have something to work with as far as the character customization code soon :)
But, for those who want to log on and "play" when that open Alpha goes, you get to try and crash my game server in addition to whatever quest generator I have up and running- wait, crashing the server can be a quest! ;) Here's the target's specs:
DSL 1.5/256k
Athlon64 3400+
1 Gig PC3200 Ram
(2) 80GB SATA in RAID 0
The drill is to find out:
1) How many players can fit in a zone before the server pukes.
2) How many players/zones can fit on the server before it burns my house down.
3) At what point does the DSL line shrivel up like a Cheese Doodle(tm).
Those numbers will help me gauge network traffic and what kind of servers I need to support the game. Off the top of my head, if I can get to 50-100 players sustained without the DSL line snapping like the underwire in Anna Nicole Smith's bra, then I'm in good shape. On the other hand, even if it does, I have some tricks up my sleeve that I'm looking to use to trim down the network bandwidth for the game(thanks to Alex Swanson telling me about the RTS pack's "lighter" Player class).
And I'll need it, because this game will be pretty heavy on the bandwidth even after the optimizing, given the amount of data that will potentially be slung back and forth. And that means that in early January, this Access database I've been using for testing has to migrate to MySQL. Access already complains if TGE talks to fast for it on simpler things, much less rapid-fire requests for dozens of players, but I never expected it to hold up to that, just to be easy to set up while I get the GUI and main queries in place. Exporting to MySQL shouldn't be that much of a headache, though I'll miss working with the tables visually ;)
About the author
Started with indie games over a decade ago, and now creates tools and tech for games. Currently working as a contractor for startups and game studios.
#2
12/18/2004 (12:09 am)
Good plan, nice pic's, keep up the good work.
#3
Question on a completly different topic:
Reading your last plan (IIRC), you seemed pretty disapointed with the plans for tS7, are you dropping plug-in dev completly or what ??
12/18/2004 (1:56 pm)
Wow Ted, that is looking great... Your stuff is coming along nicely I must say !!Question on a completly different topic:
Reading your last plan (IIRC), you seemed pretty disapointed with the plans for tS7, are you dropping plug-in dev completly or what ??
#4
@Jorgen: That's up to Caligari. I've told them of the issues that are involved in this in person, and they are aware of it. Whether they move to fix the situation or not is a ball that is in their court, but all I can say is this...
If Caligari does not provide either an SDK to create compiled plugins with, nor a way to "lock" or compile scripts made with it's new Rosetta architecture, then DigitalFlux Entertainment, LLC, will not be able to provide more than limited troubleshooting for it's plugins. What that means is, that I will do what I can to help fix or workaround a problem, but if it requires something that is not available in an SDK and is only available in scripting which cannot be secured, then I can't offer that level of support, nor release anything new which I don't want to be ripped up and shared between unscrupulous members of the tS/gS community(and while 99% won't, 1% will, and that's enough).
That said, I actually dropped plugin development back in early 2003, and mapExporter was released only because I had made it for myself and thought it was better served being sold for a small price. But if things change, then the above paragraph has a good chance of changing along with it. So right now, I'm just waiting for them to do what they're going to do, so I can decide to do what I'm going to do. Either way, there's still a free mapExporter upgrade going out the door come hell or high water, because I want it to support all the .map entities available, just because I said I would.
12/18/2004 (4:40 pm)
@All: Thanks!@Jorgen: That's up to Caligari. I've told them of the issues that are involved in this in person, and they are aware of it. Whether they move to fix the situation or not is a ball that is in their court, but all I can say is this...
If Caligari does not provide either an SDK to create compiled plugins with, nor a way to "lock" or compile scripts made with it's new Rosetta architecture, then DigitalFlux Entertainment, LLC, will not be able to provide more than limited troubleshooting for it's plugins. What that means is, that I will do what I can to help fix or workaround a problem, but if it requires something that is not available in an SDK and is only available in scripting which cannot be secured, then I can't offer that level of support, nor release anything new which I don't want to be ripped up and shared between unscrupulous members of the tS/gS community(and while 99% won't, 1% will, and that's enough).
That said, I actually dropped plugin development back in early 2003, and mapExporter was released only because I had made it for myself and thought it was better served being sold for a small price. But if things change, then the above paragraph has a good chance of changing along with it. So right now, I'm just waiting for them to do what they're going to do, so I can decide to do what I'm going to do. Either way, there's still a free mapExporter upgrade going out the door come hell or high water, because I want it to support all the .map entities available, just because I said I would.
#5
I can see that such an policy will limit the amount of good plug-ins for future caligari software.
I have bought your map exporter and is using it for some things, it is really good.
Can't wait for the update.
Best of luck to you on your other projects :)
12/19/2004 (11:19 am)
Ted, I'm sad to hear that Caligari hasn't choosen a better approach in their upcoming tech for 3rd party support.I can see that such an policy will limit the amount of good plug-ins for future caligari software.
I have bought your map exporter and is using it for some things, it is really good.
Can't wait for the update.
Best of luck to you on your other projects :)
Torque 3D Owner Adam
Adam deGrandis