Last night was a refactoring hell, but the code is now much cleaner and more efficient. I changed the way my interact system works, which was previously done by an inefficient loop that checked distances between the player and the target. Now it's done using a smart-click ability which is then caught by triggers. Previously, items and monsters were spawned as units already when the map started, and now they are only spawned when any player enters the building for the first time during the game. This speeds up the building generation on map start by a little, but most notably it reduces the number of units that simultaneously exist in the map.
I considered slowing the enemies down so that they'd be slower than the player, but it just won't work. If they're that slow, they'll never get to do anything to the players and don't really pose as a threat. This isn't Resident Evil with endless masses of zombies blocking your way. To compensate this, I'll probably give the players more weapons than I originally planned. I need to redo some of the AI as well so that it's easier to flee by using shadows and corners to your advantage.
Before last night, I got my weapon system partially done, but it's since been slightly improved. Here's a short video of its first version:
Perhaps I'll make most zombies slower than the players, but add some tougher ones that need to be ran away from? And sprint needs to be a lot less efficient. The current version of it is just a Stimpack without the health cost, and I've just been using it for testing.
I'm currently working on the weapon system. Just got it to the point that weapons can't be fired through walls even if the player has vision through it.
The camera is now unlocked from the player, but can't be moved outside the indoor area. Outdoors the camera can be freely moved, so players can see what's happening to other players. And since the camera is unlocked, zooming is now possible.
Also, I modified the UI layout a bit. If required, the bars can be extended to the right, but I'll keep them limited to 10 slots for now.
@cookies4you: Go
That sounds a bit too fantasy for this, and death isn't supposed to be rewarding anyway. I don't want players to sometimes want to die. I think it's also not possible to block players from using the [All] chat?
I now have the light system working quite well, as I described earlier. I had to do a little trace line trick for checking the light's line of sight to the player but I don't think it's too performance-heavy. Now I just need to modify the building generators to spawn lights in reasonable spots (now they just spawn randomly around there). The lights behave as if they would turn on when the player comes near, and turn off when the player goes away. This means the players won't see the "light beams" through doors until they enter the room. But we can think of them as scifi lights that have a motion detector or whatever. :P
Update: Monsters can now follow players from building to building. The system is still missing the case when a monster is trying to move inside an unspawned building, but I think I'll fake it by just teleporting the monster out of there after a specific amount of time based on its direct distance to the door. No one sees what happens there anyway since it's unspawned... It should be just fine.
I'd like to add that not everything we discussed on IRC was "decided", just discussed. The item system for example might need to be changed if there would be too many items for the engine to handle simultaneously. In that case, I need to implement containers that work both ways; you can take items off and put them back. Items in containers wouldn't be actual units so that'd allow a far larger number of items to exist.
The current crafting ideas are just examples of what the system could be like. I think my approach will be first figuring out the interesting items I want in the game, and after that the crafting patterns and component items.
As an update from yesterday, I have a much neater inventory now. It keeps the items "compressed", removing all empty spaces between them. This enables an item being selected all the time, so that when you drop an item, the next item "falls back" in the inventory and becomes selected. If you drop the last item in the inventory, the selection itself falls back and the previous item in the inventory becomes selected. I also have a working food item now, which removes a bit of your hunger. From now, it'll be easy to add other items into the game as well.
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.
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.
@dra6o0n: Go
Continuously rescuing civilians for points would change the map into something completely different, taking it more towards the Lemmings style from survival style. The traits system could be a nice touch instead of just having characters with different numbers in their skills as I had planned it so far.
There are two ways to take the map to, both of which have gotten quite a lot of ideas and approval: The "death means death" mode where you lose your character when you die, and the mode where you preserve some of your characters attributes when you die and then get to respawn in some way. The latter could benefit from a character save/load system, and the death-means-death mode not so much.
A save/load system would also mean that the character development system was interesting enough over a long period of time to benefit from the save/load system to begin with. If you'd be just getting more and more traits over time, then eventually all characters would end up being the same. So it'd probably mean each trait would need its own level up system, like a character with Military Training would become better and better at using guns, and so on.
However, then some of the players would start with a more and more powerful character each time, and the game would have to be balanced for that, requiring me to create new content for the more powerful characters... The whole thing would become very chaotic considering that not all players would start the game with a character of the same level, and the game would also be more predictable if the character levels would mean enabling a different set of gameplay content.
For a "casual" game like this (compared to big MMORPGs which you might spend months or even years with), it seems to me that it's better to add replayability by creating various different kinds of random encounters and randomizing the city for each game, so you never know which of the possible variations you'll be getting into when starting the game. Considering all this, I don't really see the usefulness of the save/load system even for characters, because I don't have the will to spend so much time balancing the gameplay for progressively improving characters.
The traits system can still fit into this, but only by using them as static attributes which instantly tell you what the character is good at and which skills he can improve faster than others. Still one more possibility to use a save/load system for is that the more times you have beaten the map, the more choice you have for what kind of starting character you get, otherwise being completely random. First you'd be able to choose one of your perks, then the rest, then the point distribution into each of your skills, and eventually even the starting equipment you have.
Maybe I have a bit different idea of what an RPG means to some of you, but in this case I'm mostly referring to the style of gameplay with it, not everything related to a game where you assume the role of a character and emphatize with him/her like maybe in some pen & paper RPGs. There's no point spending months into developing original lore for a map which people will play for a few hours.
Seesh, just calm down everyone. :P I'm not getting insulted by any of this, so no need to feed the trolling...
The map will be at least loosely SC2 lore based because of one simple reason: I don't have the skills to make new models. However, so far I'm only building the engine and the content can be changed later on. Also, how is a generic zombie setting any more creative than a setting based on SC2 lore? And of course I'm going to call them zombies even though they are Infested Terrans. A zombie is a zombie, no matter what it looks like or what it's called.
Same goes for the contiguousness of the game world: right now the plan is to just have each game last up to a few hours without a save/load system, because I haven't yet planned any comprehensive skill system which would remain interesting over a long period of time. But once the base engine is done, I'll start properly thinking of how I want to expand it. It's also only possible to save a very limited amount of data, so saving the entire city in the bank is out of the question. Characters would be possible to be saved, but I'll have to see if it's going to be useful enough for the effort.
Also, I'm doing this for fun, and won't be spending endless hours on it... so it probably won't become anything overly popular any time soon. As you might notice I've been just talking here for the past week without any real progress, so don't get overly excited just yet.
The ideas about the random encounters for blocking debris, lockpicking etc. are nice, and just about what I was going for anyway.
Very nice. But does it currently Support Sub-Levels such as basements?
With basements added You could add some kinda of "sewer system" support which might make it very interesting as well =)
Also a Dialog Box in the top right that shows you the "name" or "id" of the building the player is in and the current floor/level they are on of the building.
Yeah, it supports basements as well. I was thinking of making a sewer system, but that might take for a while since I still have a lot of more important things to do. The building name and level display is a good idea, I was wondering how I should do that... and a simple dialog will be nice and clear.
@dra6o0n: Go
Protoss purges and a queen spreading creep tumor sound like good random encounter possibilities, but I'll have to see how many of them I have the time and motivation to implement.
@oODoomieOo: Go
That's one of the possibilities for a respawn system, but I have a feeling it would become too random since the map isn't linear. Sometimes the player might spawn into a place where it's nearly impossible to rescue him and sometimes in a building that's right next to the other players. That's why I was planning for having the players rescue NPC civilians so that the new player could just "possess" one of those.
However, I think I'll go for a death-means-death system but with some possibilities to bring dead players back to life, possibly with an adrenaline injector which the players first need to find. I'll try not to make fleeing from enemies too difficult so you always have a fair chance of survival if you didn't do something stupid yourself, like running right next to a monster. This could be balanced by making your sanity drop reasonably fast when you're hiding.
I talked a bit about the crafting system with Xenox and I'm not so sure about it anymore, since it'd make more sense for the survivors to craft weapons like crossbows, molotov coctails, swords, axes etc. and not complex things like shotguns, pistols and rifles. I'd also have wanted to give the players a choice of what they want to craft since what'd be the point of a crafting system if they couldn't decide? It'd be the same as just making obtaining weapons more difficult, and the same effect could be achieved just by setting the chance to find them lower. So the random identification idea wouldn't really work with that, but because none of the weapons I just mentioned can really be crafted by using the same parts (like how do you make a crossbow from the same parts as a sword or a molotov coctail), a crafting system might not be that good for the gameplay after all.
Instead, I was thinking of a "repair system" like in Fallout 3, where you can find different kinds of weapons (then there can be shotguns, pistols and rifles as well), where you can repair one weapon by using another one of the same type as spare parts, like combining two shotguns together destroys one of them but increases the durability of the other one. This way the players would need to decide if they want to share the weapons they've found with everyone, or use some of them to make the others more reliable.
One idea was to let the players use almost any wooden and metallic weapons and equipment to fortify barricades (some better than the others), but you'd need a blowtorch or similar to do so. Maybe have an ability to destroy a weapon into scrap metal or scrap wood, and also have the weapons that are destroyed for repairing produce a little bunch of those.
—
I've been a bit busy with other things for the past few days but the zombie AI is coming along quite nicely. So far it only works for zombies and players who are in the same building or outside, but the code structure allows me to add the other cases without having to change the structure itself. Here's what I have implemented so far:
Whenever a zombie sees a player and isn't chasing him yet, the zombie generates 10 threat per second (TPS) towards that player.
At 35 threat towards a player, the zombie starts a countdown timer of 3—9 seconds at random (resetting on every AI cycle when the zombie can see the player) during which it knows where the player is and generates 1 TPS towards that player up to a limit of 100 threat.
When the countdown ends, the zombie doesn't know where the player is anymore and issued a move order to the last known position of the player.
While the countdown isn't running, the zombie loses 2 TPS towards that player.
Each zombie has separate threat counters and countdowns for each player (stored in the zombie unit's custom values), and if another player has more than 110% threat than the current target, the zombie changes its target.
This means that if you walk past a zombie so that it only sees you let's say for 2.5 seconds, it only generates 25 threat on you and doesn't yet start to chase you. While you're hiding, the zombie loses 2 TPS from you, so after 5 seconds it still has 15 threat on you. If you then let the zombie see you for another 2 seconds, its threat increases by 20 from 15, adding up to 35, and the zombie starts chasing you.
It also means that the longer the zombie chases you, the more threat it gets on you and the longer it takes for the zombie to "forget" you, and even if it forgets where you are, it still remembers how much threat it has on you. So if you manage to lose a zombie but it still has more than 35 threat on you when it sees you the next time, it instantly starts to chase you again.
Later on, I'll add more complex threat generation which will be partially based on the distance between the player and the zombie, the view angle of the zombie towards the player, and the speed at which the player walks by the zombie. Sounds will also generate "environmental" threat for the zombies, which can cause them to move to the point where the sound came from (if the threat generated by the noise is high enough compared to the zombie's current target).
Status report!
Last night was a refactoring hell, but the code is now much cleaner and more efficient. I changed the way my interact system works, which was previously done by an inefficient loop that checked distances between the player and the target. Now it's done using a smart-click ability which is then caught by triggers. Previously, items and monsters were spawned as units already when the map started, and now they are only spawned when any player enters the building for the first time during the game. This speeds up the building generation on map start by a little, but most notably it reduces the number of units that simultaneously exist in the map.
I considered slowing the enemies down so that they'd be slower than the player, but it just won't work. If they're that slow, they'll never get to do anything to the players and don't really pose as a threat. This isn't Resident Evil with endless masses of zombies blocking your way. To compensate this, I'll probably give the players more weapons than I originally planned. I need to redo some of the AI as well so that it's easier to flee by using shadows and corners to your advantage.
Before last night, I got my weapon system partially done, but it's since been slightly improved. Here's a short video of its first version:
Perhaps I'll make most zombies slower than the players, but add some tougher ones that need to be ran away from? And sprint needs to be a lot less efficient. The current version of it is just a Stimpack without the health cost, and I've just been using it for testing.
I'm currently working on the weapon system. Just got it to the point that weapons can't be fired through walls even if the player has vision through it.
The camera is now unlocked from the player, but can't be moved outside the indoor area. Outdoors the camera can be freely moved, so players can see what's happening to other players. And since the camera is unlocked, zooming is now possible.
Also, I modified the UI layout a bit. If required, the bars can be extended to the right, but I'll keep them limited to 10 slots for now.
Watch it on youtube for higher resolutions (up to 1080p)!
@cookies4you: Go That sounds a bit too fantasy for this, and death isn't supposed to be rewarding anyway. I don't want players to sometimes want to die. I think it's also not possible to block players from using the [All] chat?
I now have the light system working quite well, as I described earlier. I had to do a little trace line trick for checking the light's line of sight to the player but I don't think it's too performance-heavy. Now I just need to modify the building generators to spawn lights in reasonable spots (now they just spawn randomly around there). The lights behave as if they would turn on when the player comes near, and turn off when the player goes away. This means the players won't see the "light beams" through doors until they enter the room. But we can think of them as scifi lights that have a motion detector or whatever. :P
Update: Monsters can now follow players from building to building. The system is still missing the case when a monster is trying to move inside an unspawned building, but I think I'll fake it by just teleporting the monster out of there after a specific amount of time based on its direct distance to the door. No one sees what happens there anyway since it's unspawned... It should be just fine.
I'd like to add that not everything we discussed on IRC was "decided", just discussed. The item system for example might need to be changed if there would be too many items for the engine to handle simultaneously. In that case, I need to implement containers that work both ways; you can take items off and put them back. Items in containers wouldn't be actual units so that'd allow a far larger number of items to exist.
The current crafting ideas are just examples of what the system could be like. I think my approach will be first figuring out the interesting items I want in the game, and after that the crafting patterns and component items.
As an update from yesterday, I have a much neater inventory now. It keeps the items "compressed", removing all empty spaces between them. This enables an item being selected all the time, so that when you drop an item, the next item "falls back" in the inventory and becomes selected. If you drop the last item in the inventory, the selection itself falls back and the previous item in the inventory becomes selected. I also have a working food item now, which removes a bit of your hunger. From now, it'll be easy to add other items into the game as well.
Update: A few screenshots below.
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.
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.
No, it's still alive. Just having a little break from mapping altogether.
@dra6o0n: Go Continuously rescuing civilians for points would change the map into something completely different, taking it more towards the Lemmings style from survival style. The traits system could be a nice touch instead of just having characters with different numbers in their skills as I had planned it so far.
There are two ways to take the map to, both of which have gotten quite a lot of ideas and approval: The "death means death" mode where you lose your character when you die, and the mode where you preserve some of your characters attributes when you die and then get to respawn in some way. The latter could benefit from a character save/load system, and the death-means-death mode not so much.
A save/load system would also mean that the character development system was interesting enough over a long period of time to benefit from the save/load system to begin with. If you'd be just getting more and more traits over time, then eventually all characters would end up being the same. So it'd probably mean each trait would need its own level up system, like a character with Military Training would become better and better at using guns, and so on.
However, then some of the players would start with a more and more powerful character each time, and the game would have to be balanced for that, requiring me to create new content for the more powerful characters... The whole thing would become very chaotic considering that not all players would start the game with a character of the same level, and the game would also be more predictable if the character levels would mean enabling a different set of gameplay content.
For a "casual" game like this (compared to big MMORPGs which you might spend months or even years with), it seems to me that it's better to add replayability by creating various different kinds of random encounters and randomizing the city for each game, so you never know which of the possible variations you'll be getting into when starting the game. Considering all this, I don't really see the usefulness of the save/load system even for characters, because I don't have the will to spend so much time balancing the gameplay for progressively improving characters.
The traits system can still fit into this, but only by using them as static attributes which instantly tell you what the character is good at and which skills he can improve faster than others. Still one more possibility to use a save/load system for is that the more times you have beaten the map, the more choice you have for what kind of starting character you get, otherwise being completely random. First you'd be able to choose one of your perks, then the rest, then the point distribution into each of your skills, and eventually even the starting equipment you have.
Maybe I have a bit different idea of what an RPG means to some of you, but in this case I'm mostly referring to the style of gameplay with it, not everything related to a game where you assume the role of a character and emphatize with him/her like maybe in some pen & paper RPGs. There's no point spending months into developing original lore for a map which people will play for a few hours.
Seesh, just calm down everyone. :P I'm not getting insulted by any of this, so no need to feed the trolling...
The map will be at least loosely SC2 lore based because of one simple reason: I don't have the skills to make new models. However, so far I'm only building the engine and the content can be changed later on. Also, how is a generic zombie setting any more creative than a setting based on SC2 lore? And of course I'm going to call them zombies even though they are Infested Terrans. A zombie is a zombie, no matter what it looks like or what it's called.
Same goes for the contiguousness of the game world: right now the plan is to just have each game last up to a few hours without a save/load system, because I haven't yet planned any comprehensive skill system which would remain interesting over a long period of time. But once the base engine is done, I'll start properly thinking of how I want to expand it. It's also only possible to save a very limited amount of data, so saving the entire city in the bank is out of the question. Characters would be possible to be saved, but I'll have to see if it's going to be useful enough for the effort.
Also, I'm doing this for fun, and won't be spending endless hours on it... so it probably won't become anything overly popular any time soon. As you might notice I've been just talking here for the past week without any real progress, so don't get overly excited just yet.
The ideas about the random encounters for blocking debris, lockpicking etc. are nice, and just about what I was going for anyway.
Yeah, it supports basements as well. I was thinking of making a sewer system, but that might take for a while since I still have a lot of more important things to do. The building name and level display is a good idea, I was wondering how I should do that... and a simple dialog will be nice and clear.
As soon as I have any. :P
@Kimphoe: Go Nope, but I heard a bit about it though. I haven't taken any ideas from it, sanity has been used as a stat long before that. ;)
Though if you're just saying it might give some ideas, then I maybe should give it a try.
@dra6o0n: Go Protoss purges and a queen spreading creep tumor sound like good random encounter possibilities, but I'll have to see how many of them I have the time and motivation to implement.
@oODoomieOo: Go That's one of the possibilities for a respawn system, but I have a feeling it would become too random since the map isn't linear. Sometimes the player might spawn into a place where it's nearly impossible to rescue him and sometimes in a building that's right next to the other players. That's why I was planning for having the players rescue NPC civilians so that the new player could just "possess" one of those.
However, I think I'll go for a death-means-death system but with some possibilities to bring dead players back to life, possibly with an adrenaline injector which the players first need to find. I'll try not to make fleeing from enemies too difficult so you always have a fair chance of survival if you didn't do something stupid yourself, like running right next to a monster. This could be balanced by making your sanity drop reasonably fast when you're hiding.
I talked a bit about the crafting system with Xenox and I'm not so sure about it anymore, since it'd make more sense for the survivors to craft weapons like crossbows, molotov coctails, swords, axes etc. and not complex things like shotguns, pistols and rifles. I'd also have wanted to give the players a choice of what they want to craft since what'd be the point of a crafting system if they couldn't decide? It'd be the same as just making obtaining weapons more difficult, and the same effect could be achieved just by setting the chance to find them lower. So the random identification idea wouldn't really work with that, but because none of the weapons I just mentioned can really be crafted by using the same parts (like how do you make a crossbow from the same parts as a sword or a molotov coctail), a crafting system might not be that good for the gameplay after all.
Instead, I was thinking of a "repair system" like in Fallout 3, where you can find different kinds of weapons (then there can be shotguns, pistols and rifles as well), where you can repair one weapon by using another one of the same type as spare parts, like combining two shotguns together destroys one of them but increases the durability of the other one. This way the players would need to decide if they want to share the weapons they've found with everyone, or use some of them to make the others more reliable.
One idea was to let the players use almost any wooden and metallic weapons and equipment to fortify barricades (some better than the others), but you'd need a blowtorch or similar to do so. Maybe have an ability to destroy a weapon into scrap metal or scrap wood, and also have the weapons that are destroyed for repairing produce a little bunch of those.
—
I've been a bit busy with other things for the past few days but the zombie AI is coming along quite nicely. So far it only works for zombies and players who are in the same building or outside, but the code structure allows me to add the other cases without having to change the structure itself. Here's what I have implemented so far:
This means that if you walk past a zombie so that it only sees you let's say for 2.5 seconds, it only generates 25 threat on you and doesn't yet start to chase you. While you're hiding, the zombie loses 2 TPS from you, so after 5 seconds it still has 15 threat on you. If you then let the zombie see you for another 2 seconds, its threat increases by 20 from 15, adding up to 35, and the zombie starts chasing you.
It also means that the longer the zombie chases you, the more threat it gets on you and the longer it takes for the zombie to "forget" you, and even if it forgets where you are, it still remembers how much threat it has on you. So if you manage to lose a zombie but it still has more than 35 threat on you when it sees you the next time, it instantly starts to chase you again.
Later on, I'll add more complex threat generation which will be partially based on the distance between the player and the zombie, the view angle of the zombie towards the player, and the speed at which the player walks by the zombie. Sounds will also generate "environmental" threat for the zombies, which can cause them to move to the point where the sound came from (if the threat generated by the noise is high enough compared to the zombie's current target).