I've been following custom projects like the hearts of oak for many years in different genres when they attempt to copy a game. To not discourage or "criticise" the developers too much, I'll put in a few opinions in this thread (since it's been brought up already). Just a few opinions... (based on my experience of witnessing many such projects over time)
1. If something works well in the game you're trying to copy (don't attempt to fix it TOO much, if it's working, it's working, no change needed, just a facelift is needed)
2. Don't go wild on the details before first release (too many things put into the game pre-release can turn out to be a mistake)
3. If the game you're trying to copy is very simple in nature, try to make YOUR game simple in nature too on first release,
then take it from there
4. If the game you're copying is fun
because of simplicity, be careful to try to improve that part of the game
by implementing more complexity
5. There is a reason you are programming a new game based on an old game, it's because you liked the old game (Try to consider that before changing every aspect of it)
6.
Every change you make is an experiment, it may succeed and it may fail. Every change you
copy from the old game is a success by default
7.
Fun factor is more important than
details.
Fun factor is more important than
details.
Fun factor is more important than
details.
8. Find the cruicial elements of the game, and spend an incredible amount of time making sure the basic elements are
fun.
9a. Why did games like Open Transport Tycoon succeed?
Because they copied every aspect of the original game in perfect state, and
then changed the game from
that point on. Might be worth considering.
9b. If you pretend to be copying the game but are really creating an entirely new game, it's a gamble. Don't forget it. (In this case with hearts of oak, I think that gamble may succeed, based on what i've seen)
10.
Use other people to test if the game is fun. Developers who test their own project
become delusional over time because when they perform thousands of tests themselves. (If you drive your car through a 100 mile long tunnel, you'll become blind of speed eventually, the same is true for testing fun factor, testing other elements of the game. USE other people to test if its fun, don't do it yourself, as a developer)
11: Exellent architecture and excellent graphics is not enough. Excellent architecture and excellent graphics is not enough. You need to adjust how the world is shown to create a vivid colorful but simple old fashional environment of the 3d representation. Look at the cozy environment of PotC you'll understand why its magical. Look at the incredible nice graphics in modern 3d shooters, you'll understand why its beautiful. But a pirate game
needs a cozy environment before a
nice graphically environment.
12. Overly complex GUI systems
absolutely destroys the game. There are ways to implement advanced features of the game
without implementing more advanced GUI's, it just takes an einstein to figure out how to do that.
13. In all games that have ever succeeded, there was one common elements in all of them.
Simplicity on the surface, with
potential complexity under the hood. Your job as a developer is to remove complexity from the eye, and keep the complexity available if the player digs deeper to find it.
14a. Avoid symmetry. (Huge shipyards with a hundred vessels at the port might be a tempting feature to implement into the game, but it's a mistake, don't do that,
it adds absolutely nothing to the game, just take my words for this)
14b. The player wants to see his own ship at the port (with one or two minor cheaper vessels). He wants to go "Wow, look at my wonderful ship". He doesn't want to go mining for his ship in a swarm of other beautiful ships.
Simplicity always works.
14c. You may be thinking to yourself "
But i'm a developer, I WANT to create huge shipyards, it's so cool". Being an artist is about sacrifice, it takes a piece of your ego to
NOT implement beautiful things.
15. Decide early on whether or not this game will be a personal game for your own taste or if its going to be for you and for other people as well. When you have made that decision, shape your game philosophy and
stick to it, no "half assed" attempts.
16. Avoid duplicating "things" in the game of equal value. Make sure that each item is useful to the player, to avoid confusion and avoid redundancy. The player wants to experience that each change has a meaning. If a new item or a new quest doesn't add or take away anything to that experience, it's redundant to have it in the game.
17a. When you walk into the tavern, is your only thought "
I want to get to sea again as quickly as possible because I love it there" then you can be sure that you have succeeded implementing fun factor with sailing ships.
17b. When you walk into the store to buy a gun, is your only thought "
I want to get into the jungle as quickly as possible to find someone to shoot" then you can be sure that you have succeeded implementing fun factor with guns in the game.
17c. Ditto with swords. (Try to make these 3 basic elements of the game FUN, almost desperate to get back to playing out these 3 elements)
18. To maximize the fantazy factor in the game I highly suggest sticking to the no-clear-voice characters as you find in PotC.
19. Music in the game should be the "optimistic" type of music, which brings your mood up to a joyful level, avoid the "sad" kind of music.
20. If the player chooses to be an evil pirate, it's important that the developers try to make the player still believe he is the good guy. It's quite twisted how this works, but the player does never want to be the bad guy and game designers know this. It takes quite alot of skill to implement that, but you should allow the player to be the bad guy without being the bad guy, as strange as that sounds. (Every "bad guy game" out there ultimately leads the player to believe he is actually good without even knowing it) if you can manage to do that properly, the player feel he has more options to "play out his dark side" without paying the consequences of that. There ought to be short term consequences, but not long term.
21. The longer it takes to open the hatches and prepare the guns for offensive, the more romantic and more special each battle will be. If the hatches and guns only takes a few seconds to open up, the less romantic each battle will be. That doesn't mean the player should "work hard" to get the guns prepared, no, he should be able to prepare the gun with the single click of a button, but it should take some time to get the guns ready. 10 seconds is probably a good number here (give or take) and the guns ought to move forward and backward asynchronously (so that each gun moves before or after the next, and a small amount of difference in the angle it moves (to prevent symmetry here))
perhaps with a bit rumbling sound on the wooden floor
22. The sails in PotC is "too loose". There ought to be more tension on the sails the stronger the wind is. Keep in mind that these canvas are carrying one thousand tons of weight, there should be more tension on the sails.
23. Ability to give permanent orders to your other ships, instead of having to give specific orders to those ships every time you go to sea. You can give each ship a "job" and it sticks to that job, and also form "formations". If there is anything that mattered back in those days, is ship formations.
24. Ability to toss planks between two ships while at sea, so you can walk over to the other ship in real time without overcomplicating the interface for achieving that (automated).
25. More rats on the ship. Have to keep in mind that, rats also travelled back in those days and they still do today, rats were common "passengers" on those ships and they travelled between continents just like humans did, by joining the ship.
"Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away" - Antoine de Saint-Exupery
