Heatmaps for Halo Custom Edition

I'm having quite an interest in heatmaps recently. They actually are quite useful for debugging and other neat little things. I know there's a heatmap generator out there right now (thanks IG!), but it just barely cuts it.

I'm wondering if anyone here, including those who made the first heatmap tag collector, would be interested in expanding on the idea and make actual heatmaps for Halo. There's an idea that's been sitting in the back of my mind for the website, and for it to work perfectly, we'd need heatmaps to be created as color images. It's definitely more difficult than just putting dots on an image, so it would take a little thinking. I'm not even sure how much work it would take someone to do this. If anyone has any thoughts (logical ones), then please don't hold them back.

Well, I assume the map has x,y coordinates, right? The way I would create a heatmap is getting a list of coordinates (the kills/deaths/whatever), adjusting a radius for each dot, and using the resulting circles' intersections, create an image with the heatmap colors representing certain concentrations of intersections. I'll try to put this in image form if it's not as clear as I'm thinking it is.

The main problem I see with heatmaps is getting an overhead view of the map, then taking points in the map's 3d space and plotting them on that view. Collecting statistical information is the easy part

COuldn't you get the app to spawn planes instead of spheres. Than just apply a transparent mat so that the more planes in an area, the more opaque it is?

Quote:

---

Originally Posted by Kornman00

The main problem I see with heatmaps is getting an overhead view of the map, then taking points in the map's 3d space and plotting them on that view. Collecting statistical information is the easy part

---

What about rendering a topview image of the map, then plotting it on that?

Thats one way of doing it, but that requires you to have the source level geometry (ie 3dsmax) and bitmaps\shaders (if you really want it to look right). Doing something like b.net stats requires a generic method which can be ran in game for instance so any map can be done.

From there you would have something stitch multiple overhead views together so you could have a wide, high precision landscape view to plot on. Then using view frustum with screen <-> world matrix math you could begin plotting points. The engine has the functions do such things, but I've only researched where they are in the tool code. So in theory, OS could be made to not only stitch a few overhead captures together, but to also perform the plotting math at the end of the game (or as a game is played using a simular system as a halo 3 saved film).

It could be taken further to extending tool\sapien to auto-generate tag data (which could be inserted into the 'yelo' tag for OS to operate with) which determines the location spots for the overhead (among other things) to goto by analyzing the bsp geometry and boundries. Stuff that I'm sure Bungie is already doing with their Halo 3 codebase and tools

Well let's say that getting an overhead view of the level isn't an obstacle. If I was going somewhere with this, I would just get the views from Max. I don't think I would generate heatmaps for every level - only those which are "the best" and the most played.

Do you think there could be a way to bring an image into an app and then assign the left, right, top, and bottom bounds for the coordinates of the image? It would create a grid, essentially, and then the app could place a dot at the coordinates of the image where there was a kill. Think of something similar to Google Earth (the way it works, not the click and drag ability, though that would be pushing it for awesomeness).

Like Kornman has already said the hard part is plotting the locations onto a 2d image. I remember trying to track players location in real time with Keihatsu.

Skyline and I were thinking about heatmaps for CE just a day ago lol weird huh.

Well if I was going to design something, I would want to be able to use it myself, since I don't have 3dsmax.

You would need the 3d bounds (not just the 2d as you're thinking) of the view frustum image. Having 3d information would simplify the process of doing a heatmap view in a google-maps way (which actually isn't all that difficult to implement).
You would start with a overhead view which encompasses the entire map. Just like b.net's overhead views, these would have to fit into a single "capture". When I say a single "capture", imagine that you're in a debug camera mode and you just looked down at the ground, and started going up. At the point where you can see the entire lay of the land is when you're at the point where you encompass the level in your view frustum and can get it all in one "capture"

Then you would figure out how far you want to be able to scale up the magnifcation which would then determine the math in solving the grid "capturing" so you obtain a higher detail of the land, all while being able to scale that captured image down to allow different zoome levels. These gridded captures would be stitched in a fashion which isn't too different from how Yelo on H2 Xbox did its high-res screen shots. Grid "capturing" would just be lowering the camera down closer to a defined grid of the map, then like say, stitching it with other grid captures until you have a whole which matches that single "capture", but at a much higher LOD.

The "faked" 3d representation (3ds max thing) would need to be scaled perfectly to the size of the map, maybe not 1:1 ration but a constant ratio. So the halo 3d points would work scale down. This is the bit that has puzzled me and kinda grinded me to a halt on it. I'd need to experiment which actual figures and an overall picture laid out.

Do you have any 3d software package installed kornman?

Like I said earlier (phrased differently), using a view frustum system with screen <-> world translations you achieve the ability for plotting heatmaps on a image. The image represents the screen of the view frustum. Such systems are how Halo is able to render friendly indicators or nav points on your screen.

The only software I have installed is Maya (actually I think I uninstalled it to free disk space a while back) and Blender

Run this by me again:
If you need an overhead view, why don't you just use devcam and zoom out above the level?
I know it's something about 3D points or whatever, but could you just run it by me one more time?

it could look like this

http://img265.imageshack.us/img265/8194/heat.jpg

I'll explain how this works in a little. If anyone has any interest...

Quote:

---

Originally Posted by Conscars

it could look like this

---

Using the same concept with how the game renders the hud indicators for friendlies you can have a view frustum from an angled overhead view (or even just a view from a player) then plot points to an image of that view frustum.

Actually, now I have an idea on how to implement this system while offloading the majority of the work and math to the game >:3

But is there a method of collecting multiple sources of game kill statistics and creating a massive heatmap based off of that?

I was thinking along the lines of an application which could track every single kill made and then log it into a simple txt file with semicolon separated values. Each game would have a txt file marked by the map name, date, and time. The format of a kill would be (x,y);playername;weapon and the file would be called mapname_yyyymmdd_hhmmss.txt

Then a compiler, hopefully something that could be run on Linux in a CRON job to update every weekend, would use a set of parameters to build heatmaps for specific maps. The parameters could be something like heatmap -bloodgulch -all which would search for ALL txt files with the prefix of "bloodgulch_". Additional parameters could be specified to compile only heatmaps within the last day, week, or x months. Also, by default it would compile into one single heatmap with all data, but maybe a parameter could have them compile into separate images for those who would want.... (don't know why they would want to though)

I'll continue this thought later. g2g bbl

Of course there is, OS can record statistical information, such as the positions of where the players died.

I've been thinking up a different setup for OS which would use an event stream for recording data such as player deaths. It wouldn't be that hard to export to an intermediate format like the one you're suggesting.

I've never programmed for linux so I'm not exactly sure how something like that would be made. What architecture is linux running on (ie, intel, ppc, etc)? Is it 32 or 64bit?

Quote:

---

Originally Posted by Kornman00

Actually, now I have an idea on how to implement this system while offloading the majority of the work and math to the game >:3

---

Perhaps rendering objects in-game at the position of the kills/deaths? Then just use your previously said method of obtaining high res images and stitching them.

And then maybe someone could make a site for the heatmaps, and its updated every 24-48 hours?

That site, if Jcap's insinuating what I think he's insinuating, would be Modacity, my friend.