Starcraft and Warcraft MOD sign up.

Main differences here include combat bug fixes and correct building construction and cancellation for all buildings.


- Multiple combat bugs fixed.

- The Zerg buildings will kill the constructing drone and spawn the drone if the building is cancelled.

- The Terran buildings building like Terran buildings, requiring SCV's.

- Morphing units now retain % of hp that their original unit had.

- Morphing units can be canelled to their prior form (or, in the case of larva->? morphs, the unit is killed).

- Buildings being morphed now correctly upgrade the building-unit on the plot.

- Changed mod options so that only scenarios are playable by the player ("Play Game" greyed out).

As always, files here.

Spoiler Full Changelog :

----------------------------------------------------------------------------
-----------------------------------------------------------------------------
v0.12:
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-------
Fixes:
-------

Fixed known bug: A unit held-up due to population doesn't start training until the turn after the population is available. (Originated in v0.06)

Fixed bug where errors will appear on someone's screen if they have no selected unit and another player in MP pops up the unit chooser.

Fixed bug where unit attacking with turn-attack mode would attack with all attack points left, even if they didn't have enough movement points.

Fixed bug where some units will attack even though they have no attack points, but because they are in a group with a unit that does.

---------
Changes:
---------

- Made building cancellation refund a percentage refund rather than full refund (75%).

- Cancelling the only building in a city destroys the city.

- Zerg buildings destroy drone on build and spawn drone on cancel.

- Terran building only builds with SCV constructing on the plot. The SCV can leave the building and keep it "stalled" until it or another scv comes and continues the build using the "Continue Construction" mission.

- Zerg eggs are now cancellable.

- Morphs now retain percent of HP from unit morphed from.

- Added functionality for morphing units to cancel back to their original form.

- Buildings start with small HP and HP slowly builds as it's building.

- Made mod only allow for non-public maps (This means that only scenarios will be allowed to be played. You'll notice that the "Play Game" function has been disabled on the main screen, so only the scenarios will be allowed. This DOESN'T mean that player-made maps will be unsupported. They will just have to use the "Mod=Civcraft SC" tag in the map file to ensure that it is playable in Civcraft).

- Changed implementation of global building prereqs (This shouldn't change anything, but is put here as a notice incase there is a global
building-prereq bug to pop up in the future, so now I know when it probably was introduced).

- Implemented building upgrades to update city name and building-unit w/ proper hitpoints. (Hatchery->Lair->Hive, Spire->Greater Spire).
 
Okay, I'm starting to work on the movement system (allowing for enemy units to coexist in a plot if they are of different types, etc.). However, I have a few things that should be dealt with...

Moving to attack a unit that is not within current range (single- or turn- attack only):

Typically, in order to attack a unit, you must move your unit within range, then commence the attack. This may cause uneeded strain on the user. So, if the unit is out of attack range, I would say allow the unit to give chase until it's within attack range, then attack. This works fine for destroy mode, but for single- or turn- mode, the user might be expecting to gain control of the unit the next turn.

1.) What if the enemy unit was further than a single turn's movement away? Should the control still be returned during the next turn, even if the enemy unit never was attacked?

Moving to a plot with an enemy.

It will be completely possible to move into plots with enemy units that are of opposite domain than you. A SCV can enter the plot of an enemy overlord, and vice-versa, but an SCV cannot enter a plot that contains an enemy drone. This will make sure that a user can not "block off" their base with air units at a choke-point, while allowing their own units to move freely.

BUT:

2.) Can an air unit enter the plot of an enemy air unit? You would still be able to attack it using a targetted-attack, so it wouldn't be invincible, but it might be confusing as players could "hide" a unit in a stack of another players units, if the other player isn't careful. I'd hate to see players have to manually check all of their stacks. Perhaps a box could outline any plot that has a mixture of friendly and enemy units on the map?

Another question to this degree: Imagine a marine right-clicks to attack an enemy overlord. It's completely possible for that user to actually want the marine to just move to that space (perhaps the overlord is sitting on the terran player's choke-point, and the player actually just wants to move the marine there to block zerglings from getting into the base). Using right-click, the marine would just fire on the overlord.

3.) Would something like a shift-click alleviate this, saying that if you shift-click a plot, even if there are enemies there, the unit will move towards that plot rather than attacking? Would this shift-click work if the unit would not be able to move into this destination plot? Using the example above, would the marine be able to shift-right-click to move towards the plot rather than attack the units in the plot if there was also a hydralisk there? If so, where does the marine end up? One plot short? Or should the shift-click only be available when the unit can actually enter the plot?


Group-attacks.

Note that for terminology, a "stack" is all the units on the plot, whether they are selected or not, where a "selection group" is a group made by selecting various units on a plot.

Imagine of the two units in the same selection group, only one can attack the targetted unit from the current range. So, a marine and a firebat are both selected in the same selection group and a single-attack order it given to a unit on a plot two tiles away. The marine is within range to attack, the firebat is not.

4.) Should the two units seperate so the one that needs to travel can do so to attack (i.e. the marine attacks, the firebat leaves the group, moves the required distance, then attacks)? Should the two units move together to the plot where the closest unit can attack (both the firebat and marine move to where the firebat can shoot from, then they both attack)? Should the units stay still, only allowing the units that can attack from that distance to actually attack (the marine fires, the firebat does nothing)?

Similar question. Imagine we have that key combo I discussed earlier where you can shift-right-click a plot that you can travel to with an enemy unit on it to move to that plot rather than attack the enemy.

5.) What if your selection group has one unit that can move to that plot and another that can't? Say, a marine and a wraith try to move to a plot with a zealot. The Wraith would be able to, but the marine would not. Would the two seperate, and if so, what would each do? Should that shift-right-click mode even be available to the selection group if one of the units in the selection group can not support it?
 
Gerikes said:
Moving to attack a unit that is not within current range (single- or turn- attack only):

Typically, in order to attack a unit, you must move your unit within range, then commence the attack. This may cause uneeded strain on the user. So, if the unit is out of attack range, I would say allow the unit to give chase until it's within attack range, then attack. This works fine for destroy mode, but for single- or turn- mode, the user might be expecting to gain control of the unit the next turn.

1.) What if the enemy unit was further than a single turn's movement away? Should the control still be returned during the next turn, even if the enemy unit never was attacked?
Well in starcraft the unit, once clicked on another unit will follow it but once cliecked on an enemy unit, it will also follow it until it goes into the Fog of war (black sheep wall :lol: ) Soo i think we should have them follow the unit unless either changed by user or enemy went into fog of war.
that reminds me, Should we add the Cheats of the original Starcraft???? It would be hilarious. We could use the talk box, if its in Single player, but for multi player, there should be no cheats.

Gerikes said:
Moving to a plot with an enemy.

It will be completely possible to move into plots with enemy units that are of opposite domain than you. A SCV can enter the plot of an enemy overlord, and vice-versa, but an SCV cannot enter a plot that contains an enemy drone. This will make sure that a user can not "block off" their base with air units at a choke-point, while allowing their own units to move freely.

BUT:

2.) Can an air unit enter the plot of an enemy air unit? You would still be able to attack it using a targetted-attack, so it wouldn't be invincible, but it might be confusing as players could "hide" a unit in a stack of another players units, if the other player isn't careful. I'd hate to see players have to manually check all of their stacks. Perhaps a box could outline any plot that has a mixture of friendly and enemy units on the map?

Another question to this degree: Imagine a marine right-clicks to attack an enemy overlord. It's completely possible for that user to actually want the marine to just move to that space (perhaps the overlord is sitting on the terran player's choke-point, and the player actually just wants to move the marine there to block zerglings from getting into the base). Using right-click, the marine would just fire on the overlord.

3.) Would something like a shift-click alleviate this, saying that if you shift-click a plot, even if there are enemies there, the unit will move towards that plot rather than attacking? Would this shift-click work if the unit would not be able to move into this destination plot? Using the example above, would the marine be able to shift-right-click to move towards the plot rather than attack the units in the plot if there was also a hydralisk there? If so, where does the marine end up? One plot short? Or should the shift-click only be available when the unit can actually enter the plot?
2) As for the air units, I think they should attack if entered enemy unit territory but if Enemy is defenseless, then the Enemy unit moves to a different tille right away. As for identifying diferent Alliances in a Tile, we should have something that shows Green for Every freindly and Red for every Enemy (even multiple rtaces in one tile.) We should have this on the radar and some kind of indicator on the actual tile. Another thing, Lets say a Siege tank goes on the same tile as a Corsair, Nothing should happen.

3) well have to play test and see which ways efficient.

Gerikes said:
Group-attacks.

Note that for terminology, a "stack" is all the units on the plot, whether they are selected or not, where a "selection group" is a group made by selecting various units on a plot.

Imagine of the two units in the same selection group, only one can attack the targetted unit from the current range. So, a marine and a firebat are both selected in the same selection group and a single-attack order it given to a unit on a plot two tiles away. The marine is within range to attack, the firebat is not.

4.) Should the two units seperate so the one that needs to travel can do so to attack (i.e. the marine attacks, the firebat leaves the group, moves the required distance, then attacks)? Should the two units move together to the plot where the closest unit can attack (both the firebat and marine move to where the firebat can shoot from, then they both attack)? Should the units stay still, only allowing the units that can attack from that distance to actually attack (the marine fires, the firebat does nothing)?

Similar question. Imagine we have that key combo I discussed earlier where you can shift-right-click a plot that you can travel to with an enemy unit on it to move to that plot rather than attack the enemy.

5.) What if your selection group has one unit that can move to that plot and another that can't? Say, a marine and a wraith try to move to a plot with a zealot. The Wraith would be able to, but the marine would not. Would the two seperate, and if so, what would each do? Should that shift-right-click mode even be available to the selection group if one of the units in the selection group can not support it?

4) Well I think the option to where the marine gets in range to attack but at the same time stays with the firebat is the best bet. If we can play test, we will see the best way, or wee can allow the player to choose the mode.
5)Again we have to playtest and see the best option but maybe the idea of seperation is the most relistic. In the Game Starcraft, a Vulture with a Goliath, and you tell them to move to a cetain place, a Vulture will get there first, but if not with the goliath, then it will be an easier target, rather than moving them together.
 
Killamike718 said:
Well in starcraft the unit, once clicked on another unit will follow it but once cliecked on an enemy unit, it will also follow it until it goes into the Fog of war (black sheep wall :lol: ) Soo i think we should have them follow the unit unless either changed by user or enemy went into fog of war.
that reminds me, Should we add the Cheats of the original Starcraft???? It would be hilarious. We could use the talk box, if its in Single player, but for multi player, there should be no cheats.

I was thinking of doing that, it would at least help with debugging some. I'm sure at some point.

2) As for the air units, I think they should attack if entered enemy unit territory but if Enemy is defenseless, then the Enemy unit moves to a different tille right away.

Yeah, I hadn't thought of that. Then, would that unit's "runaway" movements be taken away from the actual unit? If so, I wonder if someone would want to, say, send their overlord in on a suicide mission because it has units in it, but when it's moving towards the heavily defended island it starts running away because it gets hit once or twice.

As for identifying diferent Alliances in a Tile, we should have something that shows Green for Every freindly and Red for every Enemy (even multiple rtaces in one tile.) We should have this on the radar and some kind of indicator on the actual tile. Another thing, Lets say a Siege tank goes on the same tile as a Corsair, Nothing should happen.

Right. I was thinking of putting a little red outline around any tiles that had enemy units as well as your own units in them. Putting the colors on the radar might be a good idea too, although I'm not exactly sure how to do this (also, I wouldn't be able to test it out too well, as my computer can never render the minimap correctly anyway :P)


3) well have to play test and see which ways efficient.

I think what I'll do is make right-click default as move, but attack if the end plot is an enemy plot, and if there's an enemy then it does the attack, but have the goto button in the unit's screen be "just move", even if the plot has an enemy in it (of course, it would fail to do so if the plot wouldn't be enterable, like the enemy unit is land and so is the unit you're trying to move.



4) Well I think the option to where the marine gets in range to attack but at the same time stays with the firebat is the best bet. If we can play test, we will see the best way, or wee can allow the player to choose the mode.

I'll see what I can come up with with allowing this to be an easy-to-set option.

5)Again we have to playtest and see the best option but maybe the idea of seperation is the most relistic. In the Game Starcraft, a Vulture with a Goliath, and you tell them to move to a cetain place, a Vulture will get there first, but if not with the goliath, then it will be an easier target, rather than moving them together.

Not exactly what I was asking, but that does bring up a more interesting point. In Civ4, the default action is that if two units are in a selection group with differing unit movements, then the faster of the units will slow down to stick with the slower. I had just assumed that we'd use that idea, but perhaps making that an option to test with also is a good idea.


So far, the main point is, make it all configurable. Some are going to be player-independent (what style of attack is done on a right-click), where some is going to be configurable so that when the game starts getting interesting, we can play-test and check it out, then make those the standards upon the release.
 
Killamike718 said:
Just a question: What if tow players, are playing online and have different settings, Will there be errors or will it work flawlessly?

For the things that will in the end be user-configurable items, there should be no errors. What happens is that the game determines using the user-configurable options what happens when, say, a right-click is entered. Right-clicks themselves are not events transferred to other games, but the action that happens is. That is determined on the machine the click happens, and then is transferred.

More of the options, like whether or not it's possible for two air units to enter the same plot, is something that all players will have to have set, and will probably be something that will be placed in the game options menu (if I can mod that, I'm not sure) or in an ini file, which while testing, we will make sure is all the same.
 
Well, all my hopes and dreams for player-configurable options are all but dashed. I haven't found any way to modify the PlayerOptions xml file. It seems no matter what I do, I run into the same problem where it will just load the default XML file, so I don't think we'll be able to easily have player-customized options.

This is too bad, because without it, multiplayer would be a lot tougher to make work, since every right-click would have to check options that may be different on every system. I was under the assumption that the player options were moddable, so felt that this wouldn't be a problem, but now I guess it will. I've made a thread in the main forums in case anyone knows any ways around the problem, but for now I'm going to put it in the back of my head and don't bring it out for awhile. If the problem can't be resolved, I'm probably going to default the right-click action to destroy mode, since that's just the easiest one to do.

Aside from that, ever since the job interview I completely bombed last week, I've been in a coding rutt. I've decided to take a week off (no more!) from coding, whether it be Civcraft or one of my other projects, and when I come back hopefully I'll have a fresh mind on things. I'll probably jump right into the add-ons, and after that upgrades. I don't think those will be too much trouble, so they'll be a good "welcome back" gift, as they'll be little work for a lot of change. I may even take a look at how FFH2 does their spell system aftewards, because they have an original spell xml file as far as I know, and I was hoping to do something like that.

However, that's all for next week. I'll still check the boards and all, but just no coding. I don't want to get burnt out being a programmer before even getting a job :lol:
 
Ah, it was a nice week to relax. Aside from twisting my ankle playing frisbee and questing w/ my friend on Neverwinter Night (hurray, my Druid Shifter!), I was able to relax while at the same time avoiding the glares of people who realized it odd that I still hadn't found a job. Good times.

Files located here, but you already knew that.

But more good times ahead, with this release! Actually, there are two basic changes, one that does nothing right now but took a bunch of code, and the other that does a ton and took little code. Funny that.

1.) Terran Add-on implementation. You can now build an add-on for those Terran building that have them. I would say you could even build a nuke, but because I haven't implemented spells yet, you'd be sorry to hear that you can't launch it. Since everything else done at Terran add-ons involves researching techs and upgrades (which will be implemented in the next version), add-ons don't really do much right now. So, I give you your fun update:

2.) Cheats! I've added some cheats which, to be honest, I can't believe I was living without while trying to debug. Having to go into the console and type a paragraph of code just to build a supply depot without having to wait for minerals to mine was a pain, but now they're here. They even work in multiplayer too (for now), so the debugging should be a lot easier. You might want to read the notes in the changelog for how to use them.

Spoiler Full Changelog :

-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
v0.13:
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------

-------
Fixes:
-------

- Protoss Building Shields as well as HP will increase slowly while the building is warping. (Previously, only HP would and shields would never rise from zero).

---------
Changes:
---------

- FINALLY consolidated the text files into one file with just Civcraft texts (I did not know I could do that until recently).

- Added addon buildings into XML (building, unit, and text keys).

- Addon buildings are constructed at the building's plot, with a unit specifically for the add-on (so enemies can target add-ons).

- When a city has an addon, the city selection buttons (train and construct buttons) for that city are "split" into the typical city selection buttons and the buttons for the addon.

- Removed Conscript, Hurry, Automate and Emphasize buttons from city screen interface (replaced with flag). There's no point in having them there any more.

- Added text to pop-up window of greyed-out units as to what buildings they need to be built.

- Added cheat codes :) Type these into the chat as is without quotes (note, all lowercase) to get them to work. Note that the message must be a "send to all" message, and the end result only works for the person who entered the cheat. Obviously, these will be removed from multiplayer at some point, but since they may prove useful to debugging they are part of multiplayer. You (and others in the game) should recieve a "Cheat enabled" message if it works. To turn off a certain cheat, re-type it into the chat to get the "cheat disabled" message.

"show me the money" - Adds 10,000 minerals and vespene gas to your coffers*
"operation cwal" - Everything takes one turn to build.
"food for thought" - Supply limits are ignored.
"power overwhelming" - God mode
"modify the phase variance" - Building prereqs are ignored.
"black sheep wall" - The entire map is revealed. Note that all members of the same team as the player with this cheat enabled will have the map revealed as well.

* Note: show me the money might cause a small out-of-sync error during multiplayer, but it should relieve itself in a matter of seconds, and the game will continue as usual.



Edit: Wow, I COMPLETELY forgot to make anything produced within add-ons cost you money. I guess I'll throw that in with v0.14 :P
 
Patrolling??????? My Fave Of Actions In Sc!!!! Where Is It???????

and whats with teh tech tree???? is it useless or do u actually use it at some point???? and can someone please lead me to a GOOD website that teaches me how to make graphics....
 
darkonion said:
Patrolling??????? My Fave Of Actions In Sc!!!! Where Is It???????

and whats with teh tech tree???? is it useless or do u actually use it at some point???? and can someone please lead me to a GOOD website that teaches me how to make graphics....

I imagine that a "patrol" mission shouldn't be too hard to make. Right now, I don't have any plans for the tech tree, although perhaps near the end we can convert it into the actual tech tree used (showing the buildings, for example). It wouldn't do anything, but you could open up the "tech tree" screen and use it as a reference.
 
Gerikes said:
I imagine that a "patrol" mission shouldn't be too hard to make. Right now, I don't have any plans for the tech tree, although perhaps near the end we can convert it into the actual tech tree used (showing the buildings, for example). It wouldn't do anything, but you could open up the "tech tree" screen and use it as a reference.

the tech tree as a refference on the order needed to build what would be nice... and it can also be used to let u get what updates u want... like the wraiths cloke...

and how are u goin to work out the bunker/cannon/sunken+spore thingys...?
 
darkonion said:
the tech tree as a refference on the order needed to build what would be nice... and it can also be used to let u get what updates u want... like the wraiths cloke...

and how are u goin to work out the bunker/cannon/sunken+spore thingys...?

Yeah. At the very least, you could use them to zoom in to various buildings.

And for the defensive buildings, I'm still not sure yet. The bunker will just be a container for the other units, but for the cannons/turrets/sunkens and spores, I'm really not sure. I was thinking just make them like other units to start, but that they can't move.
 
Latest version is out. Added armor and shield armor into the damage calculation. Also, all weapon/armor/moves/sight/max attacks/attack range upgrades are fully implemented. Some parts of the screen (specifically the plot lists) show these updates.

Also, Zerg HP regeneration (Zerg) and Protoss Shield regeneration was implemented.

Finally, two problems with the addons were fixed. The first involved addons not correctly reloading after a save, the second involves addon productions finishing in half the time that they're supposed to.

The most important thing, in my opinion, is that I've got everything off of my to-do list that I wanted done before I started implementing spells and special abilities. So, by the next update expect to be able to burrow, seige, parasite, ensnare, etc. It may not all be perfect, and the graphics obviously won't be there, but it should still add that last element of game in that should mean that it would be fully playable when that's all complete, there should be a small testing phase and then we can make one or two bug-fix updates and call it v0.2.

v0.2 will concentrate fully and wholeheartedly on figuring out a way to update to Warlords while keeping backwards compatability. Probably going to be more theoretical updates than actual code.
 
Nice job gerikes i think we might even be able to bump up the version to .5 even. Good news on the front for graphics, I found a New technique that might get the Unit animation to work, and get it into max, to export into the game, im gonna try it and see if it works wish me luck. Im also planning on Createing the base geometry for the Archon and dark archon, then we can have an effewct for the both of them to make them look like a circular fireball.
 
Killamike718 said:
Nice job gerikes i think we might even be able to bump up the version to .5 even. Good news on the front for graphics, I found a New technique that might get the Unit animation to work, and get it into max, to export into the game, im gonna try it and see if it works wish me luck. Im also planning on Createing the base geometry for the Archon and dark archon, then we can have an effewct for the both of them to make them look like a circular fireball.

Neato burrito!

I was thinking that for the archons we could use special effects (like how a city has fireworks when celebrating WLTKD) if the unit animation doesn't work well enough, but if you can pull it off all the better!

I was thinking about bumping to a little higher level because code-wise, we're much farthur along than 14% done. I'd say more to the realm of 60%. However, that's not the only thing obviously.

Also, what do we have for upgrade/research icons?
 
As for icons, I could make some but im not the best 2D artist, do you want to use the original type but give it that Civ button Style, or should we use the originals? or do we create super cool ones. Right now im actually finishing up the Dragoon and adding the Color map(texture) soo after that it will be 100% finished but still without its special effects(fireing its ball, and death blue blood). As for the Archons, i was thinking about doing the special effects. im gonna do it all till the plugin is finished. Good news and bad news, I can get animations into Max but they cant use bones, soo the dragoon will not be able to be exported into the game, but a unit like the Dropship, or Wraith or even the Batlle cruiser, we can get them in but i still need to do their animations and texture them, but we wont be able to have them deform when they get damaged. Soo there is hope for now, and after i completely finish the dragoon, ill begin on the others. and try to get them into the game.
 
Killamike718 said:
As for icons, I could make some but im not the best 2D artist, do you want to use the original type but give it that Civ button Style, or should we use the originals? or do we create super cool ones.

Well, I'm reluctant to use any graphics that come directly from Starcraft. We could probably pickup a artist on the forum who wants to do it. I like the idea of having one person do all the buttons because then you get that similar "theme", you know. Although at this point, I think we can just put what graphics we have and later on if something doesn't sit right we can try again. For example, some of the button units are a bit dark, so it's tough to tell if the button is greyed out or not. But, I'm not worried about that right now.

Another option would be for the unit upgrades to take a screenshot of a wireframe model of, say, a zealot. Then, convert that screenshot into a button (I think I have a basic idea of how to do that if I had the picture). Then, copy that picture three times over, and for each picture highlight a different part (say, in one highlight the blades, in the next highlight the armor, in the next highlight the "shield" that eminates around it). There would be three pictures for protoss ground weapons, ground armor and shields.

Right now im actually finishing up the Dragoon and adding the Color map(texture) soo after that it will be 100% finished but still without its special effects(fireing its ball, and death blue blood).

Neat! I'm looking forward to it!

As for the Archons, i was thinking about doing the special effects. im gonna do it all till the plugin is finished. Good news and bad news, I can get animations into Max but they cant use bones, soo the dragoon will not be able to be exported into the game, but a unit like the Dropship, or Wraith or even the Batlle cruiser, we can get them in but i still need to do their animations and texture them, but we wont be able to have them deform when they get damaged. Soo there is hope for now, and after i completely finish the dragoon, ill begin on the others. and try to get them into the game.

Sounds good. I don't think the deaths are too important right now, if we really want to we can make one "death special effect" that is like the fireworks display and just play it when a unit dies, and then later replace those with actual death animations.
 
I wouldn't be too reluctant to use graphics from starcraft. Artists are rare but more important you can't have better flavor for the mod. Even if you get assistance and someone would do the buttons you need they certainly won't give the same Starcraft/Warcraft feeling you get if you just "borrow" what you need. Anyway I doubt you get into trouble with that if you just make sure to have similar legaldisclaimers like approved fansites have.;)
 
Gerikes said:
Well, I'm reluctant to use any graphics that come directly from Starcraft. We could probably pickup a artist on the forum who wants to do it. I like the idea of having one person do all the buttons because then you get that similar "theme", you know. Although at this point, I think we can just put what graphics we have and later on if something doesn't sit right we can try again. For example, some of the button units are a bit dark, so it's tough to tell if the button is greyed out or not. But, I'm not worried about that right now.
I totally agree with you, I personally will leave the buttons for last and then if we get no artist till then ill work on all the buttons.

gerikes said:
Another option would be for the unit upgrades to take a screenshot of a wireframe model of, say, a zealot. Then, convert that screenshot into a button (I think I have a basic idea of how to do that if I had the picture). Then, copy that picture three times over, and for each picture highlight a different part (say, in one highlight the blades, in the next highlight the armor, in the next highlight the "shield" that eminates around it). There would be three pictures for protoss ground weapons, ground armor and shields.
I could take one picture of the wireframe and then with photoshop i can color each wire of frame appropriately and have MULTIPLE if not unlimited version for each unit. So if i supply you the images, is it possible to acutally get that feature in the game, like the yellow and red wireframe???

gerikes said:
Sounds good. I don't think the deaths are too important right now, if we really want to we can make one "death special effect" that is like the fireworks display and just play it when a unit dies, and then later replace those with actual death animations.
I was thinking more of a big explosion and the units disappears or it flies to the ground and crashes.
 
Back
Top Bottom