jMonkeyEngine 3.0 Beginner's Guide - Author Interview with Ruth Kusterer
Join the DZone community and get the full member experience.
Join For Free
how did you get involved with the jmonkeyengine team?
i discovered jmonkeyengine 2.0 at javaone in 2007, and then joined the community. at first, i went through the beginner tutorials for versions 1.0 and 2.0, and made edits to samples on the wiki.
in 2009, the jmonkeys (as team members are called), led by kirill vainer, kicked off the jmonkeyengine 3.0 code base; around the same time, i added new tutorials to the wiki as i was learning the api. later that year, i "applied" and joined the core team as the official doc writer.
can you explain the connection between jmonkeyengine and the netbeans platform?
in earlier versions, jmonkeyengine was just a bunch of jar files—powerful, but not very user-friendly. we spent a lot of time repeatedly explaining things to users: how to put the jars on the classpath, how to set things up in various ides, how to link the javadoc, etc.
in early 2010, normen hansen discovered geertjan wielenga's netbeans rcp tutorials and realized that the platform had half the stuff people asked us for anyway, and it was an ide. so normen built a netbeans platform app as a proof of concept. he bundled the jars with it, and added custom jme3 project support, a 3d model preview window, and a "convert model" button. suddenly, we had a game development environment! we could install just one tool, start out with a pre-configured project, and build executables, just like that. that was pretty cool and felt like a leap ahead in usability.
with normen's platform app, you just create a new java project from a template, and the bundled jars are put automatically on the classpath. the project is created with the recommended directory structure; the bundled jme3 javadoc and sources are linked in the editor; the default main.java and the code palette contain jme3 sample code; and the included build script automatically packages your non-code assets, sounds and images and so on. the help search box even pulls up pages from the jmonkeyengine 3.0 wiki, solving a good "90%" of our user questions!
over the last three years, the developers have added more features to jme3, and normen has developed additional netbeans plugins. today, we have asset browsers, live previews, material editors, property editors, terrain editors, effect editors, etc, and thus the "jmonkeyengine sdk" (software development kit).
how did the idea for the book start?
one of our community members, taksan tong, had already written a book about 2d and 3d game development . in late 2010, he reached out to packt publishing about a new game development book. around the same time, i was collecting content for a potential jmonkeyengine 3.0 user guide. we worked together and presented a jme3 book outline to the publisher. the publisher gave us the green light; unfortunately, taksan couldn't continue, so i took over as sole author in early 2011.
how do you personally use jmonkeyengine?
privately, i use jmonkeyengine for procedural 3d art. for example, to generate "endless" landscapes, planets and space scenes, or fractal geometries that you can fly through. i also wrote a very simple tower defense game once, where you fend off waves of attackers.
what challenges do you face creating a game?
providing the engine with quality data to work with. creating good-looking 3d models, materials, animations, sounds, and music is a whole learning experience of its own. personally, i start off with basic shapes and stock art, that way i can continue fine-tuning the game interaction without worrying about the looks. mock-ups can always be replaced with better models later. you can search asset packs, creative commons and download free models. the jmonkeyengine community has a lot of great hobby artists who really show off what the engine can do, and people with complementing skills often work together.
another challenge for me is that i cannot easily tell what's wrong by looking at a rendered 3d scene. i load a model and can't find it in the scene. where did it go? the misplaced object may be too large or small, too near or far, too dark or bright; it may be stuck underground, overlapping something else, or missing its surface material. you can't track down 3d transformation or rendering errors with junit tests, a debugger, and a profiler unlike with other kinds of programming.
how long did it take you to write the book?
the same amount of time it took the team to develop jmonkeyengine 3.0--three years. this includes the extra year i spent learning the new api and writing the beginner tutorials that i used as a base for the book. in the following two years, the draft went through several iterations, api changes, and restructurings. and of course, i still had a day job and wrote mostly only on weekends. in the end, the book had 350 pages and about 100 code samples. plus, one extra downloadable chapter that didn't fit in.
you've been published once before. was it different a second time around?
it was quite different. my first book ( 100 netbeans tips and tricks ) was shorter; the code samples were simpler; and i had a lot more freedom about how i wanted to structure it. 3d game development is a more advanced topic, and requires more research and more in-depth explanations. also, packt publishing has guidelines on how to write for a beginner audience, so i had to adapt my drafts to that. on the other hand, finding material to write about was easier. i had a lot of support from other jmonkeys--they have a ton of combined experience that went into the book.
will you write another book?
possibly, but not right away. for now i'll stick to writing on the jmonkey wiki and finishing my procedural planet. maybe that will be a next book. we will see!
Opinions expressed by DZone contributors are their own.
Trending
-
The SPACE Framework for Developer Productivity
-
Design Patterns for Microservices: Ambassador, Anti-Corruption Layer, and Backends for Frontends
-
A Complete Guide to AWS File Handling and How It Is Revolutionizing Cloud Storage
-
Observability Architecture: Financial Payments Introduction
Comments