New Feature: Map Snapshots. A VARIETY of Uses!

ID:260756
 
Jul 12 2009, 7:24 am
Snapshot() or something similar, would allow you to grab a picture using the default map.

client/proc/Snapshot(args) // Args could allow for something like forcing the snapshot to be monochrome, or some sort of color filter


Here's how it would be used.

mob/verb/Take_Picture()
     var/image/picture/p=usr.client.Snapshot()
     usr << "Let's look at that picture..."
     browse(usr,picture) // Probably messed something up here


How would this benefit a variety of people with a variety of games? Let's start!

1.) People who want to make simple programs, like image editors, or image generators, would now have an option to save created pieces of art.
2.) Shooting Games could use it as a 'flashbang' sort of effect, where the screen blurs a bit.
3.) Adventure Games could use it as record-type deal, where a player's events could be visually captured to be seen later on in a picturebook, for instance. Imagine looking up a picturebook with your level 70 character and looking at all the feats you've done, then giving that book to someone else!
4.) Racing Games could use it as a ''Photo Finish'' of the final stretch of the race.
5.) Strategy Games could use it to capture a gameboard image at the beginning of the turn, so the next turn, you can look back and know EXACTLY what moves have been played since last turn, visually.
6.) Action Games could use it as a screenshot feature, where you can share the screenshots with others.

Yes, I know BYOND has a built-in screenshot feature, a macro called .screenshot; however, there's little way to police these images, and developers can't really use those screengrabs in a game, it would be difficult to. Also, .screenshot can't be used in a proc so you can't make a new varaible that of a result of .screenshot, so there's a lot of functionality gone. The above listed features are not possible with the .screenshot command.
Jul 12 2009, 8:19 am
It's possible to do this now, albeit with speed/processing issues. Crispy's Mapper library does something like this by creating an image for each turf and displaying it in a browser window. The other approach is creating a blank template image using Crop() and using icon.Insert() to create your screenshot. Android Data has a library that uses this second method.

Jul 12 2009, 9:13 am
In response to tenkuu
Would it not be easier to have a built-in method of doing this that does not have speed/processing issues?

I can find it annoying to have to lag a little bit when doing certain things involving this, like the processing issues in the 2nd/1st methods would create a temporary lagspike in a racing game right when the race is finishing.
Jul 13 2009, 3:23 am
In response to Mista-mage123
It's always better to have something built-in, but when you don't you'll have to find an approach that is good enough for what you want. You can always argue for a cool feature, but what if you never get it? It's always nice when you have alternatives whether they are feasible or not.

In the racing scenario you could have it "buffer" cars or any other non-static atoms in view of the finish line and then create the photo-finish after the race is completed.
Jul 13 2009, 5:08 am
Mista-mage123 wrote:
Snapshot() or something similar, would allow you to grab a picture using the default map.
[...]
5.) Strategy Games could use it to capture a gameboard image at the beginning of the turn, so the next turn, you can look back and know EXACTLY what moves have been played since last turn, visually.

I've gotten around this with Chess using a gameboard notation called FEN. Endgame boards (such as this one) are formed with PHP's image functions using the FEN-end field in the movelog, and I could very well create a move-by-move recreation of the game if I ever find the motivation to do so (which seems increasingly unlikely the longer I hang around here).

I do, however, see the merits of the developer snagging screenshots. It would certainly help those without $500/year servers to toy with =p
Jul 18 2009, 6:55 am
Mista-mage123 wrote:
2.) Shooting Games could use it as a 'flashbang' sort of effect, where the screen blurs a bit.

No, not really. Action games are slow enough as it is.
Jul 18 2009, 1:49 pm
In response to SuperAntx
SuperAntx wrote:
Mista-mage123 wrote:
2.) Shooting Games could use it as a 'flashbang' sort of effect, where the screen blurs a bit.

No, not really. Action games are slow enough as it is.

Poor game development is no reason to discard a feature that could help competent designers.
Mar 12 2010, 10:44 am
2.) Shooting Games could use it as a 'flashbang' sort of effect, where the screen blurs a bit.

Sounds like Shader effect, would VERY nice to see those, way much more could be achieved, also those effects hardly take any space, and are very easy to implement (post process ones)
Mar 13 2010, 4:02 pm
I like it, however http://www.byond.com/members/ DreamMakers?command=add_tracker_issue&tracker=4
is where it should be :)
-EDIT-
Oh wow, 07-09 Didn't pay attention to the date, Bad Ripiz! *Smacks with a newspaper*
Mar 14 2010, 7:39 am
In response to Ripiz
I've suggested this two or three times, and it hasn't gotten any support. I think I'll post it in the feature tracker, though, to see what people think.
Mar 14 2010, 7:42 am
In response to Jeff8500
I think its a good idea.