EPT
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/header.jpg)
Previous updates:
GameHeart Project, Update #1
GameHeart Project, Update #2
Update -
Well we had better get started, there is a lot to talk about in this update! First of all, I said I would be working on notifications this week but I have not. Shortly after my last update two weeks ago my partner Ahli made some discoveries about the interaction of custom maps and blizzobs interface files. These discoveries are well, fantastic. However they have throw my plan for notifications a little up in the air. We can discuss them more in a little bit but first I want to do a general recap of where things are at.
Interface file
To be perfectly honest the interface file still isn’t ready to go. We have been having massive problems working with the unit info panel which has some very strange restrictions on the ways that you can manipulate it. In some instances it is very difficult to make it look good. The revelations that Ahli has made also have a huge impact on how we need to design interface files, but I will go into that more later in that section of the blog.
The interface file is in a pretty usable state but it is not perfect. Unfortunately I have decided NOT to release it to you guys yet because I don’t want people to start using it in this state and then write it off for the future if they don’t like it.
The things Ahli has discovered which I discuss in the MIT Overseer Integration section of this blog also mean that we need to be certain of how we will be implementing such features so when we release the interface files they will work with it correctly. Sorry for more delays but it’s just the way it has to be for now.
Stronger team colors
I do not have a lot to talk about on the STC front but there is some good news, which is that pzea469 has started to adapt some of the new HotS units for Stronger Team Colors. He has sent me a couple of preview images and I think they are looking fantastic.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/gameheart/blog/images/STC-Swarmhost_lrg.jpg)
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/gameheart/blog/images/STC-Viper_lrg.jpg)
He has also started to go back and modify some of the WoL units which people did not care for with STC, such as the colossus. So I am excited to see what he does!
File structure -
In this section I just want to enlighten everyone a little bit on the functioning of GameHeart, and this time I will talk about the file structure. It also contains some tidbits about why I have it organized a bit oddly. The way GameHeart mod files are organized is rather complicated at first glance, but I think easy to understand with a little bit of an explanation. First I want to define a few terms so you understand what I am talking about when I use them.
A ‘Core File’ is a mod file that contains the main content associated with whatever module it represents. Core files are at the bottom of the chain and are the files I actually have to update when I want to make changes to GameHeart. If you are looking for the code or other content such as custom images and font styles in GameHeart maps the core files are where you should look.
A ‘Pod File’ is a mod file which contains a core file. This is it’s only purpose. There will be no other changes inside of this file except that it has the core file inside of it as a dependency with the setting ‘use latest version’ checked. I will explain the reason I do this shortly.
To understand why I need to use pod files you first need to understand a few of the restrictions the map editor places upon modders. The first restriction that you should be aware of is that each Battle.net account is limited to uploading only 20 files per region, regardless of their filesize. This is a problem for mods like GameHeart because it isn’t just one map like most arcade games. I have to provide many different maps that have GameHeart enabled on them, so I fill up my 20 slots quite quickly. That means I am forced to use three different accounts to manage GameHeart, which can be fairly obnoxious for several reasons. It means signing in and out of the editor or game constantly to switch accounts, it means I have to be extra careful about how I name my files because I cannot move a filename from one account to another, and it means that the ‘use latest version’ function on mod files will not work for me unless I put the mod files on the same account as whatever is using it, which unfortunately is not always possible.
So what is the ‘use latest version’ function? Basically if you add a mod file to a map or another mod and you set it to ‘use newest version’ then the map or mod containing that mod will always try to use the most recently uploaded version of it. Sounds straight forward right? Well this option was only added in the 2.0.10 patch. Previous to that when you added a mod to your map it would always use the version of the mod that existed at the time you added it. If you uploaded a new version of the mod file later, you would also have to go back and change the mod settings on every map that was using it. That meant that before when I wanted to update GameHeart I would have to reupload every map that was using it, instead of just one mod file. So adding this functionality was fantastic for my project, except that they added a, what I think is rather arbitrary restriction to it. They made it so you could only use that setting with your own files. Or to be more specific, files that are on the same account.
Why do I say it is an arbitrary restriction? Well there may be some fantastic reason for this restriction that I have not conceived of and what I am about to suggest is really just conjecture. But the only two reasons I can think of for making it this way is if there were some kind of technical reason it had to be this way (unlikely), or that they are concerned people will add mod files from other developers and then have their maps break later when those other developers make changes to their mod files. Now lets be clear, this function is an option which is OFF by default. You have to go out of your way to turn it on, so I don’t see why they should be concerned about us using it with other people’s mod files. We are big boys who are capable of making these decisions for ourselves, and designing functions into the editor which are ideal only for people who are unlikely to produce high quality content seems questionable to me. But that is the way they have chosen to implement it for now at least, though I hope they will change it in the future. It is frustrating for me because it means I cannot have a map that auto-updates with a mod on a different account than the mod itself.
Or can I? There is a really obvious work around to this restriction and I wonder if you guys have caught onto it yet. Despite how obvious it is it took me awhile before I thought of it. I do not know if Blizzard is aware of the work-around or whether they intend for it to be usable this way. I hesitate to talk about it because I am somewhat concerned that if they find out about it they may change it so it no longer works, but hopefully that doesn’t happen. In any case they will find out about it one way or the other. The work around is basically that you just take one of your mod files and put it inside another mod file on the same account (a pod file as I call it) and set it to ‘use latest version’. Now anyone who wants to use an automatically updating version of your mod can just add the pod file instead of the core file, because the pod file will always use the latest version of the core file. Because they are both on the same account it works fine. This is the reason I can say that tournaments can add GameHeart to their own maps and have them automatically update, and why I can use my own mod files across my three accounts without worrying about this strange restriction. It also means I can work with other developers like the gentlemen from MIT Game Labs to integrate their work into GameHeart and allow them to work on it separately without worrying about updating GameHeart itself each time they make changes to their project.
So that is why my file structure looks so complicated, and why there are so many files to keep track of. But it’s a system that works so until they remove the use latest version restriction this is how it will look. So lets get into the actual structure of the files themselves. For this I am going to use GameHeart Light but GameHeart Classic is structured the same way, just replace the word ‘light’ with ‘classic’ where necessary.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/FileStructure.jpg)
So obviously there are a lot of mod files that go into GameHeart. Some are large and some are small, but each one is designed to be very modular so people can add individual mods to their maps instead of the complete GameHeart if they so choose. So if you want the STC system but not the rest of GameHeart you can just add the ‘GameHeart STC’ pod mod to your map and you will be good to go.
In the future I hope other developers will create mod files to integrate into GameHeart, and tournaments will be able to add those mods themselves to their own GameHeart maps easily. Anyways that is all on the horizon hopefully but for now I am struggling just to get a working test version together, which I will outline in the next section.
Problems -
I have been having a lot of problems with the editor throughout this project. I believe most are bugs with the Game Attributes system, the multi-region uploading system, or the mod file system in general but it is difficult to say for certain in some cases. Right now the problem that is having the greatest impact on the project is a strange issue that occurs when I try to upload a file to multiple regions sometimes, though I cannot say whether that is the cause of the problem or just a symptom.
Basically, when I try to upload a file it will go through to the first region, but uploading to the next three will fail. It fails while trying to transmit the header file, and kicks back an error saying the default attribute values could not be validated. This wouldn’t be a huge problem if it meant I just had to upload to each region individually, but I have found that even for the region it supposedly uploads correctly, Game Attributes (the custom drop down menus to the left side of the screen in a starcraft lobby) will not be functioning correctly anyways.
Here is a screenshot of what the error looks like.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/GameAttributeFailure.jpg)
I cannot figure out why it is doing this, because at times a file will work fine for days and then suddenly when I try to upload it again without making any changes at all to game attributes it will break. Even deleting the game attributes and rebuilding them does not fix it, the file just seems permanently corrupted.
I have reported this and another problem to Blizzard weeks ago. They have said at least one problem (not this one) they will fix in the 2.1 patch if they are able to verify it is actually a bug so that is pretty positive. I am not sharing all of this with you to throw them under the bus though it may seem that way. I really just want you guys to understand that often times on these projects we are up against more than just doing the work. Sometimes there are problems we have no control over and while we are often able to find a work around, unfortunately sometimes we are not. I may yet discover the root cause of this issue and I hope I do so that at the very least I can give Blizzard more detailed information about what is causing it.
If you are a developer and you have had this problem and perhaps found a solution please let me know. I could really use one right now, I think as soon as I can fix this I can start uploading a working version of GameHeart Light for tournaments to use. With that negative stuff out of the way let’s start talking about some positive stuff.
MIT Overseer Integration -
Well here is an interesting topic, and some of what I discussed earlier regarding the revelations about cooperation between custom maps and interface files is going to be outlined in this section. I mentioned it briefly in the last update but if you are unfamiliar with the MIT Overseer project you should read about it in their blog here.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/MIT_Game_Lab.jpg)
Revelation
The gist of the revelation I am speaking of is that you can toggle and manipulate interface elements created inside of a custom map by using a Blizzobs interface file that is setup to work with that map. What this means is that most of, if not all features that the MIT Game Lab has implemented into their Overseer mod can be integrated into both GameHeart Classic and GameHeart Light. Unfortunately it does not eliminate the need for GameHeart Classic but hopefully we will get there someday.
This also opens up the possibilities for other mod developers who might want to try their hand at improving the SC2 Spectating experience. At the moment it requires a Blizzobs interface file that is setup for it, but I am working on a proposal to Blizzard on a number of (simple) changes they could make so that it will work with any interface file by default, as well as some (simple) changes they could make to improve our ability to create high quality interface files in general.
There is more good news to this though. Basically with this knowledge interface designers will be capable of some amount of customizing the look of some GameHeart features themselves without even touching the custom maps. But maybe we had better save that for later.
If you are a developer and want more information about how this works please let me know. I can be reached on skype as ‘rtschutter’ or via email at TeamGameHeart@gmail.com
Cooperation
So now with that in mind I want to talk about MIT Game Lab and how both Ahli and I have been discussing with them how we could integrate much or most of the Overseer project into GameHeart so that tournaments and showmatches do not have to pick one or the other, but can use both at the same time. This is a similar situation to how I ended up working with Ahli the first time. He was working on a project that would have been competitive with GameHeart, but lucky for me he decided his efforts were best put towards improving GameHeart instead.
Currently they are working on creating a mod we can add to GameHeart to test the function and the integration of it. I really hope it all works out because they have brought a lot of awesome features to Starcraft spectating and I want to see those in GameHeart!
Changes
One thing it is important to note, is that MIT Overseer already features an awesome upgrade notification system, which was the stretch goal on my project that was met. What they have done is already better than what I was planning, so after discussing it with them we decided that it would be best just to use their system.
Now the upgrade notification system I had planned was a two-part system. There were going to be both notifications on the side of the screen and above unit’s heads. I will still have to work on the overhead notifications but not having to create the sidebar notifications does free up some of my time and because you guys paid me to work on them it is only fair that I try to make it up to you in some way. And that brings us to this week’s new discussion topic.
New discussion topic -
Unfortunately last week’s discussion topic of team sponsors did not really pan out. But this week we have a new topic up for discussion so please weigh in!
Team-colored effects
A couple of weeks ago some of you may have seen a popular post on /r/starcraft about team-colored ability effects. For those of you who missed it, here is a link. The basics of it are that many ability effects would become colored to represent the player that used them so it is more clear which player did what in mirror matches.
Here is a screenshot of a quick version of it with forcefields. This is done in-game and is not modified in photoshop other than cropping.
![[image loading]](https://dl.dropboxusercontent.com/u/49867307/GAMEHEART/Blog/Images/Colored_Effects.jpg)
This seems like a great idea, but there is a lot that needs to be figured out before we can implement it. First we need to know if we can do this so that it does not affect the players. That is the number one rule when working on anything like this. Right now, I think we can. Using the Gax3 mod Renee created we can do a lot of things like this. But it will need thorough testing before I can make any promises that we can implement it.
But before all of that we should discuss how we would implement it anyways. We need to decide which abilities we would and would not want to colorize.
So in that screenshot above I have colorized some force fields, but maybe we don’t want to colorized force fields. After all, force fields affect both players regardless of who cast them. So is knowing who casted that specific force field important enough to colorize it? This is the discussion we need to have.
What I want from you is a list of abilities you think should be colorized. And in the case of abilities like force fields, which affect both players let me know why you still think it should be colorized (if you do).
Thanks for your help!
