Interesting article on UI:
http://www.burningsea.com/pages/page.php?pageKey=news/article&article_id=10122
I'm not going to quote it as it's not directly relevant but there's some interesting info in there about SWGesk macros.
Ship to ship combat damage, Just read and dance for joy!:
http://www.burningsea.com/pages/page.php?pageKey=news/article&article_id=10127
Macros Part 1 (The pics aren't actually viewable in the original page so I can link to them here):
Quote:
Macros, Part 1
01.19.04 by Robespierre
Part 1 – the Pirates Of The Burning Sea internal macro system
First thing to know is, you do NOT need to know how to write macros to play PoBS. We are designing a wonderful user interface which you can use as-is, or customize by dragging windows around, resizing them, dragging buttons onto the toolbar, etc. If you love the idea of macros, dive right in. If you fear it, no pressure, just read on at your own pace. It is all optional knowledge!
Here is a one-paragraph summary of our internal macro system: You can use nearly any command in the command set. You can assign finished macros to toolbar buttons using the icon of your choice. You can use macros you write in much the same way as the built-in commands.
Really, if you have played SWG and used their macros, you have a decent idea of what ours will be like.
DISCLAIMER 1: The macro examples I am about to give are not guaranteed to work in the final (or even beta) version, because we may change command names, break commands into smaller bits, combine them, change the names of weapon batteries, change the names of shot types, etc. But I wanted to give you some concrete examples, so all of these are things you can do … well, ok, WE can do in the alpha today. DISCLAIMER 2: The art you are about to see is programmer art – no artist has yet touched it, and it is not at all final. I had to get special permission to leak a few UI bits to make my devlog clearer. No image ever dies once it hits the internet, but if you like us at all, don’t put these images on your site. Just link to them. Please!
OK, on to the good stuff.
What can a macro do? Well, it can do just about anything a player can do using a command, which turns out to be almost anything the player can do at all, especially at sea. Almost all the buttons in the game’s interface execute some kind of command behind the scenes. So, for example, the button to open and close the Inventory executes the command “/toggleWindow inventory”. Clicking on a specific gun battery is the same as “/selectbattery [name]”. Picking roundshot as the ammo type does “/setShotType roundshot”. All of this is done via pretty buttons (image 1), so if you don’t want to remember commands, you don’t have to! But when you want to write a macro, then the commands come in very handy.
The toolbar buttons also give you a handy way to learn the commands, since hovering the mouse over them brings up the associated command text.
Let’s say you want to create a macro to get away as fast as possible if things start to go wrong during a fight. You want get the sails up fast, and load the stern chasers with something properly discouraging. For me, Plan B is what I call the thing I do when things go wrong, so I would suggest making a macro called “PlanB” (note that a macro name cannot contain spaces).
/setSails Full
/setCrewPriority Sails Urgent
/selectBattery aft
/setAmmoType chainShot
/report Plan B is in effect!
The last line simply echoes the text to the command line. It is a handy way to give yourself a little confirmation that you pressed the right button. If you wanted to have it broadcast over the local-area chat channel, use “/say” instead. It all depends on whether you’re the kind of captain who likes to give warning to your buddies, or get a head start on the general retreat. For a compromise, try this added to the macro above.
/pause 10
/say I’m outta here!
Now you have given yourself 10 seconds of head start before you tell the world about your departure, and maybe saved more seconds just by having a macro instead of doing the four actions manually.
After writing a macro like this, and assigning it any of the available icons (I used the big “2” icon because the selection is kinda limited in our alpha code), you can now drag it to the toolbar to use like a regular command button. Or, you can type “/macro PlanB” in any chat window. In effect you have created your own custom command.
Here are a few dry facts … again specific numbers are subject to change before release:
Macro names are limit to 64 alphanumeric characters, no spaces or punctuation.
You may have 10 macro chains executing simultaneously.
A macro can call another macro via the toolbar (SWG-style) or directly using “/macro [name]”.
Macros are stored on the client machine in a single file. You can copy that entire file to a second machine if you upgrade your hardware or play in two different locations.
Macro total size limit is not yet defined, but will be over 1k characters.
So far the only prohibited command is /logout.
Coming soon: Part 2. Um, I guess that was kind of implied by the title of this one, eh?
EDIT:
Macros Part 2, Less useful but is informative:
Quote:
Macros Part 2
01.26.04 by Robespierre
Part 1 covered the core of the macro discussion, which is the now-implemented R1 (first release of the game) macro system for PoBS. Let’s continue with some related issues: external tools, and the future of our macro system.
External Macros, Bots, Hacks, Etc.
What about external macros? By this I mean any of the various tools that have been developed to automate, enhance, and yes even exploit the various current online games. Most of these are prohibited by the various EULAs (end-user license agreements) and yet continue to be popular with some players, reviled by others.
We have not yet come up with our EULA language for this, so I can’t write the final binding word on these tools. But I will devote a few paragraphs to the concept because the topic seems to naturally spring to mind when the word “macro” is used in conjunction with an MMORPG.
Once again, keep in mind that this is a general discussion, and our final EULA may have specific things to say about using external macro tools.
The short answer is we don’t think external tools will provide an excessive advantage because:
1)The rich internal macro language will reduce the incentive to use external macros.
2)Repetitive treadmill macros will be less needed and less useful.
3)All crucial calculations (hitting, damage, prices, sightings) are done on the server, so external tools will have no chance to improve results.
4)Because PoBS is a game of tactics and not reflexes, traditional client-side “bots” provide less advantage.
Point 1: The rich internal macro language will reduce the incentive to use external macros. Rather than be a cause for fear among the less technical players, the macro system outlined in Part 1 of this devlog should be a cause for joy. You can now access simple improvements by entering text from other players or from forums, or even dabble yourself. No need for complex languages, external tools, or EULA violations. External tools can still do more things, as outlined below, but a lot of basic tactics can be enhanced by a few macros instead of installing a 3rd-party, potentially-forbidden tool.
Point 2: Repetitive treadmill macros will be less needed and less useful. Many games have a long level treadmill, and such games do very well as commercial MMOs. I think there are basic human reactions to incremental improvement that these games draw upon. But that’s another devlog. In such games, many folks find ways to speed up the process, often using external tools. They also find ways to gather resources, perhaps taking advantage of some easy prey which they can kill without risk. Sure, it gains them only a little xp per kill, but what does that matter if you can run the macro all day? Some games – many games in fact – forbid the use of external tools for these activities. It undermines their perceived player retention, reduces a sense of fairness, and in some cases overloads their servers with AFK macro’ers.
We’re different. (Yeah, yeah, we’re all different) No, really, we are different in this specific way: compared to most MMORPGs, PoBS increases the importance of tactical decisions, and has less sheer grind involved in improving your character’s abilities. We do have some time-based aspects to the game. We’re trying very hard not to make those into a huge grind, because we do not intend to use a treadmill as a primary source of “content.” Our combat also has a LOT more human involvement—in theory PVP can happen at any time. Macros that can handle PVE combat will not be able to handle PVP. Our internal macros in PoBS, as discussed in Part 1 of this devlog, are tools to help you. Those macros can’t replace you, the player.
There are things you can’t do with our macros. There is no “branching” where a macro can make a decision based on things in the environment, like “if I missed my last broadside entirely, close range with the opponent.” It is possible that the very best macro writers can use the output of our logs to write clever, AI-like macros. I never underestimate the abilities of humans to innovate!
But I don’t think those macros will be as important, due to (a) a reduced need to grind and (b) a lot fewer places where you can PVE for hours at a time in total security. So, though I cannot make a definitive statement about the EULA yet, I do predict that people will find external macro tools a lot less useful for PoBS than for other games.
Point 3: All crucial calculations (hitting, damage, prices, sightings) are done on the server, so external tools will have no chance to improve results.
The client computer is a hostage to the player, and however normal the data from the client software sounds, we know it may be coerced. So, the server checks every command from the client. The server knows how fast you are going, and where you really are. All the client does is project those things in a nice smooth line (which works amazingly well so far). Ships over the horizon are not even known to your client computer. We are not claiming the game is hack-proof. What we do claim is that we’re working to ensure so that there is nothing on the client that will give you added advantages or extra information. This reduces the data that can be exposed via some third-party tool. If the client computer doesn’t know about it, a tool on that computer can’t expose it to the player.
Point 4: Because PoBS combat is primarily about tactics and not reflexes, traditional client-side “bots” provide less advantage.
A common external tool used in many tactical games is the “bot” of various flavors, etc. Unlike xp-grinding macros, these bots are intended to improve the combat effectiveness of the player by cybernetic intervention, using the local client computer to aim / jump / react in place of the player’s own coordination and reflexes. In PoBS, you are not aiming each cannon yourself, You decide when to fire, and what part of the opponent’s ship to aim for, and what ammunition to load … but your hand-eye coordination doesn’t decide if each round hits. The server does, taking into account all pertinent factors.
Some games depend on player speed to limit the frequency of certain actions. For example, in Unreal Tournament you can only fire certain weapons once every two seconds. But, you can fire a rocket, switch to a second weapon, fire it for two seconds, then switch back to the rocket launcher which has re-loaded for you. Of course, the best players have a macro for that, and don’t sit around waiting for a precious 2 seconds while they reload. We’re trying to make sure nothing works like that in PoBS. If you tell your crew to load guns AND change sails, you better have a lot of crew or both things will be done slower. Plus, tasks in sailing combat take longer than 2 seconds, so the advantage to a macro-writing player is “clarity of thought and command” more than simple reflexes.
In summary, for all those reasons, we’re not too worried about bots, speed hacks, map hacks, etc We think internal macros will improve the player experience, not turn into the focus of the game or a way for a subset of players to gain unbeatable abilities. And, last but not least, we have not yet written out the EULA which defines how we treat external tools.
The Future Of PoBS Macros
There are a few directions macros may take after R1. None of this is set in stone, and we may never do any of it, but it makes for interesting discussion. I’ll present these in order of likelihood, most probable first.
Small improvements like allowing comments in macros, providing a debug output window (so you can at least spot those typos when the window shows “command not found”), allowing simple parameters to macros (probably very DOS-batch-file like), etc.
An ability to detect simple things about the existing environment, with concepts like “current target” and “ships in my current group” being things you can access and use in a macro. This will further diminish the attraction of external macro tools that are log-driven, but before we do this we would consider the impact on gameplay for those folks who are not into macro-writing.
And finally, the ultimate macro interface: full access to the Lua language for complete client/UI customization.
Our client is written in Lua, with some support routines in C++, and of course the graphic engine is in C++, and shaders are written in a special language. Lua is an interpreted language, and Lua controls all the top-level UI bits: the display of the compass, the look of the buttons, the way the chat is displayed to the player.
The obstacles to exposing the Lua client are not so much traditional security worries, but rather making something that is robust enough that it can survive a user mod. I would expect that very few players would attempt a mod at this level. Our client is a very complex dashboard. We could expose the client entirely and not compromise security, BUT a modified client could become a huge source of customer support issues, and there are some legal issues to consider. Last, of course, we don’t want this to become a programmer’s war. We would need to consider any possible impact on the game before we give players the ability to full customize the game via Lua.
For all those reasons, this may be a long time coming, if ever. But hey, I told you, this was a glimpse of a possible future.
This ends my two-part devlog on Macros. Thanks for sticking with it to the end! I’m gonna go write some code now. I’m looking forward to your comments in the forums.