It might have some advantages if we don't want players tunneling across the entire map. Another possibility is leaving the world very "thin" to not leave a huge underworld to tunnel through. Overworld is better for this sort of thing.
Cervator: Agree, although the space where resources can be found is heavily limited then.
What do you think of playing cards as resources, which are produced by the playing card minerals constantly. You can attach tools to said blocks to get better cards (hey, there are enough of them in a deck of cards ). A simple blueprint mechanism could be to just align different cards on a book page as recipe to craft weapons/ summon some slaves/ get building blocks from a mason/...
Sounds like were going straigt to a TCG battleforge like modul.
Summoning slaves with cards.
Maybe we can put 4 rare cards somewhere and only who got them all/or 3of them can Build a Special Tower or worldwonder
In regard to the overall gameplay style... snip ...I think ultimately though you would still have to pick a faction and be colored appropriately at the start of the game.
First attempt at MoSCoW requirements for the above post. Split into first test version and first release version.
(First release could be several test version away. Timeline not defined.)
Feel free to chop/change as required (is aimed @ first test version requirements):
--First test version requirements--
(Bare bones requirements, just to get something started to work from) MUST:
Have 2 factions
Have 1 basic map layout
Allow the player to join either faction
SHOULD:
Have a main keep for each faction, loss of which results in defeat.
Spawn troops for each faction, that attack the opposing faction.
COULD:
Have multiple types of units.
Have multiple types of buildings.
Have pathing across complex terrain.
WOULD LIKE TO:
Have basic resource gathering.
Also, the requirements for the first release version:
--First full release version requirements-- MUST:
Have at least 2 factions.
Have at least 1 map layout.
Allow player to:
Join a specific faction
Craft items
Gather resources
Engage in combat
Build
Quest
Donate crafted items or gathered resources to factions
Customize their avatar in appearance
Crafted items include:
Tools
Weapons
Armour
Have construction include the following aspects:
Semi-freeform (according to rules, not exact blueprints)
Affect faction statistics and production
Obstacles and traps for enemy factions
Gathering resources include the following aspects:
Allow upgrading of resource sources
Questing include the following aspects:
Special resources and items not normally gathered by factions
Gathering neutral units to join the faction
Let factions have the following aspects:
Squad spawn rates
Squad make ups
Technology level
Stored resources & magic
Magic level
Have command and orders allow:
Specific attack targets
Specific defense targets
Specific crafting tasks
Specific building tasks
Specific gathering tasks
Special magic strikes and spells using faction magic
Have combat include the following aspects:
Anything is destroyable
Order friendly faction units
Directly control friendly faction units
Siege units
Defensive structures (Towers, walls, traps, etc.)
SHOULD:
Have 4 factions
Have multiple maps supporting between 2 and 4 factions
Have procedural generation of maps.
Crafted items include:
Items providing faction bonuses
Have the following physics:
Structures collapse from structural integrity failure
Structure collapses affect nearby terrain and entities
Have construction include the following aspects:
Variations within a structure should affects its indirect statistics (bonuses, etc.). Better variations means better bonuses.
Allow player to:
Customize their avatar in skills and abilities
COULD:
N/A
WOULD LIKE TO:
N/A
Was a bit rushed, so please review and comment.
Especially on the first full release version, specifically on the MUST/SHOULD/COULD level of the requirements.
Faction choice probably isn't even needed for first version, I'd just dump the player into the world as a red piece of whatever kind.
Would add "Singleplayer" to first version, another reason faction choice doesn't reallly matter, and "Multiplayer" to the full version under Must.
Would move "Customize their avatar in appearance" down to "Would like" - beyond being able to select / possess a specific piece (I think of that more as swapping as customizing, might be semantics)
Would move crafting (separate from making buildings and defenses) down to "Should"
Gathering neutral units is a cool idea, I might move it to "Should" or even "Could" though
Magic (aside from "assumed" stuff like why wands shoot magic fire) I'd also put more in the idea bucket than "Must"
More than two factions I likewise would put in an idea bucket. Where does that even truly go? It sounds like a "Could" but "Would like to" almost seems more desirable than "Could" ?
Multiple / procedural maps I'd put in "Could" - I do think small parts of the world would be procedural, like where trees and resources spawn, so the first world wouldn't play the same every time
I would add (to final):
Power system including circuitry you can hook up to towers for better damage and likewise sabotage ("Could" - or is this an implementation detail?)
Central quest the factions will fight over in the middle with a big advantage going to the victor (the white wand - "Should", although again might be implementation detail ...)
But then I start thinking I'm doing it wrong with being too detailed
Allright, updated from feedback. [+] Means a new requirement. [-] Means a requirement was removed. [~] Means the requirement was slightly changed (or just reworded).
An requirement changing priorities would be shown as a [-] on the old priority, and a [+] in the new priority.
Sidenote on MoSCoW:
For those who might not have googled "moscow requirements" yet...
Link: MoSCoW
MUST: Means "This must be in or the version is not done and cannot be released"
SHOULD: Means "This really should be in there, and unless you have a really good reason why not, the version isn't done.". Typically these are only cut if there are no COULD to cut, and there are really good reasons why you want to drop it. (Behind schedule NOT being a good enough reason. The schedule should then be adjusted. But "Terasology game engine cannot do this yet" would be a good enough reason.)
COULD: Means "Nice to have", typically these are dropped if a version needs to be released (i.e. we do not want to adjust the schedule). In such a case, the requirement would probably just move to the next release.
WOULD LIKE TO: Means "Nice to have, but not in this version. Somewhere in the future." Or "Idea bucket" if you will. These do not automatically become COULD for the next version.
--First test version requirements--
(Bare bones requirements, just to get something started to work from) MUST:
Have 2 factions
Have 1 basic map layout
[-]Allow the player to join either faction
[+]Start player as part of the red faction
[+]Singleplayer only
SHOULD:
Have a main keep for each faction, loss of which results in defeat
Spawn troops for each faction, that attack the opposing faction
COULD:
Have multiple types of units
Have multiple types of buildings
Have pathing across complex terrain
WOULD LIKE TO:
Have basic resource gathering
--First full release version requirements--
MUST:
Have at least 2 factions.
Have at least 1 map layout.
[+] Allow single or multiplayer
Allow player to:
Join a specific faction
[-]Craft items
Gather resources
Engage in combat
Build
Quest
[~] Donate crafted items or gathered resources to factions
[-]Customize their avatar in appearance
Crafted items include:
Tools
Weapons
Armour
Have construction include the following aspects:
Semi-freeform (according to rules, not exact blueprints)
Affect faction statistics and production
Obstacles and traps for enemy factions
Gathering resources include the following aspects:
Allow upgrading of resource sources
Questing include the following aspects:
Special resources and items not normally gathered by factions
[-]Gathering neutral units to join the faction
Let factions have the following aspects:
Squad spawn rates
Squad make ups
Technology level
[~] Stored resources & magic
[-]Magic level
Have command and orders allow:
Specific attack targets
Specific defense targets
Specific crafting tasks
Specific building tasks
Specific gathering tasks
[-]Special magic strikes and spells using faction magic
Have combat include the following aspects:
Anything is destroyable
Order friendly faction units
Directly control friendly faction units
Siege units
Defensive structures (Towers, walls, traps, etc.)
SHOULD:
[-]Have 4 factions
[~] Have multiple maps supporting between 2 and 4 2 factions
[-]Have procedural generation of maps
[+] Have partial procedural generation of maps
Crafted items include:
Items providing faction bonuses
Have the following physics:
Structures collapse from structural integrity failure
Structure collapses affect nearby terrain and entities
Have construction include the following aspects:
Variations within a structure should affects its indirect statistics (bonuses, etc.). Better variations means better bonuses.
Allow player to:
Customize their avatar in skills and abilities
[+] Craft items
[+] Donate crafted items to factions
[+] Crafted items include:
[+] Tools
[+] Weapons
[+] Armour
[+] Have a power system that:
[+] Allows at least 1 way to generate power
[+] Interacts with various structures to boost their core function
[+] Is fully constructable & destructible
[+] Place emphasis on the central "contested" area by:
Having central area contain powerful artifacts for the players to use
COULD:
[+] Have full procedural generation of maps.
[+] Questing include the following aspects:
[+] Gathering neutral units to join the faction
[+]Allow player to:
[+]Customize their avatar in appearance
[+] Have a power system that:
[+] Allows multiple ways of generation power
[+] Interacts with various structures to give them new functions
WOULD LIKE TO:
[+] Have up to 4 factions
[+] Have multiple maps supporting up to 4 factions
[+] Allow player to:
[+] Customize their avatar in appearance
[+] Let factions have the following aspects:
[+] Stored magic
[+] Magic level
[+] Have command and orders allow:
[+] Special magic strikes and spells using faction magic
As I was doing the list, I thought of the following:
To place emphasis on the middle, should there perhaps be a direct benefit to the factions as well?
The powerful white wand is more a direct benefit to the player (and indirectly, if not betrayed, to the faction the player fights for).
The idea of magic "King-of-the-hill-style" magic source points was a concept of a direct benefit to the faction that can capture and hold the center.
Also, for the power system. I think it might be good to present the player with the decision if they want a structure to become power dependent.
A power dependent structure would be greatly boosted over its normal counterpart, but be useless without power.
A normal structure provided with power, would only be marginally boosted, but also simply revert to normal efficiency when without power.
This then presents the player with the choice of going full power or not. And while the choice for far back well guarded buildings might seem obvious, remember that a loss of a power generator could then be made to cause the whole system to become "underpowered". (Think Command and Conquer Red Alert)
Additionally, if the boost for going "power dependent" is good enough, the choice for frontline buildings is still an attractive one.
For example, a powered ballista tower would become rapid fire (or perhaps self repair), but also not shoot at all if power is lost (or for self-repair, actually slowly break down if no power is available).
P.S: Where in the priority list these ideas go is only relevant if they are accepted at all, so don't stress about that now.
Rather than necessarily make the center the "King of the Hill" spot we could just slowly add neutral buildings to the map that bestow some benefit on the owner. Maybe have them dot the map along the top and bottom edge or so. And we take one more step toward the LoL setup
Can focus on the center too, maybe buildings ringing the central Parcheesi board, seems to me that might emphasize the center too much? Without some stuff to go after elsewhere, anyway.
Good point. The center will already be a battlefield purely from the "shortest path" point of view.
Neutral buildings sound good, though I wonder how you would repair them should they get damaged. Or would they simply be indestructible to start off with?
And how would capturing work?
By proximity or by crafting some sort of flag and sticking it in a slot on the building?
On the first test version, when (if any) is the current date aim for having it out?
Can we have actually a one place that describes the L&S game play mechanics (at least for the first alpha milestone)? It seems I have a completely different idea from what everyone else has, and most likely it will be different for everybody. Brain-storming is good, but useless if we do not come up with one consistent idea that we all understand.
What is missing in the MoSCoW is several details (requirements gaps):
- where and how do the minions (NPC) spawn? based on time, acquired resources, something else?
- what is the player fighting against in single player? is there going to be an AI opponent? if so, is the AI going to have the same setup as the player (core building and spawned minions) or just random waves attacking the player? if it's random waves, than what is the single-player mode objective? surviving all the waves?
I could probably list plenty more, but maybe we should appoint someone who is going to be a "creative director" for the L&S (Cervator?), who has a vision and knows the direction he wants to go with it. That person could then describe the first playable version we could actually release in more details than the MoSCoW above. This post should answer all the questions we might have and should be updated with what we have, what we are missing and what is the short-term goal.
This one place should be here I think, and the MoSCoW-specification is a starting point. But you're right, we should split the brainstorming and discussion from the decisions already taken. I suggest to leave this thread only for already determined decisions, and move all the discussion over to the L&S thread in the art subsection.
@Marcin Sciesinski : The MoSCoW requirements listed two posts before is an attempt at fleshing out what L&S should be.
Currently we are trying to flesh out two sets of requirements, namely those for the first test version. And those for the full release version.
Feel free to add to/ remove from them.
Brainstorming is typically more for the final release version, and the first test version requirements are extremely bare bones.
I was planning on drawing up some form of roadmap, once we have a set of first release requirements that are somewhat agreed upon, and a date that we want to aim towards.
(I.e. since we know what today's date is, and what the first bare-bones version is.)
Is this what you mean, or do you want a fuller more detailed description of what the gameplay is like?
I was thinking of first agreeing upon requirements, then going into detail. But that isn't the only way to do it.
[EDIT]
@Skaldarnar: Ninja'd!
Point taken about the split.
Should we do the brainstorming in the already existing L&S thread in the Art forum section?
The reason I'm asking about the details, is that if I wanted to pick up something to work on for the first milestone - there is almost no programming work, at least nothing in a workable state (requirements). Maybe having a release with only graphic assets might be fine, but if that is the goal, maybe it's just better to release a video with the assets and put it on youtube.
So, to have something to work on, I need a plan of what game content (playability wise) will be there, and what are short-term goals/plans, as well as what is the direction L&S will be going.
Maybe that'll sort of collapse together my idea for milestones 1 + 2 and give a better chance for playable, if kinda goofy? Previously the low amount of actual coding was on purpose to keep it minimal.
As for the two threads - I was sort of thinking implementation discussion would go here and art + conceptual stuff in the original? Could keep a summary in the top post here like intended for Incubators. But yeah, need somebody to keep that organized and on point. Probably not me since I try to do all the things at all the times
Can we use the MoSCoW fun here and spin out the exact milestone implementation detail from that? I like the added split between "minimal for testing", "minimal playable alpha", "full release" - I think trying to do everything till playable in an enjoyable fashion would be a very big mouthful.
Rather than necessarily make the center the "King of the Hill" spot we could just slowly add neutral buildings to the map that bestow some benefit on the owner. Maybe have them dot the map along the top and bottom edge or so. And we take one more step toward the LoL setup
Can focus on the center too, maybe buildings ringing the central Parcheesi board, seems to me that might emphasize the center too much? Without some stuff to go after elsewhere, anyway.
I like this idea. This could be the Osgiliath of the Realm (contested ruined city). Just because the White Avatar wasn't as ambitious with his world vision as the Black and Red doesn't mean he was idle. The buildings around the pachisi board could be ruined temples, libraries and other peaceful but ruined areas. In addition to the secret White Chamber, holding this landmark could provide a big bonus to speeding up tech progression in crafting. Or, as a simple way to start - say it just ups available resources while being a strategic jumping off point (with some pre-built defensive structures) for invading the opposing faction.
White blocks! With vines on em! Lost Temples! Neato!
Sorry for brainstorming in the wrong area ; )
I think the requirements we're compiling for various stages of development look very promising (and hopefully will be achievable). I think we're so early in this process that we're still learning what IS and ISN'T possible for near and long term goals - but based on the above, I think we're on the right track.
To get this thread updated again:
* Overrides of basic terrain textures are ported to the new structure and work from the LASR module
* new block assets like Red/BlackTowerStone are ported as well
- combined block structures (like the playing cards) are not ported yet
I checked out the L&S Resources and L&S modules a couple of days ago and was making them work with the latest develop branch, just to get an idea of what was currently implemented.
One big problem that took me a long time to track down is that the assets are in both modules. Often with the same names. And mostly only partially there. I did finally write some code so that whenever I pressed the B key that a redQueen asset would successfully materialize, and for kicks and to make sure I understood what pieces did what, I updated the texture with pictures of my family. But we definitely need to clean up the L&S resources assets so that everything that is there either works or is documented as to what is missing/broken, and remove the assets from L&S.
I mostly have the L&S module ported to the latest code branch, although there are issues with Pathfinding/Behavior since those two are based against NUI/Miglayout. For now, I just commented that stuff out.
The LASR module was pretty much so we could put some stuff into a working module while keeping the now-broken code in the old one until we could fix and straighten them both out. If you're up for doing that - then cool! Reorganize away
The main perceived obstacle was a lack of game mode/type selection, which we had before multiplayer/restructure. After seeing the work msteiger did on Cities, however, I'm realizing maybe the world gen selection will be enough (it even sees to auto-select the right modules - unless I'm just imagining that)
Another piece is a finite world gen with static placement of stuff, although that isn't really critical. Cities could probably be configured to make two about equal cities in two nearby spots ... and there's the world!
Yet another piece is equipping the models with different tools to make gameplay look more sensible - glasz got the models prepared pretty well but I think we need the code to modify/swap models around in-game based on current action (where behavior indeed would come in handy)
There is also an assortment of issues in two milestones on GitHub (one, two), although they two need to be dusted off with the work done since their creation and any realignment to better fit what we've got available now
The L&S module is untouched quite a long time. It should not contain any assets - they should be moved to LASR. So the LASR module may be used as a dependency by other modules without bringing new code / modifying things in the game world.
The code in L&S is mostly outdated. All classes, except CardComponent + CardSystem can be removed safely, they can now be found in the Pathfinding module. This is not final, since I plan to port the MinionMove and MinionAnimation stuff back to the miniions module (which will remove the code there) or even create a new minion module.
For now, everything depends on my behavior branch of the engine. You need this, to properly get the lastest Pathfinding module running (which contains some Behavior nodes).
Mike Kienenberger: If you already did this, would you mind removing the commented out code + everything except Card* and push it? Otherwise I will tidy up the L&S module later.
Not realizing that the code was outdated, all I did was get the code to compile and run. So if we want to remove all the classes but CardComponent + CardSystem, there's not much that I've actually done that could be saved.
Finally I tidied up the LAS module. As I said, most of the code was outdated. I also removed all assets from LAS, since they can be found in LASR now.
The override mechanism doesnt work out of the box (I did not touched this). Either its a small fix (directory?) or it doesnt work no more
Right now, there are two blocks, a spawner and a target. The spawner spawns minions that are defined in the SpawnerComponent (which minions, how many, how often, ...). I also added a simple behavior to make a minion walk to target block.
Next steps are:
Make LAS world gen working. Right now, its a copy of the cities generator. The goal is, to have two cities with a target and a spawner in the middle. Some work on world generator and cities module needs to be done first.
Decorator node, that activates when an enemy is around and sets enemy as current target.
Attack node, that deals damage to enemy/target block if in range.
"Death" system to remove minions without hp.
Next big topic is, does all this works in multiplayer? Never tried this
). A simple blueprint mechanism could be to just align different cards on a book page as recipe to craft weapons/ summon some slaves/ get building blocks from a mason/...
