IrrRPG Builder

[pera]

I'll have to try this, it looks very professional. Site looks great. Features are well presented. My congratulation.

[christianclavet]

Thanks Pera!

[pera]

Tried playing with editor little bit, and it looks good. Pretty intuitive interface, terrain editing quick and easy, going in the good direction to become great tool for making games. And here are suggestions:

1. Context menu: Right click, anyone? You let the left click be able to select / drag model around, and right click bring the context menu.
2. Camera positioning: How do you move rotate it? Is it not implemented yet? This is first thing you do when making 3D world editor. Fixed camera makes me wanna jump out of my skin. Here's suggestion: you make camera movement identical to at least one 3D modeling program, so artist have easy learning curve /transition from their software of choice to your game maker. Blender for example is good choice, its free like your program, and they could have brotherly functions. When you work in blender, and switch to irrrpg, you use same mouse action (middle button click and hold) to look around, natural right?
3. Is issue tracking system available on source forge? Forum topics are ok, but these are better.
4. When I put model on map, it is not visible completely, looks like occluded by something invisible. Maybe my integrated graphic card is not good enough.
5. Someone said about LUA: scripting system was at first intended to liberate people from programming, then it got so complicated that you just move programming from one language to another. Hint, don't make everything luable, only few customizable actions. For example, if you tell frog to move, make it animated per default, don't make people write script: frog->setAnimation(walk), if they already wrote frog->moveThere, you lose some customization and get some simplicity.

[christianclavet]

Hi, Pera.

For the context menu, we plan to add more to it, what you see are only the "base" function for the context menu. Thank for the feedback, we'll check if it would be better to have it on a right click event.

The editing camera is matching the ingame camera right now and you can't rotate around. As it's perspective top view, it allow modeler to check to model optimized geometry (don't model the back faces). We're working with a new viewport system that would allow you to use a "maya" camera so editing is easier with a button or item to try to match the camera if you have a fixed camera. This will come with one of the next versions.

For the tracking system, I just have barely the time to consult the forum now. I'm not sure I would have time to manage this... Thanks for the suggestion, perhaps Andres could set it up.

For the LUA scripting, don't look too much on the examples on the web site. They need to be updated.

We want to have both method. Quick a easy way and a more step-step approach. Right now the animation are handled automaticaly by the AI/Animation system if the states are properly defined in you character definition. The system really consider them to be "scripts" as the refresh rate is lowered to half a second. I would not use this to create a subsystem. This should be used to setup things, check for certain game conditions and do a specific action on it (higher level) as AI for example.

For the model, I think it ok. We force static meshes to be rendered as Octree's. This as proved to increase performance, but for certain mesh, will cause problems. I'm checking to add a XML tag so we can switch this on/off.

Again, thanks for the feedback!

[pera]

don't do static camera topview, and models without backfaces! if it is already 3D, later you can give user option to chose camera for his game: topview, firstperson, 3rdperson... and editor should have free camera. imho. cheers!

[christianclavet]

Exactly! That's the idea!

As for the current method. It's how its done for most topdown RPG commercial games. For IRB the models will need to be modeled completely as we want to have a choice of different "player controls theme" -> RTS Type (The current one we have), 3rd person, and first person.

As for the Editor, the view need to be matched if the game developper need to use the lowest polygons count for the models. As I said previously we're working on a new viewport system that will allow more control over the editing window with a much improved camera. Will be implemented eventually in a next version.

As with the current release, the controls scheme is a RTS type with point and click. So a topdown view is needed. The other views will surely require modified control (not sure the 3rd person over the shoulder view i'm planning to do will work well with a point and click control, will surely need keyboard or joystick controls to move the character)

[christianclavet]

Hi. Here is a little update on the project. I had a little more time and morale was up so I continued working on IRB. Here is a quick progress screenshot:

Here is a screenshot from the IRB alpha 0.2 (Irrlicht only GUI's):


Here is a screenshot from the IRB alpha 0.2 that I improved during the weekend (All GUI's rendered by Irrlicht, exept the status bar):


The improved interface is based on my experiences with the wxWidget Ribbon interface (2.9.1) that was buggy and not completed. So I dropped this version of wxWidget to come back to a version that Andres was able to build correctly on Linux (wxWidget 2.8.12 - with no Ribbon interface). Now I will only use wxWidget for "os native requesters/dialogs" and perhaps use it to open sub-editors in other windows, for the rest: All Irrlicht GUI's. For this I'm still not sure if I can open multiples Irrlicht devices and scene manager from a single application. I will have to check.

Just remarqued a problem with the Irrlicht (1.7.2) maya camera. The instant that we enable the inputreceiver, the camera almost decide for itself the position and rotation it will take. It could be a bug or something that I don't know. Once the inputreceiver is disabled, the camera seem to be ok, as position and angle can be set by code. If this is not fixed in the latest SVN, I will probably have to create another camera... For the time being, each time the input receiver of the camera is enabled, it completely overide the position and angle of the camera! I was assuming the camera would start rotating, zooming and moving from the position and angle given by code. It doesnt seem so.

At least now; When we edit a map, we can navigate the scene more freely, since it's not using the ingame fixed camera anymore. (first implemented camera system)
I was finding it a little problematic when editing terrains.. Now it's much easier to work with.

Edit:
Here are new screenshots showing the combat and dialog interfaces:

[CuteAlien]

Just remarqued a problem with the Irrlicht (1.7.2) maya camera. The instant that we enable the inputreceiver, the camera almost decide for itself the position and rotation it will take. It could be a bug or something that I don't know. Once the inputreceiver is disabled, the camera seem to be ok, as position and angle can be set by code. If this is not fixed in the latest SVN, I will probably have to create another camera... For the time being, each time the input receiver of the camera is enabled, it completely overide the position and angle of the camera! I was assuming the camera would start rotating, zooming and moving from the position and angle given by code. It doesnt seem so.

Is this a new problem in Irrlicht 1.7.2 or just something you noticed new? Anyway - you should better make a thread in the bugforum for this.

[christianclavet]

I've seen it happen more than twice, but I was working with 1.7.2 all the time. I'll report it then.

[Mel]

That seems to be an issue with any missing "true" return so the event isn't handled any further. When i use the maya camera, i have two modes, one of them lets the camera move freely, and the other simply doesn't allow to the mouse buttons events to go any further than my own event receiver.

The problem is when the event misses some clicks, then, those reach the camera, and they are processed. I think it would be easier to have your own custom maya camera controller, and avoid Irrlicht's one,

[christianclavet]

Thanks Mel. I will look at the source and as you suggest: create my own variation. Right now for me, the current maya camera is broken anyway. I could fix it and improve it for my project (giving the workflow I would like instead of being constrained by the ones defined).
For the rest, I like this camera, exept that we can't set it position adequately at initialisation. I used to disable/enable the input receiver and this work really well with the FPS cam. (So I can use a key modifier to acticate the navigation). Will do the same here.

[christianclavet]

Hi, A little update on the project. I impletemented for the moment the standard 1.7.2 Maya Cam from IRRlicht and doing my test on a new build of IRR RPG Builder. This one (even with it's current troubles) is much more efficient for edition. The gameplay camera is still the same.

Using this camera for editing the terrain is really fun, as the other (fixed) camera was PITA because we could not see behind the hills. When I will have more time to polish it, I will use my patched camera instead, that allow to "match" from another camera and will surely use the potential "auto-zoom" feature that Hybrid added to it. (Hybrid added an input so that we can change the zoom distance by code). My patched one will allow for key remapping and camera matching (will be able to set the maya cam at a proper position and angle from a target).

Here is a new screenshot of the editor. I dropped the wxWidget gui and done all the Gui's using irrlicht this time. I will still use wxWidget, but it will be mainly used for creating "native" dialogs when opening/saving files or projects.

[REDDemon]

since the gameplay camera is almost fixed you can try to think how easy would be to implement advanced texture splatting. I'm speaking about using 9 render target textures (4 is enough too). Every texture is updated when moving to new sector by redering to it many details that will be baked in real time. This will allow for high quality terrains (of course there's a limit to texture size so that most hardwares can't go above 1024x1024 or 2048x2048. But would be a nice a addiction for future projects ins't that? After the baking is done it is also pretty fast to draw since will require no shader. but just a standard solid material (this way also lighting can be baked into terrain textures), of course this way you don't have to save a custom texture for every terrain tile, but you have just to store some info about "what need to be rendered to". Wich can be just a list of IDs. coordinates, rotation and scale values. (you can also use that for nice blood splatting effects , craters from explosions, magic rings etc.)

[christianclavet]

Hi, REDDemon. I could think about it.
But the idea I have it to update the terrain shader to use "masks" Theses mask would be painted with the mouse from collisions point and would let a specific texture go thru (as a trail going up the hill).

This is not urgent at the moment, As I have lots of other area to refine. But I'm still checking for Code Snippet that would allow me "paint" the splatting.
Our current terrain, is splatting by shader 4 textures based on elevation, would be nice to have "manual" mask that would allow the user to "paint" trails or even water in certain areas.

At the moment i'm not too confortable with the shaders, as I want them to be "compatible" with Intel, ATI and NVIDIA at the same time (Now they do, and I had to put a lot of time on they to find why they were not working on the other platform).

If someone on the forum has good knowledge of shaders in IRRlicht and has some time to spare, We would gladly appreciate your help.

[REDDemon]

well for my Idea there's no need for shaders at all. You can render 2D elements like pieces of road in ortho mode. Circular (or other shapes) shapes of terrain with transparent borders. One above each other and you render to a texture. I will be happy to help a bit for implementing this. I'll download the last version and see if something can be done . The shaders will be needed if you want to add normal mapping or other features to baked terrains. else you can achieve high quality also on low-ended hardware (at the cost of sacrificing first person camera of course)

Edit: I found the link for SVN access finally XD