Blender The Jungle

Trying to get some experience with blender, not an easy job for a noob like me! :) Here are the results. Some tropical climate specific trees and vegetation plus a desert cactus... That's all folks! I have finished flora and modeling for a while...now onto Engine and Time...

New snapshot release available!

I've decided to put out a new snapshot release that fixes the uglinesses of the previous hurried release. I have included JME's dependencies under MacOSX, so it is highly possible you can run it on your Mac (although I cannot test it). Now we have a world where you cannot pass things so easily, theoretically cannot go underground, and we have all the places with flora. :) Check out at sourceforge!

Flora meets World's All Places

After near-perfection of movement restrictions (still fall/walk down on hill side must be implemented) I have revisited the Surface interface and its implementations like Mountain, Plain and Forest. Now they give back the right information about where their surface is located on a 2D coordinate of the world, and so the World will generate Flora on the right Cube.

All this means that Mountains, Plains and Forests, so basically all current Geography units have climate and geography dependent Flora upon them! :-) If still not clear, I have some screenshots! :-) (Notice that mountains has Pines and Bushes while Plain has some Acacias and Oaks too, all because of their own different kinda FloraGenerator extension.) This way it is really easy to have custom mountains and plains with variations in Flora based on which climate belt and level its visited part belongs to.

Movement? Restricted!

Tonight, little time for work...some side rendering position bug fixed (sides were put on opposite direction) which only became apparent when I started to implement forward movement's restrictions. Now - in current SVN version - walls and trees cannot be passed.

RenderedHashRotatedSide finally working

Now that the fix and complete implementation added to the project, trees or other objects in the 3D core can be rotated in different directions based on the hashing of its containing Cube's coordinates. This may create the feeling of a more natural forest for example.

freegamer post made me snap shooting :-)

It's freegamer @ blogspot again who mentioned our project and an initial snapshot release. Well, actually we didn't release snapshot, but did submit the project availability in svn on Freshmeat.net. Anyway, freegamer blog now bent reality, gave us a great opportunity to move out of the shadow of Eclipse IDE, and resolve the dissonance! So!...here we go, the first snapshot release today for people who do not want to compile the project from source: download link ! Don't expect much, you can move around freely and nothing more. But it should run on your Linux / Windows box. (OpenGL hw accelerated X11 or Windows and Java 1.5+ is a requirement.)

Thickening dark woods

Again, Blender revisited tonight... have to get some more experience, couldn't find really usable open source models yet. So I created some ugly to make the forest thick and more robust...

Into the woods - again

Little time and energy today for something definite, yet we have some new models for demonstrating the three levels of flora: ground (grass/ice...), middle (bushes), top (trees/?). Some basic blender models and the two new classes GreenBush and GreenPineTree, yeah, welcome them, that's what fit in today. :-) Enough to demonstrate how flora levels will look in the first iteration...

We are being watched

It seems freegamer @ blogspot keeps an eye on jcprg! :-) The post mentions the need for common licensed medieval fantasy models on which the jcrpg project highly agrees! We thank free gamer for spreading the words of jcrpg!

Hash, hash, silence

Using fast integer hashing algorithm the HashUtil came alive in the project. Plants are now placed based on exact hash values of a Cube's coordinates. That way things look like random, yet results are always exact, making the terrain usable for exact gaming and data-less Save and Load...cool and fast. Look, there we have two continental trees with 2% chance to appear (yet they will appear there each run!), and some palms with 5% chance to appear. :-)
The code is rather simple now:

public BaseFloraGenerator()
{
addFlora(Continental.CONTINENTAL_ID,ClimateLevel.CLIMATELEVEL_ID,new FloraListElement[]{new FloraListElement(new Grass(),true),new FloraListElement(new OakTree(),2), new FloraListElement(new CherryTree(),2)});
addFlora(Tropical.TROPICAL_ID,ClimateLevel.CLIMATELEVEL_ID,new FloraListElement[]{new FloraListElement(new Sand(),true),new FloraListElement(new CoconutTree(),5)});
}

Climatic meeting

Some minutes of blendering, and adding sand to the grounds of tropical climate belt, a meeting between Continental and Tropical climate has became possible. Now we have two Climate belts on our demo world...expect to have more in the near future. Desert and arctic are to be, they are relatively easy to create.

Feel the difference

Yeah, the first fruits of Climate and Flora cooperation are getting ripe! After some hours of implementing and rethinking the Climate and Flora concept the World is now filled with Continental ClimatePart and uses the BaseFloraContainer's BaseFloraGenerator...it generates two kind of trees, Oak and Cherry...look at the screenshot, can you feel it? It's not geographical anymore...it's climatic and floral... :-)

First a geographical Cube will determine its climatic conditions using the World's Climate object, and then relies on World's FloraContainer object to look for a FloraGenerator suitable for the Place. The FloraGenerator will look up its hashmaps for flora suitable for the ClimateBelt and ClimateLevel type belonging to the coordinates of Cube. Then gets the Flora from the hashmap which will tell its displayable Cube form (with Sides) based on Season and DayTime on the given ClimateBelt. So the trees can have many faces depending on Season and even DayTime, and the forests trees and plants species depend on climate belt and level! Do you like the idea? :-) (Check SVN for a better understanding.)

Climate

"Climate is the average and variations of weather over long periods of time." - Wikipedia.
jcrpg is aimed to have a mostly complex climatic engine with climatic belts and climatic levels. The basis is a class called ClimatePart which is similar to the class called Place (simple geographical base class that returns Cubes based on coordinates), except that it is parameterized with another new class: Time and that it returns Conditions instead of Cubes.
So things will be changing based on days of the year and hour/min in a climatic region. Also the climatic region will have impact on the fauna and the flora and the AI in general. Now we will have climatic belts and climatic levels. Levels will be much simpler, it will just return a bunch of weather Conditions (warm, cool, dry, rain...) based on height. Belts are more complex, they will tell Conditions with the help of Season classes and DayTime classes based on the world's local Time. Beyond the impact of this on the abstract World, the 3D core will render dependent things based on those Conditions, like night sky, snow, rain (if I will get to implement it soon, which ain't an easy 3d task :-) ). Have a look at the svn for a first perception...

World engine is put to rest for a little while. Notice, that the project has incorporated now the license header in the majority of the source files, and the copyright LGPL license in the root directory.

Brain vs. Mountain semifinal: 1-1

Okay, some struggle around the new equation to create a mountain, I have decided to keep the pyramid like mountain code, and upgraded it to be able to put other cubes above it, for example these trees...not much progress, but little time for it. I have written one method in a new interface Surface that will return the surface Height (coordinate Y) for a given X,Z coordinate, and if it is walkable or can have things upon it (so it isn't a steep). Still have to implement it for mountain, but for Plain it will be simple case. :)

jcrpg got into freegamer @ blogger.com

We have made it into a recent post on Free Gamer - open source games blog. It is one cool blog often updated, nicely written about free games. The blog gave some really nice words about our very initial jrcpg project. Thank you, freegamer blog! One cold virtual beer for that! :-)

ant build script contributed

Daniel (formerly HelloWorld82) in his recent comment has contributed a freshly written ant build script for Jcrpg! Many thanks for it! Now people without Eclipse, using the ant tool can easily compile classes and run Jcrpg with this script. It is already in the SVN repository, so check out if interested!

Mountain revisited

Not much progress...some less blocky mountain...still looks like a pyramid! :-) Well, for some time I am done with that mountain thing, or I will go nuts...gotta find some better algorithms and generation method inside a Place's getCube method...gotta learn some equation calculations yet!

The first contribution to the project

Wow, the project has received its first contribution! A 3D tree model made in blender by DomoN, a Hungarian developer/3d modeler. Thank you for doing so and being the first in the line! :-) It has already made into the game. Look for the screenshots...
Implementing the World subgeographies, the first version of the Mountain is ready and screenshot! It's too ugly and cubic, but after a few hours of bug hunting - at last - it works!

The Mathematical World of jcrpg

The world engine is getting more complex, and more implemented. The first 1-1 magnification algorithm based Place is almost complete. It is called House. It is parametered by Size and one house is differentiated from another based on calculations (may call it unique hashing) of World coordinates and size only! The generated unique models are cached, and are reused for fast world building. You will meet the same house, let's say 100 cubes away, but the nearest house may differ where it's windows are located...you get it? I hope so, it's an easy concept.
SideSubType, what determines a Cube side subtype (grass, water,wall, window), is now a Class, extended by Swimming side, NonPassableSide for later use in movement blocking, swim skill probes etc. Oh yeah, object oriented programming is cool... :-)
The World is now Globe, you can walk around and get to the same place again, like on a real planet. :)

The Great Magnification Commit

Yes, the Boundary magnification system at first glance and implementation seems to do the trick for generating very huge places to dwell with simple code like this:

World w = new World("world", null); w.setBoundaries(BoundaryUtils.createCubicBoundaries(1000, 1, 1, 1, 0, 0, 0));
Plain p = new Plain("2",null); p.setBoundaries( BoundaryUtils.createCubicBoundaries (100, 1, 1, 1, 0, 0, 0));
w.geographies.put(p.id, p);

Every place in general may have subplaces, call it smaller regions in it. This code will create an 1000x1000x1000 in game cube world in a single world cube, and in it a 100x100x100 in game cube grass Plain in a single Plain geography place cube. The Plain will take care of how it's in game cubes will look alike based on it's own algorithms or if the Plain will be divided into more subplaces with lesser magnification, those places will take care of a bigger and exact detail. How a plain have some trees on it? It can be pure mathematical with this concept, instead of designing every cube in a designer tool! Look at these codes:

The magnification trick in Boundaries is to divide real world coordinates with a Place's magnification level:

public boolean isInside(int absouluteX, int absoluteY, int absoluteZ) {
boolean ret = area.get(getKey(absouluteX/magnification, absoluteY/magnification, absoluteZ/magnification))!=null;
return ret;
}

And the Plain returns a Cube based on real world coordinates:

@Override
public Cube getCube(int worldX, int worldY, int worldZ) {
return new Cube(this, Cube.DEFAULT_LEVEL,worldY==0?(worldX%10==0 && worldZ%10==0?TREE:GRASS): EMPTY,worldX,worldY,worldZ); }

In real life imagine the concept like there are places that more or less look the same without interesting details, but they may contain specific places with interesting details. Like a barren plain and a house in it. The plain will be of magnification level 100, while the House will be of magnification level 1 -- "place cube" = "in-game cube".

Concept of classes/races

A recent interesting blog comment by Dragonbait made me thinking about Classes/Races of the jcrpg framework. I wanted to express the first conceptual thoughts about it. I find it important and a thing to discuss, so I will place this as a new post for your intention - although really not crystallized (like many other aspects :-) ) :

DB: "... Any info on what type of races/classes are gonna be in it?"

Me: "... The races/classes are not yet determined and probably will only be fully so when a game will be done with a story. Races will be traits of intelligence in the fauna AI so maybe a lot of them will be shaped while experimenting with it. Classes will be traits of social behavior in the AI part too, so you may meet AI classes of your characters. Yet much thing to think about in terms of the dynamic complexity of the game, so I cant tell you precise decision, only that I really would like to see many classes of Wizardry 7 in this framework's class collection too."

(image is from Baldur's Gate, it's copyrighted material)

Building a world from scratch

Creating a well structured, object oriented hierarchy for mirroring a world. After tough thinking I've started to construct the class hierarchy and implement some part of it. Imagine classes that extend the base class Place which has Boundaries, and are structured like World -> Plain, Forest, Jungle, Desert, Lake, River or World -> Population, House or World -> Country, County etc. This will be the locational basis for the AI modules to percept and make choices upon and in the World they are living. It must be a dynamic, interconnected complexity... This means my nicely modeled static small village is past...the world is a void now. A cosmos creating in the chaos. Have a look at the barren plains and the river that flows through it to get involved in the beginning...

The tricky part will be the Magnification Ratio of the places. After some calculation it turned out that for a huge world I will need to create a magnification system which allows to have small scale coordinates for big regions too yet smaller parts can still have detail when entered. It is not yet crystallized, but a really big coordinate system eats up my dual core, so it must be invented...

jcrpg on linuxgames.com

We have made it to linuxgames.com. :) I will be sincere, I've posted the newsbit there to have some more attention of you... The project also had some web hits from all over the world. Thank you for visiting ( and I hope the project disappointed you only half way :-) ).

Tree and skybox

I couldn't leave 3D modeling without creating an ugly tree. See for yourself. I've experimented with the skybox, looking for a nice more generic image. I've found one for now.

Minor enhancements, levels, optimization

Caching model byte data, optimizing rendered cube number, enhancing keyboard input and timing, building towers. :-) That's all what fit in today. A week of tweaking the rendering and blendering has passed. The next week is a week of designing and detailing the world behind the graphics beyond what Area and Cube mean now.

Smooth walk'n'turn in a planned village

I've tried to make use of JME's own matrix calculated rotation, but ended up with my own little rotation code, calculating between the 'from' and 'to' Vector3fs. The same for the location of the camera when moving ahead. So mostly 4 direction movement is rather complete and nicer than ever. Worth to check out and see the village planned in the int[][][][][] arrays of the main application Jcrpg.java. :-) Or just click on the screenshot to have a closer look. A bit more work on the 3rd dimension of height, and the basic space render will be considered usable and complete, so the project can move onto the next task...
P.S.: Use W/S/A/D and try Q/E (strafe), R/F (move up/down), CursorUp/Down (look up/down).

The Mysterious Village

Can you spot why this village is mysterious? Something is strange about it ( besides the ugliness of course :-) )... Okay, I will tell ya, the walls have no eyes! Yes, no window to look through yet.

Now I have made some thinking about what else the 3D core needs to be easily adopted to simple map designing I am willing to create later. So I need roofs and such objects on continuous wall segment without having to bother with it in map designing. The solution was to create 4 types of additional objects: continuous roof, left side corner roof, right side corner roof, non continuous (one cube) roof. I only have to look for the Side main type property which tells this is one kind of a wall which should generally belong to one continuous segment, so the roof can be put based on that information continuously or fragmented if the neighbor continuous side is not of that main type. On the other hand, the subtype of the Side in case of a wall will tell if the wall is with a window/door or just simple wall. The AreaTypeID -> 3DTypeId mapping will take care of it, and return the RenderedSide type which contains now all info: normal always rendered SimpleModels, nonContinuous-, oneSideContinuousNormal-, oneSideContinuousOpposite- and continuous SimpleModels. Check the code for further understanding...

Enter The Matrix - Which Door?

I feel I am getting familiar with some aspects of Blender. With one door in the game it occurred to me how a RenderedSide element of the RenderedCube must contain complex data about itself to be able to display derived contents from a simple abstract Side of the Cube. Tough thinking ahead yet...

Thick walls and cave entrances - weird compositions

Some minor happy success moments with blender and texture mapping with UV calculation. Now at least I proved for myself the usability of blender and JME together, so I can step further with the comfort. This feature let me to take these screenshots...

Blender tutorial and little java coding

I've run through some parts of the blender quickie tutorial, and feel much better related to this software. I could create a clumsy piece of textured wall.. :) Ugly, I won't post in-game pictures. After that I found out how to set MaxToJme 3ds reader's texture url, so now jcrpg happily reads up the textures for the models. Although it doesn't display it correctly it's a step ahead. I had no more time today, that's all, folks!

Ultra classic keyboard input handler

Oh yes, the ultra classic input handler for keyboard is up and ready - 4 directions, constant step distances in the cubic space! Also the J3DCore is now rendering dynamic range of the total area, called RenderedArea. So now I can walk around the random generated labyrinth. Nice, now I will make some smooth tuning on it, maybe get some better 3D wall model and then to begin other parts of the game. So some kind of iterative development to be done to have a simple but playable version soon. (You can check the sources in the new and active sourceforge project: link.)

Textures on the wall under a blue sky

Take a look! ( Second one added later, after some hours of programming :-) I call the picture CardCastle)

Game space meets 3D

After some coding I can say it won't be an easy task to reach the goal of a nice 3D look, but still I got inside a very simple area with some walls and grass around. Admittedly ugly, resembles old C=64 times labyrinth game. I am at the very basics of blender, got to look around for some nicer objects.
SourceForge.net project is registered now: http://sourceforge.net/projects/javacrpg

SourceForge.net project registration

In a few days hopefully we will have a sourceforge.net project registered, so I can upload sources into version control for other people to examine them. The requested UNIX name for the project is javacrpg.

The Space To Move Into

Yesterday I had some free time to continue. I've decided to put aside the 3D engine, and started creating the Space in which all the things will take place and which the player will run through. After a while of thinking and coding I put aside hexagon and octagon based columns and decided to follow the ultra classic cube based space. It will bind a bit the hands of the graphical view and will simplify space designing, but I still have an extraordinary idea of cubes with diagonal wall which would be not passable, but gives some freedom of look and design, yet the whole will contain the classic principle of 4 way walk. The cubes right now will have 4 (walls) + 4*2 (up and down and 4 directions) +2 (up and down, floor/ceiling) reachable cubes. So you can put stairs leading up ahead, ladders up and down and the normal walking directions. The cube will have a parameter called relative level (-1, 0, +1) with which a smoother steep can be modeled and displayed, yet player will remain on the same level of cubes.

Now we have the Area cut into Cubes with Sides and directions to move. Diagonal obstacles are in consideration as written above. Hopefully this will cover all the needs of a CRPG...and then it's up to the 3D display mode to enhance it beyond what we know as a CRPG. Let JME do its miracle...yet a hard fight to come.