GSoC Proposal Draft (seeking feedback): Extending “Light and Shadow” Gameplay and Functionality

dacharya64

Member
Contributor
I've written up a first draft of my Summer of Code proposal, "Google Summer of Code Proposal: Extending “Light and Shadow” Gameplay and Functionality", and would appreciate any feedback! Please let me know if you think the pacing of the schedule needs work, if the priorities of tasks needs to be changed, or if you have any other feature requests for it!

--
EDIT:

First draft: https://docs.google.com/document/d/1pWsCea_bn8l7agVbbI2ZIfo2eu9oHhfdbdin7gPWjoo/edit?usp=sharing
Second draft: https://docs.google.com/document/d/1lbCFbu3Ya4Iy9_dHlvXHd4tse3bvc7GTxHERnkVpmBI/edit?usp=sharing
Third draft: https://docs.google.com/document/d/1jCgZtg78jGBTu3KNzxFbrDIJ0beEWK-dzr-53P_JN5o/edit?usp=sharing
--


Also putting goals and timeline here in spoiler tags, if people want to review those separately:

Goals:
Core Gameplay
  • Capture-the-Flag (CTF) gameplay mechanic -- Players will compete to capture a relevant “McGuffin” (ex. flag) from the other team’s base, and return it to their starting base. Alternatively, the goal can be to kill the enemy faction’s king who resides within the enemy’s base. When a player satisfies this goal their faction wins the round, and the level will be reset
  • Factions -- Players, NPCs, and other relevant in-game objects will be given divided into factions (red, black, unaligned). Factions will determine the team of the player and the player’s starting base.
  • Bases -- Each faction will have its own base that must be defended from other factions.
  • Scoring -- Score is determined by the number of successful flag captures made by each faction
  • Map / Level Design -- The level(s) will consist of a finite, somewhat symmetrical world with bases placed at either end. The world will have varying terrain features that can help/hinder players
Secondary Goals
  • Flora and tree generation -- Replace current generated flora and tree assets with themed assets (ex. card-based flora, board game-based trees)
  • Players can choose their own faction (ex. from menu or in-game dialog)
  • Faction conversion -- Unaligned items can be “taken over” by players to convert them to the same faction as players. This provides some benefit to the player’s faction (ex. converting unaligned flora to faction-specific flora produces faction-friendly NPCs)
  • Destructible bases -- Bases and other base buildings / items in the base (ex. turrets) can be damaged by the opposing faction
  • Base building -- Players can add onto their base to help defend it, for instance with guard towers / turrets. This can take advantage of the crafting system as well.
  • NPC mobs AI and pathing
  • Combat System integration for NPCs -- Player can damage and be damaged by NPCs
Stretch Goals
  • Multiplayer support
    • Lobbies
    • PvP
  • Art Asset Creation -- 3D modeling and animating additional assets for the module
  • Additional resources -- Ex. ores, that can be found and extracted by players for crafting (For items? Base modifications?) or glyphs (discussed in the Art forum thread)
  • Power -- Players can power elements of their base such as weapons
    • Weapons have two varieties, the high-power version of which doesn’t work without power but does much more damage when powered than the regular version does when powered
  • Procedurally generated maps -- Placement of base position and terrain varies within certain limits, but level is roughly symmetrical
  • Custom map support
  • Support for more than two factions
  • Quest system integration -- Completion of tasks that benefit your faction are built into quest notifications
    • Collection quests (ex. Convert 10 flora to your faction’s side) give some additional benefit to your faction
    • Victory condition quests are what must be completed for the player’s faction to win the round
  • “White Scepter” item (https://forum.terasology.org/threads/las-light-and-shadow-art-discussion.762/page-3): King of the hill-style item that provides a large benefit to the faction / player holding it
  • Currency and Vendors -- Players are given money and / or earn it in game to purchase items
  • Items and item trees -- Players start off with helpful items (or buy them) and can craft them into better items (ex. equipment, traps)
  • Player Improvements
    • Individual scores -- Players get individual scores based on their play, such as time with the flag, number of items converted, etc.
    • Player levels / rankings
  • Custom characters -- Players can pick which avatar they want to play as (ex. different chess pieces)
  • Skills -- Certain units have certain skills and abilities, may have prerequisites to being unlocked (ex. player attaining a certain level)
  • Commanding and ordering NPCs
  • “Command center” minified map / game board
Lore implementation (Intro screen? Books? Architecture?)

Timeline:
Pre-GSoC (Apr - May):

  • Connect with appropriate mentor(s) and community bonding
  • Continue to explore code base through appropriate tutorials and issue fixes
  • Evaluate current L&S module, seeing what currently implemented, functional
  • Relevant PRs to the current L&S module to fix conflicts with develop and master branches
  • Review current information on potential project directions and reach out to community about suggested work on L&S
Week 1 (May 14):

  • Initial map design / generation and soliciting feedback / redesigns
  • Initial base designs and implementation (red base and black base)
Week 2 (May 21):

  • Implement factions -- player and other in-game objects (ex. NPCs, flora) given specific faction type (red, black, unaligned)
  • Begin implementing CTF gameplay
    • Adding faction-specific “McGuffin” (flag) to each base
    • Changing flag behavior according to player faction
      • Can be picked up by player of opposing faction
      • Dropped on player death
      • When dropped, can be picked up by opposing faction player (added to inventory) or friendly faction player (moved back to spawn point in base)
Week 3 (May 28):

  • Finish implementing CTF gameplay
    • Players score when the flag is returned to base
    • Level resets on player score
  • Implement score and score UI
  • End of milestone 1 -- all Core Gameplay mechanics completed
Week 4 (June 4):

  • Begin base building implementation
    • Evaluate what additional buildings can be placed within the world and how to craft them (ex. guard towers)
    • Begin design / implementation of additional base buildings
Week 5 (June 11):

  • First evaluation
  • Continue base building implementation
    • Create and implement weapons that can be added to bases / additional base buildings
    • Set up a system for allowing bases to be destructible (and repairable)
  • Rework flora / tree generation with new L&S-specific assets
Week 6 (June 18):

  • Implement NPC mob spawning, pathing, combat
Week 7 (June 25):

  • Implement NPC AI -- Reactions to opposing faction NPCs, reactions to opposing faction players, reactions to opposing faction bases / buildings
Week 8 (July 2):

  • Create mechanic (ex. specific tool) for player to perform faction conversion (ex. convert unaligned flora to faction-specific flora)
  • Determine and implement benefit from faction conversion
  • Create and implement “lobby box” for player to choose faction
  • End of Milestone 2 -- all secondary goals completed
Week 9 (July 9):

  • Second evaluation
  • Implement basics of resource-gathering mechanic (ore)
  • Implement basics of power mechanic (ore needed to generate power, which improves weapons)
Week 10 (July 16):

  • Implement individual player scores / rankings / level based on ingame performance
  • Implement wearable equipment and equipment crafting / upgrades
Week 11 (July 23):

  • Evaluate current multiplayer support and provide fixes to easy problems, document larger problems
  • Investigate procedural map and custom map implementation. Provide as much of a solution as can be developed in this time; document what still needs to be done
Week 12 (July 30):

  • Final additions and code review
  • Completing additional documentation and comments where necessary
  • Evaluating and documenting what goals were completed, what still needs to be done overall
  • End of Milestone 3 -- stretch goals either completed or documented as future possibilities
Post-GSoC (Aug 6 - on):

  • Final evaluation
  • Final code submission and project summary
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Very nice write-up! Especially since the application period isn't even open yet :)

As a general note that proposal is packed - I imagine you could work on all that stuff for a year or longer, unless you're just an absolute code writing monster :)

I would suggest picking a few of the major concepts and extend on the technical details, to better estimate scope. It is very typical especially for GSOC proposals to underestimate just how long it can take to get the smaller details done for individual items, if you just have the high level targets. Let us take on CTF as an example

CTF high level targets:
  • There is some sort of flag
  • There is a transfer mechanic of the flag between players
  • There is some sort of scoring and rounds
That seems simple enough, but that is deceiving. Really solid CTF with a good feel for players could probably take up nearly an entire summer on its own. Lets consider some challenges
  • How do you visualize the flag to make it clear to players where it is? Especially while held by a player? If you want the physical object to be visible you might be looking at attaching a second model object to the player model and keeping the two in sync. Alternatively you could attach a bunch of particle effects to wherever the flag would be, which is probably easier but would take some investigating of the particle system plus experimenting with something that looks good
  • What would be a natural transfer mechanic that would feel smooth with current gameplay? Player death is a simple choice, but it isn't necessarily simple to arrive at right now as our combat system is still somewhat shaky. Also on death of a player you might encounter some timing issues as to when the player/client dies vs when the flag would detach. Finally if the flag carrier dies, how do you respawn and jump right back into the action? Would it be frustrating to just be served a respawn screen and you start over?
  • For scoring and rounds how do you configure the various details? You don't necessarily want to put into the proposal that "Rounds will last 15 minutes and a player who remains still for 1 full minute will automatically drop the flag" then hard code all that, but instead cover how an author / game admin would set it up and what options they'd have available. You might want a series of in-game console commands that would configure the gameplay, or even prepare a "control center" (imagine a visual score board built out of blocks with a technical booth below it) where players with access could click buttons that would change the display on blocks indicating current game config
Now, you don't have to exhaustively detail these things on the proposal, but you need to show you understand the details that will be required to fully implement one concept, and that you've considered the scope in the overall setting of the proposal as a whole :)

For something like CTF I would suggest considering a series of items with cooldowns and maybe avoid player death completely:
  • Flag stealing raygun: can fire every x seconds, shoots out a line of particle effects and if a flag bearer is hit some extra particle effects trigger and you steal the flag. Maybe the range on this is relatively short
  • Flag disruptor raygun: longer range but makes the flag drop instead of stealing it
  • Shield: use to give yourself invulnerability to flag stealing for x seconds, use some nice particle effects around the player while active. Naturally has a longer cooldown between uses
  • Boost: use to give yourself a brief burst of extra run speed, higher jumps, multi-jumps, or similar (check out the Potions module for examples, could likely depend on it directly)
  • Repulsor raygun: can fire every x seconds like the flag stealer, but instead pushes back other players (doesn't steal a flag). Could possibly affect a dropped flag, throwing it around
  • Attractor raygun: Guess :D
Imagine now if all that was hiding underneath the high level goal of "Implement CTF" - does the scope suddenly look bigger for that one item? :)

You could pick a smaller "minimal viable product" (MVP) set of functionality then shove a lot of extras into the stretch goal section. For instance maybe a CTF map could involve obstacles or even interactive defensive structures like turrets that blast repulsor rays every x seconds. Or indeed side quests to claim more territory for your faction which grants added benefits of some sort. Or let the player pick a class (chess piece) with special abilities (faster, shorter cooldowns, unique items ...)

You don't at all need to jump on making this into a CTF item extraordinaire just because I picked that as an example to expand on, but consider each part of your proposal with this in mind - how big is each item really? Do you want all of them or would it be better to dig deeper on a few specific items?

Some additional bits of specific feedback:
  • Due to the complexity of AI you might want to move multiplayer considerations to the core gameplay, so it is easier to test (writing CTF-capable bots could be its own whole GSOC item)
  • However, PVP you might not want along with it, instead perhaps consider some explicit "tagging" of sorts for CTF like I describe above.
  • Faction choice should probably also be up front and center on even joining the world. Like spawn players on the faction choosing platform in L&S to pick sides (red vs black) or just be a passive observer (white)
  • Destructible bases is a can of worms. Huge amount of potential, but also huge amount of possible complications. Again could probably be its own whole GSOC item to solely build up / tear down bases rather than just run around predefined areas
  • I would stay away from crafting entirely as well for any sort of MVP write-up. Very cool but also very big.
  • Stretch goals don't go into the timeline :D Then they wouldn't be stretch goals!
You're in the somewhat cool situation where you could probably write a larger "Future possibilities!" section than the entire remainder of your proposal, since the L&S concept is so rich with ideas. You could also quite possibly achieve a bunch of them - but I would suggest first cutting back on your outright core goals dramatically :)

Since particle effects are a relatively straight forward way to indicate a lot of stuff you might want to start digging around in that system during this early period, to get a feel for how it works and what might be missing for it to work well in repetitive gameplay. Like we suspect there might be an entity leak where some effects do not fully finish / clean up, leading to performance issues.
 

dacharya64

Member
Contributor
Thanks for all the suggestions!

Here's a second draft of the proposal: https://docs.google.com/document/d/1jCgZtg78jGBTu3KNzxFbrDIJ0beEWK-dzr-53P_JN5o/edit?usp=sharing

+Gets rid of tutorials to do section
+Breaks down MVP in timeline into more actionable steps and time estimates
+Rearranges priority order of tasks and takes out less relevant ones
+Adds the system of tagging / rayguns and skills (shield, boost)

As always, would appreciate any feedback on it.

Goals:
MVP
The MVP aims to cover all elements needed for a successful core game loop, and all elements should be completed by the end of Google Summer of Code.

  • Capture-the-Flag (CTF) gameplay mechanic -- Players will compete to capture a relevant “McGuffin” (ex. flag) from the other team’s base, and return it to their starting base. When a player satisfies this goal their faction wins the round, and the level will be reset.
  • Factions -- Players, NPCs, and other relevant in-game objects will be given divided into factions (red, black, unaligned).
    • Factions will determine the team of the player and the player’s base
    • Players can choose their own faction (ex. from menu or in-game dialog)
  • Bases -- Each faction will have its own base (structure) that will contain the team’s flag
  • Scoring -- Score is determined by the number of successful flag captures made by each faction
  • Map / Level Design -- The level(s) will consist of a finite, somewhat symmetrical world with bases placed at either end. The world will have varying terrain features that can help/hinder players
  • Multiplayer Support
  • Tagging -- Players can transfer the flag from one to another through getting tagged with weapons by other players
Secondary Goals
Secondary goals will be met only after MVP completion. Features that would be nice to have but are not necessary for the core game mechanics of the module, and may not all be completed by the end of Google Summer of Code.

  • Adjustable Settings -- Different elements of gameplay can be adjusted via menu or console, such as round time limit and level map
  • Quest system integration -- Completion of tasks that benefit your faction are built into quest notifications
    • Collection quests (ex. Convert 10 flora to your faction’s side) give some additional benefit to your faction
    • Victory condition quests must be completed for the player’s faction to win the round (ex. when holding the flag, the quest “Return to base” appears in the Quest pane
  • Procedurally generated maps -- Placement of base position and terrain varies within certain constraints, but level is roughly symmetrical
  • Custom map support
  • Additional UI -- details on who is in the game, which player is aligned with which faction, and scores from previous rounds will be accessible on screen or in menu (ex. Tab menu)
  • Base building -- Players can add onto their base to help defend it
    • Secondary structures, such as guard towers, can be constructed and fortified with crafted weapons
    • Resources placed throughout the world can be mined in order to craft new base structures
    • Crafting could potentially expand to other elements such as traps and power-enabled weaponry
  • Faction conversion -- Unaligned items can be “taken over” by players to convert them to the same faction as players. This provides some benefit to the player’s faction (ex. faction-specific flora hinder movement of opposing faction members)
Stretch Goals
Stretch Goals are to be completed if all previous goals have been met. Likely span beyond the scope of Google Summer of Code, and detail future possible plans for development

  • Custom characters -- Players can choose their avatar (different chess pieces)
  • Support for more than two factions
  • NPC Implementation -- AI, Pathing, Commanding and ordering NPCs
  • Player Scores
    • Individual scores -- Players get individual scores based on their play, such as time with the flag, number of items converted, etc.
    • Player levels / rankings
Destructible bases -- Bases and other secondary structures can be damaged by the opposing faction

Timeline:
Pre-GSoC (Apr - May):

  • Connect with appropriate mentor(s) and community bonding
  • Continue to explore code base through appropriate tutorials and issue fixes
  • Evaluate current L&S module, seeing what currently implemented, functional
  • Relevant PRs to the current L&S module to fix conflicts with develop and master branches
  • Review current information on potential project directions and reach out to community about suggested work on L&S
Week 1 (May 14):

  • Initial map design / generation and soliciting feedback / iterating through redesigns
    • Generating a finite, symmetrical world that is fairly featureless, and placing placeholder bases/flags on either end
    • Brainstorming and reviewing past ideas on creating various terrain features (hills, forests) and regions; researching how to implement them
Week 2 (May 21):

  • Faction system
    • Each item capable of having a faction (ex. player, NPCs, flora, flag) will be associated with a faction. Interactions with in-game items will be dependent on factions
    • Players new to the world will begin the game on the spawn platform, and will be able to select a faction (by default unaligned) through a dialog
Week 3 (May 28):

  • Flag mechanics
    • Flag be picked up by only by player of opposing faction when flag is at spawn point (ex. block that can be destroyed and picked up based on attacker’s faction)
    • When a player holding a flag is tagged (see below), flag is placed into the world at place where player was tagged and removed from player’s inventory
    • When dropped, flag can be picked up by opposing faction player (added to their inventory) or friendly faction player (flag moved back to spawn point in base)
    • When a player holds the flag, the player has a particle emitter attached to them (indicating to others that they are holding the flag)
Week 4 (June 4):

  • Score system
    • When player returns opponent’s flag to their base, level is reset and score increments
    • Score UI placed onscreen showing current score of both teams
  • Victory condition implementation for individual rounds
    • Figure out and implement what needs to be met in order for a team to win
      • In each round: successfully capture the flag, timer, etc.
    • On round win, reset map
Week 5 (June 11):

  • First evaluation
  • Weapons with cooldown
    • Research any current implementation of guns in Terasology (ex. Sample, BoomSticks)
    • Weapons only affect players from opposing factions (ex. red team player can only harm black team members)
    • Weapons are equippable and shoot out a raycast (shown through particle effects) from the player’s position towards the direction player is facing, for a given distance. If the ray intersects with another player, this constitutes a hit.
    • Flag stealing raygun: short range, on hit attacking player steals the flag from the opponent
    • Flag disruptor raygun: longer range, on hit opponent drops flag
Week 6 (June 18):

  • Skills with cooldown
    • Shield: temporary invulnerability to flag stealing guns, with longer cooldown. Denoted through particle barrier around shielded player
    • Boost: temporary increased movement speed for boosted player
Week 7 (June 25):

  • UI support for weapons, skills cooldown
    • Inventory bar shows weapons and skills, when usable and non-usable, and time remaining before cooldown finishes
  • Continued multiplayer testing of weapons, skills (players can hit one another, and can see when other players have the flag)
Week 8 (July 2):

  • Create way for player to adjust settings of round (ex. in-game control panel, menu settings, console commands)
    • Only allowing host to adjust/ select settings? Or all players?
    • Do changes take place at the start of the next round? Or are settings only adjustable before play/round begins?
  • Implementing victory condition for multiple rounds
    • Determine what is needed (ex. number of rounds needed to win) for a team to win overall (ex. first to a certain number of points, or three of five rounds)
    • Possible to implement more than one, and have requirements to win adjustable by the player
Week 9 (July 9):

  • Second evaluation
  • Design bases for red and black factions
  • Construct bases and implement appropriate base generation and spawning on world creation
Week 10 (July 16):

  • Research / discuss what additional buildings can be placed within the world
    • Are they craftable? What components do you need to craft them?
    • What benefits do they provide?
    • How are they placed within the world? Are there limited spots where you can construct structures?
  • Begin design / implementation of additional base buildings
Week 11 (July 23):

  • Create and implement weapons that can be added to bases / additional base buildings (ex. Larger scaled versions of the different kinds of guns)
Week 12 (July 30):

  • Final additions and code review
  • Completing additional documentation and comments where necessary
  • Evaluating and documenting what goals were completed, what still needs to be done overall
Post-GSoC (Aug 6 - on):

  • Final evaluation
  • Final code submission and project summary
 

SuperSnark

Lore Master
Contributor
Design
Art
Hi Devi!

I'm the creator of the "Light and Shadow" concept and I'm extremely excited that you're interested in further developing it. I'm strictly an Art/Design guy, but if you have any questions that I can answer or help with, please let me know.
 

dacharya64

Member
Contributor
Thanks for the comments, Cervator! And good to hear from you, SuperSnark! Is the best way to reach you here or a different channel?

I think I'll leave this draft sitting here a few more days for comments / review, then do another pass and submit that version to the GSOC website.
 

SuperSnark

Lore Master
Contributor
Design
Art
Is the best way to reach you here or a different channel?
This is probably the best way. Cervator and I know each other in person as well, so if for some reason I'm not responsive he has lots of ways of bothering me. ;) That said, if you start getting into it and want to talk more frequently, just let me know and I'll give you some additional contact info.

Again - I'm super excited you're taking this on. It's been YEARS since we started work on this and it's wonderful to see activity on it. :)
 

dacharya64

Member
Contributor
Posted the link above with previous corrections to the Google Summer of Code website!

@SuperSnark, is there anything else you'd recommend taking a look at or taking care of before GSoC begins?
 

Skaldarnar

Development Lead
Contributor
Art
World
SpecOps
Hej @dacharya64, that is a solid, although still very broad proposal :)

I've left a bunch of comments on the GDoc with some feedback for further refinement. As @SuperSnark I'm super excited for LaS to be brought a bit further. The concept and lore has so much potential to become a unique and fun game mode for Terasology!

In order to further improve the proposal you might think about technical pain points. Try to break down each item into the technical steps and find out whether you'll need further enablement by the engine or other modules. This can be something simple like "load a given map for the game mode" or "reset the world" that might depend on a lot more than you might think initially.
Depending on the results of detailing out the proposal, you might want/need to shrink the scope, or adjust it further.
 

oniatus

Member
Contributor
Architecture
I like the concept of L&S a lot, promising to see a nice proposal :thumbsup:

The timeline looks way too stuffed for me though :eek:.
I would suggest to start with the bare minimum which is fun like capturing a flag on a flat plane and let the player with the flag walk a bit slower or so. Then start to build on top of it, like scoring, win conditions, buffs etc, maybe add UI elements later on.
That alone could be like one-two months with ease ;)

Overall try to reduce the scope, if the focus is CTF, stick to it and move base building, crafting, pvp combat, equipment, npcs and world generation out of the timeline as long as they are not absolutely mandatory for the "fun" part of the game mode.
If the focus would be npc factions, maybe eliminate the CTF element and stick to npc combat without players fighting but placing blocks or so.
My main expectation for a gameplay setting would be to maximise the funny features and game content and cut down on technical things as far as possible. Especially new systems like factions or base building but also modification of existing systems like NPC can grow to huge complexity drivers very fast. Own experience: Needed a npc -> startet to fix behavior -> got lost in behavior stuff -> no new npc ever :gooey:
 

Nihal Singh

Member
Contributor
World
Hunter
Just went through the proposal, good work :D

Before building Lost for my GSoC, I had gone over the whole concept and lore of L&S. I feel it has great potential and would definitely be something fun to work on.
As others have pointed out already, you're probably underestimating the time that can go into some of the items. Things like multiplayer quirks can become hard to figure out and easily become too complicated. I believe that the CTF would largely depend on PvP combat (although you have it as a stretch goal), and it might end up taking a bulk of your time if you choose to go at it.

Your timeline might end up being too tight. I would recommend adding 1 or 2 buffer weeks in between to make sure you have time to deal with unexpected problems that show up. If all goes well, you could use that time to work on a stretch goal or better document the work you've done. Shifting a few more items (like NPCs, combat and their AI) at this stage, would be something I'd recommend. (was looking at older proposal).

I've left more messages as comments on the doc.

Also, please update the first message of this thread with the second draft of your proposal.
 

SuperSnark

Lore Master
Contributor
Design
Art
Posted the link above with previous corrections to the Google Summer of Code website!

@SuperSnark, is there anything else you'd recommend taking a look at or taking care of before GSoC begins?
As others have recommeneded, keeping it simple to start is my only recommendation. The concept for this game grew quite expansive as I was working on it. Four years down the road and there's still no game. I'm hoping my original ideas weren't so grandoise that they scared away developers. So I would just say, take the components you think you would personally most enjoy from the concept and turn that into anything playable. I would count that as a success! If you're having fun with it, chances are higher that we will make it to a finished state. :)
 
Last edited:

dacharya64

Member
Contributor
Thanks for all the feedback and comments! I worked on simplifying some of my timeline and adding in some buffer weeks to take progress and pacing into account. I've uploaded the final .pdf version of the proposa to the GSoC website, and I'll update the first post on here with all the drafts so far for posterity.
 
Top