(I am just talking about the development aspect here, not the design aspect.)
I think developers should include a healthy amount of non-referenced work in their early careers. Many junior programmers sometimes think they cannot solve certain problems, simply because they have not had the experience (or a suitable reference). It's not just a matter of developing the actual problem solving skills when you are on your own, but also to have the confidence to attack such problems in the first place. IMHO, this sets you up on a path that has much more breadth (which is very useful in our microscopic game industry in South Africa).
"You can't find this algorithm online? Of course not! You are about to invent it!"
To be clear, by cloning I do not mean blatantly ripping off another game in every way and then calling it your own
That's what cloning means! Please stop muddying an already confusing conversation by re-defining one of the core terms. Yes, people can build Tetris-variants or riff off of Donkey Kong as much as they like. But can we stop calling the apprentice-level re-making of games some sort of "positive cloning"? It isn't.
So if you want to intimidate beginner into trying to be super creative off the bat beyond what they are capable of, that is your business, I will continue to encourage them to work from reference and fall back on it when they need to, saving themselves the disasters I brought on myself when I started.
So, lets just agree to disagree ;)
I don't know where you think we disagree. I keep telling hopeful devs to make Tetris - if they do end up making a unique twist on it, yeah, then maybe sell it... I just wish you wouldn't advocate an edge-case definition of cloning.
There's nothing wrong with cloning if you're just making stuff and practicing. There's something wrong with cloning if you're copying it exactly and blatantly and selling it.
The "classics" like Tetris and Pacman are less un-OK to clone for profit, because they're obviously really old and people know them for what they are and your game is unlikely to be seen as an "innovator" which it isn't, but cloning newer games for profit is a problem because it attempts to undercut the originality and creative currency of the original creator.
People need to understand the difference between a mod and a clone. I wouldn't rely on the Wikipedia definition of the term either, it was basically made popular by game journalists (not the most reliable sources of information). E.G just because you made a fighting game in 1993 with digitized sprites suddenly means you're a Mortal Kombat klone? Lol. Even most video game ports can't be called clones, would you say Pac Man on Atari 2600 is a clone of the Arcade version? Typical game industry, basically rewrite scientific definitions to suit popular trends.
Except that while I worked for Gameloft and several other fairly well established game developers, the word clone was used as a games inspired and referenced from other games. I guess Gameloft and their brother company Ubisoft must just be strong arming their 10,000 employees into miss understanding the word. I guess its ok since my friends from EA also understand what we mean when we say clone, so its not a problem for cross company communication. Those damn jernos, confusing so many industry pros. :D
To me, a clone is a copy that adds no or a trivial amount of original content/innovation over the original. I think these are negative, especially when they can obscure or push past the real innovators, because this means that the real producers of value in the market/society are not the ones being supported. Iterating significantly over an existing idea is a positive thing, IMO. I always found terms like "doom clone" amusing when I saw that they were only similar in the irrelevant bits. Of course I'm only talking in a commercial context - practice and learning is separate.
This topic looks like some kind of hydra with some interesting heads, IMO, but I'm not sure about advice for new game developers.
Except that while I worked for Gameloft and several other fairly well established game developers, the word clone was used as a games inspired and referenced from other games. I guess Gameloft and their brother company Ubisoft must just be strong arming their 10,000 employees into miss understanding the word. I guess its ok since my friends from EA also understand what we mean when we say clone, so its not a problem for cross company communication. Those damn jernos, confusing so many industry pros. :D
Gameloft has ample reason to muddy the definition of cloning.
But yes, let's try to confuse a definition of a shitty practice so that new developers have clarity... Cool story bro! I note that you're not going "Oh, yeah, that previous thing I accused you of doing was wrong, my bad" and instead justifying things based on some sort of appeal to authority. Rad.
@disleksia sure I think you try to intimidate other devs into seeing the word definition the same way you do, referring to the way you addressed the issue. Your counter argument was that you encourage people to clone by my definition, but that you do not agree with the definition. So addressing your concerns over the definition, And based on we agree on the practise of using reference games as a junior. I will apologise for miss understanding the intent of your intimidation.
The "classics" like Tetris and Pacman are less un-OK to clone for profit, because they're obviously really old and people know them for what they are and your game is unlikely to be seen as an "innovator" which it isn't, but cloning newer games for profit is a problem because it attempts to undercut the originality and creative currency of the original creator.
I think you are wrong here. Cloning classics for profit is not OK.
I came across some auto-maze generation algorithms for Pac-man, but the guy had to take off his source code: https://github.com/shaunlebron/Pac-Man (the source code was eseentially a Pac-man clone, not only the maze algorithms).
Well it depends on how you go about it. Honestly do you think a straight-up tetris or pacman clone is going to be profitable easily in this day and age when they've been out there for so long?
To re-iterate: Advice for new game designers is to re-make "smaller" classic games to get the feel for what it's like to actually put gameplay to metal (as it were) and then branch out to more complex projects from there. DON'T TRY TO SELL THINGS YOU COPY. If you can't finish a project, start one that's half the size - keep doing that until you finish something.
Sometimes it's fun starting something and after some of the concepts start coming together, you run unto what can probably best be described as artists block or something like that, where you are not quite sure what to do next. Right there you run the run the risk of thinking "hey, this new game idea sounds more fun, lets do that".
So while there is nothing wrong with canning a project that isn't working, don't fall into the habit of not finishing what you start. See it through, learn something from it. Do something with it. Heck give it away for free. This is a simple way to build goods habits around your bad habits and soon enough, your bad habits will drive good behaviour. It also helps you talk to your spouse/girlfriend/boyfriend/cat/donkey/shrek/local indie forum. Get their feedback on what you do and how you do it, that also helps you drive out the non-finisher behaviour or to identify it early.
It's interesting where the answers to "advice for becoming a better game designer" and "advice for becoming better at running an indie game dev studio" diverges. It's something I've been giving a lot of thought to lately and I don't actually think I have I have a clear answer yet, not even close to one.
Given hypothetically infinite amounts of time I think the answer to these two questions become more similar but sadly in reality it's not always viable to follow the same approach.
I realise that this distinction doesn't really concern a lot of hobbyist devs but its been interesting thinking about how to invest your time and the time of your company when the goal is to become a studio that can self sustain purely on the creation of games.
I didn't read the whole thread, but can not pass an opportunity to say a thing or two about creating your own engine.
There is a game that was promised some 10 years ago, Infinity:Quest For Earth, the dev decided to make a custom engine for the game, the game itself was supposed to be an Elite Clone MMO with a million features and community content (his first game). Years passed and the engine was never good enough, then a dev from Epic Games joined the team and with his wealth of experience in engine coding decided that the whole engine had to be re-written. It's now 10 years since the start of development and the engine is still not good enough and is not in a state where a game can actually be made with it.
I have been the part of that community for nearly 10 years, and my advice is that you do not code your own engine, it's just way too painful to watch. ;)
It's interesting where the answers to "advice for becoming a better game designer" and "advice for becoming better at running an indie game dev studio" diverges. It's something I've been giving a lot of thought to lately and I don't actually think I have I have a clear answer yet, not even close to one.
Given hypothetically infinite amounts of time I think the answer to these two questions become more similar but sadly in reality it's not always viable to follow the same approach.
I realise that this distinction doesn't really concern a lot of hobbyist devs but its been interesting thinking about how to invest your time and the time of your company when the goal is to become a studio that can self sustain purely on the creation of games.
I think, personally, I've neglected the "business" aspect of it for far too long. Sure, it's a part time hobby-hope-to-make-it-a-business.com thing for most of us, but the overwhelming feeling I have and one that I certainly share with quite a few game devs that I know, is that success doesn't come cheaply, err, most of the time.
While you can in theory plan for success, look at MonsterBusters as an example, the effort involved covers a broad range of business decisions that very well might impact your game design. So the if you build it, he will come approach may not be the best way to go, even though there are a few stand-outs for whom it worked.
A silly example would be your revenue model, with the emphasis here on silly. If you charge for your game, your barrier to entry for a customer is trust. The customer needs to see the value in your game. One of the metrics (not the only one) is how many people play it? That's a chicken and egg scenario right there and with the proliferation of free games these days, difficult to overcome.
If however you make your game free, you need some form of advertising revenue or In-App purchases to see any returns.
For advertising revenue, you need boat loads of people to play your game before you see any value. Getting boat loads of people to play your game requires lots and lots of work on advertising, social media and of course, player incentive to share the fact that they play your game. In addition, your player retention needs to be excellent. You don't want your game to be installed, played a few times and then uninstalled. No no, you need every player who installs the game, to grow your active user base to which you are pushing ads. Thus the design impact. By contrast, the pick and play through once game that you sell for $1 doesn't have this issue, you've made your money from the customer before he played it. So now, he plays the game, finishes it and gets his $1's worth. I'm not saying you shouldn't, but for your revenue model you don't care about the retention ratio for him.
If you decide on the In-App purchase revenue model, you need an in game currency that encourages your players to actually make a purchase. You want the player to "want" to do something that results in him making a purchase. But again, this is a fine line. Over charge him and he won't buy. Charge him too often and he loses trust in you. Charge him too little and he can just buy his way through the game and there goes your retention ratio.
Obviously you could design the next World of Warcraft where players play for free in their thousands and sell it Zynga for a fortune. Or you could not.
Of course, this isn't applicable to everyone and all scenario's, just my own rambling on some of the things I think I've neglected and that I will attempt to right my ways on. You could also argue that if you build a good game it will be successful/make money etc etc. The bottom line, Proper Planning Prevents Poor Performance....and some luck.
It's interesting where the answers to "advice for becoming a better game designer" and "advice for becoming better at running an indie game dev studio" diverges. It's something I've been giving a lot of thought to lately and I don't actually think I have I have a clear answer yet, not even close to one.
Given hypothetically infinite amounts of time I think the answer to these two questions become more similar but sadly in reality it's not always viable to follow the same approach.
I realise that this distinction doesn't really concern a lot of hobbyist devs but its been interesting thinking about how to invest your time and the time of your company when the goal is to become a studio that can self sustain purely on the creation of games.
The way I see it, the only "difference" is a focus on useful metrics and ruthless evaluation. Basically, when you're trying to run a company and not starve, you can't afford to let the lies you tell yourself to assuage your ego gain traction. Your cash-flow can't lie the same way.
It's pretty easy to trace the results of different indie companies back to the specific types of metrics they prefer and, as a result, the behaviors that they prioritise over others. A studio that can prevent spending good money after bad is going to do better. A studio that can generate multiple potential leads and income sources with the same set of skills (and team) is going to do better. A studio that can properly focus its resources efficiently is going to do better. All of those things are only possible with good, solid, meaningful measurements to make decisions against.
Experience as "gut-feel" is just a bunch of internalised measurement data.
Comments
I think developers should include a healthy amount of non-referenced work in their early careers. Many junior programmers sometimes think they cannot solve certain problems, simply because they have not had the experience (or a suitable reference). It's not just a matter of developing the actual problem solving skills when you are on your own, but also to have the confidence to attack such problems in the first place. IMHO, this sets you up on a path that has much more breadth (which is very useful in our microscopic game industry in South Africa).
"You can't find this algorithm online? Of course not! You are about to invent it!"
The "classics" like Tetris and Pacman are less un-OK to clone for profit, because they're obviously really old and people know them for what they are and your game is unlikely to be seen as an "innovator" which it isn't, but cloning newer games for profit is a problem because it attempts to undercut the originality and creative currency of the original creator.
Iterating significantly over an existing idea is a positive thing, IMO.
I always found terms like "doom clone" amusing when I saw that they were only similar in the irrelevant bits.
Of course I'm only talking in a commercial context - practice and learning is separate.
This topic looks like some kind of hydra with some interesting heads, IMO, but I'm not sure about advice for new game developers.
But yes, let's try to confuse a definition of a shitty practice so that new developers have clarity... Cool story bro! I note that you're not going "Oh, yeah, that previous thing I accused you of doing was wrong, my bad" and instead justifying things based on some sort of appeal to authority. Rad.
I came across some auto-maze generation algorithms for Pac-man, but the guy had to take off his source code: https://github.com/shaunlebron/Pac-Man (the source code was eseentially a Pac-man clone, not only the maze algorithms).
And there was a famous (?) Tetris lawsuit in 2012: http://ipspotlight.com/2012/06/12/looks-like-tetris-video-game-clones-and-copyright-law/ (not sure if the article is good, just wanted a link for showing it happened).
Sometimes it's fun starting something and after some of the concepts start coming together, you run unto what can probably best be described as artists block or something like that, where you are not quite sure what to do next. Right there you run the run the risk of thinking "hey, this new game idea sounds more fun, lets do that".
So while there is nothing wrong with canning a project that isn't working, don't fall into the habit of not finishing what you start. See it through, learn something from it. Do something with it. Heck give it away for free. This is a simple way to build goods habits around your bad habits and soon enough, your bad habits will drive good behaviour. It also helps you talk to your spouse/girlfriend/boyfriend/cat/donkey/shrek/local indie forum. Get their feedback on what you do and how you do it, that also helps you drive out the non-finisher behaviour or to identify it early.
/me ducks under the table
Given hypothetically infinite amounts of time I think the answer to these two questions become more similar but sadly in reality it's not always viable to follow the same approach.
I realise that this distinction doesn't really concern a lot of hobbyist devs but its been interesting thinking about how to invest your time and the time of your company when the goal is to become a studio that can self sustain purely on the creation of games.
There is a game that was promised some 10 years ago, Infinity:Quest For Earth, the dev decided to make a custom engine for the game, the game itself was supposed to be an Elite Clone MMO with a million features and community content (his first game). Years passed and the engine was never good enough, then a dev from Epic Games joined the team and with his wealth of experience in engine coding decided that the whole engine had to be re-written. It's now 10 years since the start of development and the engine is still not good enough and is not in a state where a game can actually be made with it.
I have been the part of that community for nearly 10 years, and my advice is that you do not code your own engine, it's just way too painful to watch. ;)
https://inovaestudios.com/
While you can in theory plan for success, look at MonsterBusters as an example, the effort involved covers a broad range of business decisions that very well might impact your game design. So the if you build it, he will come approach may not be the best way to go, even though there are a few stand-outs for whom it worked.
A silly example would be your revenue model, with the emphasis here on silly. If you charge for your game, your barrier to entry for a customer is trust. The customer needs to see the value in your game. One of the metrics (not the only one) is how many people play it? That's a chicken and egg scenario right there and with the proliferation of free games these days, difficult to overcome.
If however you make your game free, you need some form of advertising revenue or In-App purchases to see any returns.
For advertising revenue, you need boat loads of people to play your game before you see any value. Getting boat loads of people to play your game requires lots and lots of work on advertising, social media and of course, player incentive to share the fact that they play your game. In addition, your player retention needs to be excellent. You don't want your game to be installed, played a few times and then uninstalled. No no, you need every player who installs the game, to grow your active user base to which you are pushing ads. Thus the design impact. By contrast, the pick and play through once game that you sell for $1 doesn't have this issue, you've made your money from the customer before he played it. So now, he plays the game, finishes it and gets his $1's worth. I'm not saying you shouldn't, but for your revenue model you don't care about the retention ratio for him.
If you decide on the In-App purchase revenue model, you need an in game currency that encourages your players to actually make a purchase. You want the player to "want" to do something that results in him making a purchase. But again, this is a fine line. Over charge him and he won't buy. Charge him too often and he loses trust in you. Charge him too little and he can just buy his way through the game and there goes your retention ratio.
Obviously you could design the next World of Warcraft where players play for free in their thousands and sell it Zynga for a fortune. Or you could not.
Of course, this isn't applicable to everyone and all scenario's, just my own rambling on some of the things I think I've neglected and that I will attempt to right my ways on. You could also argue that if you build a good game it will be successful/make money etc etc. The bottom line, Proper Planning Prevents Poor Performance....and some luck.
It's pretty easy to trace the results of different indie companies back to the specific types of metrics they prefer and, as a result, the behaviors that they prioritise over others. A studio that can prevent spending good money after bad is going to do better. A studio that can generate multiple potential leads and income sources with the same set of skills (and team) is going to do better. A studio that can properly focus its resources efficiently is going to do better. All of those things are only possible with good, solid, meaningful measurements to make decisions against.
Experience as "gut-feel" is just a bunch of internalised measurement data.