Page 1 of 1

ES Project Structure

Posted: Fri May 11, 2012 12:25 pm
by OmenFelix
Hey ES Team, I was wondering does ES have one source location, and then just a bunch of project solutions(VC++, Xcode etc.), referencing to that source location, or does ES have multiple copies of the code(I doubt it)?

Also how many projects, in VC++ for example, does ES have? Is it all just one big project or does ES have a AssetIO project, libGyro etc. ?

I'm just wondering, as I'm planning to create solution variants for my project, as I normally just edit the code in Notepad++ and compile using GNU-Make, from the command-line. I'm planning to edit the code as a project from now on. :P

Re: ES Project Structure

Posted: Fri May 11, 2012 12:55 pm
by JarrodParkes
The engine and libGyro specifics Falco can explain. But, for the Toolkit, the project is maintained through GIT. Whenever one of us is making major edits, we create our own branch which will eventually be merged to the master when complete. Outside of that, other resources are all maintained through GIT repos, and several of our files exist with Google Documents. In terms of projects, there is essentially one master and our own local versions. When changes are made and committed the master gets updated.

On a related note, I can tell you this...finding the sweet spot for communication is VITAL. Being spread all over the place presents challenges mainly with keeping everyone on the same page. There are several schools of thought on how to solve the problem. Here are two that come into play with code. (1) Great documentation with limited meetings or (2) frequent meetings with less documented code. Because most of us have jobs during the week, school, or other obligations we do our best to stick with the first option. And with recent project developments ;) we are focusing on this topic much more closely.

Re: ES Project Structure

Posted: Fri May 11, 2012 1:16 pm
by OmenFelix
JarrodParkes wrote:The engine and libGyro specifics Falco can explain. But, for the Toolkit, the project is maintained through GIT. Whenever one of us is making major edits, we create our own branch which will eventually be merged to the master when complete. Outside of that, other resources are all maintained through GIT repos, and several of our files exist with Google Documents. In terms of projects, there is essentially one master and our own local versions. When changes are made and committed the master gets updated.

On a related note, I can tell you this...finding the sweet spot for communication is VITAL. Being spread all over the place presents challenges mainly with keeping everyone on the same page. There are several schools of thought on how to solve the problem. Here are two that come into play with code. (1) Great documentation with limited meetings or (2) frequent meetings with less documented code. Because most of us have jobs during the week, school, or other obligations we do our best to stick with the first option. And with recent project developments ;) we are focusing on this topic much more closely.
Cookie for you, my good sir. ;)

Then I guess, I await the engine+libGyro specifics. :)