Announcement

Collapse
No announcement yet.

Reimagining of Greed [BluePrint]

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    Originally posted by RattleSN4K3 View Post
    The are several reasons why mutators (of any type, custom or official) aren't supported. The main reason is that you expect exactly one case. For instance, the damage check which includes scoring. You cannot assume that "ReceiveAnyDamage" is the final damage and will kill the player if the damage is greater or equal than the health. A mutator can prevent death. Also, there isn't a need to replace the character class (which also limits mutator support in some way). There are several other reasons.

    PS: You guessed it -
    True, but there is really no sense in playing this with a mutator that overrides a basic mechanic such as death.
    There are always things that we can and can't do. Not every GameMode will be compatible with every mutator out there. At least for me, it makes sense.

    PS: I was originally planning a third Greed mode that was exactly like Kill Confirmed, but I decided to ditch it. I felt that it didn't differentiate itself from TDM all that much.

    Leave a comment:


  • replied
    The are several reasons why mutators (of any type, custom or official) aren't supported. The main reason is that you expect exactly one case. For instance, the damage check which includes scoring. You cannot assume that "ReceiveAnyDamage" is the final damage and will kill the player if the damage is greater or equal than the health. A mutator can prevent death. Also, there isn't a need to replace the character class (which also limits mutator support in some way). There are several other reasons.

    PS: You guessed it -

    Leave a comment:


  • replied
    Originally posted by RattleSN4K3 View Post
    I just meant to be official. If C++ or Blueprint is actually irrelevant (but I think the devs prefer C++ for obvious reasons).
    I'm not sure if something which originally belonged to an expansion pack (and we usually know that most of CBPs were community made back in 2k4), can be classified as an "official gametype". And all the more when we saw in the past, that Epic's intentions were to have DM, TDM, CTF and Duel and some slight variations of those, as the basic core-gameplay. After that initial stance, the only thing that was ever heard about other gamemodes, was for Domination, Assault, BR and Invasion, and basicly what they said was "if you want it, code it yourself, because we don't have time". Maybe there wasn't a mention of Greed because it's official integration for UT3 was something that was pretty recent, compared to all those other gamemodes which the majority of them have been around since UT99.

    Originally posted by RattleSN4K3 View Post
    If such official gametype is in the core game, many mod authors don't have to rewrite code. Also, mutators for specific gametypes (such as Greed or Freezetag) can only be done these are official.
    The rewriting of code is always subjective on what you want to do with the mutator. Because if you want to alter a behavior which is part of the gamemode, you will be rewriting it.
    I'm not sure where you are seeing that mutators are not compatible with my gamemodes. Lowgrav, instagib and so on, work just fine with it. If we are speaking for custom mutators, the problem is that one of the crashes that prevented the gamemode from being playable in the game (although it worked fine in the editor), was caused by the constructor of my pawn making a call to the parent function.

    Originally posted by RattleSN4K3 View Post
    Extending Blueprint assets would also cook the original gamemode assets. Versioning won't be possible. That's also the case for maps which do include the cooked gamemode/mutator. Once cooked with a gametype/mutator and by updating the original gamemode/mutator, the map has to be updated has well only to "include" the used gamemode.
    Yes, but that's a problem that concerns Assault primarily. The assets that I'm using, most of the cases have dynamic placement and coloring. They don't require new maps to be made, they adapt to maps that are meant for other gamemodes. It'll take drastical changes, or terrible map design in order to break it.

    Originally posted by RattleSN4K3 View Post
    Also, source code versioning is more suited for text based programming ^^.
    I agree, pretty much, here.

    Originally posted by RattleSN4K3 View Post
    I know. But limited. And also way slower to develop complex non-content gamemodes/mutators.
    Indeed they are limited and hacky. And when you raise complexity (like with FreezeTag) it can take months to even reach a playable state (most of the time being, waiting for features that you need, to get implemented).
    But that's the approach that Epic wants too, I'm afraid. They are concerned with security risks, so you can't just simply write C++, you will just receive zero testing/playtime.
    Basicly, what they ideally want is what happened with Domination. TimEh started with a blueprint version, Epic saw that it was playing well, and they asked him to convert it into C++ so it can be integrated into the core. They want gamemodes to be prototyped in blueprint and then tested from a gameplay perspective. Then if they work well, and they decide that "hey we want this into the core game", they will bother looking for a C++ version of them.
    At least one thing that I give to the blueprints, is that they are hella easy.

    Originally posted by RattleSN4K3 View Post
    There is a reason why Bot support is not existing in Blueprint .
    Because Mysterial said it's impractical and non-efficient. But I believe that they could at least make some simple core functions in C++, that we could control over blueprint. I mean come on, how hard can it be to turn the AI on/off?
    Another solution is what we discussed in the past, having a C++ plugin work in tandem with the blueprint. Since the AI controller never gets transmitted to the clients, we have no issues, it's a win-win workaround.

    Originally posted by RattleSN4K3 View Post
    You'll see. Just a teaser. It will have Bot support, supports all existing gamemodes (only officials are tested), comes as gametype as well. Similar to Greed but without bases (planning to work on a algorithm for symmetrical/asymmetrical CTF maps). Started on 13th October with the main intention to see how to improve Blueprints.
    Hmm, I smell kill confirmed.

    Originally posted by RattleSN4K3 View Post
    I just checked your code, there are several gamemode concepts you could use instead. Also, there are missing checks to support mutators etc.. The code could use a bit of improvment . This is out of the scope for this release thread.
    I'm not entirelly sure of what I could use, and what I'm missing. So, by all means, feel free to contact me.
    I'm usually on IRC most of the time, and you can also have my IM information, if you'd like. I believe it's not only myself, but Vlad and Wail can also benefit from any additional information you can offer.

    Originally posted by Megasporwic View Post
    FrostbyteGR this is great news! Finally we have Greed! Thank you so much! I just loaded this on the Mega--Chicago Hub under the MegaMode Tab. It took all of five minutes! Feel free if anyone wants to try it! I Played two matches against the bots..and it was fun. I was a bit lost at first til I realized I had to cap skulls at my own base "guess I should have read the instructions first " I will be testing this more tomorrow! Thank you again for your hard work and dedication to this game!
    Much appreciated that you went through the trouble to host it on your hub.
    And yeah, you have to capture them back at your own base. After all, it's not a 1:1 copy of Greed, it's a reimagination of it.

    Originally posted by RattleSN4K3 View Post
    Because of that, I would suggest to rename it (to "Harvest" ) or change the game mechanic.

    Greed is generally encouraging players to attack while this iteration would result into a camp fest. Once a team scored, they can defend their conduit/base. Every incoming player (while they trying to attack the conduit or kill player) will either fail and getting killed, resulting into another score for that camping team, or being succesful in killing the enemy. But after killing such camping players, they still have to manage to get from the enemy base to their own base while not being killed by the respawning enemies or the ones who are still camping.

    I've also justed tested/played it (before I was only checking the source and assets). There are issues with it by playing it offline:
    - No visible skulls
    - Particle effects
    - No conduit base

    Most of the functions you are using are only replicated and not working offline. As said before, the code could need some re-work. Let me know if you need some guidance or help.
    True, original Greed had you score at the enemy conduit. And it would also give you AMP each 10 skulls you collected. (which I think is a bad idea, because you're just making the strong guy even stronger)
    The thing is, while my iteration can promote camping as you said, the other way around might promote spawnkilling and baserape, which is something that I don't particularly want either. At least with this iteration, and the ConduitDamage toggle, camping can backfire. A well organized attack can wipe out the entire defence and leave the conduit exposed to damage. I could also introduce respawn delay, but I'm not sure if that would alleviate or worsen the problem at hand.

    The offline scenario that you mentioned, can happen on listen servers and is only exclusive to the host. The conduits and bases are there and they are fully functional, the problem is that the colors depend on replication, and therefore everything is colored black. If you set it not to replicate, then you will have colors when you do a listen server, but you won't have colors in any other scenario. I would indeed like some advice on how to tackle this, because I haven't faced such an issue before with FreezeTag.

    About the particle system, it's basicly driven by a RepNotify variable. Everytime your SkullInventory fluctuates, I have an accumulator (which is fed to the particle system's spawn module) that calculates how many skulls you are carrying in total, and for some reason this updates correctly half of the time.
    In my previous iteration I would just have an integer variable that would represent how many skulls a player is carrying (that's what I use in Avarice) and that value would be fed stright to the particle system's spawn module. However I didn't like that, because whenever I had to spawn enemy skulls, I would have to do foreach loops to find the enemy team index and color information, and it wouldn't support 4+ teams. I'm not sure why it doesn't update properly, but I will think of a workaround to make it consistent.
    Last edited by FrostbyteGR; 10-29-2015, 01:41 PM.

    Leave a comment:


  • replied
    Now there's a flip... usually my projects works fine offline. And doesn't replicate online LOL

    Leave a comment:


  • replied
    Because of that, I would suggest to rename it (to "Harvest" ) or change the game mechanic.

    Greed is generally encouraging players to attack while this iteration would result into a camp fest. Once a team scored, they can defend their conduit/base. Every incoming player (while they trying to attack the conduit or kill player) will either fail and getting killed, resulting into another score for that camping team, or being succesful in killing the enemy. But after killing such camping players, they still have to manage to get from the enemy base to their own base while not being killed by the respawning enemies or the ones who are still camping.

    I've also justed tested/played it (before I was only checking the source and assets). There are issues with it by playing it offline:
    - No visible skulls
    - Particle effects
    - No conduit base

    Most of the functions you are using are only replicated and not working offline. As said before, the code could need some re-work. Let me know if you need some guidance or help.
    Last edited by RattleSN4K3; 10-29-2015, 09:23 AM. Reason: Typos

    Leave a comment:


  • replied
    FrostbyteGR this is great news! Finally we have Greed! Thank you so much! I just loaded this on the Mega--Chicago Hub under the MegaMode Tab. It took all of five minutes! Feel free if anyone wants to try it! I Played two matches against the bots..and it was fun. I was a bit lost at first til I realized I had to cap skulls at my own base "guess I should have read the instructions first " I will be testing this more tomorrow! Thank you again for your hard work and dedication to this game!

    Leave a comment:


  • replied
    Originally posted by FrostbyteGR View Post
    My C++ is not up to par, and I doubt I would get much testing, due to those limitations.
    I just meant to be official. If C++ or Blueprint is actually irrelevant (but I think the devs prefer C++ for obvious reasons). If such official gametype is in the core game, many mod authors don't have to rewrite code. Also, mutators for specific gametypes (such as Greed or Freezetag) can only be done these are official. Extending Blueprint assets would also cook the original gamemode assets. Versioning won't be possible. That's also the case for maps which do include the cooked gamemode/mutator. Once cooked with a gametype/mutator and by updating the original gamemode/mutator, the map has to be updated has well only to "include" the used gamemode.

    Also, source code versioning is more suited for text based programming ^^.

    Originally posted by FrostbyteGR View Post
    Blueprints are equally good if you do them the right way though.
    I know. But limited. And also way slower to develop complex non-content gamemodes/mutators. There is a reason why Bot support is not existing in Blueprint .

    Originally posted by FrostbyteGR View Post
    Thanks! Looking forward to what you have in store.
    You'll see. Just a teaser. It will have Bot support, supports all existing gamemodes (only officials are tested), comes as gametype as well. Similar to Greed but without bases (planning to work on a algorithm for symmetrical/asymmetrical CTF maps). Started on 13th October with the main intention to see how to improve Blueprints.

    Edit: As I see your signature. Well it is also similar to Avarice. ^^


    I just checked your code, there are several gamemode concepts you could use instead. Also, there are missing checks to support mutators etc.. The code could use a bit of improvment . This is out of the scope for this release thread.

    Leave a comment:


  • replied
    Originally posted by HenrikRyosa View Post
    someone post vid asap.
    I've contacted Zaccubus, and he's probably going to make a showcase video. No idea when he will be able to find time to get it done though.

    Originally posted by RattleSN4K3 View Post
    I thought this should be official ^^ (and C++). I also got a quite similar mutator/gametype in the pipeline. Good work, Frostbyte.
    My C++ is not up to par, and I doubt I would get much testing, due to those limitations.
    Blueprints are equally good if you do them the right way though.

    Thanks! Looking forward to what you have in store.


    PS: For anyone wanting to try out the GameMode, you can also find it on my hub: [GR] Zeus HUB.
    It's not the best regarding ping and performance, if you are not in Greece, but it gets the job done for the time being.
    Last edited by FrostbyteGR; 10-28-2015, 10:16 PM.

    Leave a comment:


  • replied
    I thought this should be official ^^ (and C++). I also got a quite similar mutator/gametype in the pipeline. Good work, Frostbyte.

    Leave a comment:


  • replied
    someone post vid asap.

    Leave a comment:

Working...
X