[Community Project] Real Time Strategy Game. NEW MODELS AVAILABLE. SEE POST #1

[ryanjon2040]

@;123655

Well i tried to update it in a hurry and broke some things, will either fix or start over tomorrow.

Sure .

@;123655

Also if you could allow me to create a branch/update my branch on your project that would be nice

Done :). You now have your own branch. https://github.com//RTS-Community-Project/tree/

@HeadClot;123779

Sending you my Email via PM also have a few questions

Replied.

@HeadClot;123779

1. Do we have a game design document or some sort of solid plan on how this will unfold gameplay wise?

So far we have Trello and mind42 created by cstpsm.

@HeadClot;123779

2. Would it be possible to derive some “Elements” from Taylor’s Kings and Castles?

Pardon me…But can you explain what you mean by “Elements”? You mean gameplay related stuffs or art style or assets?

@HeadClot;123779

3. Do we want to target just 64 bit systems to make the best RTS we can?

Yes. I only want to support 64-bit systems.

@;123944

@ryanjon2014:

I had nothing else to do today and was bored. So I downloaded your git repository and gave it a try. I must say impressive!
However I found the camera movement and zooming too linear. I mean when you want go all the way across the map or to get a long shot of stuff below, I found that the movement speed to too slow. So I thought why not implement a curve based movement.

So I went ahead and forked your repo and implemented it. Its experimental and very basic. But seems to be working. I have created a pull request on Git if you want to check it out.

Great work . I have pushed your changes to master.

@;123944

NOTE: I created it with engine v4.4.0 I am not sure if this is compatible with the existing project, so take precautions. Another thing is unfortuantely my USB mouse driver got some problems and I cannot click-and drag anymore. So connecting the blueprint nodes is a chore and I ended up with a somewhat cluttered mess. So forgive me.

No problems at all. Am still using 4.4 Preview build. Whenever i change to a newer version, i’ll update the Readme.

[Thommie]

Thanks! I’ve pushed the changes to my branch, so should i now also push to master? i’m still a bit confused

[ryanjon2040]

@;124003

Thanks! I’ve pushed the changes to my branch, so should i now also push to master? i’m still a bit confused

I’ve pushed it to master.

[mindfane]

Hello everyone,

I dont know if you’ve noticed, but I found that there is a tiny issue with camera-zoom. The issue you cannot zoom lower than the selected character. In the default map there is a valley right behind the cliff where you have that one dwarf character. Use WASD and move your camera over the valley. Now try zooing-in. You cannot zoom beyond the cliff level. I think this is because you are actually adjusting the boom length instead of camera actors location. So it technically you cannot zoom into anything beyond the cliff. Is that intended?

Another thing is you have put some logical stuff into the HUD BP. I think its better to keep the HUD for purely cosmetic stuff. The drag-drop selection stuff could be moved into a separate actor (A new Actor BP named RectangleMarquee). Do the selection logic in that actor …also you could simply add it as part of the player controller and always reference it to get the currently selected list of actor… Then do the drawing of the selection rectangle and highlighting inside the HUD. I think this is better organized and it divides responsibilities between modules.

PS: I would have tried to implement it myself if my mouse worked :mad: (Actually USB ports are malfunctioning, not the mouse). So I will have find a PS/2 mouse somewhere.

[ryanjon2040]

@;124095

Hello everyone,

I dont know if you’ve noticed, but I found that there is a tiny issue with camera-zoom. The issue you cannot zoom lower than the selected character. In the default map there is a valley right behind the cliff where you have that one dwarf character. Use WASD and move your camera over the valley. Now try zooing-in. You cannot zoom beyond the cliff level. I think this is because you are actually adjusting the boom length instead of camera actors location. So it technically you cannot zoom into anything beyond the cliff. Is that intended?

Yeah am aware of that but not quite sure how to tackle it because of camera clipping. In the Zoom In event, if we set Clamp min value to something like -4000 camera zooms in but then it clips through the landscape.

@;124095

Another thing is you have put some logical stuff into the HUD BP. I think its better to keep the HUD for purely cosmetic stuff. The drag-drop selection stuff could be moved into a separate actor (A new Actor BP named RectangleMarquee). Do the selection logic in that actor …also you could simply add it as part of the player controller and always reference it to get the currently selected list of actor… Then do the drawing of the selection rectangle and highlighting inside the HUD. I think this is better organized and it divides responsibilities between modules.

PS: I would have tried to implement it myself if my mouse worked :mad: (Actually USB ports are malfunctioning, not the mouse). So I will have find a PS/2 mouse somewhere.

Thanks . I thought about this approach at first but i felt more easier when doing stuffs inside HUD. Should this behavior be changed? What do you think?

[mindfane]

@;124137

Yeah am aware of that but not quite sure how to tackle it because of camera clipping. In the Zoom In event, if we set Clamp min value to something like -4000 camera zooms in but then it clips through the landscape.

You are right. However I think we can make use of a trace to solve this issue. But first we must redefine the camera actor. We must use a simple collision sphere (very small sized) and with no collsion. Attach the spring arm to this and camera onto the spring-arm. And then within the Zooming-in and Zooming-out section, we must move the this Actor in or out (instead of boom). When you push scroll-down or scroll-up, we do a trace towards the camera view vector. Find the distance to the hit point along the view vector. We can zoom-in as long as this distance is greater than 0. If this condition is satisfied, we move the Actor down. The Curve is still useful . And for WASD movement, like before, we move the Actor itself.

@;124137

Thanks . I thought about this approach at first but i felt more easier when doing stuffs inside HUD. Should this behavior be changed? What do you think?

Yes, but I think its better to keep HUD purely for cosmetic stuff. For instance I had searched all the blueprints in this project looking for that selection logic before I tried HUD. Nobody expects it to be there. But I guess its only a personal preference. As long as the job gets done, it doesn’t really matter I guess.

Now if I were to do it, I would implement the selection logic within a separate Actor. I would then handle the MouseX and MouseY events within the player controller and pass it to this Actor for processing. Now later I can simply query this object from any BP (by accessing PlayerController) to get the Actors selected in the last selection.

[cstpsm]

Turns out this weekend I’ve been and will still be pretty busy with other stuff.

Anyway, I must say I agree with , especially since this entire project will be pretty huge, it would be best to keep actual (game) logic and presentation stuff apart in many cases. It’s better to do that as soon as possible, before it gets too big to refactor…

My github account is cstpsm by the way.

You’ve got some solid ideas/thoughts , I like it.

[Thommie]

@;124157

You are right. However I think we can make use of a trace to solve this issue. But first we must redefine the camera actor. We must use a simple collision sphere (very small sized) and with no collsion. Attach the spring arm to this and camera onto the spring-arm. And then within the Zooming-in and Zooming-out section, we must move the this Actor in or out (instead of boom). When you push scroll-down or scroll-up, we do a trace towards the camera view vector. Find the distance to the hit point along the view vector. We can zoom-in as long as this distance is greater than 0. If this condition is satisfied, we move the Actor down. The Curve is still useful . And for WASD movement, like before, we move the Actor itself.

Yes, but I think its better to keep HUD purely for cosmetic stuff. For instance I had searched all the blueprints in this project looking for that selection logic before I tried HUD. Nobody expects it to be there. But I guess its only a personal preference. As long as the job gets done, it doesn’t really matter I guess.

Now if I were to do it, I would implement the selection logic within a separate Actor. I would then handle the MouseX and MouseY events within the player controller and pass it to this Actor for processing. Now later I can simply query this object from any BP (by accessing PlayerController) to get the Actors selected in the last selection.

Great ideas , wish i had read them before i started working on changing the camera

I did move some functionality to the playercontroller from the hud, checking which actors are in the selection box couldn’t be moved since it uses Project.
Camera now updates according to landscape height (still very basic and needs to be improved), zooming should also be fixed now.

Camera collsion still needs to be added but i probably don’t have any time for the next 5 days.

It’s still a bit of a mess and i probably forgot to delete some obsolete things so feel free to clean up after me

[mindfane]

I had another look at the selection code. Currently we are searching through all the Actors. But the thing is many actors (like terrain, trees, static meshes…) are not going to be selectable. So why not create an interface (ISelectable) and add this to all Actors that are selectable. If we do that we can tell UE4 to fetach only those Actors who have implemented this interface. I think this will reduce our search space.

I thnik we already have a BP Interface callled ‘I_Interactable’. Could we use that one instead? Is it used by all Actors that can be interacted with? OR just AI charcters? If the former, then we can query based on that interface,

NOTE: I won’t be available for the next few days (busy with work…and its not even game related ). So I hope to rejoin by the end of the week. Good luck!

[ryanjon2040]

@;124157

You are right. However I think we can make use of a trace to solve this issue. But first we must redefine the camera actor. We must use a simple collision sphere (very small sized) and with no collsion. Attach the spring arm to this and camera onto the spring-arm. And then within the Zooming-in and Zooming-out section, we must move the this Actor in or out (instead of boom). When you push scroll-down or scroll-up, we do a trace towards the camera view vector. Find the distance to the hit point along the view vector. We can zoom-in as long as this distance is greater than 0. If this condition is satisfied, we move the Actor down. The Curve is still useful . And for WASD movement, like before, we move the Actor itself.

Yes, but I think its better to keep HUD purely for cosmetic stuff. For instance I had searched all the blueprints in this project looking for that selection logic before I tried HUD. Nobody expects it to be there. But I guess its only a personal preference. As long as the job gets done, it doesn’t really matter I guess.

Now if I were to do it, I would implement the selection logic within a separate Actor. I would then handle the MouseX and MouseY events within the player controller and pass it to this Actor for processing. Now later I can simply query this object from any BP (by accessing PlayerController) to get the Actors selected in the last selection.

Nice and Thank you for the suggestions :). did all the changes and they are now live on master branch.

@cstpsm;125012

My github account is cstpsm by the way.

Hi cstpsm. I added you on Github. You should now be able to push changes to that repo.

@;125314

Great ideas , wish i had read them before i started working on changing the camera

I did move some functionality to the playercontroller from the hud, checking which actors are in the selection box couldn’t be moved since it uses Project.
Camera now updates according to landscape height (still very basic and needs to be improved), zooming should also be fixed now.

Camera collsion still needs to be added but i probably don’t have any time for the next 5 days.

It’s still a bit of a mess and i probably forgot to delete some obsolete things so feel free to clean up after me

Thank you very much . The changes you made are fantastic. Now camera wont go past the landscape (although we can still see whats behind it).

@;125571

I had another look at the selection code. Currently we are searching through all the Actors. But the thing is many actors (like terrain, trees, static meshes…) are not going to be selectable. So why not create an interface (ISelectable) and add this to all Actors that are selectable. If we do that we can tell UE4 to fetach only those Actors who have implemented this interface. I think this will reduce our search space.

I thnik we already have a BP Interface callled ‘I_Interactable’. Could we use that one instead? Is it used by all Actors that can be interacted with? OR just AI charcters? If the former, then we can query based on that interface,

I’ve already made that change. I’ll push it to master branch now.

EDIT: Pushed it to master branch.

@;125571

NOTE: I won’t be available for the next few days (busy with work…and its not even game related ). So I hope to rejoin by the end of the week. Good luck!

Sure thing mate :).

EDIT: Just added basic functions for Resource. They are not yet collectible because i still lack assets. Looks like i still have to use cubes and spheres.

Check out on Trello.

[anonymous_user_c00c6b6c]

@;123506

This is something we need to think about seriously. TBH, canvas is not on my list. I am thinking about UMG and Coherent-UI but not sure which one to use. I want to stick with Coherent-UI but i cannot decide it alone so I will email Coherent-UI developer if he can come up with some solution. But if it aint gonna work we will stick with UMG or any other HUD solution.

Hey guys,

We really love community and open-source projects and would like to contribute with whatever we can.

Unfortunately, Coherent UI, as a commercial library needs updates and support from our side, so we can be sure that our clients are getting the best of it.
Its licensing is not appropriate for open-source projects, as we would not be able to provide the support we would like to.

I really admire what you are doing and will be glad if I could help in any other way.

Thank you so much for the support!

[cstpsm]

Hi all I’ve pushed my waypoint and patrol movement stuff to the ‘Arnold’ branch. Please check it out and help me test if it functions properly. If it’s all good I’ll clean up the blueprints/functions, properly comment everything and merge it with the master branch.

@: The check to see if RMB clicked actor is a landscape has ‘broken’ the test map, since it does not have a landscape you are now unable to move units around in it. Could you please give the test map some basic landscape? I prefer a clean and stable environment (such as the test map) to develop new stuff and I have no experience working with landscape

Does anyone have experience with test functionality in UnrealEngine? It would be nice if we could setup regression tests for functionality such as selections, camera movement, unit movement, building placement (collision detection etc.)… If we don’t have some proper tests setup, I’m afraid that we will start breaking more and more stuff as we continue to rapidly add new functionality without proper testing.

I would love to hear other peoples thoughts and experiences concerning (regression) testing Unreal Engine games.

[ryanjon2040]

@avenkov;125689

Hey guys,

We really love community and open-source projects and would like to contribute with whatever we can.

Unfortunately, Coherent UI, as a commercial library needs updates and support from our side, so we can be sure that our clients are getting the best of it.
Its licensing is not appropriate for open-source projects, as we would not be able to provide the support we would like to.

I really admire what you are doing and will be glad if I could help in any other way.

Thank you so much for the support!

Hi ,

Thank you for the confirmation.

@cstpsm;125749

Hi all I’ve pushed my waypoint and patrol movement stuff to the ‘Arnold’ branch. Please check it out and help me test if it functions properly. If it’s all good I’ll clean up the blueprints/functions, properly comment everything and merge it with the master branch.

Great csstpsm. I’ll check it out and let you know tomorrow.

@cstpsm;125749

@: The check to see if RMB clicked actor is a landscape has ‘broken’ the test map, since it does not have a landscape you are now unable to move units around in it. Could you please give the test map some basic landscape? I prefer a clean and stable environment (such as the test map) to develop new stuff and I have no experience working with landscape

No problem mate. I added a very basic Landscape (no textures) to test map and uploaded to master branch.

@cstpsm;125749

Does anyone have experience with test functionality in UnrealEngine? It would be nice if we could setup regression tests for functionality such as selections, camera movement, unit movement, building placement (collision detection etc.)… If we don’t have some proper tests setup, I’m afraid that we will start breaking more and more stuff as we continue to rapidly add new functionality without proper testing.

I would love to hear other peoples thoughts and experiences concerning (regression) testing Unreal Engine games.

Pardon me…but am not sure what you mean.

Added resource collecting. Currently its just Gold only.

&d=1408972407

[cstpsm]

@;125791

Pardon me…but am not sure what you mean.

This should cover it

http://en.wikipedia.org/wiki/Regression_testing

[anonymous_user_69377e64]

Hi

Very nice project. I watched it from beginn and finally made my first minor change. It’s to leave the build mode with right click. I hope that I can contribute much more in the future.

edit: Do i need to be added to the git rep to add something?

github name:
trello name :

[anonymous_user_673ab64d]

RyanJon and others!

Great progress! Keep up the good work. I am following this thread with interest.

[cstpsm]

@;125931

Hi

Very nice project. I watched it from beginn and finally made my first minor change. It’s to leave the build mode with right click. I hope that I can contribute much more in the future.

edit: Do i need to be added to the git rep to add something?

github name:
trello name :

Sounds like a useful addition

I’ve added you to the trello board, ryanjon can add you to the git repository and maybe even create your own branch.

Another general development question that I have is how do we properly merge branches and what happens when we have a conflict while auto merging and we have to do a manual merge? I have experiencr with normal source code files (java javascript etc) and manual merges (you get 1 file in which you can see common stuff and from where the files begin to differ)… How does that work with these unreal engine files?

And what is the desired process for merging changes to the master branch? As more and more people join in, we need to establish some kind of process to ensure we keep the quality up and don’t lose changes.

[ryanjon2040]

@;125931

Hi

Very nice project. I watched it from beginn and finally made my first minor change. It’s to leave the build mode with right click. I hope that I can contribute much more in the future.

edit: Do i need to be added to the git rep to add something?

github name:
trello name :

Great addition Timmy :). I have added you to the repo and created a branch for you: https://github.com//RTS-Community-Project/tree/

@Frederic;126050

RyanJon and others!

Great progress! Keep up the good work. I am following this thread with interest.

Thank you very much Frederic!

@cstpsm;126346

Another general development question that I have is how do we properly merge branches and what happens when we have a conflict while auto merging and we have to do a manual merge? I have experiencr with normal source code files (java javascript etc) and manual merges (you get 1 file in which you can see common stuff and from where the files begin to differ)… How does that work with these unreal engine files?

And what is the desired process for merging changes to the master branch? As more and more people join in, we need to establish some kind of process to ensure we keep the quality up and don’t lose changes.

Hmmm…Am not sure about this. I checked the Arnold branch and it says its 21 commits behind master and 6 commits ahead. So if i merge changes from Arnold to master i will lose all that 21 commits and get that 6 commits. Right?

[mindfane]

@cstpsm;126346

Sounds like a useful addition

Another general development question that I have is how do we properly merge branches and what happens when we have a conflict while auto merging and we have to do a manual merge? I have experiencr with normal source code files (java javascript etc) and manual merges (you get 1 file in which you can see common stuff and from where the files begin to differ)… How does that work with these unreal engine files?

And what is the desired process for merging changes to the master branch? As more and more people join in, we need to establish some kind of process to ensure we keep the quality up and don’t lose changes.

Yes this is an issue. I dont think we can merge binary files. I think we will have to choose one over the other.

About colloborating:
My preferred way is to use forks. Create your-own forks and do stuff there. You can create branches in your forks if you want. When you want to submit your chages, you can submit a pull request. However one ‘problem’ with this method is once you fork-off, you will loose any connection to the original repository. Ie if there are some changes made in the original repo and you need those, simply pulling your fork wont do it. But you can tell the git application to do taht by setting up a special remote called ‘upstream’. Once you set that up, whenever you need changes in the original repo into your fork, you can pull from upstream.
I have tried Atlassian Source Tree for two weeks now and it is excellent. When you start working with forks, things get much easier with a good GUI application.

However, collaborators can also work in single repo without forks. Create their own branches and push it. Ask the admin to merge your branches into master. Every user can merge ofcousre but that will be problem in the long run. So I adivcesomeone should act as a de-facto admin and take care of merging.

[mindfane]

@Ryanjon @

I got some free time yesterday and I tried a new camera technique. What I did now is create a new Pawn called ‘RTS_God’. I added a sphere, spring arm and a camera onto it. Then I made this Pawn the default Pawn.

An extra dvatange is I can setup mutliple camera pawns and simply posses them (if we want multiple camera movement styles).

Also instead of constatly checking if WASD is pressed, I defined Axis bindings for those and processsed them in the Pawn’s Event graph. This will help us a lot if we want use Gamepads or Mouse for moving camera.

Anyway, I won’t be pushing this to git since we already have a cmera in place. But if anyone want to implement a new camera, I foudn this to be very easy way. If you find any issues or have a better idea, let me know