For the first time ever I got a 3D system working in LibGDX and decided to turn it into a library for me to write less code in the future.
…
Was that even a good idea?
NO – Use Unity and make Games,
Simple try save you, from internal nightmare - spending many years for 1 game 
I also use libGdx and when I have abandoned yet another game and start anew, I find myself copying half the code of the old game to the new one. It’s not a bad idea to build yourself a library of reusable code. It’s common practice.
This is a question that has different answers based on your goal.
If you want to churn out games, use an existing game engine that most professionals and game developers use like Unreal 4 and Unity.
If you want to learn about how those engines were made and figure out on your own how to do it, make your own library. An important thing to note is that you shouldn’t expect your library to compare to preexisting game engines.
I do not want to compare them to popular engines, as I know mine will be worse.
I just to not want to rewrite almost everything so I made a small library.
And I like the style of my “engine”
For my experience with Slick2d and Flashpunk I’ve created MarteEngine it was fun and I’ve learned a lot, but if your goal is to make games, do it, don’t waste time in create a new engine. Right now for me is more important to experiment with new gameplays and new ideas quickly 
Btw, years ago I’ve made same question in another forum, but there was not so much examples for doing what I want (tower defense, platformer, rpg, etc…) so my suggestion is to get a library/system/tool with a lot of examples, tutorial, video tutorial!
Reusing code is always a good thing and making it easy by wrapping it up in an easy to use way us even better. So what you are doing is definitely not a bad thing.
@icecore - your comment was not really that helpful. The poster is already using a library, albeit not your favorite one. They were just asking if it was a good idea to wrap common functionality from Libgdx in to separate API, from a personal perspective that is never going to be a bad thing.
A rule of thumb we use in The Real World doing consultancy is that it takes roughly 3x as long to make a piece of code genuinely usefully reusable as it does to just write the bare minimum to get something to do what you want it to. So bear that in mind when spending time on reuse.
Cas 
I have to agree to what Cas said.
Just today, I had some kind of discussion at my office and I have to say that even very experienced developers with all their learned patterns and best practices seem to sometimes simply be wrong about some aspects of programming. Sadly, most of them are not willed to take a look at some aspects from a different angle, because we all love static, durable things. Long story short(er):
Code duplication is often said to be the worst thing ever, for one obvious reason: The more code, the more potential bugs and the more testing has to be done to have everything properly tested. If you do something that is called abstraction, you could prevent yourself from writing equal logic over and over again - therefore you have to fix less bugs and write less test code.
That being said, and I totally agree with it, one thing is often forgotten: abstraction is not a one-way method. The wrong abstraction can cause more damage than a simple code duplication. And programmers tend to not de-abstract things - because abstraction is said to be the omni-weapon of software development and de-abstraction can be super difficult and error-prone. And code duplucation is said to be bad.
In reality, every abstraction is not only leaky, but abstractions are also very difficult to be done right. So basically, you are investing more time to generalize something that may be hard to generalize, therefore you will have comprimises and maybe you can’t satisfy specialized needs (of the future?) any more. This is the time to de-abstract things, but it will never happen. Most times, only one of the two things will happen: You carry on with your abstraction and make it worse, or you will “fork” your own abstraction in some places…effectively making the abstracted code kind of useless. You can take a look at https://medium.com/@rdsubhas/10-modern-software-engineering-mistakes-bc67fbef4fc8#.5hpekci7i, point 2. Be aware: the most useful critique you could get is from someone’s experience - yet those are the arguments that are easiest to defeat, because there will always be someone with an accepted patternor, best practise or whatever to invalidate your experience. welcome to software development.
To finally give you a more strict answer: If you realize you are writing the same functionality (not the same code) you have written before, extract it and make sure you have it tested properly. Immediately try to extract or extend an artifact and use it in all your sources as a dependency. Does it work without causing problems? There you go.
When the time has come to extend your library - how easy is it? Can you keep a nice interface for applications using the library? There you go. If you realize you are investing too much time designing the interfaces, don’t hesitate to de-abstract and purge dependencies. Or even better: Try to find out if bad code or incompatible functionality is the cause of the problem. API-design is an even bigger topic than abstraction, but often good API-design is the key for abstractions without problems.
Writing good libraries and frameworks is very, very hard to do and requires lots of experience. Even then, all of them suck, more or less. Mine too.
You can still divide your sources into two parts, one for game specific stuff and another for more generic functions which you could maybe reuse for another game. That won’t add much additional effort but gives a result of more maintainable sources.