Sharing code with Shadowgrounds

Jack Claw was in development between 2006-2008 and was released in the Humble Frozenbyte Bundle for the community to play and build upon.
alt_turo
Posts: 195
Joined: Mon Dec 13, 2010 11:06 am

Sharing code with Shadowgrounds

Postby alt_turo » Thu May 26, 2011 1:41 pm

Shadowgrounds and Survivor share a lot of their code with Claw. Currently only the Windows code has been released but hopefully we'll get the Linux/Mac code soon. When that happens some people might want to start improving on it. It would we useful to share code and effort. Do we want to do this and if so how do we want to do it?

1. Keep separate repositories and occasionally port code back and forth. Might lead to wasted effort when the same changes need to be done to both repositories. But would allow the codebases to diverge more easily where necessary.

2. Have a single repository with two top-level directories for different games. Occasionally port code back and forth. Like above but everything in one repository. Would make it slightly easier to port changes.

3. Have a single repository with top-level directory for shared code and separate directories for game-specific stuff. Would make it easy to add improvements to both games at the same time. On the downside it would also be easy to accidentally break one of them. This would also require quite a bit of refactoring out the common code before we get to this point.

Questions? Comments? Flames?
Turo Lamminen
Alternative Games

CheatCat
Posts: 14
Joined: Sat Apr 16, 2011 10:03 pm

Re: Sharing code with Shadowgrounds

Postby CheatCat » Thu May 26, 2011 2:41 pm

I like the 3'rd alternative, then you don't need to porting anything or copy code.

User avatar
Urfoex
Posts: 50
Joined: Fri Apr 15, 2011 11:14 am

Re: Sharing code with Shadowgrounds

Postby Urfoex » Wed Jun 01, 2011 6:11 pm

(I had some issues with mercurial and not being able to checkout only parts of a repository.)
So I like the idea of having one repository for the engine and for each game (without the engine) another repository.
It would be like your third option I think.
The engine should be working without any game on top of it. Changes to the engine will (should) benefit each as long as the API isn't changed.
+-----------------------------------------------------------------\
| Debian testing 64Bit on
| * AMD Phenom x4 905e (4x2500Mhz)
| * 6GB Ram
| * AMD/ATI Radeon HD4770 (fglrx)
+-----------------------------------------------------------------/

dublindan
Posts: 8
Joined: Wed Apr 20, 2011 6:16 am

Re: Sharing code with Shadowgrounds

Postby dublindan » Thu Jun 02, 2011 10:10 am

I agree with Urfoex

alt_turo
Posts: 195
Joined: Mon Dec 13, 2010 11:06 am

Re: Sharing code with Shadowgrounds

Postby alt_turo » Fri Jun 03, 2011 12:49 pm

Urfoex wrote:So I like the idea of having one repository for the engine and for each game (without the engine) another repository.
It would be like your third option I think.
The engine should be working without any game on top of it. Changes to the engine will (should) benefit each as long as the API isn't changed.

But it's almost certain the API would change. Currently it's rather messy. There's the strings issue mentioned in another topic. Then there's setting video mode/creating window part. It was designed to allow the editor to "embed" the scene in an editor-created window. This doesn't work on anything but Windows/Direct3D and even there it's rather messy.

If we have three separate repositories then it becomes very hard to keep them in sync. You update one and forget to update the other(s) and then you have a big mess. Bisect also becomes very hard if you have to bisect across an API change.
Turo Lamminen
Alternative Games

vayerx
Posts: 18
Joined: Mon Apr 25, 2011 10:41 am
Location: Russian Federation

Re: Sharing code with Shadowgrounds

Postby vayerx » Wed Oct 05, 2011 5:37 pm

alt_turo wrote:But it's almost certain the API would change.
alt_turo wrote:If we have three separate repositories then it becomes very hard to keep them in sync. You update one and forget to update the other(s) and then you have a big mess. Bisect also becomes very hard if you have to bisect across an API change.

Storm3D and other libraries may be used from external repository via git submodules, pointing to specific commits in master/features branches. This can be used to defer upgrades to newer api. Anyway, tracking/merging changes in a single repository is much easer than in different source trees.


Return to “Jack Claw Feedback & Development”

Who is online

Users browsing this forum: No registered users and 0 guests