Still Alive is back in business! I'm not going to explain what I've been doing for the past few months, since you probably wouldn't forgive me...
I have the basics of the item/inventory system done, but apart from a test item, still missing the actual items. The inventory currently has 15 slots, and items don't stack. This means you can carry at most 15 items at a time, but I might change the limit depending on how many items there will be hanging around later on. Items can be dropped on the ground, but I'm not yet sure if I need to make them decay over time because of engine limits. If there's going to be hundreds of items lying around, it might slow down the game. Dropping and using items are implemented as unit abilities, so they have hotkeys assigned. Selecting items still needs to be done by clicking on their icons, which are constantly visible on the screen.
Just now I've implemented stats: Health, Hunger and Sanity. Health... is health, and regenrates slowly over time. It can also be restored by some items yet to be decided on. Hunger increases over time (the bar goes down, for consistency), and once it reaches zero, you start losing health. Hunger keeps the players exploring to find food, and encourages them to split up so they can find it faster. Sanity is lost when near enemies (or other horrors) and in darkness, and gained near allies and in light. This encourages the players to stick together. Wicked, eh? When sanity reaches zero, the player starts suffering from insanity, which will have several consequences, although I haven't decided yet what they'll be.
I had an idea for the light system: Players have naturally short line of sight. If a player comes close to a lamp, the lamp shares its vision with the player, and the player is considered to be "in light". Otherwise he's considered to be in darkness. Areas outside the player's line of sight are constantly kept as black mask intead of the usual fog of war.
I'll post some visual media once I've made everything look a bit prettier than they are now.
I've been working on a little hide and seek map for a few days, and made a commentary video about it. The map isn't finished and some things will still change, but this should give you a pretty clear picture of what it's gonna be about. I also don't have a name for the map yet, so feel free to give me suggestions if you happen to come up with any.
Click the YouTube icon in the bottom right corner to watch it in HD.
I'm a huge fan of custom co-op maps, and I think they could be a lot more interesting if the enemies wouldn't just blindly attack-move on you and be done with it. What I'd like to see is that the computer controlled units would know how to use their abilities, how to kite certain units, and possibly even how to act as a larger group in an efficient way, etc.
Not many custom maps use the default Melee units, but I think they're being underused. Players already know what those units do and that works well for getting the players familiar with a new gameplay concept in a custom map. I'm proposing a project to create a configurable micromanagement AI library for most or all of the Melee units. It should also have some kind of an attack wave system and other ways to control the units as groups.
I don't know how much this is already explored and put to use, so it'd be nice if you could point me towards currently existing custom AIs that focus on unit microing. I've done some makeshift trigger AIs myself, but I'm not an expert. I'd be happy to work on a project like this, but I don't think I'd pull it off by myself well enough, so I need people who actually know something about creating script/trigger AIs.
The background and the foreground have too similar color shades, it almost looks like there's a transparent grey layer over the whole thing. I'd suggest making the background darker or the foreground brighter, or both.
I have a similar buff which causes an effect whenever my unit attacks. If the damage response modify field doesn't work for the attacker, then create an effect that applies additional damage and add it to the Damage Response - Handled field.
Create a buff behavior with Damage Response - Location set to Attacker, Chance to 0.2 (20 is 2000%), and Modify Fraction to 2 (which is 200%, or more if you want it to always kill with the shot). Then just give the behavior to any unit you want to have it.
@Ranakastrasz: Go
Thanks, that worked... somewhat. It gives the large blue full shield bubble thing instead of the small white shield impact effects, though, but it's better than nothing.
Center instead of Origin might work better as the attach point for some models.
All protoss units have a Shield attach point defined for their model, and others don't. Since 1.3.0 patch, units without a shield attach point started generating this error: "Could not find e_attachShield or a dynamic shield attach on unit with model Marine" (or whatever the model is). I'm using the story mode dependency, haven't tested with others yet. It all worked well before 1.3.0 and the shield impact graphics were even visible on non-protoss units, but now it just creates the error.
I narrowed the problem down to the "ProtossShieldFacer" actor. If I disabled the "ShieldImpact" actor from using that as the "Actor - Visual Directional Facer" value, the error stopped, but the shield graphics weren't obviously visible anymore. I tried looking at and changing the values of the ProtossShieldFacer actor, including deleting all actor events from it, but the error persisted.
Any ideas how to get the shield graphics show up again? Maybe the solution could be related to the "or a dynamic shield attach" part of the error? My hotfix is just using validator "Is Shield Capable" and "Is Protoss" for the ShieldImpact actor creation event instaed of just "Is Shield Capable", so the graphics still show for protoss units and not for the others, which cause the error.
Pocket Warriors is actually a good name, combines both aspects of being easily recognizable as a Pokémon clone and that they are SC2 characters rather than fluffy monsters.
What about making the game very open worlded, so we can explore the entire city, giving us something new everytime
That's the plan, though obviously there will be some areas that are more difficult or more dangerous to access to keep it interesting. There wouldn't be much point in generating a huge city if the players could only access a small part of it.
Uh, the world coordinates are 3D points, they aren't related to the GUI in any way. But no one said anything about anything being removed. I only said I don't know what they will add.
They are adding the ability to track mouse even when not clicking it, I'm just saying I don't know if they add the possibility to always get the mouse position using triggers or not. Currently it's only possible to get mouse X/Y position with the Mouse Clicked event.
0
Several Months Later...
Still Alive is back in business! I'm not going to explain what I've been doing for the past few months, since you probably wouldn't forgive me...
I have the basics of the item/inventory system done, but apart from a test item, still missing the actual items. The inventory currently has 15 slots, and items don't stack. This means you can carry at most 15 items at a time, but I might change the limit depending on how many items there will be hanging around later on. Items can be dropped on the ground, but I'm not yet sure if I need to make them decay over time because of engine limits. If there's going to be hundreds of items lying around, it might slow down the game. Dropping and using items are implemented as unit abilities, so they have hotkeys assigned. Selecting items still needs to be done by clicking on their icons, which are constantly visible on the screen.
Just now I've implemented stats: Health, Hunger and Sanity. Health... is health, and regenrates slowly over time. It can also be restored by some items yet to be decided on. Hunger increases over time (the bar goes down, for consistency), and once it reaches zero, you start losing health. Hunger keeps the players exploring to find food, and encourages them to split up so they can find it faster. Sanity is lost when near enemies (or other horrors) and in darkness, and gained near allies and in light. This encourages the players to stick together. Wicked, eh? When sanity reaches zero, the player starts suffering from insanity, which will have several consequences, although I haven't decided yet what they'll be.
I had an idea for the light system: Players have naturally short line of sight. If a player comes close to a lamp, the lamp shares its vision with the player, and the player is considered to be "in light". Otherwise he's considered to be in darkness. Areas outside the player's line of sight are constantly kept as black mask intead of the usual fog of war.
I'll post some visual media once I've made everything look a bit prettier than they are now.
0
I've been working on a little hide and seek map for a few days, and made a commentary video about it. The map isn't finished and some things will still change, but this should give you a pretty clear picture of what it's gonna be about. I also don't have a name for the map yet, so feel free to give me suggestions if you happen to come up with any.
Click the YouTube icon in the bottom right corner to watch it in HD.
0
I'm a huge fan of custom co-op maps, and I think they could be a lot more interesting if the enemies wouldn't just blindly attack-move on you and be done with it. What I'd like to see is that the computer controlled units would know how to use their abilities, how to kite certain units, and possibly even how to act as a larger group in an efficient way, etc.
Not many custom maps use the default Melee units, but I think they're being underused. Players already know what those units do and that works well for getting the players familiar with a new gameplay concept in a custom map. I'm proposing a project to create a configurable micromanagement AI library for most or all of the Melee units. It should also have some kind of an attack wave system and other ways to control the units as groups.
I don't know how much this is already explored and put to use, so it'd be nice if you could point me towards currently existing custom AIs that focus on unit microing. I've done some makeshift trigger AIs myself, but I'm not an expert. I'd be happy to work on a project like this, but I don't think I'd pull it off by myself well enough, so I need people who actually know something about creating script/trigger AIs.
0
The background and the foreground have too similar color shades, it almost looks like there's a transparent grey layer over the whole thing. I'd suggest making the background darker or the foreground brighter, or both.
0
Did you increase the shield radius enough? If it's too small, it appears inside the unit and can't be seen.
0
I have a similar buff which causes an effect whenever my unit attacks. If the damage response modify field doesn't work for the attacker, then create an effect that applies additional damage and add it to the Damage Response - Handled field.
0
Create a buff behavior with Damage Response - Location set to Attacker, Chance to 0.2 (20 is 2000%), and Modify Fraction to 2 (which is 200%, or more if you want it to always kill with the shot). Then just give the behavior to any unit you want to have it.
0
@Ranakastrasz: Go Thanks, that worked... somewhat. It gives the large blue full shield bubble thing instead of the small white shield impact effects, though, but it's better than nothing.
Center instead of Origin might work better as the attach point for some models.
0
I was able to see the shield impact graphics before 1.3.0 when it didn't give an error. Now I can't see them and it gives an error.
0
All protoss units have a Shield attach point defined for their model, and others don't. Since 1.3.0 patch, units without a shield attach point started generating this error: "Could not find e_attachShield or a dynamic shield attach on unit with model Marine" (or whatever the model is). I'm using the story mode dependency, haven't tested with others yet. It all worked well before 1.3.0 and the shield impact graphics were even visible on non-protoss units, but now it just creates the error.
I narrowed the problem down to the "ProtossShieldFacer" actor. If I disabled the "ShieldImpact" actor from using that as the "Actor - Visual Directional Facer" value, the error stopped, but the shield graphics weren't obviously visible anymore. I tried looking at and changing the values of the ProtossShieldFacer actor, including deleting all actor events from it, but the error persisted.
Any ideas how to get the shield graphics show up again? Maybe the solution could be related to the "or a dynamic shield attach" part of the error? My hotfix is just using validator "Is Shield Capable" and "Is Protoss" for the ShieldImpact actor creation event instaed of just "Is Shield Capable", so the graphics still show for protoss units and not for the others, which cause the error.
0
Pocket Warriors is actually a good name, combines both aspects of being easily recognizable as a Pokémon clone and that they are SC2 characters rather than fluffy monsters.
Try asking a moderator to remove the poll?
0
That's the plan, though obviously there will be some areas that are more difficult or more dangerous to access to keep it interesting. There wouldn't be much point in generating a huge city if the players could only access a small part of it.
0
No, it's still alive. Just having a little break from mapping altogether.
0
Uh, the world coordinates are 3D points, they aren't related to the GUI in any way. But no one said anything about anything being removed. I only said I don't know what they will add.
0
They are adding the ability to track mouse even when not clicking it, I'm just saying I don't know if they add the possibility to always get the mouse position using triggers or not. Currently it's only possible to get mouse X/Y position with the Mouse Clicked event.