What do you guys think about a model such as this. Basically it's a distributed development model, where a core group creates a seed game engine (this includes logic, UI flow, hooks for all the SFX and GFX) and pass it off to an external team which then takes it all the way and they split the profits? The core group is tasked with creating fun game dynamics and gameplay implementation, it's up to the external teams to flesh it out, polish it, tweak it, and finalize it. (core group is also responsible for creating / providing tools for integration of assets and also debugging support. ) From a work standpoint it should be about 50/50. The idea why this is better than just having the core group finish the development of the game is its 2x faster in the long run to pass it off for both parties. After the core group passes off the project they can begin on the next one. Once the external team finishes up their project, the next project from the core team should be ready for them, thus they have little down time and no ramp up time for creating new tech, and for 1/2 the time they can get a product out (the external team that is). The cool thing is the engine/framework which the core teams passes along can be the seed for many types of games of similar genre, so instead of passing the seed engine to just one team they can pass it to multiple teams which increases the chance of success. -ddn
The problem is that game development is not a cut and dry process. By nature it's a creative process in which iteration is king. The faster you can iterate the more you can throw crap out which just isn't working before you spend time fully fleshing it out. Furthermore, (and I'm assuming this would be for iphone development since you're posting at TA), you are taking away one of the key advantages of cellphone game development in that a small team of 2 or 3 people can work and produce a fairly high quality game. Instead you are introducing layers of complexity in which are more common in larger companies in which there might be a tools team, a gameplay team, etc... Also, you will never be able to accurately plan what the gameplay team would need in order to do what they want. So either the gameplay team needs to cope with what they have (which sucks until a few iterations of your seed comes down the pike), or you need to drag someone out of your engine team in order to produce content alongside the gameplay team, which of course, starts to break down the model described here.
True but most games on the iPhone arn't really complex enough to require full time developers involvement. The idea would be to give the external teams tools and they would have to work within those domains, otherwise if the core team was spending time making one off features, which you've noted kinda breaks the whole scheme. High level engines like Unity and the like try to do this but they are missing the big picture, that is most people don't have the time to learn to program or create UI frameworks or any of that, but they do have some cool ideas and can create the artwork/sfx if given a prebuilt engine with gameplay prebaked. That's the idea anways, to combine the expertise of experience developers with the entuahism of novice developers. -ddn
It's so funny reading this intelligent exchange of ideas regarding product dev, yet if you read the forum threads about EA and 8lbs Gorilla, you'd think these ppl are on another planet!
How is this any different from using a pre-existing engine? or developing an engine at the same time as developing the game? If your focus is with a community developed engine, find an open-source engine and contribute to that? If you want expertise in an engine... use an established engine, eg. unity... As wizard341 said, the problem with engines (or more specificly middleware that does game-related stuff, AI, render effects etc) is that it's never created specifically for a game in mind, the code is generally multi-purpose and instead either the gameplay team has to fit into the design of the middleware's AI (for example), OR the middleware has to develop more specific-game-orientated stuff, in which case it becomes inflexible (or flexible and ineffecient) for other games that want to use the middleware. Just as an example, the unreal engine is great for first/3rd person games, not so good for rolando... you COULD fudge a rolando game from it, but it would be inefficient compared to a rolando-specific engine (eg. simple vector graphics, 2D rigid body physics etc) Not trying to troll, but this doesn't sound like something new to me...
This model isn't exactly new but a variant of the one which larger game companies use. They found eventually that you can't do both technology and gameplay research while doing the production side of the game ( doing them well anyways). So they split the teams into the core team which in traditional studio model develops the engine, underlying technology and support infrasturcure and the external teams which actually develop games. Wizard341 is correct within that model the core team is reponsible for alot of maintance and tasked to support the external teams, but that's counter productive for small core teams since you fall back into the same old problem again. In the traditional model, the core team only works on technology but this model I'm proposing the core team works on both technology and gameplay design. The difference is this, it is a non-trivial task to develop gameplay (complex one anyways). It's also non-trivial task to produce a polish game (art, level balance, polsih, sfx, etc..). But those 2 task are almost othogonal, that is they can be developed by 2 different teams. Think of it as not making a game but making a very modable engine which has strong guarentees of stablity and some prebaked in gameplay and design. Again it falls back to the concept that programming games isn't easy, esp the more complex types. The core team leverages their experience and the external teams leverage their resoruces but they do it in such a way they both work simultanously to get things done in shorter time. I see the trend starting, as people leave the iPhone market they are selling off their prebuilt engines which I'm sure someone will buy and mod to make another game. But those engines were not designed to be moded so you can only take them so far. -ddn
It's counter productive for large teams too... it gets even worse when a "gameplay" middleware layer is added too. Where I used to work we had an engine (physics, rendering, hardware specific stuff) and as the game teams used parts of the engine in wholly different ways, and implemented other elements from scratch (eg. UI/menus) it was decided a middleware team should be setup for common game elements (menus, clever animation stuff like IK, user management, networking lobbys, base AI systems, pathfinding etc) This then meant the engine had to negotiate changes with game teams and the middle ware. The middleware had to negotiate changes with the engine and games teams. This was more counter productive than the lack of code re-use. Tools (another whole team) suffered with the same problem as game teams had to shoe-horn in features into tools designed for other things. (eg. use of instancing in tools was designed for foliage and was quite random. The technology in the engine was built around this... when we needed to use instancing for the crowd system -non random distribtion/modelling- the tools and engine needed a bit of an overhaul. This caused big delays for the game team) Won't they end up tailoring the engine towards the game they're working on? (especially if time is an factor) To make a good engine/middleware that is non-game specific, don't you think the engine developers should keep a distance from the game? (This may or may not be my opinion, just being objective) This doesn't sound like a 50/50 workload distribution to me either. So a much more established engine which is stable and has been used for many games would be much more suitable? There are various open source and paid-for engines that do this already... eg. unity, orge, unreal, quake/id tech, cocos2d... Again, I'm trying not to troll, I'm just trying to grasp what the new part of the idea is Just sounds like a (TA I assume) community contributing to an engine... and you want the engine to be designed to handle multiple game types, whilst providing common game-specific functionality. Edit: lots of people have tried this before and failed. Programmer ego (or the want to work on the technology themselves) drives people to re-invent the wheel again and write their own engine... That's what we've done, we think we can do it better than the efforts currently availible and the design model we've used works very well for us. But other people won't like how we've written it...
Yup, this does work, with one caveat. You need to dedicate a person (at least 1) that asks as an 'interface' between the tech and the gameplay. This person needs to be both knowledgeable of the engine architecture and the game architecture. When a new version of the engine is ready, this person would be in charge of dropping the new engine into the game and making sure all systems still work as intended. Many times you can have some very unexpected bugs due to how game logic may have been referencing memory, or interface changes... etc which may take this person days to fully integrate the new engine in. The problem is that you need a devote a whole person to doing this. Stressing the importance of small cell phone development teams, you need to ask yourself if hiring this middleman is feasible on your budget. If so - go for it. Just make sure he is the point man on any game->engine (and vice versa) communication and that he knows both systems equally.
ddn, do you have core team/engine and want to hire external teams to finish games? If yes, we can discuss this.
You bring up valid points HouseTreeRobot, but my idea is to not try and provide an engine and let the user develop a game from it, it's to give the user a prebaked game with no assests but hooks for logic and gameplay, tools, and let them go at it. Think of it more like how the mod community on the PC works, people have access to the tools and if their luckily the logic hooks and they can create "variants" of the game fairly easily. The work involved in that case is more 50/50 than the traditional middleware setup of i would say at best 20/80 (where the engine is only 20% of the work). Also the engine isn't directed toward developers who can do the programming themselves, it's more directed toward novices and artist who have cool ideas and enough technical competence to make the assets and tweak the gameplay to realize a sellable product. Programming puzzle games, rts, fps, etc.. I've done almost all those and know the pitfalls and what's needed to setup a content pipeline for each. That's pretty much what you're getting from the core team (implementational experience, content pipeline, hooks into a prebaked game engine), they have to provide the design,art,assets,levels and QA. to ivan_m: This is just a feeler concept right now, It's just myself and my brother right now, but we are thinking about opening up our technology as we develop it for our internal games. We develop prototypes which we just don't have the time to peruse, but might be of interest to others. -ddn
Development time would be better spent learning an existing library, with all of these steps already finished for you. If you really need something different, contribute to the library (if it's open source), or write an extension.
I'm already well versed in all those technologies, so for me that's not the bottle neck. Also I can make games quickly but to get them to a polish sellable state is the bottle neck. The idea is to partner up with external teams where we can use our strengths to finish games faster then if we had done them individually. That's the idea anyways. -ddn
