It is co-op for 1-8 players, but I'm not sure it should be called "survival" since it's about progression as well, not just defending in one place. Players respawn when they die as long as there's at least one Command Center up. If all structures die, or if all players die and there are no Command Centers, the players lose.
When a player dies, his cargo is dropped on the ground as a Discarded Cargo item that can be recovered by any player. The item disappears after a couple of minutes. The dead player loses all upgrades he has, but can easily just craft them back after respawning. The upgrades don't cost a lot to craft, but the tech to get those upgrades takes time and resources.
To scale the game for different numbers of players, movement speed, mining speed, attack speed, and cargo capacity of the SCVs changes depending on the number of players. Enemy spawn rate also varies slightly. I'll also need to scale the Goliaths and other mountable vehicles.
Anything that consumes resources takes it directly from the common resource pool. I had it previously so that the players had to manually fill the turrets and power generators with vespene, but that turned out to be extremely boring and annoying. Power generator consumes vespene when it generates power, and that consumption scales down if the full potential of the generator is not in use.
The power cable connected to the turrets is just an alternate graphic for the cable, because the default one would look bad. The turrets don't need power while idle, but they need to be connected to an active grid to unburrow. They require a small amount of power when they fire and for ten seconds afterwards (to cool down), and they consume a bit of vespene on each shot. The black out system is not very realistic, but it is required for the gameplay. If everything just slowed down instead of shutting down completey, turrets would still be able to fire at enemies even while underpowered, which is not what I want.
And yes, each player gets one SCV, and can only control one movable unit (the SCV or a mountable vehicle) at a time during the entire game. This is a technical limitation because of the amount of minable rocks. The rocks are spawned around the players and unspawned when the players move away, so that there aren't too many units (which the rocks are) on the map simultaneously. This also means that areas the players can't see must be hidden in black mask, even around the buildings, because otherwise the minable rocks would seem to appear out of thin air.
I'll worry about difficulty levels later on, since the map will already be very difficult to balance for the different numbers of players. I'll try not to make the initial versions too difficult, though. On the video it seems quite hectic at times, but that's just because I hadn't had a chance to test the balance after making some changes.
CraftCraft is a co-op mining, construction, and exploration map with mostly defensive combat. Its development is still in progress, but there's already a great deal to show you.
Features
Procedurally generated, epic-sized map with a minable object on nearly every tile
Co-op for 1-4 players against computer controlled, randomly spawning enemies
Action-packed gameplay for one to two hours with always something useful to do for everyone
One controllable worker per player, with the ability to mount vehicles: Goliath for agile combat, Science Vessel for support and exploration, and Thor for total destruction
Power grid system to make base management interesting
Resource management system with three functionally distinct resources
All buildings and resources with shared control between all players, giving high value for teamwork
Randomly placed objects around the map to make mining more than just grinding of rocks
Various interesting researches to enable powerful, infinite-range abilities for the worker
Primary objective to activate three xel'naga vaults scattered across the map by using the power system
An older video (followed up by an older post, skip to the last couple of pages for up-to-date news):
What's seen on the video is a small portion of the entire map. I have plans for a lot of content, but implementing it all will take time. The main idea is to explore the map and uncover new technology from protoss relics and terran wreckages while the enemy forces keep getting more and more devious. The ultimate goal is to find the reason for the zerg presence, and deal with it. I can't say more without spoiling the story.
The larger areas the players start to control on the map, the more difficult it will be to maintain the base against the enemies. Gaining access to new technology will help with this. By researching protoss relics, the players will eventually be able to build a teleportation system. Destroying zerg structures will provide the players with organic researches, and allow them to upgrade structures with regenerative materials. Coming across uranium will be useful once nuclear reactor research is complete...
The entire map is procedurally generated, but for now it's just noise in the rock types. Later on, the locations of different research enabler objects will also be randomized, and hopefully I can come up with other interactive world objects as well.
CraftCraft is about an epic team effort where everyone will have something useful to do all the time, be it building or managing the base, mining for resources or exploring, or using battle tech to attack or defend your base. However, the map might be difficult to play in public games, because all the resources and buildings are shared among the players. It will be easy to ruin the game for everyone, and I'm only aiming to prevent it being easy to do so by accident. To be safe, play it with people you trust to have fun with.
I'd very much appreciate your feedback, and especially any ideas on how to make CraftCraft even more interesting and entertaining than it already is.
I'm trying to change the Adjutant sounds into something else, and so far I've managed to change them by modifying the Sound data entries to use different files. However, the sound that's played when trying to place a refinery in an invalid location ("Vespene geyser required for placement") seems to be unchangeable.
I found the "Alert_TerranPlaceOnVespeneGeyser" sound which seems to be the right one, but changing it doesn't change the sound in-game. I also found the entry in the Conversations data entry that links to this file, but modifying that also has no effect in-game.
It also seems that any unit with "built on" set to something plays the "vespene geyser required for placement" sound, no matter what unit it is and what unit it's being attempted to build on. Any ideas how to change the sound?
"PlacementModel" is the name of an actor (not a model) that creates all the default range actors, such as Photon Cannon, Missile Turret, and Hive Mind Emulator range actors. I didn't realize it at first because the same placement actor is used by all unit actors by default. It's referred in the "Art: Placement Model" field of each unit actor (not "Art: Model (Placement)").
I've been trying to replicate the way turrets display a range actor when they are being placed by the build ability for a building that has no weapons. The turret "Protect Range" actors link to the turret's weapon and are created that way, but for example Hive Mind Emulator has some other way to create the actor and I haven't figured out how it works.
What I want is the building that's being placed have a range actor around it, and the range preferably (but not necessarily) based on one of the abilities the building has (like Hive Mind Emulator does it, I just couldn't figure out how the references actually work). Any ideas?
Nevermind: Everything I was missing was in the actor called PlacementModel.
Yeaah, well... I already did, as shown on the second video, and described in my first post. ;)
It doesn't differ hugely but it does require constant interaction from the player (left click to fire a few shots) and I think it works just fine for this map.
Goliath Online is a mix of RPG elements and classic beat'em'up style gameplay. Each of up to six players assumes the role of a mercenary, a mech pilot who's up to earn some credits. The gameplay consists of missions where the mechs defeat waves of enemies while making their way towards the end. The view is a sidescroller with a bit of depth, and the camera moves automatically as the players progress in the level. Between missions, the players can upgrade their mechs by purchasing various kinds of upgrades from the store for credits they earn by completing the missions.
The map is still work in progress but I wanted to share what I already have. I created the headquarters UI for this map long ago but didn't figure out how to continue from there. The mission system I had planned back then seemed boring, so I set the project aside for quite some time. Not long ago I began working on a sidescroller map, and suddenly realized it'd make the perfect mission system for my mech RPG, and after a night of working with the editor, I combined the projects into one.
Long story short, features as currently planned:
Mission system with various levels of missions providing increasing difficulty and better rewards. Players can vote which mission they want to start, and there can be only one mission active at a time.
Upgrade system which allows the player to replace the engine, hull, weapons, missiles, and addons of his mech.
Engine module defines the mech's movement speed, energy regeneration rate and provides one activated ability (such as a temporary speed boost) depending on the engine.
Hull module defines the mech's life, armor and number of addon slots. It also sets its Tech Level which restricts the player from attaching all the best upgrades to his mech too soon. Hull modules can't be traded between players and better hulls are gained progressively throughout the game. Hull module also provides the mech with a Repair Drones ability, and different hulls come up with varying stats for that ability.
Weapons and missiles come in various types with different stats. Each mech has Missile Barrage which is an area effect damage ability on a rather long cooldown.
Addons provide the mech with different kinds of abilities, both passive and activated. Each mech can have one to four addons, the number defined by the hull module. Unlike other upgrade modules, addons can be detached from the mech even without replacing them with a new one.
Factions for the players to gain reputation for, taking the place of an experience system. Factions provide the players with new missions and new upgrades to buy from the store.
Combat system where firing a weapon is executed by simply left-clicking on the ground. The mech fires towards that point for a short duration and the first enemy caught in the line of fire takes the damage (or all of them in case of a flamethrower, for example). The weapon can also be aimed directly at a unit by right-clicking on it, but the line of fire can still be interrupted by other units.
Boss battles with varying scripted encounters providing interesting challenges to beat.
I must admit that I have a bad habit of losing interest on my projects over time, so there might be times with this one as well when I just can't get myself to work on it. If you're interested, post a reply and help me keep my motivation up! Or just hope I won't lose too much of it... I'd also like to know whether "Goliath Online" sounds like a proper name for this map, or if there's a better one to be invented.
And last but not least, here are a couple of progress demo videos:
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.
0
It is co-op for 1-8 players, but I'm not sure it should be called "survival" since it's about progression as well, not just defending in one place. Players respawn when they die as long as there's at least one Command Center up. If all structures die, or if all players die and there are no Command Centers, the players lose.
When a player dies, his cargo is dropped on the ground as a Discarded Cargo item that can be recovered by any player. The item disappears after a couple of minutes. The dead player loses all upgrades he has, but can easily just craft them back after respawning. The upgrades don't cost a lot to craft, but the tech to get those upgrades takes time and resources.
To scale the game for different numbers of players, movement speed, mining speed, attack speed, and cargo capacity of the SCVs changes depending on the number of players. Enemy spawn rate also varies slightly. I'll also need to scale the Goliaths and other mountable vehicles.
0
Anything that consumes resources takes it directly from the common resource pool. I had it previously so that the players had to manually fill the turrets and power generators with vespene, but that turned out to be extremely boring and annoying. Power generator consumes vespene when it generates power, and that consumption scales down if the full potential of the generator is not in use.
The power cable connected to the turrets is just an alternate graphic for the cable, because the default one would look bad. The turrets don't need power while idle, but they need to be connected to an active grid to unburrow. They require a small amount of power when they fire and for ten seconds afterwards (to cool down), and they consume a bit of vespene on each shot. The black out system is not very realistic, but it is required for the gameplay. If everything just slowed down instead of shutting down completey, turrets would still be able to fire at enemies even while underpowered, which is not what I want.
And yes, each player gets one SCV, and can only control one movable unit (the SCV or a mountable vehicle) at a time during the entire game. This is a technical limitation because of the amount of minable rocks. The rocks are spawned around the players and unspawned when the players move away, so that there aren't too many units (which the rocks are) on the map simultaneously. This also means that areas the players can't see must be hidden in black mask, even around the buildings, because otherwise the minable rocks would seem to appear out of thin air.
I'll worry about difficulty levels later on, since the map will already be very difficult to balance for the different numbers of players. I'll try not to make the initial versions too difficult, though. On the video it seems quite hectic at times, but that's just because I hadn't had a chance to test the balance after making some changes.
0
I will try to get the early releases on NA as well when the time comes. I can poke some people around... But I can't yet say when that will be.
0
Greetings!
CraftCraft is a co-op mining, construction, and exploration map with mostly defensive combat. Its development is still in progress, but there's already a great deal to show you.
Features
Follow the development process on my blog at a1win.blogspot.com
Update on January 24, 2012:
An older video (followed up by an older post, skip to the last couple of pages for up-to-date news):
What's seen on the video is a small portion of the entire map. I have plans for a lot of content, but implementing it all will take time. The main idea is to explore the map and uncover new technology from protoss relics and terran wreckages while the enemy forces keep getting more and more devious. The ultimate goal is to find the reason for the zerg presence, and deal with it. I can't say more without spoiling the story.
The larger areas the players start to control on the map, the more difficult it will be to maintain the base against the enemies. Gaining access to new technology will help with this. By researching protoss relics, the players will eventually be able to build a teleportation system. Destroying zerg structures will provide the players with organic researches, and allow them to upgrade structures with regenerative materials. Coming across uranium will be useful once nuclear reactor research is complete...
The entire map is procedurally generated, but for now it's just noise in the rock types. Later on, the locations of different research enabler objects will also be randomized, and hopefully I can come up with other interactive world objects as well.
CraftCraft is about an epic team effort where everyone will have something useful to do all the time, be it building or managing the base, mining for resources or exploring, or using battle tech to attack or defend your base. However, the map might be difficult to play in public games, because all the resources and buildings are shared among the players. It will be easy to ruin the game for everyone, and I'm only aiming to prevent it being easy to do so by accident. To be safe, play it with people you trust to have fun with.
I'd very much appreciate your feedback, and especially any ideas on how to make CraftCraft even more interesting and entertaining than it already is.
0
That worked, thank you. :D
I did do a search myself before asking but apparently I failed. <.<
0
I'm trying to change the Adjutant sounds into something else, and so far I've managed to change them by modifying the Sound data entries to use different files. However, the sound that's played when trying to place a refinery in an invalid location ("Vespene geyser required for placement") seems to be unchangeable.
I found the "Alert_TerranPlaceOnVespeneGeyser" sound which seems to be the right one, but changing it doesn't change the sound in-game. I also found the entry in the Conversations data entry that links to this file, but modifying that also has no effect in-game.
It also seems that any unit with "built on" set to something plays the "vespene geyser required for placement" sound, no matter what unit it is and what unit it's being attempted to build on. Any ideas how to change the sound?
0
"PlacementModel" is the name of an actor (not a model) that creates all the default range actors, such as Photon Cannon, Missile Turret, and Hive Mind Emulator range actors. I didn't realize it at first because the same placement actor is used by all unit actors by default. It's referred in the "Art: Placement Model" field of each unit actor (not "Art: Model (Placement)").
Anyway, I already figured out all I needed.
0
I've been trying to replicate the way turrets display a range actor when they are being placed by the build ability for a building that has no weapons. The turret "Protect Range" actors link to the turret's weapon and are created that way, but for example Hive Mind Emulator has some other way to create the actor and I haven't figured out how it works.
What I want is the building that's being placed have a range actor around it, and the range preferably (but not necessarily) based on one of the abilities the building has (like Hive Mind Emulator does it, I just couldn't figure out how the references actually work). Any ideas?
Nevermind: Everything I was missing was in the actor called PlacementModel.
0
Yeaah, well... I already did, as shown on the second video, and described in my first post. ;)
It doesn't differ hugely but it does require constant interaction from the player (left click to fire a few shots) and I think it works just fine for this map.
0
Goliath Online is a mix of RPG elements and classic beat'em'up style gameplay. Each of up to six players assumes the role of a mercenary, a mech pilot who's up to earn some credits. The gameplay consists of missions where the mechs defeat waves of enemies while making their way towards the end. The view is a sidescroller with a bit of depth, and the camera moves automatically as the players progress in the level. Between missions, the players can upgrade their mechs by purchasing various kinds of upgrades from the store for credits they earn by completing the missions.
The map is still work in progress but I wanted to share what I already have. I created the headquarters UI for this map long ago but didn't figure out how to continue from there. The mission system I had planned back then seemed boring, so I set the project aside for quite some time. Not long ago I began working on a sidescroller map, and suddenly realized it'd make the perfect mission system for my mech RPG, and after a night of working with the editor, I combined the projects into one.
Long story short, features as currently planned:
I must admit that I have a bad habit of losing interest on my projects over time, so there might be times with this one as well when I just can't get myself to work on it. If you're interested, post a reply and help me keep my motivation up! Or just hope I won't lose too much of it... I'd also like to know whether "Goliath Online" sounds like a proper name for this map, or if there's a better one to be invented.
And last but not least, here are a couple of progress demo videos:
0
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:
0
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.
0
Watch it on youtube for higher resolutions (up to 1080p)!
0
@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.
0
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.