triplea-game / triplea Goto Github PK
View Code? Open in Web Editor NEWTripleA is a turn based strategy game and board game engine, similar to Axis & Allies or Risk.
Home Page: https://triplea-game.org/
License: GNU General Public License v3.0
TripleA is a turn based strategy game and board game engine, similar to Axis & Allies or Risk.
Home Page: https://triplea-game.org/
License: GNU General Public License v3.0
A conversation around this question asked from another thread:
@djensen47
"What are the different types of issue tags that we need in order to organize the types of issues, discussions, questions, and whatever else we anticipate."
Scenario:
Defect:
Problem:
Expected Behavior:
Work-around:
Best fix:
Low priority, but I want consensus on this so we can do this while we move along on to bigger items. Below are some items that are somewhat whacky things going on in class files. I propose we fix the items below in an ad-hoc manner (and if someone really wants to, they can do a sweep and get everything!):
I've been thinking a dependency injection container would be very helpful. Particularly given all the singletons we have floating around. In triplea-test it was recommended to use Dagger2. So far it looks nicer for us than Spring by being far lighter in weight. I pulled down a Jar file and threw in some annotations, so far so good.
Question then, is everyone good with us using Dagger2 for dependency injection?
Question 1 - How do we keep track of priorities of what needs to be done? Do we have a wiki page with some mission statement items, maybe more granular with general things to improve? Do we supplement that, or only do prioritization in whatever project tracking mechanism we choose?
Question 2 - Does this process take into account that some contributors will only be able to work on low priority items?
So we have a few users that are having technical difficulties with the latest release on a Mac. Does anyone have a Mac and can help debug?
Let's establish exactly how release patches are to work. Both of these routes are okay:
I thought we would go with the first, but looks like we are doing the second. Let's discuss.
#72 is not complete, I can't re-open it, hence the new issue..
Now that travis CI has access to github, you need to also tell Travis to start doing the builds: https://travis-ci.org/profile/triplea-game (simply a matter of clicking the button towards the center of the page showing a big "X")
Note that my view of that page says admin is needed:
Now that we have a much better AI, should we remove the half-done, land-only, Dynamix AI?
The main reasons to keep it around would be because maybe some people like playing against it, or maybe Redrum is still using it for inspiration on his own AI.
@ron-murhammer: Redrum, mostly looking for your opinion on this, as you are the official AI guy these days.
Unless my arithmetic is off, we have 27 files at the top level folder and 16 folders. This is quite a lot of content at the top of the project folder. Consider we are rebuilding our build system (ant to gradle), it should be a good time to move to a more organized folder structure.
Below is a summary of how many files we have by file extension type:
~/work/triplea$ find . -maxdepth 1 -type f | sed 's/.*\.//g' | sort | uniq -c | sort -nr
6 xml
6 sh
3 bat
2 txt
2 plist
2 gradle
2 exe
1 vimrc
1 properties
1 pdf
1 md
1 ini
1 html
1 /gradlew
1 gitignore
1 docx
The 6 XML files include:
$ ls *.xml
build.xml launch4j_embedded_jre.config.xml
digests-include.xml triplea_java_eclipse_cleanup.xml
launch4j.config.xml triplea_java_eclipse_format_style.xml
3 of those files look like logger files that just need to be on the classpath. Standard thing to do AFAIK is to have a "resources" folder for this. For us, we can probably put these files in data or assets maybe since those are on most paths. We could also create a resource folder to house them.
The two eclipse xml files could use a home, likely with other IDE files.
The 6 *.sh and 3 *.bat files can likely go into a scripts folder.
There looks to be a long tail of documentation files, we can probably organize those in a docs folder.
I'm interested to hear thoughts if this is reasonable, and or alternatives or improvements/additions.
For convenience, here is the listing I get from the top level tripleA folder:
~/work/triplea$ ls
assets maps
bin old
build.gradle readme.html
build.xml README.md
changelog.txt run-headless-game-host-mac-os.sh
data run-headless-game-host.sh
dice_servers run-headless-game-host-windows.bat
digests-include.xml run-server.sh
doc ServerInfo.plist
fix_mac_icon.sh settings.gradle
gradle src
gradlew system.ini
gradlew.bat test
icons triplea_embeded_jre.exe
Info.plist triplea.exe
installer triplea_java_eclipse_cleanup.xml
junit triplea_java_eclipse_format_style.xml
launch4j.config.xml triplea_mac_os_x.sh
launch4j_embedded_jre.config.xml TripleA_RuleBook.docx
lib TripleA_RuleBook.pdf
license triplea_unix.sh
MacOS_users_read_this_first.txt triplea_windows.bat
I'd like to request to be a "collaborator" on the project so that I can at least help by labeling topics. I'll start with the default labels Github provides until we decide we want more. Reasonable? ๐
We have a Travis CI file in our build. It works and has been building in my local repo: https://travis-ci.org/DanVanAtta/triplea, I'm already at build 41.
All we need to do for Travis CI to build triplea-game is to grant it access and then click a button on the travis CI web UI to turn builds on. So this all a simply a matter of clicking yes, all configuration is done and already pushed into master.
@veqryn and @ron-murhammer , could you please find the email and grant access (should be dated Aug 7th)?
After we get Travis CI permissions, and turning build son, any branch with the .travis.yml file will automatically be built (compiled and tests run). Later Travis CI can be updated to do more, like create and push releases when we want it to.
The grid game code introduces a lot of dependencies into the tripleA code making the tripleA code much harder to work with. This is a big drag on efficiency, and given the features are barely functional and rarely used, I don't think we gain much of anything by having them around (and meanwhile we are committing hara-kiri by keeping this code around).
It's very easy to delete the packages for those three maps. The code update so clients do not freak out about the missing delegates should be mostly straight forward, so this should be feasible and not too much effort.
The how-to-release notes have a mention to download a number of maps to include them in the "maps" folder. This seems a bit hacky since some maps are there, and others are in another location.
I then suggest we do this, create two map folders, "maps" and "maps-extra" (ideally the second would be called extra-maps, but to keep the two folders closer together when sorted, hence: map-extras)
Everything in maps would be packaged in the minimal version, used for engine upgrades and perhaps deployments. The maps-extra would be packaged in the 'all-maps' version and would include everything in 'maps' as well.
This dovetails with CI, so despite my preference to leave this for another day... I'm bringing it up, particularly since we already broached on the topic.
Now that we'll be looking to be build "unstables", the work flow would be to increment and tag after merging to master. This will create a series of artifacts that are automatically pushed into github. From there, at any time we can then choose to do release/best testing.
With the current release number scheme: https://github.com/triplea-game/triplea/wiki/Release-Version-Numbers, we would be re-using the same number. This loses the track record, and is a bit of an anti-pattern for version numbers, which are supposed to increment on change.
Our last release number as an example: 1.8.0.7
The 1 and 0 spots are not very well used, particularly the 1. We are also missing a spot to be able to increment different unstable versions. So my proposal is we remove the 1 and 0 spots, and add a new spot to the right for a build number.
So the current stable version would be:8.7.0
The next unstable would be: 8.7.1
The next stable that is still save game compatible would be 8.8.0
The next unstable that is not save game compatible would be 9.0.1
The next version that is not save game compatible would be: 9.1.0
edit updated to add #65 to list
If i had my preference of which PRs should be merged first and in which order:
Add Travis CI config and fix Junit tests run from Gradle
58 opened 3 days ago by DanVanAtta
Game freezes on startup - Game chooser synchronize deadlock fix
66 opened 39 minutes ago by DanVanAtta
Remove commented out code from 121 files
54 opened 6 days ago by DanVanAtta
Veqryn final cleanup
65 opened 2 hours ago by veqryn
I've looked over creating OS dependent packages. Given that with the Gradle system will need to restart this issue mostly from scratch I decided to revisit the problem at hand.
At the moment from my understanding we use:
I've researched the subject somehow, the better ways of doing this is:
I tend to opt for the 3rd as it provides the most polished result with the least effort. So what do you guys think?
Thanks,
I'd like us to agree on a continuous integration process and to document it on the github wiki.
Definition: continuous integration means the work of multiple developers is integrated together on a short iteration cycle. Meaning, merge conflicts that come up are small and not so frequent.
Proposal: simply use master branch for integration. Pull requests will add new code, "git pull --rebase" to pull down remote code and integrate it locally.
Some lightweight discussions would be nice via email.
LIke for example, hey Mr xyz repo owner, I've an interesting change on this branch in my fork, could you look at and tell me what you think?
Some things don't deserve a github issue I think. What do people think, create an email distro? Probably would be a google group.
Also nice thing, for short more informational messages, it would reduce our reliance on creating issues on the more transient, developer interested only topics.
Anyone have any thoughts or desire to change how the various game settings are presented to users?
Some problems we have:
Some possible ways to improve:
<name, value, recommended value, description>
Why?
We could use a definition for the release process. I'd like to discuss what that process is, we'll document it afterwards.
Below I'll outline a pretty standard release process to start the discussion:
The git commands for the new branch and tagging are pretty straight forward:
git checkout -b <new_version>
git tag -a <new_version> -m '<new_version>'
git push origin <new_version>
On one individual's computer, a large file is not an issue but when dealing with these file en masse it it burdensome.
Benefits of a smaller file format:
Options:
(oops, didn't mean to close and re-open)
I've got a couple of eclipse launchers with args to launch the game and the headless server, and a third for running tests. It's preferable I think to have these files checked in, easier than giving details of how to set them up. Also when I clean my environment it's one way I can see to make set up time easier and more efficient.
Questions:
This release was particularly confusing with the multiple avenues for bug reports, multiple posts on multiple forums.
We previously discussed migrating from source forge and merging forums. In that context, @veqryn and @ron-murhammer , which forum would you prefer to keep?
I think it's literally that sample. Start with choosing one, then post on the one that is being deprecated that it is going the way of the dodo. Eventually then close the ability to add new posts. IMO we'll bleed over to the one forum for some time and then use the one for a considerable time (months/years)
We previously touched on this topic and found consensus we would like the "m_" and "s_" naming convention dropped. We did not discuss the "I" interface prefix convention, likely this would be dropped as well.
Next on the agenda block is the code formatting. The only remaining convention is then that curly braces are on their own line and to use tabs (announced to gasps and shocks of horror), otherwise the rest are effectively whatever happened to be in the eclipse formater when it was exported. This does create a small problem since multiple developers will not be able to auto-format code in both IDEA and Eclipse and get the same output (so in effect we may get auto-format wars going on).
The goal of this thread is to talk about updating our formatters for consistency. The goal is not to get your favorite formatting idiom in a spec, but more for us to agree on what the format spec should be. That agreement will ideally take the form of perhaps a wiki document that spells out in detail formatting decisions, and/or both eclipse and intelliJ formatters.
I think we have I think these options:
My proposal is to solve this would be for the 3rd option, a 3rd party format spec. Reasons:
So, my question would be - is there agreement that we should try to find and use a 3rd party formatter? This lets us have consistent formatting and agreed upon formatting rules. If so, is google the only 3rd party that gives a formatter and spec? Any objections to going to that format spec?
It's probably useful to have a list of items that have been identified as things to work on. I found the source forge ticket queue useful for giving some direction for some things to fix.
So, question: how are we going to track the existence of things we want to do, improve, fix, add, etc? Secondly, any thoughts how we will administer that list?
To start the list of things to format (please comment on additional items to be mass formatted):
@author
, @version
, empty javadocMap parse errors on load should be quietly logged (ie: logged to console in background but not shown to the user). For this issue, make that change, and also add an option to the game (default to off) where all such messages can instead be logged to standard error instead of standard out (which brings the console window to the foreground with the error message). This will be a useful option to be set to "on" for map makers and developers.
Please assign to @ron-murhammer
Code to do it would look something like this:
( https://reviewable.io/reviews/triplea-game/triplea/54#-JwSqFD6mzl6vTFqIOEF, ProPurchaseAI.java)
/*
* Currently the place delegate does not accept bids by the AI to territories that it does not own. If that gets fixed we can add the
* following code in order to bid to allied territories that contain our units (like Libya in ww2v3) (veqryn)
* for(Territory alliedTerr : ourFriendlyTerr)
* {
* if(!Matches.isTerritoryOwnedBy(player).match(alliedTerr) && alliedTerr.getUnits().getMatches(Matches.unitIsOwnedBy(player)).size()
* > 0)
* {
* ourSemiRankedBidTerrs.add(alliedTerr);
* }
* }
*/
We have a long list of pull requests sitting around. They're small and focused as requested, sometimes even trivial like #33. So perhaps size or complexity of a pull request is not the reason they are not being merged.
So what is going on? Why are so many pull requests sitting around? What are the various things we can do to address this problem?
edit skipping the details of why this is a problem. I'd like to keep this discussion as matter of fact as possible. Though without further elaboration, I'll state this is a very significant problem in my point of view.
@ron-murhammer @veqryn
I broke up the how to release page (http://github.com/triplea-game/triplea/wiki/How-To-Release) into smaller pages, idea being to make the steps a bit more bite sized. As an added benefit it makes a convenient check list. Please run with this idea if you like it, but I think it would be good to create a ticket for when we do releases and include the check list in it. As we automate, the check list will become smaller. The check list should help ensure we do the process completely and correctly, but will also help keep everyone on board with where we are with the release.
@ron-murhammer , since this would impact you most immediately, if you do not want to do this, simply close this ticket...
The following three libraries I think will need to be added very soon:
Down the road I think we'll be adding the jars for:
And of course eventually maven/gradle will be getting this stuff for us, so we won't have the jar file checked in. Till then, wanted to raise this issue, see if there was any objection.
So I think we need to have a little bit of a process around pull request reviewing and assignments.
When you open a pull request please assign it to me. I'll then do an initial review and do 1 of 3 options:
Veqryn tends to be the bottleneck since he knows the code base the best so we want to minimize using his time as much as possible which is the reason I'll do an initial review.
Then as they are discussed please assign it back and forth between the reviewer (Veqryn or myself) and requester so that its clear who needs to take action.
This should help to identify who currently needs to take action on the pull requests rather than just having a whole list of them.
I just went through all the pull requests following this process so its clear where things are at.
Thoughts?
A how-to push release page on the wiki could be useful. Particularly if time goes by and we forget how to do it. Part of the question is, where do we release, and how?
It looks like github-releases is a slick way to go. Keeps us in the git framework. Releases would then be available from: https://github.com/triplea-game/triplea/releases
There should be a way to tag and upload to the github-release. Those steps are what I'm thinking should belong in a wiki.
After that a next step would be to have Travis push automatically for us. PR #58 Adds Travis, these steps look to be roughly what we need to have Travis push builds for us: https://gist.github.com/vinceallenvince/a7611b10f84e61eebdcc
Cool technologies, but they have some big problems:
Should we fix? Has this been discuss before? Current thoughts/ideas on how to fix?
Maps is still in sourceforge? Atari map has a bug where "Factory.png" is used instead of "factory.png". A person only see this problem on a case sensitive file system. Seeing that reminded me maps are not in git. @veqryn , will you be moving maps into git? Second thing I wanted to ask, can we check in the map files in an expanded format (not compressed in zip)? Allows for easier modification, building would be simply zipping stuff up.
Ok, so I do not really know how to use Git all that well.
Questions so far:
Any other tips are appreciated.
We had some good conversations going. It would have been nice to capture the details of some of those.
I guess we have the emails for each one so we can work from there?
Can we up the source compatibility to 1.7? What do you guys think. Given that Java 7 is no longer supported one could even argue that even going to 1.8 is valid.
Going to Junit 4 + Hamcrest is an obvious improvement.
Using Spock looks interesting, particularly for maybe a functional or acceptance test suite (perhaps a larger scope even if it proves really awesome).
Regardless, what are the current visions for how to improve testing? I'm offering my help, I've a few ideas as well ;)
PS: I started this page to capture a list of test cases we'll want to be sure are captured: https://github.com/triplea-game/triplea/wiki/Some-Things-to-Test-(Functional-Test-List-Plan)
Here are the commands to tag (assuming you are one of @veqryn or @ron-murhammer and have cloned the triple-game repo already):
$ git fetch origin
$ git tag -a v1.8.0.7 -m '1.8.0.7'
$ git push origin --tags
Anything blocking us from adding the tag? Are we set to do a release from the current version?
https://reviewable.io/ offers a better visualization of pull requests, we should add it to our system.
for example usage see for example gradle/gradle#490, notice the automatically added review on reviewable button
I heard Travis suggested as a continuous build tool. Free for open source, seems attractive. An alternative would be bamboo, but IMO I like the idea of staying in GitHub + Travis tools for now as a good thing.
You can push github release artifacts by hand.
Admins should see an "edit" button next to each release: https://github.com/triplea-game/triplea/releases. Clicking on that there is a section to 'drag and drop' files and add them to the release.
For this issue, please populate some of the releases with build artifacts.
One of the features I really wanted to build was to have a lot fewer clicks in battle. Turns out some time ago by looking at the code, I discovered the features "focus on own casualties" and "confirm enemy casualties." Then it turned out flipping those flags was pretty much exactly what I wanted all along, but I didn't know it was there.
I think we should flip the defaults, so there is by default less battle clicking. It's probably better to have someone play online and not know about this option and have fast battles, than the same person play against the AI locally and wants increased battle confirmations.
It would be great to also find a way to better publicize this option, make it clear what they do as well. Probably that is a more involved effort to group our settings and include a help roll-over. Until then flipping the defaults to faster battles will likely help online lobby users a good bit, particularly new ones.
I had a very disheartening conversation on the tripleA lobby when discussing a possible feature. The conversation boiled down to no new features because no development capacity (I mentioned this has recently changed!), but more importantly no new features because users leave whenever we release a new update.
Are there any existing or good new ideas of how we can fix this? Namely how we can improve the release process so it is easier. IMO it's a bad path if we lose users on each upgrade.
How are we going to build the unstable release artifacts?
The Travis CI release work flow is triggered on tags. I propose we answer the above question above by tagging after we merge into master. If the version number did not increment we delete the current version tag and re-add it to the current commit. In this case artifacts will auto-magically be regenerated. If the version number did change, then we simply add the new tag and again new artifacts will be created.
Any guidelines or best practices for using and working with a wiki? Second, given our current wiki, how are the pages coming up? I think the github workflow page could use some work to simplify it a bit, make it a cleaner to follow.
Are we needing any other important pages?
To start the conversation with my thoughts, please speak if you have a different viewpoint:
I think the wiki is good for:
I do not think a wiki is good for:
Some best practices:
We have two cases where we have mac only error handling. In one case we kill the game, in the other we ignore. They should be consistent, it's an exceedingly weak argument to suggest that two cosmetic game benefits should have different error handling.
This conversation started in PR #87 where @veqryn suggested we need to see these errors to get users to report them, otherwise they would be unfixed. My difference of opinion is that end users do not need to see errors and a game crash for cosmetic problems, and that we should have mac release testers look for these kinds of issues (which reveals a gap today, for the errors which we print to standard out, we will not be catching these, and we do that quite a lot).
Just saw a presentation on this format. It's supposedly 100% compatible with XML but it's about 3000% smaller.
It's widely used in industry but not so much with open source projects.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.