You know how current HUD (Heads Up Display) design uses screen objects to do the work in a very large number of games? This is mainly because it isn't hard to do and for the most part convenient. It is even easier to handle input on these objects for menus.
Unfortunately, there is a cold dark truth about these HUDs and a good number of players on here know about it. Due to the fact they are also dependent on objects; having a bunch of players with HUDs can result in severe lag. In fact, just keeping HUD-related objects in storage also results in severe lag. I even played games with crazy lag due to simply every player having a HUD.
How could this be remedied? Well, this began as an experiment several months ago. What experiment? Why, use image objects for HUD design of course! A good number of DM programmers on here know about the power of image objects. They were originally designed for visual effects. Even some of BYOND's biggest games used them. How could image objects work for HUD? Before I get started, I would like to state the fact I never even thought of taking this approach before myself. I have achieved onscreen input utilizing a hybrid icon object/image object approach (the latter used for the actual input). Last year's GIAD before it even started gave me an idea to work with just for that contest.
Not too long before last year's GIAD started; I created a working experiment dealing with image object-based HUD design. The only drawback is I did have to rely on some hand-crafted mouse handling to get interactivity whatsoever. As a restatement to what I said earlier for those who already know how image objects work; how could image objects work for HUD? This is where the solution is interesting. You create only a single screen object to serve as the master object (which works like a placeholder for all image object HUD related activity). What is clever about image objects is they only display to different clients as experienced DM programmers already know. Not only that, but they are also significantly faster compared to regular objects. With only needing a screen object shared by all clients; you get a nice working solution.
However, you do need a solution for mouse handling. This is where you add handling either to the master object or possibly even the client itself. While it does require more work; a library form of it could change everything related to HUD design on BYOND. Another benefit to having image object-based HUDs is the ability to use maptext if you don't need to utilize bitmap fonts.
As for my most recent experiment with image objects; I tested it out on my Next Generation Rendering Environment (which has nothing to do with HUD design) for image object capacity testing. Compared to overlays/underlays; it takes nearly 10K image objects before slowdown is apparent. Not only that; it only affects the client it is being displayed too. This could serve as a huge improvement to overall HUD design. A future for BYOND where HUD design revolves around image objects instead of screen objects (with the exception of one serving as the master object). I am currently working on a library that deals with image objects.
The question lies: Are you ready to start this revolution? You decide. With more libraries that utilize such capabilities; we may even start seeing fewer games use screen object HUDs. This could become very beneficial for games with larger number of players without the lag induced by screen object-based HUDs.
As for one final statement, here is the link to my experiment (source code included): https://www.dropbox.com/s/r4bdbg1owsnkxuj/ Experimental%20HUD%20Design_src.zip?dl=0
May 29 2017, 1:10 am