We're not quite ready for community development yet, but if you want to start looking into things, the current setup being used is the same one in Exilebuddy. Have a look at these threads for a sneak peak:
Using coroutines for logic development
How to Setup a Project for Exilebuddy
How to Debug Your Bot/Plugin/Routine Code In Visual Studio
How to Use Code-Behind/XAML for your WPF Guis
If you checkout the included "Stats" plugin, you'll see an example of using some of this stuff as well.
To get access to the current API, you'd add a reference to HearthbuddyBeta.exe, as the 2nd guide does for ExilebuddyBeta, and you're ready to go though things in the Visual Studio Object Browser.
Keep in mind, the actual API we provide though Triton is not quite done yet, and there's going to be some changes in the near future to it as soon as we are able to sort out the current issues post-GvG. Right now a legacy API is being used for SF compatibility so we have something to work with short term.
One thing that is a lot different with HsB, compared to our other bots, is that our core game API is auto-generated. As a result, things are setup the same way they are in the HS client for Triton.Game.Mapping, but we havn't re-wraped all that stuff into our own abstracted API. That means if someone wanted to make their own bot implementation, they'd be looking at using the actual HS API we have mapped to do it, as opposed to having something to work from that takes care of all the common things. In the near future, I'd like to fix this by making our bot base inheritable from, and users can rely on that as opposed to having to recode an entire bot themselves.
Lastly, if you look at the actual code for DefaultRoutine, you'll see the current setup for the legacy API and how it's used with the HsB specific integration for SF. A lot of this stuff will change as well, but for now, that's what's there.
