I would avoid the term "elegant". There is no clear definition, and if there were, it should not be assumed it is good thing.
First, you should make working code. If your code doesn't do what it should do, then all other qualities are irrelevant. After it works, you can refactor the code to reflect other attributes such as:
I would argue that simplification is not a desirable characteristic and optimization should only be done when absolutely necessary. Readable and modular code are the best qualities to strive for. Robert Martin (The author of Clean Code) has said:
> Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.
and
> So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.
I do like your idea of writing code like writing an essay, however I would follow the technique of writing where you start with notes, then an outline, then a rough draft, then successive revisions. I see software development as starting with a proof-of-concept, then a prototype, then a pilot, then a minimum viable product, then successive production versions.
Possibly one or both of Bob Martin's books. Agile Software Development, Principles, Patterns, and Practices (comes as a Java or C# version, but many of the ideas will probably be useful if you are using an OO language) or Clean Code
The text book I used for my Computer Graphics course has everything you'll need. Any 3D game programming material deals with the 2D window into a 3D model.
If you're looking to do this to understand the problem better, then you're taking the right approach by starting with understanding the problem. If this is just a challenge to learn to code, then a code-first approach would probably serve you better. In the latter case, a book on Unity might get you where you want to be faster.
You know that problem you have that you wish you could solve with a bit of programming? Do that.
Then do another one. Then another. Then another. And another.
Look at other languages. Spend a day each on Ruby, Erlang, Go, Scala, Lisp, Lua, Rust - look at the industries they're used in and what appeals to you about them. Choose one - you might want to stick with Java, but you might not.
Read Clean Code. Read Pragmatic Programmer. Read Practical Object Orientated Design in Ruby (I know Java devs who have enjoyed this).
Read blogs, learn your language well by reading plenty of stuff on different aspects of it.