We want to develop 2 puzzle games that will share a common ‘look’. I’m wondering whether it’s feasible to develop them both at the same time and have a separate codebase for the common elements (which hopefully will be most of the system stuff) that both projects can share.
Has anyone got any thoughts on this?
You might end up with the same design flaws in both. It’s certainly wise to maintain a separate codebase for common elements. But if you develop them in sequence rather than in parallel, your second game can benefit from user feedback on the first game.
yes its probably a good idea to do what tony said. if you develop the first game, and plan for it to be modular so you can swap out the assets you need for the second game, then you will be able to re-use the same project. trying to merge changes back and forth between two separate projects could get messy if not done right. if you really want to release them simultaneously (like pokemon red/blue for example) conisder setting up your project to have both versions in it, and keep a variable set to determine which one it is. then you could switch back and forth easily while developing.
It really depends on the nature of the differences between the two games. Many chains (looking at you Disney) these days simply swap assets out and rerelease as an entirely new game.
The main risk of concurrent development is both projects will flop for the same reasons. On the other hand you’ll get all sorts if synergies from working on them together.
Not my studio! We take great pains to reinvent the wheel every single time. Sometimes we reinvent the wheel for each wheel in the game. 
I really don’t mind it when it’s a good game, like the whole “where is my water” series. But do you really need match three for every franchise?
I’m treading on dangerous ground here, I have a three year old that loves perry and hates crocodiles. And a five year old that plays anything frozen.
But occasionally I play, and it’s disappointing to realise my phone has 50 games, but only 5 game designs.
As much as it pains me to admit it, those games make a LOT of money, seriously, A LOT of money. It is both the boon and bane of big studios. Milking the cash cows is what lets us take big bets on other games that may fail or fail to launch. While I cannot defend the originality of those games, I also can’t thank those teams enough for providing the other studios like mine in the lifestyle we’ve grown accustom to.
I don’t begrudge you that at all, Disney after all spent a lot of effort addicting my kids to Frozen. No reason you shouldn’t get paid for it. My OP was tongue in cheek, pointing out that asset switching is a legitimate strategy.
Now that you own Star Wars I do hope the games from that franchise continue to be as great as they have in the past. I will admit, that still has me nervous. Disney has a history of making games that sell just on the IP. Many Star Wars games would still be great without the IP.
As a long time fan of both Disney and Star Wars, please keep making awesome games.
Ill argue for putting them both in the same project. Suppose you add feature x, lets say highscores, or whatever then you have to do the same thing to project y, but if both are in the same project its golden
It not both in the same project, use three projects: common framework project, project specific to game 1, and project specific to game 2. Compile the common framework into a DLL and/or asset bundle that gets dumped into the game projects. This keeps the projects for game 1 and game 2 very lean, containing only the assets specific to that game.
Schell Games did a good presentation on this approach at Unite 2010, but the video isn’t online any more. You can still find the slides on their site.
Three projects is my current thinking, although using svn externals on a common repo to bring in the common code. The problem with a DLL is that I’ll lose the ability for platform dependant compilation right? #if UNITY_EDITOR, etc.
This is a good point.
This was an early thought however I think there are just too many specific settings for third party services, etc that would be different for each game.
We’ve done it at work before. Unless you’ve got plenty of experience (ie: have already delivered many projects) I’d heed the sequence-rather-than-parallel suggestion, though.
Are you talking about experience of the design side or the technical side of doing it?
We’ve released around 10 mobile games via Unity over the last 3 years (probably 3 times this if you count skews).
That’s true. It’s more of a workflow preference, though. DLLs are nice in this scenario because (1) no one can be tempted to edit source files in the game projects themselves, and (2) game project compiles are faster if you have a lot of code. You can do your development with one platform (e.g., web or desktop) and then switch all three projects to your target build when you’re building for a different platform. You can use something like uTomate to automate it.
If you don’t have a lot of source code, and if your developers know not to modify common code in the game projects (since this would be lost with repo updates), source might be more convenient.
Just wanted to come back and report. I worked on the one game only and it was released on Apple and Android stores last week. What I did do though is make some of the code generic and non-game-specific, and kept in in a separate SVN repo. Now, I’m setting up a new project for the next game and bringing in this generic code has really helped with getting going quickly. I’m going to go back and see if any other code can be refactored slightly as I know I’ll need to use some of it again in the new project.
And it turns out this new game will not share the same ‘look’ although it is a similar type of game.
Congratulations on the release!