Hedgerow Hall

by Hedgemistress
Hedgerow Hall
Serious role-playing-oriented game world, with animals.
ID:1813402
 
I am probably one of the few people who think the built-in stat panels can be pretty neat. Sure, there are a lot of games they just don't fit with and they're easy to use poorly, but for a game with the right flavor of low tech retro and/or that's basically a GMUSH/GMUD to begin with, they'd be fine. They're pretty seamlessly integrated into the system for things like mouse interactions, they don't require you to learn CSS, they're the most flexible container that can properly display atoms and text, et cetera.

I keep hearing people say "If you want to be taken seriously outside BYOND...", but the outside world's not going to go, "Ugh, a statpanel. What is this, another Zeta Rip?" That kind of reaction is a BYOND specific thing. People who've looked at BYOND and dismissed it will continue to dismiss it, and so having a tip-off in your screenshots that it's a BYOND game will make them dismiss it faster, and a certain portion of the outside world is going to reject any game that is too lo-fi, but they're not necessarily your market. The outside world is going to notice if your interface doesn't mesh with the presentation of your game, which is the real danger with relying on statpanels.

None of this is to say that I ever definitely decided to use them for HrH, only that the possibility was always there. Following the principle of "Glitz Is Not Gameplay", I have been using them as I develop HRH because they require the least work, but I have been careful not to refer to them in the code outside of the actual stat() proc itself so I wouldn't have to redo anything if I ever changed my mind or decided to do something slicker. For instance, the inventory handling mouse procs didn't check the location of the mouse events, they checked the item's loc var and whether the item was flagged as equipped.

I've been pretty pleased with the results of the statpanel use, particularly with tabs being dynamically added and closed as needed to avoid clutter, so for a while I was leaning towards keeping them. However, the one thing that's undeniable about them is that they're inefficient. My vision for Hedgerow Hall involves servers with large enough player bases for the social gameplay to take off. I tried to keep the processing overhead low, but updating all those panels every tick is a lot of traffic.

So this morning I've been working on replacing the statpanels. I have a feeling that the unfans of statpanels aren't going to find my replacement any more elegant, as they're a set of tabs that use grids to replicate what I was doing with the stat panels, just only updated as needed. There is some further room for optimization in some of them (the inventory grid refreshes itself completely for any change), but it's got to be a big step up, performance-wise.

I'm sure I'll get some comments about the aesthetics of it all when I show it, but... Glitz Is Not Gameplay. I can bash out the game without spending money or otherwise committing outside resources, but I can only do so much to make it look better on my own. It won't be worth it to shell out for a glitzier presentation if there's not an actual game to present. The interface work I've been doing today is a performance improvement, no more and no less.

Spending a morning on this does set me back in my timetable for where I thought I would be at the end of the week, but not by much.
Because I'm still keeping with the idea that the backend should work regardless of how the front end is arrayed, I could still move to a different solution in the future without much recoding. The game still doesn't care that the items are being interacted with in a grid rather than a statpanel, just as it wouldn't care if they were on a secondary map.

I tried to keep the processing overhead low, but updating all those panels every tick is a lot of traffic.

...I can't believe I'm telling you this...

if(statpanel("herpderp"))
//update the herpderp statpanel


statpanel() will return 1 if that statpanel is currently active, therefore allowing you to simply not process any unnecessary updates to a statpanel in Stat() by simply packing it into an if. Remember that DM just straight skips any code it can't reach inside of a logic branch.

Also: BOOOOOOOOOOOOOOOOOOO STATPANELS!

There's a reason that modern games don't use GDI presentation methods for their information, and those that do are from the mid-90s.
Oh, I meant "all those statpanels" with "all" being equal to the number of players online... I was already conditionally nesting panels like that a decade ago. :P It's just the sheer amount of info that had to be unpacked in some of the panels, and even with almost all of it socked away in pre-formatted lists, I figure it would still add up on a busy server.

I'm well aware of where the current standards are, but as with all things, there's something of a cyclical cargo cult mentality behind it as the interaction between what players are perceived to want results in more limited offerings which results in a narrower idea of what players want which results in more limited offerings...

I have no doubt that there's more appeal to doing it your way, but treating appeal as a one-dimensional quantity is why our cable channels are all one year away from showing the same reality show about people who try to finance new homes by making cupcakes out of the contents of storage sheds defaulted on by people used extreme couponing to prep their doomsday stockpiles. They're all competing for the biggest slice of the same audience.

Me? I'm not in competition with anyone. I'm making the game I want to play and it will be marketed to the people who want to play it.
Nothing is wrong with the stat panel's appearance. What's wrong with it is people with no taste and design-sense use it as a means to an end. Thus, creating the false-sense that it is utter trash to use.

I use tabs for a chat system in a current project. World. Game. Team. In the bottom right is a button to toggle chat channels between the three. To the left of it is the input box. And above the input box is the output box that is switched by switching tabs.

I can display things like stats on screen easily and clicking verbs in a thing of the past. Use macros for christs sake. And something never seen on byond... (bln has done it actually) allow macro customization with a user-friendly way involved. Not the edit skin way, dufus'.

Overall, if you don't use Statpanels for something that can easily be done through screen objects, giving a better visual appeal, you are being lazy with yout design. Something I should also point out is that I hide my output when they are not in a game and not able to chat. And may even give them the option to hide it in game too.
I largely agree. The problem isn't that stat panels are bad; the problem is using them--or dismissing them--without considering whether and how they suit the needs of the project.

Though I'd say the same thing about clicking verbs "being a thing of the past". If it suits a game, it suits a game. If macros work better for a game, macros work better for a game. If you're only thinking of games in terms of things where single key input is the optimum control strategy, you're using a more narrow definition of game than is strictly necessary.

The reason stat panels and clickable verbs are used irrespective of the needs of projects on BYOND is because they're easy, the system does it for you. That's why I've been using statpanels during the early design process of Hedgerow Hall (while making sure nothing in the code references them outside the stat proc, so I won't break anything as I move away from them).

And as much as I see people saying "BYOND needs to attract more AAAAAAAA+ developers so we can make a $100 billion game!", I feel like the community has lost a lot of vivacity because of how much people despise games that use the system's built-in framework for these things. No, we're not going to get the next runaway success coming up that way, but we might well get the next generation of developers, including the person who might produce that.

As things stand, the only "easy way" in is by using terrible seventeenth hand ripped code bases. Part of that is how seductive it is to have a "finished game" that you can just edit a bit and slap your name on it, part of it is the built-in fanbase those games have... but I feel like part of it is that the newbie friendliest parts of building-from-scratch are reviled by the most visible and vocal parts of the community.

And don't get me wrong, I am as impressed as heck at how people have managed to take what was originally a tile-based GMUD engine and used it to produce the things that they have. But man, when someone comes along and makes what is basically a GMUD... they're not using it wrong, you know?
Alright, let me clarify: This may come across as argumentative, opinionated, narrow-minded, etc. However, I don't want to put any of that across. You and I, Lexy have very similar means of harnessing language to put across points. Many people interpret it as hostility when it's really just a no-nonsense sort of way of going about making a point. I'm sure you won't read any extra emotion into my posts, but for those that are around here these days that don't remember how we interacted with one another in the pre-blarg BYOND days, I think this meta-analysis of game design patterns could come across as an e-genital measuring contest and I don't want people to interpret it that way.

Xirre Wrote:
Nothing is wrong with the stat panel's appearance. What's wrong with it is people with no taste and design-sense use it as a means to an end. Thus, creating the false-sense that it is utter trash to use.

This is partially true. I'll acknowledge that. The issue is the particulars of two factors: The crowd you are looking to attract to your game, and the sort of game you are making.

The reason I'm aggressively anti-statpanel in almost every post I actually make, is because I actively account for both of these factors. My initial response to this thread was mostly tongue-in-cheek. I recognize that HrH is the sort of game that wouldn't be hampered overly by statpanels. However, owing to a lack of customizability, Lexy is going to find that use of the built-in GDI elements is frustrating and necessarily sacrifices visual appeal for ease of use. This would be problematic if she wen're making a GMUD.

Of course, MUD and Roguelike players are immensely forgiving of limited focus on UI design, and actually find themselves attracted to the flexibility and verbosity of such designs rather than put off by the rather antiquated approach that BYOND was designed around.

That said, she may even see an advantage, in that if the game doesn't immediately play like something that's been streamlined to the masses, she'll be benefited by simply not attracting the kind of people who will attempt to play the game as though it's a simple and straightforward experience. She's more likely to attract people who already understand that the appeal of a GMUD isn't always in what the game gives you to do, but what you make of what the game allows you to do. Modern games often do spoonfeed players too much under the expectation that players will jump ship at the slightest hint of having to learn to play the game, rather than being excited to play something that's different.

Hedgemistress wrote:
If macros work better for a game, macros work better for a game. If you're only thinking of games in terms of things where single key input is the optimum control strategy, you're using a more narrow definition of game than is strictly necessary.

One thing you do have to recognize, though, is that often we're faced with a torrent of games that use the easy approach exclusively. Even worse, we've got quite a heap of code lying around that's being used as the basis for how most people around here learn to program instead of some of the immensely superior articles and tutorials that are easily accessible but largely ignored. Just today I had a conversation with someone who has been programming for quite some time, but didn't know what the "src" keyword was. He was searching through the entire world for every mob in the world and checking them by name to find the specific one he was looking for. When in fact, he was already in an execution path where the "this" object was accessible through "src".

This feeds into your next point:

And as much as I see people saying "BYOND needs to attract more AAAAAAAA+ developers so we can make a $100 billion game!", I feel like the community has lost a lot of vivacity because of how much people despise games that use the system's built-in framework for these things.

It's not so much that. It's that the largest portion of our games don't consider what you've already said in your post. The majority of BYOND games are attempting to be something that doesn't lend itself to the interface considerations we're talking about. Statpanels, off-screen output controls, always-visible grid controls, etc. Aren't inherently bad, but the games that they are being put into simply don't work with those interface decisions.

A large majority of our games are attempting to be fast-paced action games, which require twitch-based controls. Having immediately visible feedback is extremely important for this kind of game. Unfortunately, usr << "you are stunned" is the limit of feedback that many of these games provide, and forcing the player to look away from the screen in order to realize that the reason they can't move is because they are stunned doesn't contribute to the goal of a highly readable twitch based action game. Basically, this sort of game absolutely needs high at-a-glance information density with a minimal impact on their ability to actually see what's on their screen.

Fortunately for you, Lexy, you are in the position where you are designing to BYOND's strengths, which is that your game doesn't require that sort of readability, and actively encourages players to use their visual surroundings as more or less a scaffold for their imagination. Further, your game expects players to approach your game with an open mind and a big ol' throbbing... heart? for more imaginative enhancement of their surroundings themselves rather than expecting the game to create the magic of the environment for them alone.

I fall nicely into your game's target niche. The problem I have with the above quoted observation is merely that it doesn't address the fact that the people Tom has repeated ad infinitum are BYOND's target demographic aren't you and me. They aren't old enough to remember MUDs and they haven't hit the period of mental maturity yet to appreciate that a game can be more than the sum of its code and graphics. BYOND is confused about what it should be at the moment, and at the moment the majority of our developers are interested in action-oriented games. Unfortunately, our conversation cannot be a cohesive one when talking about BYOND as a community and UI design for your game. There are necessarily factors that make those two topics impossible to reconcile.

Though, I'm sure you recognize that. I just thought it would be good to explicitly say it so that my blind hatred of statpanels and GDI elements is given reasonable limitations and explanation.

Cheers!
This is a really interesting topic, because it gets down to the core of what we've tried to do with BYOND, and why it has been a struggle. Fundamentally, a game engine is always going to provide a tradeoff for the developer: the easier it is to do something, the more they have to give up.

People forget, but back in the early days that so many here so fondly recall, BYOND was really limited, especially with the interface. You had this block browser-type thing with a big ugly "BYOND" plastered across the top and an often unneeded compass thingy next to it. You used statpanels because, damnit, that's all you had to work with. But, you know, we had some good games back then! Maybe not the kind of games you could put on an app-store but they were fun and people like them.

So we tried to improve things with 4.0 interfaces, and that was kind of a disaster for a number of reasons, but one is that it suddenly became a lot harder for people to make games because they had to make the interface now too. To get back to the OP, the usage of grids gave more control in return for more work (and potentially more bugs). Without 4.0, the OP and others like her would just use slower, potentially uglier statpanels but they'd be fine with it!

Now we're moving onto JS and HTML and all of this webclient stuff, and while I think it's definitely going to offer far prettier GUIs than were ever possible, I have to admit that I have my concerns. The expectation now is that BYOND games may have to have pretty interfaces, that they can be "professional" quality-- and while that's great on the surface, it also may discourage people because suddenly these hobbyist projects have this pressure to live up to a certain aesthetic standard. When, in truth, the only standard they really should care about is that of their developer(s). BYOND should be first and foremost about ideas and game concepts since that's where the fun is!

That said, it is my hope that we'll get enough people who will do the grunt work of creating the pretty controls in this new system so that the end-user can effectively drag & drop them without having to put in the tremendous work that is designing a world-class GUI. It won't be as easy as it was in the nostalgic old days, but hopefully we can meet in the middle and make something everyone can be proud to play.
So we tried to improve things with 4.0 interfaces, and that was kind of a disaster for a number of reasons, but one is that it suddenly became a lot harder for people to make games because they had to make the interface now too.

It was a good effort at the time, but if we knew what we do today about where certain technologies were going to be headed at the time, I'm sure you would have spent your efforts working toward an entirely different route. I myself only tend to use two of the built-in GDI interface elements: Maps and Browsers. We use statpanels for debugging and outputs for debugging, but for the most part we stick to what we can put on the screen and then manage the interface with Javascript behind the scenes.

The trouble, Tom, isn't that it's too hard to use the new interface features. It's that nobody has leaked a codebase that uses them properly.

I do an immense amount of bugfixing of old and broken seventeenth hand code around these here parts, and I'll be honest, there are games that are prevalent here today that refuse to use TOPDOWN_MAP_FORMAT because they are afraid it causes "lag", are afraid of using grids, because they cause "lag", afraid of using pixel movement, because it's "laggy", and won't even touch the default interface file because it makes their games blurry if they mess with it.

I've had to teach even some of our best programmers in this community to understand the tick format. Because of backward-compatability, and making the icons use a 10/fps tick timer, people won't change their project's fps because they can't get their animations to sync up right, so they just stick with 10fps.

I've done my best to try to spread the gospel of green programming and try to spread more correct knowledge about how easy it is to make good-looking interfaces with very little work, but at the end of the day, our target audience is interested in the result of having made something moreso than the process of making it.


In all honesty, I'm biding my time using our existing implementation and waiting for the day that you decide to open source DreamSeeker's code so I can cut it apart and drop in some unfinished C++ code I've got socked away on my HDD.

If this were my dream world and I had infinite time and access to code, here's what I'd want to do:

1) Reimplement DM's current global functions and datum->atom structure in Dart.

2) Replace the existing compiler with a DM->Dart transcompiler and include a syntax for injecting raw Dart code into the project without need of the DMS format.

3) Break the syntax into two modules, the client and the server. Rewrite the rendering and communication protocol in Dart, leaving only pager and resource communication in the C++ code.

4) Permit user-level access to the rendering and networking code via a "show advanced project files in Dream Maker".

5) On "compilation" in DM, the transcompiler merely converts DM code into server-side and client-side Dart code. On connection to a world, the C++ code distributes the client-side end of the transcompiled DM code and user-included Dart code to the client and uses it to customize the client at runtime.

6) Provide limited QT and full OpenGL access through a dart module on the client-side. Use winset/winget format to communicate with it from the server end, or allow the client to manipulate it directly.


But it's not a perfect world, so I'm just gonna quietly work on a game using the knowledge I've got about what we've already got.
I agree with what Tom said, but I wouldn't say the new interface stuff was a failure. In DBG I'm using it to resize every single part of the UI (map, ooc chat, ic chat, and tabs). I'm also using it to switch between DBG's 'classic' UI and an 'alternative' UI, which in my mind is awesome.

I've been around BYOND since these days we're talking about (I just don't interact/post much I find oldbies too negative and newbies too 4chan), and other communities in the game development scene and I can honestly say, at the end of the day inexperienced developers will create bad UI in ANY engine.
I'd be interested to know what % of the developer-base created their very first game in BYOND (I know I did, by pasting together code snippets from separate tutorials and hoping for the best), so I think it comes down to availability and digestibility of information about the engine. Take a look at Unity for example, it's got whole swaths of professionally done tutorial videos on youtube, presented with basically a big neon sign saying "TUTORIALS, GET'M WHILE THEY'RE HOT". You can't make people watch them, but it helps the people competent enough to want to learn.

However, learning the in's and out's of an engine isn't the same as knowing good UI design. So yeah, I've stumped myself, it's kind of a 'third party' thing teching yourself how to actually make a functional and form-fitting UI.
Ter13, just to be clear: this is one of the more enjoyable conversations I've had on the web recently. I have read a lot of your thoughts on GUI design on this forum both during my lurker phase that preceded active participation and while looking up stuff about the interface elements, so I understand where you're coming from.

Tom, this is pie-in-the-sky, but as far as getting skilled people to do the prettification goes, that's one of the reasons I keep talking about saving glitz for later and just making sure my backend code isn't dependent on the front end: I'd like to think I might be in a position to outsource that down the line, if there's interest.

On that note, I actually think I'm going to fork the work I've done on the interface and go back to statpanels for this phase of development/testing. Because they require manual updating, it takes a lot more investment to make the grids work, and if they might not end up being the ultimate solution... well, I don't want to put more work into designing an interim UI that will require more work to pull out later.

If the panels cause performance issues that interfere with testing, then I can do something to address it, but I'm not going to borrow trouble.

And yeah, I remember how awfully limited BYOND was in the bad old days. I'm very happy that I can bend more things to fit what makes sense for my project rather than bending my project around what BYOND can do.
In response to Hedgemistress
Hedgemistress wrote:
Ter13, just to be clear: this is one of the more enjoyable conversations I've had on the web recently.

I've seen them all day today. They're like machines today. Endless creative minds.
Hedgemistress: I think that separating out the frontend from the backend is important regardless of whether you implement it yourself or outsource it later. It'll just give you a lot more flexibility down the line. And I also agree that you should just go with what is easiest during the prototype stage. That'll give you more time to work on the fun stuff, because only sadists enjoy working on GUIs!

Liens: I'm glad that you have been able to make use of some of the more complicated parts of 4.0, such as the resizing. Probably the most practical thing that this development brought to the table is just the ability to make minimalist interfaces of the sort Ter13 noted, because in the past you'd always have to have the browser/output stuff (not to mention the ugly BYOND logo) present even if you didn't use them.

Ter13: One day we will probably open-source everything, but, like I've been saying for so long, I don't want anyone to develop keeping this or any other features in mind. BYOND is what is is, and if it is too limiting, I don't take offense to anyone not using it. I have myself been playing with some outside tech involving some realtime physics and have been tempted to combine it with multiplayer-- this is the sort of thing I'd never consider in BYOND, even with access to the backend, because it would just be a hack. You have to find the right tool for the job. Now whether BYOND is the best tool for any job is a legitimate question with all of the cool tech that exists these days, but I think it has its place and it sounds like others agree. I do appreciate all you've done to push the engine and help others, and I hope you can be one of those people who can contribute the kinds of UI components we're counting on to make the new webclient successful.
I just added a CPU monitor to the admin panel, something I've been afraid to do because I'm historically a woefully inefficient... but even on running it on my laptop, I can't make it tick up to 1 except when I cast a certain spell. So maybe the performance hit from using statpanels isn't going to be anything to worry about.

Even adding and initializing a new burrow doesn't make CPU tick up. It lags out for a second if it has to add a new Z layer to do so, with 400 burrows available per Z level (or "lairs per layer", if you will{) I think I can reasonably set it up so it never has to do that at runtime.

I have to credit Ter13 here for the great posts on the virtues of associative lists for speeding code... I've been a fan of using list indexes basically as pseudoprocs since the days of old HRH, but always vaguely felt like I was abusing the system in a way that would bite me on the behind later.
I do appreciate all you've done to push the engine and help others, and I hope you can be one of those people who can contribute the kinds of UI components we're counting on to make the new webclient successful.

I'm not sure if you've been watching my twitch development streams recently, but if you've caught one of them, you'll be aware I'm working with MDC on a certain unspeakable project.

Part of my agreement for working with them is that the game's core code that I write, I maintain rights to do what I want with. Any graphics I make for them, and any situational code I write for them is fully theirs.

I made this agreement with the transition to the web client in mind, because I'm actively planning on releasing some generic approaches to developing tight, drop-in UI code that allows a high degree of customizability and flexibility whilst still providing the ease of use expected by BYOND developers.

I'm hoping that I have the time to not only dedicate to our project, but also to dedicate to documenting and releasing an intelligible product that may see use.
I would be very surprised if even an extensive Stat() proc took up noticeable CPU, since it ticks at 1/10th of a second (which is nothing for today's computers) and, unless you are doing serious computation, should pale in comparison to the map updates. I think the main issue with using panels (statpanels or grids) is really the aesthetic one. If you go with a windows-style GUI, your whole game has to adapt that style-- which isn't necessarily bad, but won't meet modern expectations for games. I personally think that function is more important that beauty for casual games. You can read a number of SS13 reviews that talk about how, despite the clunky interface, the game has great replayability because of how unique it is.
I have to credit Ter13 here for the great posts on the virtues of associative lists for speeding code... I've been a fan of using list indexes basically as pseudoprocs since the days of old HRH, but always vaguely felt like I was abusing the system in a way that would bite me on the behind later.

The only thing that global associative lists that are initialized outside of a proc, is that there's a 2-bit proc limit in BYOND. Each time you use

var
list/something = list()


That generates a pseudo-proc in the game's bytecode. These are part of the reason for the unnamed procs that show up when you profile your game and then reboot.

The only possible thing that can bite you in the ass later is breaching that 2-byte proc limit, but if there were a major project that had good reason to breach it, I'm sure Lummox and Tom would have no problems giving procs the 3-byte treatment that they gave other object types a few years back.
In response to Ter13
I did see one of your streams, Ter! You are incredibly talented with both the artwork and the coding. I don't want to stray too much off-topic in Hedgemistress's forum, but my main suggestion is that you guys don't make all this effort just be for another DBZ game, because that puts a real cap on your potential popularity (seeing how aggressive FUNimation is towards these things). If a game is 99% original, don't encumber it with something that you can totally avoid.

But that's awesome that you are making reusable components and approaches. That will definitely help this next era of devs.
Tom, since you're here, maybe you can clear something up for me that I've been confused about. Does the statpanel update every tenth of a second, or is it based on tick_lag/fps? I had the idea back in the day that it was some arbitrary thing that was more than once a second but not quite every tick.

It's not terribly important to my project that it be every single server tick or even a known/predictable number... this is not a twitch-based gameplay game at all. I've just been curious because I've seen some conflicting ideas.
It's based on the tick_lag. I believe it is throttled, though (I want to say once every 8 ticks). I'll have to look at the code.. that's like 20 years old and might be different for the webclient.
Throttled to once every eight ticks but those ticks being based on tick lag would match with both my vague memories of before faster tick lags were possible and what I've casually observed since.

It's not a huge deal, it's certainly called frequently enough that I couldn't tell how often it was called by watching.
Page: 1 2