long time no see
really wip, still a lot left for me and my art buddy to do
long time no see
really wip, still a lot left for me and my art buddy to do
@Curiosichi: In the example game where I have made the skills, current move is actually never reduced. It is purely action point based. This explains why you are still able to use the move skill after moving once. Movement takes one action point and you have two total. You can prevent your units from activating their skills by using a check like the one you suggest. I would add this check before Parent:ActivateSkill is run, though, since you do not want to activate the skill at all if the check returns false. Also, for the move skill you will need to make sure CurrentMove is actually reduced when you move somewhere. A good place to do this is in the DecideActionForClickedTile comment box in Skill_Move, after action points are reduced. If you do this, then I think it should work as you want it. Let me know if it does not.
@Selentic: Looks fantastic! Great to see that you’ve made such amazing progress. Cannot wait to play some cel-shaded warfare. Let me know if you make a progress blog or something, as I’d love to follow your progress
Yup, aside from changing the check from owning unit to the incoming casting unit (since owning unit is set in the parent cal of the spell), everything is working as desired.
Your help has been tremendous and really sets me off to create new skills with excitement. Thank you thank you!
@Curiosichi: Glad it worked I apologize if the organization of the skill system in the example game is a bit less intuitive than the base toolkit. The features in the example maps are a bit more experimental than the rest. One of the changes I’m working on is making the skill system a part of the base toolkit and in the process I’m organizing it in a way that is more straightforward. The general logic behind the skills is mostly the same, though, so you should be able to port over any skills you make quite easily if so desired when I complete the update.
Anything significant will end up on my artstation (or here in this thread), so you can follow me there if you want.
I might do a blog in the future, as there’s not a lot to talk about right now since all the really important game mechanics were finished months ago (make multi tile units tho plz). A lot of the work right now is just defining the style and keeping it consistent, while making sure we’ve got good visual clarity going. I’ll let you know if I end up making one though!
Ok, great I’ll check it out periodically, and feel free to post any significant progress in this thread
Your talent as well as that of your art buddy is apparent from your ArtStation profiles, so I’m super excited to see the finished game. Best of luck!
It’s been a long time since my last post and I see that project is really flying high now with built-in multiplayer support and multi-tile units.
BTW, regarding UE4 Framework multiplayer system, can you give some clues on how are you doing it?
Because, as far as I know, GameMode Blueprint should exist only in the server and my old version of ATBTT does a big rely upon GameMode Blueprint almost everywhere (PlayerController, Grid Manager… almost every blueprint gets GameMode and use it or its properties).
So, since I’m really curious about it, can you tell when you will release this new version? And also: coming from an old version will it be so much terrible to get this new multiplayer function to work without starting my project from scratch with the new release of the toolkit (with the number of custom content I put in it would be quite a nightmare to start again)?
In addition, are you using a “Listen Server” solution or “Dedicated Server” one?
Thanks in advance and thanks for your precious time investment in this great project.
Hi Wisdom-HELLy, long time no see! You are right that the way the game mode is used is a bit awkward for networked multiplayer. Same goes for the player controller. It is possible to get around most of that by using RPCs to the server etc., but it is not ideal. Because of this, much of what is handled in the game mode has been moved to a custom blueprint for managing turn order (BP_TurnManager) and the game state. As for the player controller, everything that happens after input is registered is done in skill blueprints. There is a default skill (BP_Skill_Default) that is used if the user does not want to use the skill system, which functions like the player controller did before.
It is hard to know how long it will take to finish the update. A rough estimate (which might be very inaccurate) is three months (taking delays due to summer vacation into account). It will be more difficult to convert to this update from previous updates than has been the case before. I’m going through all blueprints and I’m being quite merciless when it comes to making changes anywhere I feel things can be improved, simplified or clarified. I’m not keeping anything just for the sake of having it be similar to earlier versions. That being said, the general framework is still quite similar, and I hope most games should be able to port their additions over to the new version if they put in a few days of work.
Thanks for the ETA on the feature additions! Good luck with it and the code clean up. If it is possible, do try to document how one would upgrade from your current version to the new version to make the process as easy as possible for your current customers. Thanks!
Do you have an easy way to disable the default HUD? Or manage overriding it with a custom HUD.
In the base toolkit, you have a HUDBlueprintRef set on Begin Play(), a get at HUDTurn Toggle() and referenced again by Non_Nativized_Functions for displaying game over.
To override the functions that use it without changing the base toolkit, would I need to create a copy of Event Begin Play in a child blueprint just to change the HUD generations portions of the base toolkit? That seems a bit clunky… In the example maps, you create a reference to new UI elements in the child grid manager instead but they only overlay the base UI, which to me makes obvious sense that a custom UI goes with a custom game mode/grid manager/player controller, but I want control over the whole UI.
edit: blarg I wrote a huge wall of text explaining how I did this then unreal forums decided I wasn’t logged in while typing into the quick reply…, but I accomplished this by basically copying parent/base toolkit code into the children custom bps. As I stated above, its clunky, I am no longer calling to the base class for begin play, kill unit, copying the Non Nativized functions file and using my pawn with skills to refrence it instead of counting on the base pawn to set that.
While I got it to work, it feels wrong, this is basically just copying your base classes to my custom, so my question still stands. Is there a better way to do this while retaining your base blueprints.
I’ll repeat that I might be completely off the mark regarding the ETA, but it is the best guess I could make. I’ll have to think about the best way to log all changes. It will be tricky to list everything, but I’ll note all the big structural changes at the very least.
I’m not sure there is a super clean way of overriding the HUD functionality without altering the base toolkit. Your solution is actually pretty much how I would do it if I was forced to do that myself. I’m not sure I see the point of not altering the base toolkit, though. In the next update the HUD-setup will be completely changed anyway, so keeping the old HUD-nodes intact won’t wake porting your game to the new version any simpler. So unless there is not some other reason for not touching the base toolkit that I’m not seeing I would just alter it directly.
I suppose I am in the mindset the toolkit is a library and not a framework. I have this dream that I leave your toolkit in its own base folder and folder structure and when you do an update, I copy all the files from your new version into my project in the same structure and all my custom classes will not be affected or know anything changed and it compiles in one click with no other changes, only that I can add extra functionality from the parent now if I desire to in my custom child blueprints. You are starting to shatter those dreams from the sounds of it, heh.
Really getting into the project now with another developer and after dealing with something as simple as trying to change your base UI, if I no longer developed around the idea of not changing base toolkit functionality, things like removing the base ui calls wouldn’t be a concern. At the end of the day though, my dream is I can develop content while retaining your base kit functionality, because if and when you release an update, it will become exponentially more difficult to merge your new functionality into my child classes (or modified base toolkit if I stopped with this child blueprint ideology).
It seems inevitable for a production game the toolkit would become no more than a basis of foundation and learning if I go down this path of over writing base classes and I only just started to learn how it all works. So… til I cut ties with the base toolkit, I am trying to hold on to modifying anything core.
@Curiosichi: What you’re saying is understandable and for all updates save the next one, keeping the base toolkit unmodified and working with child blueprints etc. should be possible without too much of a hassle. However, the next update is special in that I’m doing a large reorganization and refactoring. Any updates after the next one should be primarily additive rather than transformative and should be a better fit with your preferred way of working. I’m sorry if this makes things temporarily more difficult for you, but for this particular update I felt like I needed to disregard easy backwards compatibility in order to make the toolkit the best it can be.
How difficult will it be to integrate multi tile units into the old version?
I don’t think it will be much more difficult than integrating it into the refactored version. For the most part the underlying logic is the same for the new and the old version, but how it is structured, variable names etc. is different. So problems will mostly arise if you want to do something like @Curiosichi, where you make all your changes to child blueprints and then update the underlying parent blueprints. Updating through copy-paste of new features should not be that much more difficult compared to earlier updates.
Hey Monokkel Hope you are well!
Come across a wierd issue that seems to have popped up overnight, not sure why.
The Pregenerate Gameplay Grids bool doesnt seem to work anymore.
The red grid lines stay there and toggling the boolean has no effect.
Had a check in the relevant functions and nothing is unhooked as far as I can see.
Edit: Checking source control as it may be the issue but just making sure.
Just bought it, so a couple of noob questions.
Hi there! There is no included functionality for rotating the camera using the mouse. It should not be very difficult to add, though. Were you thinking rotation at a fixed angle or more of a free look?
As for simulate, then yeah, that is not something I really use during development, so that there are some errors are unsurprising. I would recommend not using simulate with ATBTT for the time being and just using “play in editor”. I’m planning to look into it and fix it by the next update, though.
edit: double post.
Seems like my questions disappeared so I’ll try again!
I’m looking for a very good working grid system (with small tiles), a unit with working movement you can base other characters and units on is a big plus which is why I’m considering to purchase your toolkit! Either that or doing it my self, but 46 bucks or weeks of work, I choose the first!