EPT
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/header.jpg)
Previous updates:
GameHeart Project, Update #1
GameHeart Project, Update #2
GameHeart Project, Update #3
GameHeart Project, Update #4
GameHeart Project, Update #5
GameHeart Project, Update #6
Update -
Happy new year everybody! This is going to be my second to last update on the GameHeart project. The project is nearly coming to a close and most of the goals I have set out to accomplish have been met. I will talk more about the future of GameHeart and what will happen after I call the project ‘complete’ in the final blog update. Also in the last update I mentioned that this time I would be doing a ‘thank you’ to all of the people who contributed to my IndieGoGo campaign. I am putting that off until next update because it felt more appropriate for a ‘wrap up’ post. I just wanted to give you a heads up on where we are at, but for now lets talk about this update.
With the 2.1 patch so close while I am writing this I have decided this update is going to be primarily about the process of converting GameHeart into an extension mod so that you will be able to use it on any map. Well mostly.
You see the extension mod system is fantastic. It is designed to allow mod developers to create a mod which players can then apply to any map when they setup the game. GameHeart in particular benefits from this system, but because of the way GameHeart works it is not actually a perfect fit. GameHeart uses a few map-specific pieces of data to display the large logos in the middle of the map. They are located in a different place on each map, and there is no way to automatically ‘detect’ a good place to put them. That is just something that requires a human eye unfortunately.
So today I am going to talk about overcoming that challenge, as well as a couple of smaller ones. I will also talk about what happens when you try to use the GameHeart extension with a map that the extension mod is not setup for. As a result today’s update will be rather technical compared to usual. Here we go!
GameHeart as an extension mod -
So let’s talk about extension mods in general for a moment and then I will go into more specific detail about GameHeart as an extension mod and the challenges involved in converting it.
Extension mods are a new feature being released in Blizzard’s 2.1 patch for SC2. This feature allows mod makers such as myself to create a module that SC2 players can apply to any map they choose at game creation. It is a shockingly big step.
You see when I first released GameHeart updating and maintaining it was a huge pain in the ass. Putting out even a small update would take 3 hours of just uploading individual files if I managed to maintain focus throughout the entire tedious process. After the 2.1 patch it will take me 30 seconds to do what took 5 hours only 9 months ago. This isn’t all as a result of the 2.1 patch, but it is a big part of it. Blizzard has been making a lot of changes over the last 6 months to improve the way we update and maintain our custom maps and mods.
As is usual when Blizzard announces anything the first reactions I see from people in the community is to trivialize whatever change they are making because it does not reflect what they were hoping to see. But I can tell you that from my perspective this change is anything but trivial. It isn’t going to completely change the way we play Starcraft overnight but it is going to have a significant long term impact, especially if they continue to improve and add to the system in the future.
What are you likely to see as a result of this change? Well I can’t speak for other developers and I do not know the challenges they all face in converting their particular projects to extension mods or if it is even possible for them to do so at this time, but I will try to paint a picture for you to the best of my ability.
I think we are likely to see mods like GameHeart, Starbow, Peepmode and a handful of others that require a variety of maps to be viable become much easier to use, create and maintain. This in turn should encourage the production and growth of games like monobattles or micro-macro as well as new creative ideas that while possible before, were just more work than they were worth. We could potentially see custom rebalancing mods where people try to express their ideas on how to change SC2 for the better. Even overhauls to create entirely different strategy games that can make use of SC2 melee maps are possible.
What do I dislike about extension mods?
First let’s be clear. I LOVE extension mods. There really isn’t a whole lot to dislike. They are a very solid addition to Starcraft. I do have a single complaint, and to be honest it is hardly even fair for me to make it because I have not shared this complaint with Blizzard which I should have done months ago when the feature was earlier in development. It did not occur to me until somewhat recently though because it is only partially related to my own use of the feature.
I probably would have preferred if the process of selecting a melee map/extension mod combination worked in reverse. The way it works at the moment, you select a map you want to play and then you select a mod to apply to it. I would have preferred if you select the mod and then a map to apply it to. I have a couple of reasons for this.
First, it would be less likely that someone would ‘forget’ to apply the mod. At times when people are running GameHeart in their tournaments they occasionally forget to use it when setting up a game. Reversing how extension mods are applied would not solve this problem, but I think it would reduce its rate of occurrence.
Second, it would open up extension mods to include a feature of ‘recommended maps’. Some list of maps that the mod developer could setup to recommend to users who are attempting to use their mod. So for example, the Starbow guys may find that their mod does not work well on certain SC2 maps, but does work particularly well on other maps. They could assemble a ‘recommended maps’ list that would allow them to communicate with people who are new to their mod and help them setup games that will be the most fun.
Again, it really isn’t fair for me to make this complaint now. But I thought I would throw it out there in case any Blizzard guys are reading this and might consider this suggestion in the future. In all likelihood they have already considered this and decided it didn’t work for some reason I have not thought of.
What are the challenges to converting GameHeart into an extension mod?
There are two main challenges to converting GameHeart into an extension mod. There were many more previously, but Blizzard has gone out of their way to fix many of the issues I was facing so I am very grateful for that help.
The two remaining challenges are map specific data, and clearing foliage (or weed whacking).
Map specific data
GameHeart uses a handful of data that is specific to each map that it is being played on in order to display the large league and team logos you see on the map. Currently this is not an issue because when you use GameHeart you load up one of the “GHLight” maps which has this data preloaded into it.
But when you use a GameHeart extension mod the maps will not have this preloaded data, so I need to preload the data into the mod itself instead of the map. This is where the challenge comes in. I have not been able to find a way to detect what specific map is being played using the SC2 editor. There is a function which returns the name of the map, but this cannot be used in any comparative arguments I assume because the name of the map can change depending on the locale of the user. This effectively makes it useless for my purpose.
That means that I needed to design a way to ‘detect’ what map was being used with GameHeart at that moment so I could then use that information to pull and display the correct data from the mod itself. I discussed this same issue in Project Update 4 in the extension mods section, but at the time I had not yet closed in on a solution.
But now I have. The solution was to create a system that averages the x and y grid positions of every mineral and vespene unit on the field into a unique identifying number for the map. To do this I created a new GameHeart module called “GameHeart Maps” which I think will not only be useful to me, but any other developers running into this same challenge with their own projects. In this module I created a function called “Maps - Detect ID” which looks like this:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/MapsDetectID.jpg)
It works by first selecting every resource unit on the map and adding them to a big unit group, and then taking each unit in that group and adding all of their squared x/y grid values to a big pool of x/y values. I then divide my pool of x values by my pool of y values to produce a unique number for that specific map. It’s actually pretty simple, and while it is technically possible for two maps to have the same ID it is extremely unlikely unless they are two different versions of the same map, in which case I prefer the number come out identical anyways because then I don’t have to apply the same data to two different maps.
So now that I had my system for detecting what map was being played, I needed a system for inputting all of necessary data for each map so it could be extracted later. I designed a spreadsheet which could be easily updated and maintained. And then a string function in the GameHeart Maps module that only required copy/pasting the row of data for a map from the spreadsheet to input that data into GameHeart. Here is the spreadsheet.
As you can see I have not added the data for many maps yet but I will be adding them rapidly over the next few days getting ready for the launch of extension mods. Once a map’s data has been entered into the spreadsheet I just copy paste the row as a string into a function I created called “Maps - Data Input”. Here is what inputting all of the map strings looks like:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/mapstrings.jpg)
This function then parses all of the data from the spreadsheet into structs which store the data, waiting to be pulled based on the map that is being played. Simple? Simple!
But Ryan, does that mean GameHeart won’t work with maps you haven’t added to the GameHeart Maps module yet?
Not at all. It just means that the league logos and the big team logos found in the middle of the map will not show up. The mineral line logos/team sponsors and the other features of GameHeart like the production icons, stronger team colors, team colored effects and upgrade notifications will all work fine.
Clearing foliage
So what the hell is foliage and why do I need to clear it in order to make GameHeart work as an extension mod?
Foliage are the little bushes and flowers that you see all over the maps. These flowers interfere with the functioning of GameHeart by ‘covering up’ the logo decals. Normally I would manually clear this foliage from logo areas using the terrain editor in the SC2 map editor before uploading a GHLight map, but with extension mods I cannot do that.
So to solve this problem I had to design an automated foliage clearing system that would remove foliage from logo areas.
Now ordinarily this may not be a huge challenge, except I also had to do it in a way where the foliage only gets clear for observers. If I were to clear the foliage for players, they could potentially use it to determine the location of their opponent(s). While there are other systems that clear foliage in large areas, I needed one that would dynamically clear it only in areas where there is a decal, and only do so for the observers.
Because the decals in GameHeart are different shapes and sizes, and they can be rotate to different angles the system had to adapt to the current size/shape/angle of the decal. I didn’t want to just clear a huge unnecessary area, I wanted to do some precision weed whacking. With that in mind I went to work coming up with a plan, and I made a graphic so I could share this plan and get feedback on it from other developers.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/FoliageClearingHelp.jpg)
The idea was to create a grid of small foliage clearing operations within each decal. This way it could be flexible or fluidic enough to adapt to any shape size or angle. The other advantage to this system is that I can use a terrain deformer actor instead of an effect to apply the operation. What does this mean? It means that I can filter who sees this actor so that only the observers see the foliage clearing operation.
I have create a small step by step visual guide on how this works. First here is what the decal area will always look to the players in the game:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/WeedWhackerStep1.jpg)
Next I want to show you what the decal would like like if we did NOT clear away the foliage.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/WeedWhackerStep2.jpg)
So the first step to clearing away this foliage is to find the four corners of our decal. We can find these relatively easily by using the width/height scale of our decal as well as it’s facing angle. This is made much easier because Zolden (the sc2mapster guy who made the decal models for me) had the foresight to make the default size of 1.0 take up exactly 1 grid space. Thanks man!
Here you can see the four corners highlighted with blue dots.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/WeedWhackerStep3.jpg)
Next we take our four corners and use them to average out the number of foliage removal operations that need to be done horizontally and vertically, and then determine their spacing. You can see this grid highlighted here as red dots.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/WeedWhackerStep4.jpg)
And finally all we have to do now is create a special foliage clearing actor at each of these locations.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/WeedWhackerStep5.jpg)
There may well be a better way to handle this, and I may discover it in the future but for now this gets the job done so we can be ready for the 2.1 patch and extension mods.
Because I felt like other people who want to create decals in their mods might want to use this functionality I added it to the GameHeart Decals module as an option when you create a decal with it. Very easy to use. I hope other developers will start using that module in their creations.
With that out of the way let’s talk about what exactly is coming when the 2.1 patch and the GameHeart extension mod is released.
What features will come with the GameHeart extension mod on release?
All of the features already included in the GHLight maps will be available in the extension mod right away. Those features include Stronger Team Colors, Team and League logos, Production Icons, and Upgrade Notifications (courtesy of MIT Game Lab) in the same easy to use (easier in fact) format you are used to already.
But there are three big new things coming along with the extension mod that you should be aware of.
2v2 support!
The 2.1 patch is also going to make 2v2 support possible for GameHeart, so I have reworked all of the GameHeart modules to support it. Actually you should be able to use GameHeart on games with up to 7 players without issue, and 8 players as long as they all use the standard colors.
This is actually a pretty big deal and it took a fair amount of work to make happen but I don’t have much else to say about it. It’s just cool! Now that we have covered everything we need to for this update lets go into the discussion topics.
Team colored effects!
The team colored effects module is complete and waiting to be uploaded as soon as the 2.1 patch goes live. That means that if enabled, spell effects like force field, time warp and scanner sweep will be colored like the player who casted them so there is no confusion who they came from.
However I removed the effect from fungal growth because I felt like it didn’t feel right and actually made the game more confusing. Because the spell effect attaches itself to an enemy unit it heavily colored one player’s units with the other player’s colors which made reading the game difficult at a glance.
Team sponsors!
Team sponsors support has finally arrived (on the test server)! That means teams can submit their sponsors to GameHeart and have them appear in their player’s base for the first two minutes of the game. The hope is that getting more exposure for their sponsors will help teams to encourage new sponsors and keep old sponsors involved.
This feature is very likely going to need quite a bit of tweaking as we see how it looks on a variety of maps over the coming months, so please do not jump to conclusions about it right away.
Here are a few screenshots of how it looks in game with a few different teams.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/Sponsors_sml.jpg)
If you are part of a team and want to know how your team can submit their sponsors to be added to GameHeart please check this reddit post I made about a few days ago, as well as this google document that serves as a guide on how to format your images.
Old discussion topic (player badges) -
I wanted to go back to this topic because I have been thinking more and more about it lately. Recently I posted a reddit thread about the idea, and to be honest I was rather surprised at the mixed reaction. Here is the image I posted:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/badges.jpg)
While I think overall people viewed the idea positively, a lot of people were concerned that it was ‘too cluttered’ or busy looking. I personally do not share those concerns, and I think perhaps the way I present ideas by cropping the image so it’s basically the only thing you can see sometimes makes it feel like whatever feature I am demonstrating has more weight than it does in the presentation of starcraft as a spectator sport.
Nevertheless I have decided to rework the idea so its presentation is more simplified. The idea is that there are now only three different types of badges a player can earn. A white star, which is earned by winning a premier event. A gold star, which is earned by winning a WCS season (in any region). And a blue star which can only be earned by winning the WCS grand finals.
Here is how it might look using this system:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/badges2.jpg)
I am fairly pleased with the concept. Try to ignore that they are not quite aligned properly, the tool I use to arrange decals for mockups and testing is not as precise as it would be in actual implementation. As far as the dark ring they sit on, I do feel they need some kind of dark background but I am not particularly tied to this idea. If you have another thought on how to present them let me know.
I would really like to hear what you guys think of these changes to please share in the comments!
New discussion topic (team jerseys) -
The idea of ‘team jerseys’ is one that continuously comes up when people are discussing GameHeart. In particular I have a friend who is very excited about the idea and has been pushing me towards it for months and months. Unfortunately, it is rather challenging to implement.
Just recently however I considered a new way it could be done, and I think it is possible (within reason) to implement using this method. I asked Zolden to whip up a new marine model prepared for this purpose so I could test it out and here is the result:
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/TeamJerseys.gif)
Basically what is happening here is there is a new texture layer between the default texture of the marine, and the base (player) color of the marine. So now I can insert whatever texture I want in there and have it show through where the player color areas are. This would allow teams to design and submit their own (simple) texture block that could then be applied to all units. But I think I would probably create a more elaborate system if I were going to implement this. Something that allows teams to hop into a custom map and play with the colors and patterns until they find something they like which would work well across all units. They would then just press ‘okay’ and it would give them an identification number they could send to me and I would assign it to their team. This ID number would then automatically recreate the textures they selected in the custom map.
There are enormous challenges to making this work. First, while I do not think it would be difficult to get it to look good on most Terran units, I think Zerg and Protoss units would be another story entirely. In all likelihood they would have to appear simpler than the Terran textures so as not to feel too awkward in the game. Next you have the problem with player colors and observer interfaces. Once you use these special jerseys suddenly all of the interfaces which use player colors to identify player scores and resource counts will become difficult to read. A team liquid player might be showing purple on the resource bar, but teal in game. There are solutions to both of these problems but they require some real work to tackle.
This is not something I can implement in this project. And perhaps it seems unfair to share ideas with you that I do not have the time to implement. But I want to keep you excited about the future of developing spectator tools. I would love to implement something like this and maybe I will get the chance eventually but who knows if it will ever be possible.
Despite that, I would really love to hear your thoughts on the idea so that if we are ever able to move forward with it we have plenty to consider when planning it.
Thanks guys! We are almost at the end of this project, and I hope you guys have been pleased with how it has progressed and the results it has been showing.
-Ryan
EDIT I almost forgot! You guys should check out the Night of the Dead II kickstarter! It is looking really awesome!
