Changed how objects are added to HudGroups. The HudGroup's add proc can be used in one of three forms. Parameters written in square brackets are optional named parameters you can set.

add(client/c) - adds a client to the list of players viewing the hud group. Returns 0 or 1.

add(mob/m) - adds the mob's client to the list of viewers. Returns 0 or 1.

add(x, y, ...) - creates a screen object at the specified location and returns the HudObject that was created. There are many named arguments you can also use to set properties of the new object: icon_state, text, layer, and value.

Changed how objects are removed from HudGroups. The HudGroup's remove() proc can now be used in one of five forms. All return 1 or 0 to indicate success or failure:

remove(client/c) - removes a client from the list of viewers

remove(mob/m) - removes the mob's client from the list of viewers

remove(HudObject/h) - removes the object from the group

remove(index) - removes the object at the specified index in the group's "objects" list from the group.

remove() - removes the last object in the group.

Added the cut_word() proc to the Font object. The proc takes a string and a width (in pixels) and returns the part of the string that fits inside that width. For example, calling cut_word("testing", 16) might return "test", because that's all that can fit inside 16 pixels.

Added the "border-demo" which shows how to create a border around the edge of the player's screen that can be updated as the player's screen size changes.

Added the "party-demo", which shows how to create an on-screen indicator of where your allies are located.

Most of the changes were to clean up how the library is used. The HudGroup object now has just the add() and remove() procs that can both be used for adding/removing clients and screen objects.

There is now a new, single syntax for adding screen objects that have text or not. The first two parameters to the add() proc are the coordinates of the object, the remaining arguments are optional named arguments you can use to set additional properties. For example:

The first line uses the icon_state parameter to set the object's icon_state. The object's icon is still inherited from the HudGroup object. The second line doesn't set an icon_state, but it does use the text argument to attach on-screen text to the object. It also sets the object's layer. You can do both of these same operations without using named arguments:

The named arguments provide a cleaner, more flexible syntax. I can add options without having to add a new proc. And because they are named, you don't have to remember their order and changes don't affect the order.
I also added two new demos: border-demo and party-demo. The border demo just creates a border around the player's screen using a HudGroup. The HudGroup can be resized to match the player's screen size. The party demo creates an on-screen indicator which shows you where party members are located. The indicator moves around the screen as you and your ally move, and always points in their direction.

// you could do this:hud_group.layout = HORIZONTAL_ROWfor(var/i = 0 to 7) hud_group.add("health-bubble")

The positions would be automatically calculated and updated for you. I doubt I'll ever implement this because a limited feature isn't that useful and the sky is the limit for how complex this could be (think about how many rules and options there are for laying out HTML).

What about different types of health 'bars'? I would love support for circular, or a few other specific shaped bars that currently aren't possible with your system.

They're possible with the library, they're just not possible with what's provided in the health bar demo. If there's a drastically different type of health bar I might consider adding a demo for it, but generally I leave it as an exercise to the user to create things like that =)

As for nested `HudGroup`s, I can see it being somewhat useful from a superposition type of standpoint. If a user had multiple components of a HUD that could be logically grouped together and they want to allow for each part to be hidden individually or all of them hidden at once, encapsulating them with a new `HudGroup` would reduce odds of user error if they were to add a new `HudGroup` to that section. Generally speaking that would probably only work well enough if the added `HudGroup`s were named, and then /HudGroup.hide() and /HudGroup.show() could take a name for a parameter to show/hide an individual HudGroup in addition to its current behavior.

I'm afraid that nesting HudGroups can get too messy. I can imagine how having a visible group inside of a hidden group could cause confusion - the nested group wouldn't be shown, despite group.show() being called.

I have a feeling that if I do add it, it'll be to help out with another feature or demo. For example, a drag and drop inventory might be complex enough that I'd benefit from nesting groups, but I'd only add the nesting feature if I bother to add the inventory demo.

I'm afraid that nesting HudGroups can get too messy. I can imagine how having a visible group inside of a hidden group could cause confusion - the nested group wouldn't be shown, despite group.show() being called.

I have a feeling that if I do add it, it'll be to help out with another feature or demo. For example, a drag and drop inventory might be complex enough that I'd benefit from nesting groups, but I'd only add the nesting feature if I bother to add the inventory demo.

Really, it's not an absolutely necessary feature by any means- all of the use cases I can think of can be done with just a little more effort on the user's part anyways.

You should make a video of yourself programming a simple game from start to finish. Commentary as well plox.

But then you'd see how often I screw things up >.>

I think that a video could be very useful. One of my goals is to show how easy programming can be, so having a video that shows the development of a simple game in a short amount of time could be an excellent way to do that. I'll give this a shot sometime.

The only problem is that a written article is easier to work on - I can spent a few minutes here and there on it, I don't need to devote a chunk of time to recording.

That is a very intriguing idea. That should be a group project, actually. A few developers should get together and record a series of videos for the development process of a game. Having a group do it would mean that you could demonstrate effective collaboration, planning, et cetera.

You should make a video of yourself programming a simple game from start to finish. Commentary as well plox.

But then you'd see how often I screw things up >.>

At least then we'll know your human and not a robot that cranks out articles so often that it fills developer resources and I can't find the thing I'm looking for because I'm digging through a pile of your articles. *WINK WINK HINT HINT*

You should make a video of yourself programming a simple game from start to finish. Commentary as well plox.

But then you'd see how often I screw things up >.>

At least then we'll know your human and not a robot that cranks out articles so often that it fills developer resources and I can't find the thing I'm looking for because I'm digging through a pile of your articles. *WINK WINK HINT HINT*

I had enough posts saved up that I could have filled the front page with 20 posts of mine, but sometimes I made two posts a day so one would get missed and not tagged as content for the developer's page =)

I have an idea for the game I'd make for this video. I'd like to get a lot of the details worked out before taking a shot at making the video - 45 minutes of me saying "ummm..." won't be very helpful.

I have an idea for the game I'd make for this video. I'd like to get a lot of the details worked out before taking a shot at making the video...

I really think that you should do this with at least a second person. Being a documentary buff, I can tell you that it's the conversations between developers that makes these videos interesting. One person designing a game will not be, unless you are really handy with a camera or really clever with a video editor.

I figure it'll be a short video of me writing code. I'd start with a game idea and icons and make good use of my own libraries to cut down on the tedious work. I'm not sure how practical it is, but I'd rather not just talk about something, take a break to code it, then resume the video after I've done it. It'll be a simple game so I hope I'll be able to keep it realtime.

I do think a multi-developer discussion could be useful, but I'd rather not do that for this video. I'd like to show how easily one person can sit down and create a playable game. The discussion would be informative, but I want to give people the idea that a game idea can pop into your head, you can code it up in an hour, and have something that people can play - you don't need a team. And if you code it decently, it's easy to expand on it and create a polished game.