Sc2 Editor Analysis

[IskatuMesk]

This is going to be an extensive article covering the editor, its apparent limits that directly effect me, and things that should be corrected and/or improved. I will attempt to be a descriptive and thorough as possible. My primary subjects are going to involve the Data Editor as I feel this is the weakest aspect of the editor, but I will touch on many subjects.

I will start this from the basics and go down the list of major points in the easiest manner I can consider.

Part 1

General

Issue - Map Size Limit

[imgwh 640x400]http://img580.imageshack.us/img580/1280/ed1c.jpg[/imgwh]

The biggest and most apparent thing I first encounter is that the map size is still limited to 256x256. I feel that this is a severe blow to several major aspects of two of my projects I had desired to create. This decision was likely based on the factor that large maps may cause performance issues to very old computers.

Recommendations;

- I feel that the editor should support at least 512x512. However, the editor could warn the developer that this map may cause performance issues with slower machines in the event he desires to make such a map. Although Blizzard may not conceive of any use for a map that large, I personally could name several major uses.

* Active RPG maps that use functional cities and AI-controlled regions that cannot function correctly across a multi-map transition setup.
* Very large FFA maps.
* Cinematic projects involving large scale worlds.
* Special "mini-game" setups involving long-ranged units and intelligence warfare, especially something like the Sc1 Diplomacy maps.

Large-scale maps are something that are possible in games like Heroes of Might and Magic, and Age of Wonders 2. While these are both turn-based strategy games, consider that the large map sizes allow for long, dynamic gameplay on a completely active world. While I know that sc2 is capable of phasing between maps, I do not believe that the game would be capable of running a large number of AI scripted players that can keep sync with each other across these maps and interact with each other (such as sending an attack from map B to map A). Even if this were possible, a single large map would provide less of a performance impact than two individual maps of this nature running in tandem.

I do not expect this is something everyone would take advantage of but at the same time I believe the 256x256 size limit is arbitrary and only hurts those who wish to push the boundaries like myself.

Issue - Terrain Texture Limit

[imgwh 640x400]http://img693.imageshack.us/img693/2158/ed2v.jpg[/imgwh]

At a point during alpha Blizzard boasted the editor capable of loading any number of terrain textures at once. This is not possible. In fact, you can only load 8 at once. Such an arbitrary limit, in my opinion, should not exist at all. Again, a dialogue could warn the developer that a large number of textures used at once can incur a higher memory usage, but it should not completely restrict the user from using more textures. This is extremely limiting on a 128x128 map as it is for me.

Issue - Terrain Placement

There should most certainly be a snap to grid feature for the terrain tool - placing long, straight cliffs can sometimes be a real annoyance. The placement tool in general should be a bit more descriptive of how it's going to be effecting the terrain. The best way I can describe what I mean is to show you the Titan Quest placement tool for water.

[imgwh 640x400]http://img441.imageshack.us/img441/24/waht3.jpg[/imgwh]

Note the tool displaying a gizmo that allows you to easily see the elevation under the tool. It also has two circular graphs - one shows the total effect radius of the tool and the other the "minimum" effect radius of the tool. This is used for texturing, it shows you where the fade will start for blending textures.

Additionally, I'd like to make note that the Titan Quest editor allows you to resize water placement and change the water height without having to make a new water entry. SC2's editor is currently not capable of either of these.

[imgwh 640x400]http://img31.imageshack.us/img31/1391/ed3n.jpg[/imgwh]

In fact, the gigantic blocks of water the sc2 editor places can be very difficult to manage when making small rivers or ponds on raised surfaces since it will clip through the terrain on any edges. For every height level you must have a separate water entry - cumbersome and problematic in a big map.

Issue - 1 type of Creep limit

Because of the way creep is built into the tileset and game data you can only have one type of creep. This was a colossal blow to one of my conceptual projects and I can foresee it being a massive issue in any of my future projects due to the desire to create multiple creep-like substances for several races that look, and function, differently. A limit this extreme was unforeseen and, frankly, shocking.

There are probably ways you can fake having different types of creep but to me it seems like many things in sc2 have not moved anywhere since wc3.

Issue - Data Editor Organization

The biggest gripe I have with the sc2 editor is the extremely disorganized and confusing manner in which the attributes for many of the menus are laid out.

In the above tileset editor, the name for the tileset should be on the top. Instead, since it's listing alphabetically, the name is in a very random location.

[imgwh 640x507]http://img405.imageshack.us/img405/9047/ed5o.jpg[/imgwh]

Far worse than this is the unit editor. The arrangements of values in this are completely random and cripple any hope of making an efficient, painless run through a new unit. I cannot possibly imagine making a large-scale project in this editor - wc3 was bad enough with several values, like Armor, requiring repeatedly scrolling through a big list to find.

[imgwh 640x400]http://img708.imageshack.us/img708/5246/ea1g.jpg[/imgwh]

[imgwh 640x597]http://img4.imageshack.us/img4/908/ea2r.jpg[/imgwh]

The Unit Name and Unit Description fields are on opposing ends of the list and key values like health, shields and armor are separated by totally random and unrelated values.

Recommendations;

I feel that the data editor is in serious need of reworking layout-wise. With the editors the community created for Starcraft 1 having had their interfaces perfected over the course of many years of feedback it seems prudent to learn from our mistakes and our discoveries. While I would never expect an exact copy to be made the editors in question I feel that several important attributes of these editors need to be adopted in the Sc2 editor to help facilitate faster, easier, and more efficient production for users of all skill levels.

[imgwh 640x547]http://img571.imageshack.us/img571/8291/editor1.jpg[/imgwh]

Tabbed selection

Large sections of attributes that are related to each other should be organized by sub tabs. In Datedit, the attribute editor for Starcraft 1, a unit's basic vitals are in the first tab, with flags and other such items in the next tab, graphics in another, so on so forth. This allows the developer to quickly get where he wants to go without scrolling around.

Tabs are an interface standard adopted by many programs in the computing world, such as internet browsers and even many 3d applications. It is a feature users are accustomed to. While the sc2 does use tabs to organize major sections, as did wc3, the attributes remain listed in a giant, forbidding list that encumbers rather than presents.

Attribute Relationships

Attributes related to each other, like Vitals (Health, Shields, Armor - Cost, Tech Requirements, Build Time, ect.) should be grouped together for easy identification and access. The user should not have to scroll down a big list to find any of these attributes. Grouping and organizing these appropriately will go a very long way to helping new users break into the power of this editor as well as help advanced users produce their projects faster, more efficiently, and with less irritation.

Elimination of Redundancy

[imgwh 640x507]http://img297.imageshack.us/img297/4229/ed6pg.jpg[/imgwh]

Unnecessary dialogues like the above only serve to waste the user's time and instead annoy the user, especially when they are editing an exceptionally large amount of data at once.

GUI editor

[imgwh 640x507]http://img27.imageshack.us/img27/7088/ed7v.jpg[/imgwh]

In its current state the GUI editor for data is practically unusable. The scroll bar is so tiny and the organization remains so random that one immediately becomes lost and overwhelmed. There is virtually no usage of horizontal space whatsoever.

This is also a problem with battle.net 2.0, whose interface is extremely wasteful of space and you are required to scroll down in the player list to see all of the player slots. I cannot possibly fathom what kind of pressure was on Blizzard's shoulders to force a release with battle.net 2.0's interface the way it is, just as I cannot fathom anyone in Blizzard's team using this interface for their single-player campaign. This drove me mad in a day of playing with it, much less several years!

I would highly recommend investing the time into totally redoing the GUI if the plan is to leave the list editor as-is. Although this is something I would not expect upon release I would hope it would make it in shortly after release in the form of a patch. Using Datedit (source: http://files.campaigncreations.org/resources/sc/programs/DatEdit.zip ) as a basis would be my most powerful means of describing the changes I would like to see.

Obscurity

It is clear that many of the help dialogues in the editor are simply not finished, and I do believe that there was going to be a documentation of some kind in the future. Regardless, I feel a lot of dialogues and entries in the data editor need to be clarified as to what they actually do.

[imgwh 640x400]http://img9.imageshack.us/img9/3346/ed8z.jpg[/imgwh]

I have no idea why the weapon cooldown is called Period, for example. It just seems natural to me that it would be called something that makes it easy and quick to identify. Additionally there are no classifications to ANY of these attributes, and thus not even the slightest bit of organization. Again, I think developers would need a considerable hand-holding process by other developers to become acquainted with the obscurity of the data editor and the confusing nature of its arrangement, while with many other games most individuals can jump in and make basic changes without much hand holding. Unfortunately, with sc2 even changing damage and cooldown values can be a bit confusing for first-timers, and these critical, basic things become no less time consuming to do as the user becomes experienced with the editor because of their scattered nature.

I understand that the editor is complex and powerful. When dealing with games like this I do not expect the editor to be easy or newbie-friendly. I have modded games like Supreme Commander and Homeworld 2 in which there are no editors, just half-assed user made tools that are horrendously inefficient and often extremely buggy. There are many features in sc2's editor that I thoroughly enjoy, and the ui's for water and lights are exceptional and straight to the point - I like them a lot. But the data editor itself feels very haphazard and not much thought was put into it.

My effort is to spread awareness of the need for having the interface improved in the nature of organization and ease of use. This will not "simplify" the editor, this will improve the editor for those already using it by accelerating their production times through intuitive layout and arrangement that presents the immense power of the editor to them in a way that makes editing the game enjoyable and timely.

Some things like the Game Attributes editor give me only minor clues as to what they are capable of doing, and no hope for understanding their capabilities without an extensive external documentation or potentially weeks if not months of simply doing random things until something happens.

[Xenon]

Well said.

Documentation is especially needed to handle actor data; most of the more advanced features are rather impenetrable, made worse by the fact that you generally have to type stuff in to a text box and hope something happens. I have no idea how to get triggered site movers to work.

The game uses fixed reals instead of floats, and the max value is ca. 524000. If you look at scanner sweep its range is 500. I'd have to guess that since the distance between points is calculated by a^2+b^2=c^2, the square of the distance between any 2 points on the map has to be less than ca. 524000; that puts the theoretical max map size at just under 512x512. Even if you used a scanner sweep's range as the distance between corners, you could get a 352x352 map out of it.

[IskatuMesk]

The actor editor is something else I want to talk about. It's nearly as important as iscript, same with modeldata. But both the interfaces for these are exceptionally confusing and, as you have said, extremely vague. But their importance is so grand.

My proposition would be to use the existing model viewer as a foundation for a revamped data editor utility that handles these two files and allows real-time previews of your changes in actor data and model data. This could also be applied to missiles and such in general. While you may think this an outlandish concept, consider that the Halo Custom Edition editor actually ran the entire game engine in the editor itself - you could even spawn a billion warthogs in the air and watch em all come crashing down and tumble around.

Incidentally, the model viewer allows you to view material settings and such but does not allow you to change them. Seems silly.

[Magic]

Having played with the editor for 10 min, on a basic level it seems fine to me - changing portraits and attacks around is easy, but I can imagine the UI in particular being a major pain in the ass for extended periods of use.

Overall, you've made some really good points and put them eloquently. I hope Blizz see this, but given my experience of games development I can just see it as not being a priority to them, unfortunately. My best hope would be for an updated editor, post-release of Wings of Liberty. Whether the staggered release of the SC2 campaigns will help there, I don't know.

[IskatuMesk]

I've done what I can to make this information available to them. The ball is in their court now. We can only wait and see what happens.

It sucks being in the dark.

[AA7Dragoon]

I'm glad you forwarded this information to them, Mesk.  You presented rational, respectful, and reasonable arguments on all facets of this review.  I hope Blizzard takes a hard look at this for improvements.

[Marco]

I have a creative fix to your 'large scale map' problem.  It takes a bit of work, and you'll only be able to use it for custom games (in other words, no free for all.  But you can decrease all units size and speed by half.  Granted, it's not a perfect fix, but it should open up some possibilities for desired gameplay results.

[IskatuMesk]

Desler > That was my plans, actually. I employed this to a degree in wc3 as well. Unfortunately I want to keep buildings reasonably sized though (especially with smaller units, it'll give a better sense of realism and scale). And that is where the problem really comes in - making cities, fortresses, and geometric features like craters, valleys, mountainscapes, ect. I pulled a lot of creative voodoo in wc3 to make ends meet for that but I'd rather not have to cripple the map to get somewhere now, especially when the engine is fully capable of handling more.

[Falchion]

I can predict also an SC2Draft that allows for more terrain textures on one map.

[Quantam]

I can predict also an SC2Draft that allows for more terrain textures on one map.

I'd wager there's a technical reason for the limit. E.g. that's the number of textures they can sample in a target unit of time. I wouldn't really expect it to increase, though depending on their engine it might be possible to make it select the 8 most significant textures for each vertex so you can have more than 8 for the whole map.

[IskatuMesk]

NWN2's editor let you load every texture in the game, really - well over a hundred. Each tile only supported a few, but overall you could use all those textures throughout the map.

Sc2's system is just all around lame and arbitrary.

[Master Jademus Sreg]

The technical limit could possibly have been avoided if they maintained a separate map for each texture.

[IskatuMesk]

Part 2

The circle of prospect

Make no mistake, if battle.net 2.0 does not undergo a massive overhaul custom content will die out. Slowly, painfully, surely.

- No Local Hosting

Without local hosting developers are forced into publishing and the endless, ridiculous limits associated with it. Tournament and melee mappers will lose interest and one by one will leave the game for greener pastures as the map limit will continually force them to remove maps from publishing - which removes them from all of battle.net AND prevents the name from being used. Having to constantly publish maps also means that UMS map makers will be constantly trying to skirt the size limit whereas in wc3 the only thing they had to worry about was the size of the individual maps.

The fact that Blizzard's "mod" system, AKA their new campaign system, is ALSO restricted to 10mb completely defeats the purpose of having it on battle.net to begin with.

Without custom external executables or modded mpqs true modding will never exist in sc2 just like it has been for every other Blizzard game to date. The refusal to accept that modder's exist, much less acknowledge them or support them, is driving them away one by one and sc2 will no doubt be the nail in the coffin unless this changes.

There MUST be local hosting

Battle.net without local hosting is like a car without an engine. It is completely baffling that there is no local hosting available. The map restriction will restrict active developers and harshly limit the overall growth of the custom content community, something you NEVER, EVER want to do.

- No game naming

This will harm everyone, not just developers. Without being able to name your games a boundless amount of communication problems have arisen and will only get worse when maps start introducing custom options like DotA and Castlefight. Additionally, since players don't actually host games, malicious players can join and leave games over and over and over during the countdown to grief other users (which is already being heavily abused).

- Sortment by popularity

Maps are sorted by popularity. Underdogs and new maps will never make it to the top. Just like wc3, except even worse, one map will take the stage and kill all new comers. Also, the "see more" thing on the bottom after scrolling down is a terrible idea and needs to go. Just add pages, a search and advanced search function, and in general employ what any given forum or website does.

- Forced Latency

In wc3 forced latency was always an extremely annoying issue in most maps, and in sc2 the forced latency remains. Why? Why does this arbitrary, pointless limit exist? This must be removed by release. It helps no one but hurts everyone. You are not "leveling the playing field" between users, you are introducing an arbitrary delay on actions while forcing all professional players and custom map players to adhere to this silly delay with the lack of LAN. This only hurts the game. In wc3 it made serious play extremely difficult and painful. LAN was absolutely necessary.

In wc3 the enforced latency made maps like the third-person BC map we played once totally unplayable because of the delay in keys and actions.

- Censorship

Under no circumstances should a map be unable to be hosted because of text content. Period.

- Uploading limits

Mentioned in passing but here it is in stone - currently bnet only supports 5 maps and "mods" (hah!) max and 20mb max, 10mb max per object. Surely these limits will get upped on release but the fact they exist at all, especially a limit on the number, when local hosting is not an option is absolutely absurd. You are given a powerful editor and the only way you will ever be able to use half of its features is by making a campaign you'll have to host on a site like CC. Sc2 is taking steps backwards from sc1 and diablo 2, much less wc3.

I have little doubt that Blizzard will try to monetize these enforced limits by having options to buy larger caps. Which is in itself a horrifying prospect and one we should never be facing.

As it is, B.net offers nothing to the end-user or the developer that Starcraft 1 offered, and far better, through any given website. If this platform is to succeed in stimulating growth to the custom community it must see significant change.

- Map locking

The concept of map locking is stupid and harmful to the community. I guess that's fine, though, because all you need to do to circumvent Blizzard's locking is... open the map. Yep. That's it.

Recommendations

Battle.net 2.0 as it is, is not worthy of release. It's not even worthy of beta. If I were Blizzard, I'd just fire the guy responsible for it, step back, and say to the other guys: "Look, we screwed up. Let's take Warcraft 3's battle.net and do this the right way."

But this should have been done BEFORE beta. Now the game nears release. Yet, there is no better time than the present to correct your mistakes. Battle.net MUST change. It must change significantly. I have only listed a few of the editor-related features that will directly harm developers, but the system as a whole is greatly flawed and, frankly, laughable. Blizzard has constantly touted being willing to cut and redo everything but have been so reluctant to change or remove anything in sc2 I find their previous statements hollow. I think the sc2 side of Blizzard needs to take a time out and read a page from the WoW dev team.

One the first things I was told when I got into this business* was that game designers have to learn, if you'll excuse the expression, to be able to kill their babies. We thought the old design was starting to hold us, and you, back.

http://forums.worldofwarcraft.com/thread.html?topicId=24038831405&pageNo=2#21


The editor

Within Blizzard's opportunity is the capacity to fix Battle.net and, more importantly, make the editor all it can be. They need but put effort into it. The editor is best seen as a foundation right now, ready for supports and construction to create the tool developers will be able to use in the future to create custom content. The groundwork is laid out but it needs engineering and planning to begin building the real thing.

Actordata and Modeldata

The two most important aspects of custom units are those involving the graphics and the physical functions of the unit, being modeldata and actordata. These are two reasonably complicated files that, currently, are a complete and total pain in the ass to do even the most basic things with. This is in part because they are complex subjects and also in part because the interface for them compounds the complexity issue ten fold.

Luckily for us, and Blizzard, there's an easy way to get around this. The editor already contains a model viewer - this could easily be copied and modified into a real-time preview editor for actors and models, probably even Movers as well. By simulating game events with the viewer, the editor can provide a level of fine control previously only reserved for things like the RPGMaker series and Age of Wonders 2. This seems to be the natural course of evolution and it's a wonder few games have attempted this in the modern market. No, I know why - developers are lazy. But the hardest part is already out of the way for Blizzard.

Animation editing is a tricky business, but perhaps Blizzard might consider making a simple scripting language for actordata. Something like what they employed for the iscript in Starcraft 1.

Spoiler

Code: Select all

# ----------------------------------------------------------------------------- #
# This is a decompile of the iscript.bin file 'C:\Documents and Settings\Ascherzon\My Documents\Data\_Armaggedon Onslaught\Armageddon Onslaught\iscript.bin'
# created on: Thu Apr 09 03:25:25 2009
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #
# This header is used by images.dat entries:
# 356 TerranBeacon (terran\tMarker.grp)
.headerstart
IsId           	213
Type           	26
Init           	TerranBeaconInit
Death          	TerranBeaconDeath
GndAttkInit    	TerranBeaconGndAttkInit
AirAttkInit    	TerranBeaconAirAttkInit
SpAbility1     	[NONE]
GndAttkRpt     	TerranBeaconGndAttkInit
AirAttkRpt     	TerranBeaconAirAttkInit
SpAbility2     	TerranBeaconSpAbility2
GndAttkToIdle  	TerranBeaconGndAttkToIdle
AirAttkToIdle  	TerranBeaconGndAttkToIdle
SpAbility3     	[NONE]
Walking        	TerranBeaconWalking
Other          	TerranBeaconGndAttkToIdle
BurrowInit     	[NONE]
ConstrctHarvst 	TerranBeaconConstrctHarvst
IsWorking      	[NONE]
Landing        	[NONE]
LiftOff        	[NONE]
Unknown18      	[NONE]
Unknown19      	[NONE]
Unknown20      	[NONE]
Unknown21      	[NONE]
Unknown22      	[NONE]
Unknown23      	[NONE]
Unknown24      	[NONE]
Burrow         	TerranBeaconBurrow
UnBurrow       	TerranBeaconUnBurrow
Unknown27      	[NONE]
.headerend
# ----------------------------------------------------------------------------- #

TerranBeaconInit:
	imgul09        	357 251 251	# TerranBeaconOverlay (terran\tCirGlow.grp)
	playfram       	0
	waitrand       	1 4
TerranBeaconGndAttkToIdle:
	playfram       	136
	wait           	2
	playfram       	153
	wait           	2
	playfram       	170
	wait           	2
	playfram       	187
	wait           	2
	playfram       	204
	wait           	2
	playfram       	221
	wait           	2
	playfram       	238
	wait           	2
	playfram       	255
	wait           	2
	goto           	TerranBeaconGndAttkToIdle

TerranBeaconDeath:
	playsnd        	207	# Terran\CIVILIAN\TCvDth00.WAV
	imgol08        	333 0 0	# TerranBuildingExplosionmedium (thingy\tBangL.grp)
	wait           	1
	end            	

TerranBeaconGndAttkInit:
	__1e_condjmp   	25 TerranBeaconLocal00
	nobrkcodestart 	
	playfram       	0
	wait           	1
	playsnd        	205	# Terran\CIVILIAN\TCvYes03.WAV
	playfram       	17
	wait           	2
	playfram       	34
	wait           	2
	playfram       	51
	wait           	2
	playfram       	68
	wait           	2
	playfram       	85
	wait           	2
	playfram       	102
	wait           	2
	playfram       	119
	attack25       	1
	wait           	1
	attack25       	1
	wait           	1
	attack25       	1
	wait           	1
	playfram       	136
	nobrkcodeend   	
	gotorepeatattk 	
	goto           	TerranBeaconGndAttkToIdle

TerranBeaconLocal00:
	nobrkcodestart 	
	imgol08		56  0	-5
	playfram       	0
	wait           	1
	playsnd        	204	# Terran\CIVILIAN\TCvYes02.WAV
	playfram       	17
	wait           	1
	playfram       	34
	wait           	1
	playfram       	51
	wait           	1
	playfram       	68
	wait           	1
	playfram       	85
	wait           	1
	playfram       	102
	wait           	1
	playfram       	119
	playsnd        	206	# Terran\CIVILIAN\TCvYes04.WAV
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	turnccwise     	2
	attack25       	2
	wait           	1
	playfram       	136
	wait           	1
	playfram       	153
	nobrkcodeend   	
	gotorepeatattk 	
	ignorerest     	
	goto           	TerranBeaconGndAttkToIdle

TerranBeaconAirAttkInit:
	nobrkcodestart 	
	playfram       	0
	wait           	1
	playfram       	17
	wait           	1
	playfram       	34
	wait           	1
	playfram       	51
	wait           	1
	playfram       	68
	wait           	1
	playfram       	85
	wait           	1
	playfram       	102
	wait           	1
	playfram       	119
	attack25       	1
	wait           	1
	attack25       	1
	wait           	1
	attack25       	1
	wait           	1
	playfram       	136
	wait           	1
	playfram       	153
	nobrkcodeend   	
	gotorepeatattk 	
	goto           	TerranBeaconGndAttkToIdle

TerranBeaconSpAbility2:
	playfram       	0
	nobrkcodestart 	
	playfram       	0
	wait           	1
	playfram       	17
	wait           	1
	playfram       	34
	wait           	1
	playfram       	51
	wait           	1
	playfram       	68
	wait           	1
	playfram       	85
	wait           	1
	playfram       	102
	wait           	1
	playfram       	119
	castspell      	
	wait           	1
	playfram       	136
	wait           	1
	playfram       	153
	nobrkcodeend   	
	gotorepeatattk 	
	sigorder       	2
	goto           	TerranBeaconGndAttkToIdle

TerranBeaconWalking:
	move           	5
	wait           	1
	playfram       	272
	move           	5
	wait           	1
	playfram       	289
	move           	5
	wait           	1
	playfram       	306
	move           	5
	wait           	1
	playfram       	323
	move           	5
	wait           	1
	playfram       	340
	move           	5
	wait           	1
	playfram       	357
	goto           	TerranBeaconWalking

TerranBeaconConstrctHarvst:
	playfram       	272
	goto           	TerranBeaconLocal01

TerranBeaconLocal01:
	wait           	125
	goto           	TerranBeaconLocal01

TerranBeaconBurrow:
	imgol08        	423 0 0	# Unknown423 (thingy\bDust.grp)
	playfram       	204
	wait           	1
	playfram       	221
	wait           	1
	playfram       	238
	wait           	1
	playfram       	255
	wait           	1
	playfram       	272
	wait           	1
	sigorder       	4
	goto           	TerranBeaconLocal01

TerranBeaconUnBurrow:
	waitrand       	1 5
	imgul09        	423 0 0	# Unknown423 (thingy\bDust.grp)
	playfram       	255
	wait           	1
	playfram       	238
	wait           	1
	playfram       	221
	wait           	1
	playfram       	204
	wait           	1
	sigorder       	4
	goto           	TerranBeaconGndAttkToIdle

All of the source iscript code for Armageddon Onslaught is included in the mod's release package - http://www.campaigncreations.org/starcraft/armageddon_onslaught

Making these two files accessible is key to improving the overall user experience in creating custom assets and applying them ingame. But if Blizzard truly does care about the editor they will go above and beyond to provide the means to really get into the thick of these files without having a clunky interface to complicate the process.

Key functions of the new graphical actor editor should be an easy way to determine new events with only 1-2 clicks. Being able to insert a preset event - such as a sound - without any typing or external dialogues. You don't need to dumb down an editor to make it easy to use and intuitive.

[imgwh 640x767]http://img411.imageshack.us/img411/5532/edg1.jpg[/imgwh]
The AoW2 unit body editor (effectively a modeldata-esque editor)

This editor is not very powerful, but it's very quick and easy to use, and gets you where you want to go quickly. This is what I'd like to see in sc2 - an organized, intuitive, and streamlined interface where functions are obvious and quick to learn.

The key to making an editor as powerful as the one necessary for Actordata but as easy to use as this one lays entirely in how you arrange and manage the interface, and how you present it to the end-user. Enormous clusters of unrelated options like what we see commonly throughout many editors, sc2's included, bombards new users with unknowns and overwhelms them, as well as making finding exactly what you want annoying and time-consuming for more advanced and experienced users. This plays back into the first part where I talk about tabs and categorization. Speaking of which, tabs were added in patch 13, though the organization remains non-existent. At least they're updating the editor! Hopefully they continue to improve it for many years and don't abandon it like they did wc3. This editor still has a very long ways to go to.

[imgwh 640x388]http://img257.imageshack.us/img257/2374/62769663.jpg[/imgwh]

Although not as graceful as as the AoW2 editor, the RPGMaker XP animation editor for spell effects and the like is another good example of a functional and fairly clearly interface. It is not necessary to jump into an external dialogue for adding SFX files, though unlike AoW2 this editor doesn't support multiple animations per entry (aka not a unit editor).

[imgwh 640x388]http://img718.imageshack.us/img718/2718/39088999.jpg[/imgwh]

Also worth showing is the RPGMaker XP monster editor, as another source of reference of a good, clean interface for editing units.

Doodads

Doodads need to have their own editor. Additionally, they need to have a way of telling the editor which doodads to randomize in the placement tool without having to copy all of their assets around and make new entries. I wanted to place trees without placing palm trees and then manually changing them but such is a pipedream without bending over backwards. I also had a fun time trying to find doodads until I discovered the actordata IS their editor... which seems a bit weird.


Sound data editor

The preview function doesn't play any sounds for me in this in any of the menus. Otherwise, though, I like it. Clean, simple, to the point. One of the few things in the editor I actually like.

I will talk about sounds in the future.

Additional points by other users

- Maps are sorted by popularity, with (currently) no way to sort them otherwise. There may never be. Or popularity sort may be the default way. This means your fledgeling new map will be on page 371 of the map list and will simply have nobody joining. And because nobody joins, it will never get more popular.
IN WAR3: maps were equal on the game screen. Just wait a while and people will join.

- The much hyped keyboard controls are unusable online due to some sort of built in lag far beyond the 150ms default lag. It takes about a second for your unit to respond. That Starcraft Ghost map at Blizzcon? The top down shooter? Both maps are completely impossible in the actual game, only if you test them locally in the editor. (Bonus fact: they said there would be mouse control, but no - you can't lock the camera to a unit or even move it under mouse control so it's useless)
IN WAR3: keyboard controls were clunky, but not in this way. Not in this way.

Regarding Galaxy code -

Spoiler

Concerns about the Galaxy language

Hello, I have some concerns about the Galaxy language after examining data from the StarCraft II beta. First off, this list only contains issues which are not easily fixable with a preprocessor or a higher level language, some of it are just guesses which may or may not be wrong.

Dynamically allocated records
There is an error which implies that this isn't supported. This is quite an important issue since if this isn't supported it renders garbage collection, records and pointers pretty much useless.

You can't reference a record before it's defined
You fixed the chicken and egg problem with functions, please do the same for records.

Garbage collection
I don't know if and how garbage collection will work in Galaxy, but I'm confident you will screw it up anyway.

Function pointers
There doesn't seem to be any sign of function pointers. However TriggerCreate references to functions be strings, which is bad news, if Galaxy supports function pointers or not. If Galaxy doesn't support them (I'd slap the idiot who suggested that), I'll pray that there will be a way to execute triggers directly in the same and a new thread.

Fixed point arithmetics
Fixed point arithmetics, while good in certain scenarios can cause problems with doing more complex calculations. There doesn't seem to be alternative float type you can use to avoid the problems.

If you want to read more about my findings with Galaxy, I suggest you visit this thread: http://www.wc3c.net/​showthread.php?t=1090​11 (Viewing requires registration for some reason)

I have some additional concerns after studying the language and API further.

Associative arrays
This is a very important structure, which allows you to attach, e.g., a structure to a unit. In JASS2, the "return bug" was utilized to get an integer from a native type which was used as an index into an array, or previously as an string to a gamecache entry. This allowed you to construct an associative array. When the return bug was fixed, new natives was introduced (thank god Vexorian managed to convince you!) to replace that specific use of the return bug.

Galaxy has a more advanced type system with structures and pointers, which basically means it has a infinite number of types. Creating natives to return a index for a subset of these types would be a bad solution. You could however:
- allow every scalar value to be typecasted to an integer. We could use the integer as an index to a fixed size hashtable. This may however perform bad in a poor VM (which is probably the kind Galaxy will get).
- add a new type to the language which syntax similar to an array, e.g. int[string] map, which would be a mapping from integers to strings. You could use it in code like map["hello"​] = 3.

These two solutions are rather unclean and mess up the language. A much better solution would be to implement boxing (see http://en.wikipedia.​ org/wiki/Boxing_(comp​uter_science)). This would add a new native type which you could call 'object' or 'box'.
A box would contain a value of the type of this value. The type should be reduced to a simple integer ID at compile time to allow quick comparison of types. You could then for example box an object by doing this:
object b = 5;
This could be represented by by an opcode 'box', e.g., box(5, int) -> b, where int would be an integer representation of the type. Unboxing could be done like this:
int i = b;
This could be represented by by an opcode 'unbox', e.g. unbox(b, int) -> i. If you tried the following:
unit u = b;
This would result in unbox(b, unit) -> u. The unbox opcode would compare the type stored in the box b (int) to the argument in the unbox (unit), if they don't match (like now) it should raise a runtime error.

Now you could simply add a type and some natives to implement a map, here is an example for such natives:
native map MapCreate();
native void MapClear(map m); // Removes all the key/value pairs in the map.
native bool MapCompare(map a, map b); // Returns true if all the key/value pairs of map 'a' is equal to all the key/value pairs of map 'b'.
native void MapMerge(map m, map other); // Overwrites the key/value pairs in 'm' with those in 'other'.
native void MapSet(map m, object key, object value);
native object MapGet(map m, object key); // This should raise a runtime error if the key doesn't exist.
native bool MapHasKey(map m, object key);
native void MapFindValue(map m, object value, object *result); // Sets variable 'result' to the key if a key with the value 'value' was found. Sets the variable 'result' to null if no keys with the value 'value' was found.
native bool MapDeleteKey(map m, object key); // Returns true if the key was found and thus deleted.
native void MapDestroy(map m);


API Design
Native functions should not use function pointers unless absolutely required. In the case that it's required (events/timers), you should be able to pass along a boxed type to reduce the need for associative arrays.

The native functions that work on groups should not use function pointers. Here is some examples of possible ways to loop over a group:
unit *u = UnitGroupFirst(group​);
while(u) {
RemoveUnit(*u);
u = UnitGroupNext(group, u);
}

object u = UnitGroupFirst(group​);
while(u) {
RemoveUnit((unit)u);
u = UnitGroupNext(u);
}

int i;
int count = UnitGroupCount(group​);
while(i < count) {
RemoveUnit(UnitGroup ​Unit(group, i);
i += 1;
}

You seem to have gone with the last approach, which is basically a dynamic array of units. So why not implement a dynamic array instead, and get rid of those group types?
Here is an example of natives to represent a dynamic array:
native array ArrayCreate();
native bool ArrayCompare(array a, array b); // Returns true if all the elements of array 'a' is equal to all the elements of array 'b'.
native array ArrayConcat(array a, array b); // Adds the elements of array 'b' to the end of array 'a'.
native array ArrayRange(array a, int start, int stop); // Returns the elements from start to stop as a new array.
native int ArraySize(array a);
native void ArrayResize(array a, int size);
native object ArrayGet(array a, int index);
native void ArraySet(array a, int index, object value);
native void ArrayInsert(array a, int index, object value);
native int ArrayPush(array a, object value); // Adds the object to the end of the array. Returns the number of elements in the array after the addition.
native object ArrayPop(array a); // Removes and returns the object at the end of the array.
native bool ArrayFind(array a, object value); // Returns true if the object was found.
native void ArrayDelete(array a, int index);
native bool ArrayRemove(array a, object value); // Returns true if the object was found and removed.
native void ArrayDestroy(array a);

Now if dynamic arrays are added, you could extend the map natives with a few convenient functions:
native array MapKeys(map m); // Returns an array of all the keys.
native array MapValues(map m); // Returns an array of all the values.

Not all the natives I've listed here for arrays or maps would be required, but having the most common usage patterns as natives will help speed up and clean up the code.


The difference between string and text types
Strings in JASS2 was fairly limited. They were string table based (a leaking one at that!). There wasn't many operations to perform on them and they were slow. This begs the question, why are there two string types in Galaxy? It seems like the text type is used when text is needed to be displayed on screen, this suggests that text types are internally optimized to be displayed on screen somehow and are possibly still string table based. Let's hope that neither the string or text leaks memory or are too slow.


Pointers
Currently null pointers does not raise a runtime error when dereferenced. This is obviously quite bad and should be fixed. It's also weird that you can't take a pointer of a constant, maybe you should use a read-only data section if you want these to stay constant?


Function pointers
Apparently (*(&function))()​; is a valid syntax, but it generates a runtime error and I can't find out the syntax for that type. Either you aren't done taking out the functionality of a C parser/compiler, or it's still work in progress. I'm hoping it's the latter one.


Dynamically allocated records
Records (or structs if you like) could be allocated with the new operator. So you could do:
structure *a = new structure;

Deletion of dynamic records could be done with:
delete a;

This would require a runtime check to make sure you aren't trying to delete anything on the heap or stack. Extra points are given if you can allocate arrays and native types the same way.


Opcode limit/execution limit
Ever heard of threading?
This limit should be put as high as possible or simply removed.


Performance
Galaxy has the potential to be just as fast as C. However that is not a realistic goal since C programs tend to be very well optimized using relativity slow state of the art compilers. You can't compile Galaxy code and store it in a map (not the whole process anyway). It would not be safe nor portable to store x86 code there. You either need to store the bytecode there (which reduces loading times, but it's more work) or compile the code when the map is loaded. Either way the best way to give Galaxy decent performance would be to write (or reuse) a JIT compiler. Even a trivial JIT for x86 lacking stuff like register allocation would provide a substantial performance increase over a bytecode based VM and is relativity simple to write. However if you want to port StarCraft II to other architectures (PPC, x86-64 springs to mind), or you want to combine it with a decent garbage collector you will be better off using a library. I do hope that it at least performs better than the JASS2 VM did.

I've been testing and benchmarking the runtime further and I have some more input.

Performance
Galaxy seems to have fairly poor performance. Here is some benchmarks comparing it to Ruby which is regarded as a rather slow language:
- Linear graph: http://img697.images​ hack.us/img697/175/ga​laxybench1.png
- Logarithmic graph: http://img444.images​ hack.us/img444/450/ga​laxybenchlog1.png

Strings are still interned, but they don't seem to leak and they don't have the terrible performance of JASS2 (although I wouldn't call them fast).

Opcode limit/execution limit
The opcode limit seems to be around 20 times of JASS2's one, but that still only allows computation for around 200 ms. The opcode limit mostly limits what can be done while loading the map or in other appropriate situations, you don't want to play a map that constantly freezes for 200 ms, but then again I'd much rather have the map freeze for a while rather than ruining the game. If a map wanted to intentionally freeze StarCraft II, some computations and a Wait call effectively achieves that.


Type-safety
Pointers to stack variables of executed functions is persists after the function returns (more return bugs, yay!). This means you can change the value of new stack variable should they reside the in same location. You can even replace the return address to implement some goto like behavior. However, Blizzard seems to have added a lot of runtime checks to reduce the possibilities for arbitrary code execution, but they don't actually fix the issue.

The simplest and fastest solution to this problem is to implement a tracing garbage collector and allocate local variables which gets referenced on the heap, but I doubt that will happen.

Another solution would be to tag every value on the heap and the stack. This is similar to the boxing type except all values are tagged and all pointer dereferences are checked to make sure they get or set a value of the right type. You could either use two separate heaps and stacks or store pairs of a type and a value in a single heap and stack. Using separate heaps and stacks may be more secure, but it's likely slower due to cache effects and you need to calculate the offsets of the pointers into each area. With a single heap and stack, pointers can be absolute and a simple addition is enough to find the position of the other type or value. This might seem like a lot of overhead, but it will likely perform better than Blizzard's naive checks and actually solve the issue.


Function pointers/closures
Closures are extremely handy when doing event-driven programming, which is what Galaxy will be used for, so this is a must-have feature. Closures should have the same syntax as function pointers and be interchangeable with them. Closures should be able to nested and they should be garbage collected. With a tracing garbage collector implementing closures is trivial, without one, you'll need to implement reference counting to keep track off the local variables which are stored on the heap. Hopefully, Blizzard has already written this to track handles, so they could probably reuse that. If closures were implemented, natives taking function pointer arguments wouldn't need an extra parameter for passing values.

Here is some suggested syntax for closures:
int calc(int value) {

return 4 / value;

}

void run() {

int i = 2;

int(int) func;

func = int(int value) { return value + i; }; // Assign a closure to the function pointer.

func = calc; // You should be able to assign regular functions too.

print(IntToString(cl​osure(2))); // Should print 2.

}

My points about
- dynamically allocated records,
- you can't reference a record before it's defined,
- garbage collection,
- pointers,
- type-safety
have elegantly been resolved in patch 9 by the removal of pointers altogether.

To be updated in the future.