GSOC Proposal: Metal Renegades

AndyTechGuy

Member
Contributor
GSOC/TSOC 2020
Here is a draft proposal for my take on Metal Renegades: https://docs.google.com/document/d/1skxQgBgLzeFCR9-9PDCMvkN-c89aL1FsQJSJt4HMwfU/edit?usp=sharing

Please comment and tell me what you think :)

Both Wabadump and I both wrote proposals for Metal Renegades unfortunately at around the same time. They released theirs first, but I still finished mine to provide a different interpretation of the forum ideas. If I can, I will gladly pivot my project in a different direction to allow both of us to work on a project :D. There are plenty of stretch tasks that I can work with in this regard (13 potential tasks!)
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Good stuff! While both proposals deal with a very wide content area I do feel like they're trending in different directions already and would be able to avoid too much overlap. Here it seems more like an AI focus a la GooKeeper with an interesting world and a lot of background simulation

Took a look at the proposal, but not a lot of feedback yet, it looks pretty good and detailed, if a bit hard to estimate the complexity of some of the pieces. That or it may not be ideal to review at near 2 am :)
 

AndyTechGuy

Member
Contributor
GSOC/TSOC 2020
I have made my second draft to my proposal, which again can be found here: https://docs.google.com/document/d/1skxQgBgLzeFCR9-9PDCMvkN-c89aL1FsQJSJt4HMwfU/edit?usp=sharing

This draft is a direction shift from earlier to avoid conflict with Wabadump, with a more extreme shift in the way of world generation and AI. It is now intended as more of a 'world base' to build gameplay upon, in particular to compliment the gameplay developed in Wabadump's proposal. The AI characters are now developed much further than before, with them travelling throughout the landscape along with the player in order to satisfy their own needs.

The writing is more detailed and specific than before, and some formatting changes really made parts of the document pop :D

There is only a few minor conflicts left between the two proposals that I can spot at the moment:
  • My proposal introduces a faction alignment system, while Wabadump's introduces a 'wanted level'. I'm unsure how I should adapt my concept to allow both, since my alignment system is central to one of my major goals (factions)
  • My proposal uses StaticCities, while Waba's uses DynamicCities
Again, please comment and suggest any improvements you might have :)
 

wabadump

New Member
Contributor
I think "Wanted Level" can easily be thought of as "alignment towards the Bad faction" for now if you're planning to implement only three factions. So once you have faction alignment, it can be shown to the player as their wanted level. My implementation would have been a superficial thing, but yours allows us to make NPCs respond to a player's wanted level as well. I think I should move mine to "stretch goals" or remove it entirely because this seems like a better way to go about it. That'll also give me some time to write tests! :D

Regarding cities, I have no idea how that'll affect your NPCs. If you just need the location of the city, I don't think it'll make much difference because sites and handled in a similar way. But if you need any information about the city's internal structure, that'll be affected. Working with #26 might be a good way to get to know how the internals of the city work.

I might be wrong but I think integration can be worked out somehow. It would depend on the extent to which your NPCs interact with the city itself and that at the moment is limited to charging themselves in houses(?).

Really need a mentor's opinion on this though :p
 

AndyTechGuy

Member
Contributor
GSOC/TSOC 2020
As far as I understand about integrating GSOC projects (I will need a mentor's verification on this), the only guideline is that the end result of the project must be independant; not directly depending on someone elses project. However after GSOC, we can merge our projects together into one unit, taking the best pieces of both. With this in mind, it doesn't really matter if we overlap slightly in some areas, as long as our main focus areas are different, which at this point they are indeed different :D

With this approach, the different between Cities and wanted levels doesn't really matter too much; when our projects merge later on we will probably take whichever parts work best from both.

(P.S. I left some comments on your proposal; looks really good :thumbsup:)
 

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Proposal reviewed again and feedback dropped in. Looking pretty good :) The AI could perhaps get tricky to apply to NPCs (managing demands etc) but simplifying a little if needed probably isn't a huge problem.

So the main requirement from the GSOC perspective is that no two student projects must depend on each other - if it doesn't cause risk for either project you could in fact merge some things together early. For instance you both naturally have desert worlds - maybe the strongest difference is then static cities vs dynamic cities and I think that both could work fine as it feels like Andy's cities are more like outposts - they aren't really living cities so much as small places where people meet up briefly?

So I think the two types of cities could later live fine in the same world, although to limit any conflicts or other issues I would suggest perhaps sharing the underlying world generator (desert etc) but make the city modules separate and keep two gameplay templates during GSOC, where each depends on one or the other city type, otherwise using the same underlying world and some of the base assets (a la LightAndShadowResources - mostly artwork, very little logic)

If some additional bits become very shared (like charging platforms) then maybe that could be in a common module much like the world generator (but not necessarily placed in the world in that module - so each variant could determine placement separately)
 
Top