Josh

The other side of that is how many people would be interested in another 2.5D platformer that looks like all the rest? How can you make your game stand out from the ocean of games already out there? It's also worth noting that 5 out of 6 Steam users can run Leadwerks Engine: http://leadwerks.com/werkspace/index.php?/blog/1/entry-108-five-out-of-six-steam-users-can-run-leadwerks-engine

What's the purpose of encoding normals this way? Do you have some other data to store in the leftover channel? An extra square root operation is something I try to avoid.

BlitzMax has Try/Catch.

Yes, there is a callback function for events. Droplists (my version of comboboxes) are done. I had to add a "Move to back" function to move the list to the back of the queue, so it gets rendered last, on top of underlying controls. The code finds the active control in reverse of drawing order, so the top-most rendered item is selected first. One common programming problem is when you have drop lists that appears in front of buttons, and the GUI pushes an underlying button when you click the list. Well, I think that issue has been solved in a good way. I am paying more attention to the underlying logic and functionality than to the graphics of it. I figure the graphics are easily replaceable, but the functionality needs to be very solid. The whole hierarchy and draw ordering stuff is a lot harder to write than simple behavior, so that is what I am focusing on. If the foundation is solid, then people can easily add their own items without running into problems.

Don't use .ini files. They may be discontinued in the future. Everyone is using Lua, because that gives you complete control of everything.

The primary challenge with a prone stance is collision detection to tell if the player is able to go prone. An elongated shape may also cause unforeseen problems since the controller code has until now used a cylindrical shape.

Double-click on the class node in the editor to open the class script.

I recommend using the script.

I've never considered myself a fan of writing GUI code, but now that I have a small job I need to get it done for, I'm actually having a lot of fun with it. I've been tinkering around with Lua GUI code for two days, and I came up with a really neat system after lots of trial and error. Controls A "control" is the name for a button, label, or other widget. A control is a Lua table. The programmer creates the controls they want and then inputs mouse coordinates and the left mouse button state in the Update() function. There are only three real events that occur; mouse movement, mouse button down, and mouse button up. When the mouse is pressed, the system has a fast hierarchical search to find the selected control, and this control is made active. Since the programmer supplies the mouse coordinates and button state, the GUI could be displayed on a 3D surface and interacted with in the game, like in Doom 3. Frames Frames are a lua table with a drawing method. The simplest frame just draws a rectangle on the screen. An image frame draws an image within the specified coordinates. A more sophisticated frame uses nine images to draw image-based edges around a rectangle of any size. Controls use frames to draw different parts of the control, instead of using a lot of hard-coded GUI drawing or images. You can replace a control's frame easily in Lua: button.frame=CreateImageFrame(image) Methods There are some predefined methods you can add to a control. Right now I have the following: CursorDown CursorUp CursorMove Activate Deactivate HideUpdate ShowUpdate Lua makes it really easy to expand a basic control to look or act differently. You can just overwrite a function, and you have your new control. For example: function CreateMyButton(text,x,y,width,height,group,style) local button=CreateButton(text,x,y,width,height,group,style) function button:CursorMove() --Your code here end function button:Draw() --Your own drawing code goes here end return button end

It depends on the quality of graphics you want. It would be pretty interesting to see a 2.5D game with nice lighting. You could make some new gameplay mechanics with it, like giving the player a flashlight (torch) to light their way.

Maybe I can add a command for this. It will probably require some funny stuff, like the top-level mesh, the surface, vertex index, and bone index (0-3).

Can you post your code and texture?

If you post your FBX file here, someone will probably be kind enough to run it through the converter for you, just to test.

Your first post described the workflow perfectly. The only exception is that class scripts work both in the editor, and in your own game, no matter what language you program with.

UpdateController() takes an extra parameter to make the controller crouch. He will only uncrouch when there is nothing in the way of him standing up.

What language are you writing this in?

Yes. The first image looks terrible. Maybe his DDS saver is using a different technique than whatever you used?

The evaluation kit does not include the FBX to GMF converter, so the model viewer can't load your file.

This might be feasible if it is limited to movement/creation/deletion and terrain, and not stuff like undoing the last script change or crazy stuff like that.

As mentioned, official documentation will come to be on the site, in addition to the wiki.

Well who pressed the button?

Fascinating. You may be right.

I would not use Lua for the base-level AI, for a complicated game. I would use it to handle AI reactions and changes in behavior, but not for any math intensive stuff. For example, you might make the bot change from "sad" to "angry", but you would use machine code to handle those actual behaviors. For other less complex games, Lua will do just fine for simple AI.

The second thing you said.

Directional light shadows are designed to light an area of kilometers. You are not going to get high precision shadows on something as small as character facial features, with this scale of lighting. You can decrease the directional light shadow distance to have more detail in a smaller area, but you will lose shadows in the distance. You can also increase the light's shadow map resolution. This problem is common to any real-time engine that uses shadow maps. Here is an example from Crysis: