#jmonkey

The system is advancing as planned. I invest every minute of my spare time before and after work to push this project to the finish line.

So far I have a kind of complete story to show - The user starts the session with the computer, during that time he can freely speak to the Gemini agent and a game is developed in front of his eyes according to his wishes.

As mentioned in previous chapters, the role of Gemini AI is not to produce game code but rather to understand what the user wants up to a certain level of resolution so if we take a typical user sentence for example: "Hi Gemini, How are you? I would like to create a car racing game with a fast car and a professional racetrack. Can you help me please?" The Gemini prompt instruct the AI to dig just the "important" things, in this example - the user wants: 1. To create a car racing game 2. A professional race track 3. A fast car

The "unimportant" parts are: 1. Hi Gemini 2. How are you 3. Can you help me 4. Please I decided to response also to the "unimportant" parts so that the agent will react as fast as possible to user input such as "Thank you", "Hi", "Great" etc. The response can be an Emoji drawn to the game's screen along with a text and even some speech. This greatly helps the user to feel like he is having a session with a human being rather than a machine. My wife, which tested the system, liked this feature even more than the game creation itself!

What's next

...y seguimos con el tema de desarrollo de videojuegos con Java. Me he topado con este engine para el desarrollo de juegos que está centrado puramente en Java. El motor parece bastante basicorro y parco en lo que se refiere a espectacularidad peeeeeeero, si nos centramos en que estamos aprendiendo Java creo que es un buen motor de impulso para tantear un poco el terreno y ver como funciona la cosa ¿No creéis? Aquí os dejo el enlace a su web principal. http://jmonkeyengine.org/

Tiene una wiki bastante extensa con documentación a tutti más que necesaria para ver como está la cosa y aprender a como moverse así como las posibilidades del motor. https://wiki.jmonkeyengine.org/

I've been fascinated by large-scale procedural 3D worlds for many years. After taking a class on 3D graphics that brought me some deeper insights last year, I felt very motivated for digging deeper into the whole thing.

I had made many experiences with raw OpenGL programming. I think this is good because it is important to understand what is going on under the hood in order to achieve great results even when working with some sort of abstraction layers.

Framework

So I looked around for a 3D engine that I could built upon. Let me outline shortly what my criteria have been. The engine should have been free and preferably open-source, because I wanted to learn more about 3D engines and how they are designed. It should have a broad users base and community, so I wouldn't end up on my own if I get stucked at some point. And it should be modern and preferably lightweight.

I dumped Ogre and Irrlicht quite fast because both have became somewhat "dusty" and bloated over the years. Before looking closer on Unity, I stumbled over JMonkey. My decision arised kind of from a comparison of these two candidates that wasn't easy, but the aspects of being open-source and more lightweight tipped the scales in favor of the JMonkey Engine 3, JME3 briefly. Furthermore JMonkey is said to be an "engine by the book" which is very important at the sight of my desire to learn.

I consider it as a benefit that I can (must) use Java when working with JMonkey for two reasons. First, I know Java well, although I am very familiar with C++ either. Second, prototyping is just much more efficient with high level languages like Java. I consider myself somewhat inexperienced in the field of 3D applications that complex. At some point, when I have gotten a feeling for good and bad decisions in the design process of such 3D applications, I could still take the leap towards porting the whole thing to C++ and raw OpenGL.

First Results

I started maybe three or four weeks ago and here is what I got so far:

The solar systems are generated randomly at start up. For each star and planet a set of parameters (i.e. the color, the size, ...) is diced. All textures are then generated procedurally by the shaders. Also the "nebulae" are generated procedurally. They are rendered through ray marching, which is the main reason why the frame rate is somewhat meagre. Maybe I will switch to a particle system later.

Every star and every planet can be approached:

Project: Rise

This is the game that I am working on.

Welcome aboard!

I worked hard the last days to deliver at least a few basics for Warships Revolution.

Warships Revolution?

Yes, that's the final name of my battleship game. It was originally Battleship Revolution, but too many games include the "battleship" word in their name. Oh, and it's an Hasbro trademark, I'm not sure to have the right to use it.

What's this game?

It's obviously a turn based battleship game. Principle is basic: each player has a grid with ships on it, and the goal is to destroy all your opponent ships before your entire fleet has been sunk. I have some ideas to make it a bit more interesting, but I won't spoil that now.

My main goals

Ok, so I started to make my revolutionary-super-awesome battleship game. Oh wait... As I said in my last post, the main goal is to create a simple and fun game, and to produce it quickly. It has to be playable, and usable. I want to avoid the "super-production syndrom" and I think a simple battleship game is perfect for that: the gameplay is pretty easy to implement, but it has great potential for an improved experience in the future.

However I have a few more goals to reach than making a simple game:

3D! 3D! 3D! I want to learn some basics about 3D in a code POV. I've been 3D operator a long time ago (and I loved that), so I know how to use tools like 3DSMax, Cinema4D, and so on. I have some mathematic basics. But as a developer, I only made a 3DSMax plugin in MaxScript, once. Luckily, as I said before, JMonkey has a perfect learning curve. I'm not lost for the moment, and I'll be able to improve my skills by gradually diving into JMonkey methods and utilities.

Make it beautiful. Even if the game is simple, I want it to look professional. The best method to reach that goal is to keep graphic design as simple as possible, but coherent from A to Z.

Market it. For this goal the "game" will be different: I won't decide if the game is good or not, players will. So given their (your!) reactions once the first release is out, I'll decide whether I try, or not, to improve and sell it (for a very reasonable price).

What did I do the first days?

I played some battleship games

Checked if the name was available, seemed not, changed it

Stopped networking (If someone read me, are dev updates kind of networking? ;))

Started organizing my code, and made some basic implementations

Started some graphic design for the logo and the UI

Dev update #1 

Here we are! Here is the list of what is fully or partially done:

Gameplay and general purpose code - Implemented Game, Player, SimpleAI classes - Implemented grid management class and random ships placement - Some managers for game materials, debug tools, internationalization, timers (I may reuse and share all these later) - Abstract and (part of) concrete ships classes  - Prepared camera position presets that I'll use both for gameplay and cinematics

Graphics - Implemented Battleground, that generates the 3D environment - Made atmospheres tests: Sunset, and HeavyAfternoon (screenshots on saturday!) - Made tests of UI on Photoshop 

Tests on JMonkey platform - I implemented a few UI elements to understand how NiftyGUI works - I tried, but failed for the moment, to use Cinematics for the camera - I started internationalization (even if the game will remain in english, I learn how to use java RessourceBundles and properties files, as well as using it in Nifty

Sound design - Found great pieces of musics and sounds on the net, will make a dedicated post soon - Added atmosphere sounds and radio communication (part of)

What to do now? 

The next few days I'll concentrate on the gameplay. The main priority is to have a playable game. No need of 3D boat, explosions, advanced shaders: just the implementation of a full battleship game. I must be able to play with it, and win or loose against the SimpleAI.

Once the gameplay principles are done, the other priority is a UI for graphics quality settings. It's important for me as a developer in order to quickly test all graphic settings in-game (and check their impact on performances), and in any case I'll use it in the final game to let players switch on and off graphic settings.

Then I'll start working on the 3D representation of boats, their animation, and some first effects. I hope it will be in about one or two weeks. 

At last, the logo

I hope I did a pretty good logo in a Keep It Simple mind. Very classical, but at least, it's readable, has white and black background versions, and it has a ship, the most important. Obviously I'll appreciate any feedback.

Continuing to make progress with NightBlock. Demonstrated in the video are doors, which are an example of player interaction with the world - in their closed state they are just world blocks backed by a controller entity that handles the interaction. When opened they become an entity proper, allowing the door mesh to sit across block boundries.

Welcome!

This blog will be devoted to writing about developing a game with the brand new jMonkeyEngine. that is an open source java 3D engine. Try it out! There will be many problems to overcome and about these I want to report on this blog, helping others tackling them as well.

In time I will write some more about the game idea and explain the whole game design. For now I am trying to create a decent enough Basic Application to improve upon.

This is recomended by the "best practices" and who am I to stray from this path.

So the first goal is to complete an application with three States: Main Menu (here you begin), Game (here you play) and Pause (sometimes you'll want to take it slow). These States will have some GUI elements and work together seemlessly.