I've done a little Android development.The two main tools are the SDK (which includes the debugging tools and the simulator, which is a mixed bag) and the NDK. The SDK also includes the Java setup, while the NDK is an entire native toolchain for Android. You could really use either mainly, depending on whether your program is mainly Java/JVM or native based. You'd still need the tools in the SDK anyway, though.
They are both free, and don't even require a Google account to download or use, since all the associated tools are open source. They even work on OS X, Linux, and FreeBSD. And I can tell you, you will save yourself a bunch of time by using a Unix system. But it all works on Windows, too.
Getting things started is a little tough I found. I didn't use Eclipse, instead I just wrote the spec files by hand, and used the NDK and SDK as builders form SCons. That's probably not the easy way if you are starting a project from scratch, though!
Native based? As in what? I thought everything that runs on Android is Java. Or do you mean raw ASM or ARM or whatever Android devices use?
Why'll I save time using Unix? Aside from Windows being obtuse and crash-prone.
Take Pixel Dungeon for example...https://github.com/watabou/pixel-dungeon...what, exactly, am I even looking at here? What do I click on? What do I download? It's all so confusing.
Quote from: Mooch on February 15, 2015, 08:04:37 pmTake Pixel Dungeon for example...https://github.com/watabou/pixel-dungeon...what, exactly, am I even looking at here? What do I click on? What do I download? It's all so confusing.Well... you are looking at files on a virtual file structure. You can open the folders to see more files. The game is written in Java, and it's apparent that the source code is inside of src/com/watabou/pixeldungeon. The files you see that are "too small to be source code" are in fact random files, such as a readme, license, and a .gitignore which are standard files anybody would put into a basic git repository (at the root folder). So, yeah, what you are seeing is a list of files.Source code repositories are like DropBox, right, so they are a place to put files. But it's more than that since you have a history, a "commit history" that has the changes and an explanation for each commit. The files you see on github are the latest files on that branch. The default branch is master. Git and other repositories use a tree structure to track all information. Branches of this tree can be made at any time, deleted, or merged. They can even be merged into master, which some system also call the "trunk" because like any decent tree, you gotta have a trunk.Systems like these were made as metaphors of trees since it's easier to visualize them that way. Just like your filesystem. So that's what you see there.Github for windows can make it really easy to get git up and running. There are plenty of git tutorials out there. Once you do have a git repo it's up to you to commit. I usually commit whenever the features I set for myself have been coded out, but some people do it daily or for every little change. It's up to you how you want to commit and sync (don't forget to sync a git repo because commits are stored locally until you push them online, this is different than say, how SVN does things (another code repository or 'subversioning' system)).