The 3D API for Libgdx is hardly a new thing as it has been around for many months. I initially peeked at it back around when it was first proposed and the initial implementation. The work they have done with it is absolutely awesome, but the framework is still missing some key aspects. Xoppa did a wonderful tutorial on the various aspects of the API and introduced a bunch of the main concepts here. Those who are familiar with OpenGL and 3D rendering in general will probably be able to quickly skim over most of it and look at a few examples without much trouble.
It certainly matches what it was originally intended to do by mimicking the design of the Scene2d API. It also provides a great number of utilities to help with working in 3D. I have minimal knowledge of creating 3D models, but I do know how to work with already existing models so most of it isn't that new for me. There seems to be a pretty common theme, if I want to do anything in 3D for games as an indie I better start learning 3D modeling programs (i.e. Blender). There isn't anything officially included which deals with shadows (but there is an experimental directional shadow light which uses shadow mapping). Being experimental is kind of lame because I want to use it and most of what is inside it does not look experimental to me. In fact, it matches pretty much what I have done in past test projects with shadows.
No 3D particle system is really going to put a huge damper things because it is a very important aspect to any modern 3D game. Particle effects is almost as fundamental as sound effects, but it looks like I will have to roll my own solution if I want to have such a system in a game. I could always do things with bullet, but sometimes I just want something simple like smoke which doesn't need to be modeled accurately, but just provide a visual for people. Minus the whole missing features which feel essential, the 3D API is very easy to work with and looks fairly expandable. Hopefully a few more 'nice' features are added to support the previously mentioned parts, but overall I am satisfied with it.
December 14, 2013
December 8, 2013
No More Scala
My love/hate relationship with Scala is finally coming to an end. I am ditching the language entirely not because I don't like the language, but the biggest issue is tool support and well... the lack of it.
Using Scala has slowed down my development time because nothing works as well as it does when working in Java.
When it comes to cross-platform development you need to make sure everything you are working with will behave as expected and without causing you more complications or headaches. This is very important for people who are working on very small teams and can't afford to be spending time diagnosing issues. Scala does work well when you think of development speed in terms of how many characters it takes to do a task. However, that is a very biased view of development and almost backwards way to develop. This isn't the early 80s where programs are only written using a basic text editor and some syntax highlighting. It is expected to have a full IDE providing you with everything you would want and more. Scala has IDE support, but all the ones I have worked with seem to be missing the key features I use all the time in Java. It just feels so backwards and slow to not have an intelligent code completion/assist. Or be missing auto-generation of common code snippets with context awareness. Then having the tools you rely on break or fail to work on occasion for no good reason other than you've been using it for too long in one sitting.
The part the drives me nuts with Scala is trying to use it for game development. It offers a huge potential for providing many features to speed up development, but trying to make it work flawlessly/efficiently with Android has only caused more issues than solutions. I am using Java libraries because the lack of good libraries for Scala is frustrating and even the standard library for Scala is written with poor documentation and strictly from the functional point of view (not that their is anything wrong with it, but not everyone knows functional languages inside out and be able to infer what symbols used by the DSL mean). Scala libraries are notorious for using specialized DSL for no good reason other than because the developers think/feel it makes it awesome. DSL means steeper learning curve for all developers trying to use the library. Additionally, it means when someone is trying to do something outside of the status quo, its impressively complicated to bend a DSL designed for a certain workflow to do something else. Libraries should be convenient, easy to use, and perform effectively at the tasks they are built for. Most of the popular (non-enterprise) Java libraries follow these key aspects; hence, are popular by many hobbyist/professional developers.
I am strictly going to be using Java for game development from this point forward as I have not found anything I can develop 'code' in faster. When I say code I am not referring to lines of code, but am actually referring to features and functionality. One common complaint with Java is the verbosity of the code, and that is a very real issue. However, this is why I make extensive use of tools which automate tons of the boilerplate code. I can only hope Android will eventually support Java 8 because so many amazing features are coming just around the corner. It is ironic that iOS might support Java 8 before Android because of AOT native compilers... which actually makes me wonder if using such a compiler might allow me to make native applications for Android using Java 8. Oracle seems to be hinting at it... maybe the stars will align and I will get the best of all worlds.
Using Scala has slowed down my development time because nothing works as well as it does when working in Java.
When it comes to cross-platform development you need to make sure everything you are working with will behave as expected and without causing you more complications or headaches. This is very important for people who are working on very small teams and can't afford to be spending time diagnosing issues. Scala does work well when you think of development speed in terms of how many characters it takes to do a task. However, that is a very biased view of development and almost backwards way to develop. This isn't the early 80s where programs are only written using a basic text editor and some syntax highlighting. It is expected to have a full IDE providing you with everything you would want and more. Scala has IDE support, but all the ones I have worked with seem to be missing the key features I use all the time in Java. It just feels so backwards and slow to not have an intelligent code completion/assist. Or be missing auto-generation of common code snippets with context awareness. Then having the tools you rely on break or fail to work on occasion for no good reason other than you've been using it for too long in one sitting.
The part the drives me nuts with Scala is trying to use it for game development. It offers a huge potential for providing many features to speed up development, but trying to make it work flawlessly/efficiently with Android has only caused more issues than solutions. I am using Java libraries because the lack of good libraries for Scala is frustrating and even the standard library for Scala is written with poor documentation and strictly from the functional point of view (not that their is anything wrong with it, but not everyone knows functional languages inside out and be able to infer what symbols used by the DSL mean). Scala libraries are notorious for using specialized DSL for no good reason other than because the developers think/feel it makes it awesome. DSL means steeper learning curve for all developers trying to use the library. Additionally, it means when someone is trying to do something outside of the status quo, its impressively complicated to bend a DSL designed for a certain workflow to do something else. Libraries should be convenient, easy to use, and perform effectively at the tasks they are built for. Most of the popular (non-enterprise) Java libraries follow these key aspects; hence, are popular by many hobbyist/professional developers.
I am strictly going to be using Java for game development from this point forward as I have not found anything I can develop 'code' in faster. When I say code I am not referring to lines of code, but am actually referring to features and functionality. One common complaint with Java is the verbosity of the code, and that is a very real issue. However, this is why I make extensive use of tools which automate tons of the boilerplate code. I can only hope Android will eventually support Java 8 because so many amazing features are coming just around the corner. It is ironic that iOS might support Java 8 before Android because of AOT native compilers... which actually makes me wonder if using such a compiler might allow me to make native applications for Android using Java 8. Oracle seems to be hinting at it... maybe the stars will align and I will get the best of all worlds.
Subscribe to:
Posts
(
Atom
)