I've got a few items on these topics and they somewhat relate together so I decided to post them all in one big pile since I'm stuck at work and can't code or review much anyway. These are some of the things I'd post as Issues in GitHub, but I'm still tinkering with that setup 
So, going forward we want to be able to support as many concurrent contributors with minimal code conflicts - something we're bumping into even with three devs, and Git / GitHub doesn't seem hugely friendly to sorting that out, although certainly I'm still not that savvy and likely making it worse than it is
I'm thinking sorting out a few things into conventions would help a lot. So I thought we should iron some stuff out there.
1) Architecture on package structure - currently I'm not personally very sure what should go where, and have almost certainly put stuff in the wrong places and been waffly on moving things around. Should we consider some MVC-like package setup where we split out all rendering-related stuff in one package structure, all config / data in another (like groovy block files, etc), and the controlling logic in a third? I remember MVC came up in the past, but... :badmemory:
For instance I submitted the "ToolBelt" class as an odd half GUI element (with no graphic display yet...) and half controller (managing actual tools). In reality that probably should be split into a ToolBar / Belt GUI component and a ToolManager controller, in separate packages but tightly paired together, along with the Tool implementations/data being somewhere else entirely. For the Groovy Blocks I'm trying to keep stuff in distinct places (Block controllers in one package, block info in Groovy classes in another, split by type, block textures in yet another, and add-on blocks likewise in a structure but this one outright external to the src dir
Getting to a point where we know how to split out stuff right away and where we can put stuff in the right place right away would help a lot, file moves are painful with changes on both sides
2) Class scale - this is closely related to 1) as we've got several classes that get touched too much as they might be doing too much (Blockmania, World, Player, etc). Should we be trying to split these out somewhat, maybe looking at the conventions we'd come up with in #1 ? Many smaller classes with different people able to make changes without conflicting is good.
3) Tick system - an example of a sort of new system, being that we've got sort of a hodge-podge currently. I think we need to provide a central tick manager of some sort, that graphic/game actions that need to happen at certain times can register with to be prodded at said times. Without adding any specific code to said manager so we don't violate #1 or #2
4) Metrics - ties with #3 in particular. It'd be good to know more about what eats time in the code, and have a way to output said metrics either into a file and/or a GUI component for immediate feedback. I noticed Minecraft went to a pie chart from the old spiky bar chart (I think... unless the bar chart is still hiding somewhere), which displays the time spent in render (almost all) and assorted tick activity. I'm envisioning a semi-transparent http://en.wikipedia.org/wiki/Area_chart spanning across the lower half of the window with each color indicating an activity, and maybe a sharp line for overall memory usage, updated a few times a second so we have a minute or two of history to display.
If the tick system can use triggered-at timestamps + callback when complete from the registered tick-owner that should go a long way toward sensible statistics. Maybe rendering can do something similar to cut what it does into distinct phases too? Of course, at the same time we need to make sure this has a minimal performance impact itself.
I don't know if there are any decent frameworks/libraries out there for something like that.
Overall thoughts?
Edit: The other chart in MC is still there. More :badmemory:
So, going forward we want to be able to support as many concurrent contributors with minimal code conflicts - something we're bumping into even with three devs, and Git / GitHub doesn't seem hugely friendly to sorting that out, although certainly I'm still not that savvy and likely making it worse than it is
I'm thinking sorting out a few things into conventions would help a lot. So I thought we should iron some stuff out there.
1) Architecture on package structure - currently I'm not personally very sure what should go where, and have almost certainly put stuff in the wrong places and been waffly on moving things around. Should we consider some MVC-like package setup where we split out all rendering-related stuff in one package structure, all config / data in another (like groovy block files, etc), and the controlling logic in a third? I remember MVC came up in the past, but... :badmemory:
For instance I submitted the "ToolBelt" class as an odd half GUI element (with no graphic display yet...) and half controller (managing actual tools). In reality that probably should be split into a ToolBar / Belt GUI component and a ToolManager controller, in separate packages but tightly paired together, along with the Tool implementations/data being somewhere else entirely. For the Groovy Blocks I'm trying to keep stuff in distinct places (Block controllers in one package, block info in Groovy classes in another, split by type, block textures in yet another, and add-on blocks likewise in a structure but this one outright external to the src dir
Getting to a point where we know how to split out stuff right away and where we can put stuff in the right place right away would help a lot, file moves are painful with changes on both sides
2) Class scale - this is closely related to 1) as we've got several classes that get touched too much as they might be doing too much (Blockmania, World, Player, etc). Should we be trying to split these out somewhat, maybe looking at the conventions we'd come up with in #1 ? Many smaller classes with different people able to make changes without conflicting is good.
3) Tick system - an example of a sort of new system, being that we've got sort of a hodge-podge currently. I think we need to provide a central tick manager of some sort, that graphic/game actions that need to happen at certain times can register with to be prodded at said times. Without adding any specific code to said manager so we don't violate #1 or #2
4) Metrics - ties with #3 in particular. It'd be good to know more about what eats time in the code, and have a way to output said metrics either into a file and/or a GUI component for immediate feedback. I noticed Minecraft went to a pie chart from the old spiky bar chart (I think... unless the bar chart is still hiding somewhere), which displays the time spent in render (almost all) and assorted tick activity. I'm envisioning a semi-transparent http://en.wikipedia.org/wiki/Area_chart spanning across the lower half of the window with each color indicating an activity, and maybe a sharp line for overall memory usage, updated a few times a second so we have a minute or two of history to display.
If the tick system can use triggered-at timestamps + callback when complete from the registered tick-owner that should go a long way toward sensible statistics. Maybe rendering can do something similar to cut what it does into distinct phases too? Of course, at the same time we need to make sure this has a minimal performance impact itself.
I don't know if there are any decent frameworks/libraries out there for something like that.
Overall thoughts?
Edit: The other chart in MC is still there. More :badmemory: