Skip to main content


Topic: Polygon on Copying/Stealing Game Design (Read 2793 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Polygon on Copying/Stealing Game Design

A well-informed article by Ben Kuchera on learning how to copy someone else's game design aspects and, more importantly, when to do it and what to actually "steal." A good quotation from early in the article (emphasis mine):

Quote from: Mike Bithell, developer of Thomas Was Alone
Look at the game you are thinking of copying, the one that got all those YouTube views, and look at why it worked, the decisions and choices, the objectives, how the surface of the game achieved the outcome, and then come up with something different that may duplicate some of that success.

I highly recommend reading the entire article because there are some really good anecdotes peppered throughout, so I'm not going to summarize the thing here.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Polygon on Copying/Stealing Game Design
Reply #1
Sorry I didn't comment earlier but I did have a look at that and I must say I agree. I mean look at the flappy bird clones. Even getting a few sales in those games and you have already turned a profit since they are so easy to make. They looked not at the game per-se but at the fact that the controls and presentation reeked of efficiency in terms of ROI.

The idea, the core underlying powerplant of an IP is more important than the content. I think the I in IP, the word "Intellectual" means a lot more than just 'of/from a human' but that there was a smart idea behind the P "property".

One Idea I had felt like stealing was Halo. Picture fighting on a 'man-made planet' that's other than a torus. Then immerse the player in that world so when they tilt the camera up they see a different shape looming in the background. Things like that, but more importantly for FPS's or RPG's is to look at the statistics: how hard enemies are, where to spawn players. This kind of tweaking is what can save you. There was a shooter, "Rekoil" that wanted to copy arena shooters from back in the day like Quake. A solid idea I'd say (I mean they were immensely popular, what changed since?). However, they did not account for handling any of the modern smart placement of respawns on a map. Players who knew the 'n' respawns on a map can literally camp on those x/y/z locations and kill the player every time.

But that's not just a good idea gone wrong that's true for anything. I'd say in addition to that article is that you should look at games that failed and as to why they failed. Then and only then can you see both sides of the coin. What was successful, and importantly what wasn't?

Now I play a game called King's Bounty and I say the game is neither a success nor a failure, so there is that possibility where you've made a game that was good enough to slip on by without making it big. They made a well polished game, but since they had no driving 'wow' factors, in the end they just made a solid game that was good to play and nothing more, and failed at captivating large audiences since you kinda just play it and like it or not, nothing spectacular about it. But as I said nothing bad about it either.

My game Blockman was going to be a Secret of Mana type game, but with different paint and story. But boy is it hard. Sometimes a game is successful due to the shear volume of amazing content. Not a single set piece moment, but the whole thing. I feel the same way about earlier FF games and Chrono Trigger. Nothing too amazing besides having solid amounts of effort on all fronts of the games design and execution. Some might cringe to hear this, but, I think Chrono Trigger would have been the same in success no matter what story they wrote (so long as it isn't too inane or banal). Of course that's not true for every game but for some that was undeniably the main selling point. Minecraft may not have the best graphics so it's motivations, unlike Chorno Trigger were different.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here