Ari, here's an in-depth (and quite long) message containing my criticism and suggestions for Eden as they relate to update 2.0.
I have posted some of my criticism of the update on Facebook. As I understand you aren't a big fan of reading Facebook comments (for understandable reasons), so here it is on the forum.
The thing that bugs me the most in the new update is the distortion of the blocks in the world. Blocks may become rectangular and stretched, and this is especially noticeable with treasure cubes that rotate in place.
This should not be the case. As I have stated elsewhere, to handle a larger screen size, simply extend the field of view. Allow more of the world to be seen on each side. Don't stretch the world out to fit the screen, as this is inelegant and rather painful for the human brain to process.
The human brain has evolved to see the world as constant. That's how it wants to see the world. When it's stretching, it's not constant anymore. This creates dissonance, and dissonance is not great for your experience playing the game.
Yes, you may certainly get used to it, but that doesn't take from the fact that it could be done in a more proper manner (how it was prior to the update).
As you may know, I have been working on a massive obstacle course world. Treasure cubes sound perfect for this type of world, as it gives more incentive to add secret areas (rewarded with treasure cubes), and for completing hard mode challenges instead of only the normal mode challenges.
I was deeply disappointed to find that I could place at most 10 cubes. There's no way this will work with the size of my course.
And this brings up a larger issue that isn't specific to my case alone. The problem of scaling with various world types. Some people make huge worlds, some make small worlds. Doesn't it make sense that a huge world would require more treasure cubes than a small world?
And what about worlds that want to make treasure cubes the main element?
When making a sandbox game, try to add features that give the player as much control over the world as possible rather than making them very restrictive.
My suggestions, then, are as follows:
1. Allow unlimited treasure cubes to be placed.
2. Each time a treasure cube is placed, add one to the total treasure cubes in the world. This number should be displayed to the user in some way.
3. Each time a treasure cube is collected, add one to the total treasure cubes in possession. This should also be shown to the player. Example: if I place five cubes and collect one, it should display to me that I have collected 1/5 cubes.
4. Each time a treasure cube is deleted, subtract one from the total available cubes in the world.
The one problem we will run into with these suggestions is: how do we remove cubes that have already been collected? They now cannot be deleted from the world. This is a problem because there's no distinction between editing mode and playing mode.
To deal with the problem without any large scale programming projects, I propose a new button be added. This button will let you empty out all collected treasure cubes, which will place the collected treasure cubes back where they were originally placed and no longer count them as being collected.
Then from there, they can be deleted as normal.
This requires some programming work, but I can't see it being a significant issue. The computer will have to remember the positions for the collected treasure cubes, which is a very simple task. All you have to do is fill up an array, or some other data structure, with the position of each treasure cube that is collected. When you go to collect, add to the list. Then pressing the button simply means iterating through the list and placing a treasure cube at each position, replacing whatever other block is there in the case that one was placed there.
What we have done now is allowed unlimited treasure cubes to be placed, allowed for a counter to exist that will show how many treasure cubes are in the world and how many have been collected, and the ability to empty out all collected cubes back to their original locations.
This latter feature is particularly handy for those players who played through a world such as the obstacle course world I'm working on, and want to start over again. Since all the cubes are collected, how is the world to be reset so they can get collected again? This button.
Most of what I have to say about portals in terms of criticism is the exact same thing I said about treasure cubes.
It's fine if you use less portals than there are colors. And there are a lot of colors, but for larger worlds you might certainly want more portals than that.
This is, like with the treasure cubes, a problem of scale. Some worlds may want a very portal-focused world, and some may simply be so large that a massive amount of portals will be required.
You can certainly place more portals than there are colors at the moment. But the behavior becomes strange once you have more than two portals of the same color. Each portal becomes linked in a circular way. The problem here is that it might change the link that had existed before, that you created for a specific reason.
My suggestion here is a very simple one.
Link only two portals of the same color. That is, if I place two red portals, they should be linked. If I place a third red portal, it should not be linked with any other portal because the previous two are already linked together. If I place a fourth, though, then it can link with the third one.
This will theoretically allow infinite portals to be placed in the world. It isn't without a few issues, though.
What if you delete a portal? If you do, treat it as unlinked and link it with the next portal placed of the same color.
This does not allow for more complex behavior. Examples being linking all portals of the same color together and randomly teleporting out of one. It also doesn't allow any other way to link multiple portals together, you're stuck with two.
Trying to fix this problem with the color-based linking means limiting how many portals can be placed. I think limiting how many portals can be placed is worse for the game than the other options, given that you can try to find workaround ways to create complex portal behavior while using two being linked as the basis.
I would, if I were developing this game, have preferred a different approach entirely. I don't like the idea of linking portals via color, for two reasons.
The first I already spoke about. No matter how you go about doing it, you're limiting the players. You're either limiting how portals can be used or limiting how many can be placed. Really, it's most likely that you're limiting both of these.
The second is that some worlds have strong visual components that could be disrupted. I may want a certain color pattern along a wall. If I have to use a different portal color because the other color was used elsewhere and I don't want interference, I have to use a color that doesn't fit in with my wall anymore.
The solution I propose is as follows.
The Function Button
Add a new button to the game. This button I will call the 'function' button. This is going to be a general purpose button which will have a behavior based on the block it is used on. It works like the fire or deletion buttons that currently exist. When you tap on fire, the game's state is set to 'burning' mode. Now each time you tap, fire is applied to where you tap.
This is how the function button will work. When you tap it, you're in 'function' mode. When you tap a block now, the block type will be read and behavior will be based on it. So if I am in function mode and I tap on a portal block, the function that will be used is portal linking. It will mark the portal that was tapped as ready to be linked. Now if you tap a non-portal block, nothing will happen. You can't link a portal with a non-portal block. What you will do now is go to another portal and tap that portal. You had a queued up link action thanks to tapping the other portal, and it will be applied to the new portal you tapped.
These portals are now linked.
This has interesting implications as far as complex behavior is concerned. While it still may be limited to two portals being linked, the player now has more control over how portals can be linked. This allows you to much more easily provide support for complex portal behavior (linking more than two portals together in this way).
And I don't think it is very inconvenient to the player. It solves both of the issues I mentioned previously.
Beyond this, this function button allows for a whole new world of features to be added to the game since this function button would be general purpose and work for many types of blocks. You can really get some complex and interesting mechanics going in your world with features this button could allow for.
This, of course, is a large-scale programming project and is simply a suggestion for the future. My recommendation for the short-term is to apply the suggestion I offered using the color linking system which only links two at a time together. This will allow unlimited portals to be placed.
I will go ahead and admit at this point that I haven't studied the behavior of 3+ portals of the same color deeply enough to be able to adequately understand which types of behavior are supported by it. What I have gathered is that it's rather likely that your attempts in creating more complex behavior will end up ruining functionality you had created previously, in ways you wouldn't prefer. So I will make the claim, perhaps with limited knowledge, that implementing my suggestion would either entirely improve the current portal system, or the positives should outweigh the negatives in general.
I have now listed my three main concerns with the update, and possible solutions to those concerns.
Apart from these issues, I find the update to be quite fantastic and a job well done. I am pleased that you have decided to release it and that you didn't give up.
I am hopeful that you will continue to develop Eden. Don't be demotivated by the insults found on Facebook, or by competition such as Minecraft. Most of the anger by the players comes from the fact that they love the game and really want to see it improve. And I personally would love to see Eden and Minecraft diverge more and more. They should be separate games going in separate directions. Let Minecraft be focused more on survival and simulating (in a blocky way) reality. Let Eden be about building, and what makes an enjoyable and fun building experience.
I am also hopeful that you will consider the words I've written above. I have taken the time to write this post because of how much I want to play Eden again and enjoy it. When I heard the update came out today, I had to download it and play it again. And I want to keep playing it, and work on the obstacle course again with Ashley (who was equally as excited about the update as I was).
But if you, Ari, don't have much faith in your game, then how can we? As long as you do and plan to support it (including by fixing some of these issues I mentioned in the above post), we will continue to play it.
And the last thing I will say on this is: thank you for finally updating!