A few things to note: This project would not be for financial gain. This would also be open source. I am expecting that we would try to adhere to modular design. Also, each addition to the code base would be its own branch. So, person A and Person B would be working off of different branches. Also, ideally, I would like to track the features/functionality added by each user so as to avoid replicating or conflicting work.
Again, this project already has some code, so it's not like I'm asking the community to do the entire coding for me. lol I am definitely contributing as well. And finally, since I run the original project, I will approve all changes and merge them into master, unless you want to use a fork of it to do other projects. I do want to note that I am 100 percent flexible if you come to me with reasonable conversation. In other words, I am willing to repurpose the code, use different libraries, or have a desire to do pair programming or something similar.
Things you should probably know: If some of the above jargon confuses you, I would recommend you Google, pick up a book, or find a way to learn some of the following technologies. Git for version control. Github as the main host for the project. Travis for possibly having builds of the project (any similar service will work. we can discuss). Python3 is what I began building this system off of.
At the moment, I am using PyInstaller for packaging, Tolk for screen reader output, and Pyglet for sound, basic window rendering, and a few other things. We can certainly write things to Cythonize, encrypt, etc if you want to suggest it. Again, I know a lot of you use Soundlib. I am open to switching for the sound.
Now for some final notes: OK. I don't want to exclude anyone. But I am going to apologize ahead of time for possibly leaving some of you out via some very random criteria. I would really like to work with people who are serious about collaborating. I would really prefer if you have relatively good English skills. Also, there will not be too much handholding (it is my hope that you've coded enough to understand a lot of the code being written). This being said, I would also want people to leave in-line comments to explain how code is being written to accomplish certain tasks. I try to be reasonable when it comes to honoring each person's coding style. However there are standards that would help facilitate code organization and modularity. Also, arrogance and unwillingness to compromise will get you nowhere with me. You will be ignored!
The reason why I want to bring this up now is because I believe that if enough of us put our heads together, we could make a really neat game that could potentially be a next great hit in our small community. I want to see if there is enough interest. If none exists, then I won't bother. But if it does exist, maybe we can start a skype group or something to discuss specifics about the type of game we are going to create, libraries, and other specifics. The repo in github can be found at this link. Feel free to browse and view the source. No pull requests or contributions will be accepted until project starts. Also, if you don't necessarily wish to contribute, feel free to use this as a starting point or something for another project. What do you guys think?
I might be interested in contributing, depending on the sort of game that we'd be working on.
#3 (edited by pauliyobo 2019-08-02 18:17:00)
Checking out the code right now. Would love to participate though.
I'll give the code a look. i'll gladdly work with you on this.
I'd definetly be willing to participate in this project. I think if this is done right a great game or set of games can come out from this and make a great advancement in audiogames.
I'm sorry to post this here but you said that you were using tolk. I can't seam to find the python bindings fore tolk that I downloaded from the git project for tolk. Sorry for being off topic I just thought I would ask here. Also what is soundlib?
I would also love to help where i can
never give up on what ever you are doing.
I would also love to help where i can
never give up on what ever you are doing.
I'd be interested, though I dono how difficult it will get with so many other devs. I haven't used Git beyond the basics yet, but I am a quick learner
What is hard is making code that accepts different and sometimes unexpected types of input and still works.
This is what truly takes a large amount of effort on a developer's part.
Wow! I'm glad there is some interest. I was afraid nobody was going to offer. It sounds good to me. If you guys wouldn't mind, send me your Skype addresses, or suggest another messaging method so that we can communicate more freely and we have a dedicated space to talk about this project. I can start a Skype group unless others have other ideas. If you don't want your Skype out there for everyone, just go to my website at edgarl.com and fill out the contact form. It has a "I'm not a robot" thing, so you can just fill out that form and provide me with your Skype address. My website is a really bare thing, but the contact form works, and I'm planning to add other things in the future when I can get around to it. Also, I noticed someone already submitted a pull request. The effort is much appreciated. However I will not merge it because I am going to be firm about enforcing the rule about good version control practices. And usually, in a good development setting, each person will create their own branch, even off of their own forked project. This branch with the new feature or bug fixes is eventually merged into master by the original author. That way there is some central authority. Direct changes to master will not be merged. Sorry! If the contributor that made the pull request to improve the build process could make a separate branch and call it "improve-build" or something like that and commit that and do another pull request, then I would be happy to merge into master. Also, I did say pull requests would not be accepted until the scope, goals, and extent of our project is further discussed and established. I can make exceptions for pull requests addressing documentation, build environment improvements, and anything not related to the code directly. I also want to emphasize no contribution is too small. If you make small spelling corrections, grammar corrections, etc, that's just as valid as code contributions. In my opinion, documentation is just as important! Anyway, I'll keep an eye on this thread, and I am excited to work with some of you guys.
It doesn't matter what the origin branch of a PR is if you're merging it into master.
I.e. it doesn't matter to you at all that I submitted my PR on the master branch. You can merge it into master, a branch called development, or whatever you like. The only thing that matters to you as a maintainer is that you pull the commits you want, and as long as I push nothing else to master before you merge it, which I won't, you'll be fine. Our repositories are entirely separate namespaces, and we have lots of latitude about which commits arrive and where they end up.
So I won't redo my work on another branch. Sorry. But I also won't push to master before you accept the PR, so you're in no danger if you accept it. I just thought that my changes--using a virtualenv, documenting it, and adding a requirements.txt--were pretty standard for modern Python projects, so thought I'd nudge folks in that direction.
Either way, best of luck with this project!
nolan, your contribution is much appreciated. And I understand your explanation. However identifying parts of code as branches is still somewhat valuable to get an overview, from a glance, as to what the issue or feature being added is, and how it's commits relate to the current flow. I understand branches can ultimately be created by the maintainer from a fork contribution. Still it's good to have some accountability on the person forking and contributing by identifying parts of code as branches. Also good concise commit messages are great too! Of course I can't prevent people who fork from sticking to my conventions, but I certainly encourage it. Commits, making small feature changes, are probably fine just leaving at master (e.g. spelling changes). Again, thanks for your contribution. I'll be definitely merging your contribution. I'll be adding a contributors.md file. You're first on the list. Also, I had some sounds I began using for this project. I have to figure out a way to host them such that collaborators can add sounds and be able to have a complete build to play the game and distribute if they so desire. Maybe OwnCloud?
If you're making a sample game, and want to make developing it as easy as possible, I'd look into git-lfs for sound storage. You manage your audio assets just like other files in Git, and git-lfs transparently handles making sure the binary diffs don't land in the rest of the .git/ directory, and uploads/downloads your files transparently behind the scenes. If you have gigs and gigs of assets then it may not be a great idea, but you're probably better off just starting with git-lfs and kicking that problem down the road until it becomes one.
this sounds like a good idea. It would push the community away from BGt. going to be cloning the code to have a look. also if any one is a little hesitant with git don't worry it's pretty simple to grasp. A good book is called Git Succinctly
the website plays well with screen readers. here's the link.
https://www.syncfusion.com/ebooks/git. also a little question.
are we going to be testing are code? since we are doing this with python using library's like like unittest or test. thanks.
#16 (edited by kaigoku 2019-08-04 19:34:58)
OK guys. For all interested in this project, you can join the Skype group at this link. Also, Nolan, thanks for your suggestion for Git LFS. I think we might use it. I encourage the collaboration to make use of ogg files.
The next thing on the agenda is to discuss what kind of game we are going to make. I think a todo.txt file might help us get a little organized as to things to be implemented, discussed, etc. Oh, and I made a commit to change the source files to an src directory and added a gitignore. If we're using Git LFS, maybe we can modify it such that the sounds directory is no longer excluded from the tracked items.
So i'm assuming i have to create a github account? aalright.
#18 (edited by defender 2019-08-04 22:13:00)
I'm 80% sure this will blow up in your face completely.
Sorry to say it, but I'm surprised no one has already...
It's been proven time and time again by failed projects that some serious selectivity, common sense, a tough attitude, proper communication, and good code security is needed in this community to get anywhere with a collaborative project made up of randoms.
You will have people telling you they can do things they can't because of ego. You will have people saying they have time when they actually don't, or flaking on responsibilities they've taken on out of laziness. You will have people asking how to do basic things with github or programming it's self so much that you can't work. You will have people arguing amongst them selves to the point of flame wars, so that you become a moderator first and a head coder second. You will have people sharing your Alpha builds and trying to steal code you give them to use in their own crappy projects. You will have people bitching at you constantly to do things faster.
On your end you need to A. Select your people carefully based on previous experience, communication skills, and demonstrated ability, not just what they say they can do. B. communicate with them consistently and clearly, even when that just means telling them when you won't be working on the project. C. Never give them hard dates for anything, only vague ones. D. When someone is assigned a task, keep them to that task, everyone can't do everything, or they'll just step on each other's toes. E. Be able to cut people out when it comes down to it, even if it's just because they haven't been around for a long time and they never told you they'd be gone (trim the tree to keep the rest healthy) and F. Never cave to pressure, it's your project, remember that. And your mental health matters too. As long as you can be honest and communicative, it's okay to take breaks and delegate tasks.
And that's just a slice of the pie, you'll learn plenty more along the way I'm sure... But if you dive in head first than the results could kill your motivation to ever code audio games again, let alone collaborate with others.
I can't say that inviting everyone (with totally different levels of maturity and experience) to a group to talk all at once, is a good start.
Collaboration without preparation is never a good idea.
Lets demonstrate this: stand still Thom...
defender, thanks for your optimism. lol And I understand collaboration hasn't been a strong part of our community. I know about the many leaks, disagreements, lack of communication, and other negative attributes associated to collaboration within our community. This is the beauty of Github and open source projects. I am not obligating anyone to work on the project once they commit. I don't have to accept any pull requests if I don't want to. And if people distribute the source, so what? It's open source! This is just an attempt to get people to work together! If I'm the only one that contributes to the project in the end, so be it! It doesn't bother me. Heck, I might not even contribute too often. I have a life outside of this, and I'm not obligating myself to work on it to release it for any reason. This is a mere attempt to get something going for people to enjoy. I'm not trying to say that I'm not treating this like a real and true project, but at the same time, I'm not stressing out about it! I have a job, I have other commitments. But you never know, something cool might come out of this. I'm leaving it up to you guys to commit as you see fit. If nothing comes out of it, I don't loose anything. Also, if people expect features to be added, they can add it themselves. Again, I can promise you I won't be unmotivated. The major reason being that I'm not anchored to this community. People's feedback doesn't affect me. I just want to do something good to help our developers, especially our beginners. Maybe you can even help since you are good at procuring sounds.
yeh, it would really be nice if we could accomplish something. However it's not a big deal if something goes wrong. This community in the past might have been flaky around the idea of team development. But there's always a time to improve and try again.
Yeah alright, the structure you've set up and your seemingly realistic attitude about this should help then. Guess I mischaracterized your aims... I just tend to warn people ahead of time because I have seen too many people get burned out by doing this kinda thing in the past, and I don't wana see that happen to you too.
I think you've got a healthy approach here though, if it actually pans out that way.
Lets demonstrate this: stand still Thom...
Agree with @20.
Alright. So this reply is going to contain some information for how you can get started with Git and Github. If you're a Git or Github expert, I want to appologize ahead of time. Some of this will be oversimplified for the sake of explaining this to newcomers. If you are somewhat familiar with Git or github, this might still be helpful because it will have some cut and paste commands. I've written this over a span of a couple of days, so it might be a little unorganized in some parts.
First, here is how I think about Git and Github. If you don't know the difference, this might help.
Git is the program used to manage, create, clone, and contribute to repositories. A repository is basically just a code project. The advantage of using Git is that you have the ability to view the history of files, revert to files whose contents have changed over time, and isolate changes that you make to code to work on separate features and issues at the same time as other contributors.
Github, on the other hand, is, in its simplist form, a place where these projects can be stored, viewed, and from where latest code changes can be retrieved. It's like a dropbox for code. lol Normally, Git projects are only stored on your computer, and contributions of the simplist kind can be made. Having an area where things can be centrally stored, such as Github, allows other developers to see and contribute to it.
The Git program runs on Mac, Windows, and Linux/Unix systems. It can be downloaded at the Git downloads page. Most users run the Git program on the command line. There are GUIs, but I can't speak as to their accessibility. In my opinion, it's much more accessible to run commands in command line environments anyway. The only challenge most beginners experience is the fact that there are so many commands. This can become overwhelming. But no worries, if you're confused, you're not the only one. Even experienced developers have to look up commands from time to time. That, and the fact that books just for git have been written can tell you how complex this system can be. My aim here is to write just enough to get a collaborator to my project up and running. I'm certainly not going to write a whole book about it. lol
So, the first exercise is to get this project onto your computer. Here is where I want to introduce two words of Git/Github terminology: cloning and forking.
Cloning a project is to essentially grab the repository from the web and making a copy of it on your computer. Forking a project is to essentially grab a copy of a person's repository, associated to a particular Github user, and making a copy of it on your own Github account. There is a difference! You need an account on Github to do both.
You might ask, why would someone fork a project? Well, Github is full of open source libraries and projects. When cloning, although you do have a copy of the project on your computer, the repository is still associated to the location on the web that corresponds to the user that originally created it. So when you make contributions, the only location it can go to is that on the original owner's reserved project location. The original owner might have even restricted others from collaborating directly to their project on this dedicated space. However, when forking, you get a copy of the project, and you reserve a separate location on your account for changes to be made. You can also think about it in terms of URLs. When forking, you get a different URL that you can use to host and retrieve your copy of the repository. There is a bit more to it than that, but I'll introduce it as the concepts come up.
Note: I will use the dollar sign ($) to denote that these are commands to be typed into the command line. I am assuming Git was installed on your computer. I am also assuming you have created a Github account. That part should be easy.
So, there are two ways to get my project onto your computer:
Cloning my repository. This would only be used for viewing the code because I don't have people as collaborators explicitly stated in the repository settings (which is required for allowing direct contribution via my web location). The command to achieve this is:
$ git clone https://github.com/EdgarLozano185519/Au … Pyglet.git
When you press enter, because this is https, it will ask you for your Github username and password. Just enter that information, and a copy of the code is created in its own automatically-created directory.
The second way is to fork a version of my repository onto your account and clone that fork.
If you go to my repository URL (found in the first post), then you should see a "fork a copy of this repository" button. This should direct you to adding a repository with a similar name to your Github account. Once this is finished, the forked repository should appear in your account. You then want to take the url from your version, found as a collapsed button that says something like "clone or download", and paste it into your command line. Do the same thing as the first method, but replace my repo URL with the URL just obtained.
Now you have a copy of my repository on your computer. I now want to take you through a set of steps that you can do to make a change to the code. But before that, I want to introduce a few more things.
A commit is something you want to be recorded. Almost like saving the changes you made to a file. When you commit something to the repository, you are telling the program to remember this change or changes to a file, or even multiple files, and save the current state. Almost like bookmarking a state in the code.
A branch is a step beyond that. It's basically a way to tell the program, "Hey. I want to make a few changes from this point on. But these changes should be identified with this name." The changes made from this point on can be 1 or more commits you decide to make under this name. Now, the beauty of this is that each branch can be considered a feature, issue fix, or any contribution of any sort! And you can call it almost anything. This also allows for multiple people to work on multiple things (contributions) at the same time.
The important thing to remember, or know as I am just now introducing it, is that usually, you have a main branch into which, most of the time, all code is eventually added. This branch is called master. And the process of putting the code of one branch onto another is known as merging. So, most commonly, people will merge all of their branches onto the master branch. You can also make commits directly on the master branch if you don't want to go through the hassle of creating a branch for a simple change to the code (like a single spelling mistake correction).
Something I tend to do is to make a single branch, and once I finish with my changes on that branch, I merge into master. Sometimes you will have things such as merge conflicts. But I won't take the time to explain them here. You can read about them. I also want to let you know that there is more than one way to do something in Git. You just have to know the commands to get it done.
Another thing you should be aware of is pulling and pushing. Essentially, pulling is the process of retrieving latest code changes from the online repository. Pushing is the process of telling your program to add code changes you want to the storage place for your code, in our case, Github. Fetching is similar to pulling. However pulling does a few more extra steps than fetching. For our purposes, we are going to stick to fetching instead of pulling. Fetching will just retrieve branches from the place on the web where your repo is stored. If you want them to sync to your local branches, you will have to do some manual merging, which is the extra bit that pull does.
Another thing to be aware of is Pull Requests. A pull request is a way to let the original owner of a project know, "Hey! I just made a change to the code. Can you come check it out? If you like it, please add it to your repository." Then, the owner of the original repository, that would be me, can go check out your code. If I like it, I can then merge it to my repository's master branch.
One final thing you want to know about is the fact that you can have multiple repository URLs associated to a repository. I hope this part isn't too confusing. But why would you have more than one URL associated to your repository? Well, you might want one url from which latest code changes can be retrieved, and the other to be used for pushing changes. How is this applicable to our situation? Well, we will have two URLs: 1 URL is my main repository URL from which all changes are going to be stored (the place where I am planning to do the merging that serves as the central repository), and the other URL for your fork (the place you will use to store your changes and if you follow the pull request process, I can get changes from your fork and put them on my repo). If you try to push directly to my repo, I think it will give you an error.
So, this next part is important if you want to contribute to this project and we are to maintain some order.
If you already cloned my project, and you are planning to contribute, you want to follow above method to make a fork of my repository. Instead of cloning, you want to use the url normally used for this purpose to add it to the list of remote URLs associated to the already-cloned repo. To do this, run the following command:
$ git remote add upstream https://myforkurl.git
You can replace upstream with a more meaningful name so that you can keep track of your repo url. Also, if not obvious, replace https://myforkurl.git with the actual url to your clone url retrieved from your forked repo.
However, if you want to start off by forking your own copy, that's fine too. You first fork and clone your repo, and add my repo url with the same command above, but replace the url with the clone url associated to my repository. It just depends how you want to start. Either way, you can keep track of your URLs with this command:
$ git remote -v
OK. Now let's go through an example of how you would make a change to the code. Let's assume you wanted to add a sentence to the readme.md file (which Github uses as the main text displayed on the frontpage of your repository). Here's just one way to make this change and make me aware of the change.
Note: I'm assuming you began by cloning my repo first, and then added your fork url later. The name for the main cloned repo is usually "origin". But you can assign a name to the other urls via the command to add a remote above. Usually, a common name is "upstream". So I'll use upstream as the fork URL. Also, the commands listed will have to be executed form within the repository directory. I hope this is obvious by now.
Here is the flow:
A good practice is to always fetch latest stuff from main repo where collaborations are being done before making a change or changes. This is just to make sure you have latest branches and changes. Then merge remote changes just retrieved into master. These are the commands I would use:
$ git fetch origin
$ git checkout master
$ git merge origin/master
Note: Remember, in this example, "origin" is the main repo where the code is located, the central location which is my repo.
You decide you want to make a change. If it's a significant change, you create a branch. If it's something small like a spelling mistake fix or something, you don't have to go through this step. So, let's assume you want to make a huge change. You run this command, replacing stuff in between less than and greater than signs, and omitting the less than and greater than signs when actually writing this command out:
$ git checkout -b <new_branch> <from_starting_point_which_is_usually_master>
You make your change or changes on whatever branch you decide to make it on from step 2.
You can now commit it to the current branch with this command, replacing the message with something meaningful. The message is the stuff in between quotes. Oh, and do include the quotes. You can do it without the -m command, but if you do, you have to deal with vim. But this is how I do it:
$ git commit -a -m "A meaningful message for the commit"
Do some more work if you want to and follow the same procedure as steps 3 and 4.
When you think you're done, you can then run this command, after running and testing of course:
$ git push -u upstream <name_of_branch_work_was_done_on>
Note: Remember, in this example, "upstream" is the name of the forked repo. "origin" is the main repo where the code is located, the central location which is my repo.
Alternatively, if you want to keep things consistent, before step 6 above, and your changes are committed to something instead of master, you can merge things into the master branch and then just push master to upstream like this:
$ git checkout master
$ git merge <branch_work_was_done_on>
$ git push upstream master
When you're finished with all that, the last step is to put in a pull request so that I know that you want your changes in my repo. If you don't know how to do this, let me know, and I can provide instructions as to how this can be done. This process is managed through Github. Essentially, you're telling me which repo has your fixes and which branch of yours you want to merge with which one of my branches on my repository. Then, you submit the pull request. I will get to it, I promise. The rest can be handled by me. All I would have to do is see the branch you want me to merge into my master branch, and I'll pull and merge on my end.
Well, I think that's it. Sorry this reply was kind of long. I just wanted to document some of the process so that you guys have a quickstart to getting up and running with my repository. I know I may have left a lot of things out, and made an error or two. Feel free to point it out, and I'll edit my reply accordingly. Let me know if this was of any help to you. If so, I'm glad I could help at least one person. Happy contributing! And feel free to join my Skype and clone and contribute to this project! Please do read more for a more in-depth guide to Git and Github. This was just a quick tutorial. Nevertheless, hope it was useful.
just one small correction: when cloning a repository that is not private, even though you're using a https url, you don't need to provide username and password, you don't even need a GitHub account.
And one other addition: in my oppinion, the best possible GUI Git client for Windows is TortoiseGit. Its entirely accessible, integrates into the Windows Explorer context menu and does things fairly easy where even command-line commands can become pretty long. Showing/reading through logs, rolling back to certain commits, cherrypicking, all of this is no trouble with TortoiseGit and deffinitely saves you some time. Even though thats probably too advanced for the stuff you're gonna be doing for now, its still really convenient. So all of you who want to give it a try, just go ahead.
#25 (edited by Ilya 2019-08-06 12:30:22)
@24 thanks i wil have a look at that.
It might be useful.
I all ready have a plugin for VS code which does most of the stuff that i want it to do. But I am sure I will find a use for TortoiseGit.