Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,353

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh
    Based on a little observation, I've made the following changes to the publish routine on the beta branch:
    The FPS Player script has been updated so that the footstep sound files are explicitly named, so they don't get missed in the publish step. You will need to update your project to get the new script (or just copy FPSPlayer.lua to your project).
    There is now a checkbox to "Only include used files". If this is checked, then the new packing routine will be used, otherwise the old behavior of including all files is used.
    The file extension filter will now be used so you can include files like XML, TXT, or whatever else you want.
    The routine has been fixed to pick up terrain textures and include those.
    A few people suggested a "tagging" system so the user can mark files to be included or not. This is a very bad idea. The whole point of the selective file inclusion system is that the user doesn't want to maintain a clean directory. So adding a manual system to overcome the limitations of the automatic system...it would be easier just to delete the unwanted files. When your feature requests lead to more feature requests, to fix the problems of the previous feature, that is a strong sign of bad design. So we won't be going down that path.
    If you are using the selective file inclusion and you want to force a file to be included that would otherwise be impossible to detect, an easy way to do this is to just add a commented-out line in your main script that names the file:
    --myfile.tex Anyways, the new build is available now on the beta branch. Let me know how you like it.
  2. Josh

    Gameplay!

    By Josh,

    The Leadwerks community project "Midnight Salsa" was one of my favorite things that came out of Leadwerks 2. Watching the videos of everyone collaborating across the globe was really interesting, and with Aggror's leadership they did pull off what they set out to do: Make a playable zombie FPS. However, there were some weak points that showed me where I could put effort and have it be the most useful.
     
    When you go through the first set of doors, a carefully placed light above the door shines to illuminate a sitting zombie as the doors open. I noticed right away the animation transitions weren't completely smooth. Although our animation system makes it very easy to transition between frames and do all sorts of interesting things, the logic that manages multiple animation sequences blending in and out can get a little messy. I approached this as a general problem and wrote an animation manager script in Lua that handles a "stack" of animations. When you set a new animation sequence, it is added to the top of the stack and blended in over a specified amount of time. Once it is completely blended in, all animations beneath it in the stack are removed. This process can handle any number of transitions smoothly, so you can just always set the latest one and there will never be more than two or three sequences active in the stack.
     
    The second problem that affects a lot of people is AI. How do you get characters to go where you want them to go? My advice in the past was to implement a system of connected nodes, as I did in my game "Metal". I finally solved this problem once and for all with a relatively recent technique called navmesh pathfinding. This provides more accurate pathfinding that isn't limited to node points, and it's completely dynamic. If the level changes, the pathfinding adjusts to it. This level of integration is only possible because Leadwerks 3 was built with pathfinding baked into the core, and it makes it very easy to use. Implementing this system was a huge investment of time and effort, and there was no guarantee it would have succeeded, so it probably wasn't conceivable to add this on top of Leadwerks 2. In retrospect, I really should have built node-based pathfinding into Leadwerks 2 so we could all have a common foundation for AI.
     
    In this video, the project leader mentions having to send the level model back to the artist for resizing. This causes a delay in progress while everyone waits for the new model. Our new CSG level design tools eliminate this problem because the map can be immediately adjusted right in the editor, without any waiting around or reimporting. Even if the artist wanted to take their time to make it perfect, a quick modification could be made to give the other team members something to test with. When combined with the built-in navmesh pathfinding, you can visualize the navigable areas as you build the level. There's never any guessing or going back to redo things because your enemies don't have room to get through a hallway or something.
     
    Finally, there is the matter of game object interaction. Sometimes you have special interactions in a map, and abstract classes aren't always the best way to manage that. In the past, gameplay mechanics like doors, switches, were exclusively the domain of expert programmers. Although Leadwerks 2 had a built-in messaging system, too much was left undefined. Consequently, even the programmers who were able to implement advanced interactions each isolated themselves from the community of developers, because they were branching the engine. Our new flowgraph system provides a shared framework we can all utilize and share code within. This means reusable scripts can be written that can be used in many games, by many developers, and our scripts can "talk" to each other through the flow graph. In the map below I've set up a collision trigger (shown in grey) and attached it to two doors (shown in green). When the player walks into the collision trigger the doors open. This simple example shows how anybody can set up advanced game interactions in their map.

     
    Our primary focus for Leadwerks 3 is delivering gameplay. I think all of these features will facilitate collaboration and give the community some much needed high-level frameworks. Not only does it make building games faster, it gives us all a common framework to work together within.
  3. Josh

    Android Progress

    By Josh,

    I got touch input and text rendering working on Android. Happily, I have not encountered any issues with different behavior on any tested OpenGLES devices, including iOS. The framerate on my HTC Evo jumps around quite a bit, which appears to be an issue with the Java garbage collector. Framerate on iOS is a solid 60 FPS, so we should be able to get this sorted out.
     
    Here's a video:
    http://www.leadwerks.com/werkspace/page/videos/_/leadwerks-engine-3/android-progress-r100
     
    I also discovered that LuaJIT for ARM processors was recently released. This is fantastic because it means Lua script will run on Android and iOS at about the same speed as C# and Java. I knew this would eventually be supported, but I didn't know until yesterday it was released about a month ago.
     
    We've had a surprisingly strong positive response from developers over our support for mobile platforms, especially Android. This feedback has been coming from both the Leadwerks community, as well as other places like Google+. My estimation is there's probably ten times as many people interested in mobile game development as there are interested in PC development. Since Android especially is going to be an important platform for us to support, I've decided to implement an OpenGL 2.0 renderer, and make that a higher priority than the OpenGL 1 fallback I originally planned. Leadwerks Engine 2 used OpenGL 2.1, but this will be a much simpler renderer that just matches the functionality of the mobile renderer, so you can get the exact same pixel output across all supported platforms. Expect to see something about as capable as the Half-Life 2 engine.
     
    Of course, the OpenGL 3.2/4 renderer will still be available on Windows. At this time, Apple's OpenGL 3.2 drivers are not functional, but when they are it will be no problem to enable the OpenGL 3 renderer for Mac computers as well. (Tim Cook: Please see bug report #9896622.)
  4. Josh
    I hope everyone is having an awesome Christmas week. I'm taking a break from coding to show you our new office we moved into in November at the Sacramento Hacker Lab.
     
    All decked out for Christmas:

     
    Chris is pretending to work, but he's not fooling me:

     
    So we changed the arrangement to make a reverse mullet. (Party in the front, business in the back):

     
    The kitchen provides energy, both in the form of food and alcohol:

     
    The common area:

     
    The room-temperature beer flows freely:

     
    A closeup of our lovely tree, topped with the stuffed figurine Intel gave us (they're one of the sponsors here):

     
    To celebrate, here is an eggnog-induced off-the-cuff Christmas poem:
     
    Twas the night before Christmas,
    And all through the forum,
    Not a creature was stirring,
    (But Lumooja was snoring.)
     
    The coders were nustled all snug in their beds,
    While visions of Leadwerks 3 danced in their heads,
    And Aggror in his T-Shirt, and Roland in Sweden,
    Had just settled down their brains after solving a rather difficult programming problem.
     
    (Add your additional verses in the comments below.)
     
    MERRY CHRISTMAS!!!
  5. Josh

    Terrain Tessellation

    By Josh,

    Our "dynamic megatexture" terrain system contains a lot of powerful capabilities we haven't yet been able to tap into. One advantage of this approach is that it works extremely well with hardware tessellated terrain. In fact, our terrain system was originally designed with this in mind, which is the main reason we have a slot allocated for a displacement map. This video shows my first-pass implementation of the technique. When a displacement map is assigned to a terrain texture layer, painting the texture layer results in geometry that appears right as you draw. As you can see in the video below, this is one of those features that are just "magic".
     

     
    To make this look good, you really need high-quality textures. An auto-generated heightmap will look grainy and "spiky" but a high-quality material created from a sculpt will look incredible.
  6. Josh
    We're finishing up 2009 by resolving some longstanding design issues that haven't been particularly critical, but have weighted on my mind. Framework is not like the main engine. It's far more high-level, and is also the kind of code people want to customize. I don't like locking the user into my way of doing things. However, the interaction between Lua, C++, and Framework commands are a real issue, which we started to see immediately as Lua became available. This was resolved by compiling Framework into the engine DLL and providing the source code in the BMX folder. Most people will be happy with the default settings, but a few will want to write their own renderers, and fortunately they still can. Most importantly, Lua can access the Framework commands, so all the water and atmospheric effects will work the same in C++ and in the editor. In the end, we finally wound up doing something I said we never would: There are commands like SetBloom(), SetNearDOF(), etc. However, since this is open-source code built on top of the buffer and shader systems, I am happy with it. The user still has low-level power, but is supported by a lot of default code that does most of what they want. This is the design I have always tried to provide.
     
    The solution we arrived at with Framework can also be applied to other systems that are commonly needed, yet don't quite fit into the main engine. Providing open-source code, and then compiling it into the DLL and adding a Lua interface seems to be a good solution for anything like this. The next system I could see handled this way is AI. I am carefully watching the work Chris Paulson is doing with the recast library, and I think it has a very promising future.
     
    Oh, and in other news Penumbra is finally available on Steam! Penumbra is a physics-driven game that uses the same physics library we use, Newton Game Dynamics. I highly recommend this series, both for learning and for fun.
  7. Josh

    The path we are on

    By Josh,

    Previously, I have talked about my plans for Leadwerks and how to get there. In that blog I started with technical specs and went backwards with the path we would follow to achieve those goals. Now I have begun to put some of these ideas into practice and I want to review my plan with you.
     
    I met with a very large academic institution a few months ago and talked about using Leadwerks to teach game programming. This is the whole reason I wrote this blog and did the research included therein. When I put the graph up showing job requirements, it was a very easy sale.
     

     
    I then gave a short talk to a group of their students who had some web development background, but had zero game development experience. Perfect! These people are my bread and butter. The purpose of this was to gauge interest in a class in game development, and they were very interested.
     
    As I was talking to these people I realized I could not meet their expectations. No one else could either, but I knew at the end of a two week course they would only have very rudimentary ugly games made, not the dreams they had in their head. These people did not know anything about mipmaps, debuggers, texture coordinates, and they did not care. They just wanted to make games.
     
    I cancelled my plans to hold a class because I knew we weren't ready to give them what they really needed. Leadwerks is the easiest way to build your own 3D games, but we are not all the way there yet. No one out there is really giving complete beginners the means to learn to make their games quickly, but we can be the first to do it with a bit more work.
     
    As I stated previously, the documentation is being revised, including an offline copy of the docs. This takes an enormous amount of time because I have to copy, paste, and edit hundreds of pages. I am also revising all the code examples to only use the main .lua and .cpp files and get rid of the App::Start() stuff, which is a holdover from mobile.
     
    The next step is to create a broader selection of high quality game templates. This is the final step that is needed to bridge the gap between game development technology and a complete beginner. The templates have to be polished and feel like a game you would actually want to play. This must happen or everything I have done has been a waste of time.
     
    We are in a race against time to connect with a large audience in a way where they can't imagine life without Leadwerks. If I fail to do that, we will go the way of every other abandoned open-source game engine out there.
     
    So that is what I am working on.
  8. Josh
    The new Lobby system in Leadwerks 4.6 allows you to create a public listing of your multiplayer game for others to join. This uses the Steamworks library. You can tap into the Steamworks lib by piggybacking on the default "SpaceWar" example game, which uses the Steam app ID 480. This is set up by default when you create a new Leadwerks project.
    Now you might think of a lobby as a place where people hang out and chat before the game starts. You can treat it like this, but it's best to keep the lobby up as the game is running. This will allow other people to find the game to join, if it isn't full or if someone leaves the game. So a lobby is better described as a publicly advertised game others can join.
    Creating a new lobby to advertise our game is easy. We just call a command to create it, and then we will set two string values. The game title is set so that we can later retrieve only lobbies that are running this particular game. (This should be done if you are using the SpaceWar app ID instead of your own Steam ID.) We also add a short description that can display information about the game.
    Lobby* mylobby = Lobby::Create(); mylobby->SetKey("game", "MyGameTitle"); mylobby->SetKey("description", "Here is my lobby!"); It's also easy to retrieve a list of lobbies:
    int count = Lobby::Count(); for (int i = 0; i < count; ++i) { Lobby* lobby = Lobby::Get(i); } We can use GetKey() to look for lobbies that are running the same game we are:
    if (lobby->GetKey("game") == "MyGameTitle") We can retrieve the owner of the lobby with this command that will return a Steam ID:
    uint64 steamid = lobby->GetOwner(); Once you have that Steam ID, that is all you need to start sending messages through the new P2P networking system. More on that later.
    And we can also retrieve a list of all members in the lobby:
    int count = lobby->CountMembers(); for (int k = 0; k < count; ++k) { uint64 steamid = lobby->GetMember(k); } After a lobby is created, it will have one member, which will be the same Steam ID as the owner.
    Joining a lobby is simple enough:
    if (lobby->Join()) System::Print("Joined lobby!"); And leaving is just as easy:
    lobby->Leave() Now here's the magical part: When the owner of the lobby leaves, the lobby is not destroyed. Instead, the system will automatically choose another player to become the owner of that lobby, so the multiplayer game can keep going! The lobby will not be destroyed until everyone leaves the game.
  9. Josh

    Happy New Year

    By Josh,

    Today I added the visible guides in the editor for point and spot lights. I also tested out the new FBX converter, recompiled with the 2012 FBX SDK. It works. (There are no file format changes in the 2013 FBX SDK, so this will load everything.) Our character models still have to be rescaled, so I added a resize option in the model editor. That way models can be resized and the model file saved, so you don't have to rescale a model every single time you place it in the editor. Having models I obtained from a third party who had never used Leadwerks gave me models that required slight fixing, but I didn't mind because it was a chance to test the art pipeline and improve the import process.
     
    The command reference is just about finished up. Chris just needs to add a few missing pages. I still have to write most of the editor documentation.
     
    Literally, the only thing left to program is the undo system. I expect there are still a few bugs to fix, but there's no new features that have to be implemented.
     
    We are meeting with a packaging manufacturer tomorrow...
  10. Josh

    New game engine examples

    By Josh,

    The new game engine needs to roll out with some top-notch examples showing off what it can do. Here's what I want:
    First-person shooter Offroad racing game Space shoot-em-up side-scroller. Side-scoller platformer similar to the Contra Playstation game. Now what I can use your help with is finding good example games on YouTube or Steam that I can start designing these samples around. Post your ideas below!
  11. Josh

    Package Plugins and Mods

    By Josh,

    Leadwerks 4 supports compressed and encrypted game files in ZIP format, but there are many different custom package formats different games use. The plugin system in Leadwerks 5 allows us to create importers for these different package formats so we can access content directly from commercial games you have installed on your computer. The example below shows how to load a VTF texture from the game Half-Life 2 directly from the game's install files.
    First we need to load some plugins to deal with these weird file formats.
    --Load VPK package loader plugin local vpkloader = LoadPlugin("Plugins/VPK.dll") --Load VTF texture loader plugin local vtfloader = LoadPlugin("Plugins/VTF.dll") Next we will load a single VPK package directly from the Half-Life 2 install directory. If you have Steam installed somewhere other than the default path you can change the value of the STEAM_PATH variable to load the package from somewhere else.
    --Steam installation path local STEAM_PATH = "C:/Program Files (x86)/Steam" --Load package (Half-Life 2 must be installed) local pkg = LoadPackage(STEAM_PATH.."/steamapps/common/Half-Life 2/hl2/hl2_textures_dir.vpk") Now we can load content directly from the Half-Life 2 game files. Although the file specified below does not actually exist in the game folder, it will be loaded as if it was because of the VPK package we previously loaded.
    --Load texture local tex = LoadTexture("materials/building_template/buildingset040a.vtf") Here is the result when I run the program:

    Now if you wanted to load all the HL2 data files when your game starts, that is easy to do too. If you place this script in the "Scripts/Start" folder all the content will be automatically made available:
    local STEAM_PATH = "C:/Program Files (x86)/Steam/" local HL2_PATH = STEAM_PATH.."steamapps/common/Half-Life 2/hl2/" local dir = LoadDir(HL2_PATH) local k,v LoadedPackages = {} for k,v in ipairs(dir) do local ext = Lower(ExtractExt(v)) if ext == "vpk" then local pkg = LoadPackage(v) if pkg ~= nil then table.insert(LoadedPackages, pkg) end end end What is this good for? You can browse and view all the content in your installed games and use some assets as placeholders. Valve is pretty lenient with their IP so if your game is only published on Steam, you could probably use all the Source games textures and models. You could make a mod that replaces the original game engine but requires the game to be installed to run. It would also not be too hard to integrate these features into the new editor so that it can be used as a modding tool for different games and allow you to create new game levels.
    You can get the source for this and other plugins on Github.
  12. Josh

    Leadwerks 3.4 Launch Prep

    By Josh,

    Leadwerks 3.4 will be launched as soon as AMD releases their new driver, preferably by Monday. The three big features this introduces are:
    Vehicles
    Water
    Built-in Workshop browser

     
    As well as over 100 small fixes and improvements.
     
    The launch will coincide with a week-long sale. The results of the sale will give me an estimate of cash flows for 2015 and let me make decisions about what to invest in the company and continued development.
     
    Following the launch, we'll have a period until summer where I will work on new features for 3.5 and resolve a few remaining Linux issues. I expect to make some minor changes to the renderer and update system in particular, but nothing that breaks the API. I'm not going to attempt anything like this until the launch is over, as it is possible I might have to make some quick fixes the first week.
     
    Summer will see the release of Leadwerks 3.5 and the Leadwerks Summer Games Tournament. Leadwerks Game Player will have a private beta, and will launch to the public when there are 50 small games ready to play.
     
    You can help the 3.4 launch by spreading the news on social media, when it is released. Thank you.
  13. Josh
    Light is made up of individual particles called photons. A photon is a discrete quantum of electromagnetic energy. Photons are special because they have properties of both a particle and a wave. Photons have mass and can interact with physical matter. The phenomenon of "solar pressure" is caused by photons bombarding a surface and exerting force. (This force actually has to be accounted for in orbital mechanics.) However, light also has a wavelength and frequency, similar to sound or other wave phenomenon.
    Things are made visible when millions of photons scatter around the environment and eventually go right into your eyes, interacting with photoreceptor cells on the back surface of your interior eyeball (the retina). A "grid" of receptors connect into the optic nerve, which travels into your brain to the rear of your skull, where an image is constructed from the stimulus, allowing you to see the world around you.
    The point of that explanation is to demonstrate that lighting is a scatter problem. Rendering, on the other hand, is a gather problem. We don't care about what happens to every photon emitted from a light source, we only care about the final lighting on the screen pixels we can see. Physically-based rendering is a set of techniques and equations that attempt to model lighting as a gather problem, which is more efficient for real-time rendering. The technique allows us to model some behaviors of lighting without calculating the path of every photon.
    One important behavior we want to model is the phenomenon of Fresnel refraction. If you have ever been driving on a desert highway and saw a mirage on the road in the distance, you have experienced this. The road in the image below is perfectly dry but appears to be submerged in water.

    What's going on here? Well, remember when I explained that every bit of light you see is shot directly into your eyeballs? Well, at a glancing angle, the light that is most likely to hit your eyes is going to be bouncing off the surface from the opposite direction. Since you have more light coming from one single direction, instead of being scattered from all around, a reflection becomes visible.
    PBR models this behavior using a BRDF image (Bidirectional reflectance distribution function). These are red/green images that act as a look-up table, given the angle between the camera-to-surface vector and the incoming light vector. They look something like this:

    You can have different BRDFs for leather, plastic, and all different types of materials. These cannot be calculated, but must be measured with a photometer from real-world materials. It's actually incredibly hard to find any collection of this data measured from real-world materials. I was only able to find one lab in Germany that was able to create these. There are also some online databases available that these as a text table. I have not tried converting any of these into images.
    Now with PBR lighting, the surrounding environment plays a more important role in the light calculation than it does with Blinn-Phong lighting. Therefore, PBR is only as good as the lighting environment data you have. For simple demos it's fine to use a skybox for this data, but that approach won't work for anything more complicated than a single model onscreen. In Leadwerks 4 we used environment probes, which create a small "skybox" for separate areas in the scene. These have two drawbacks. First, they are still 2D projections of the surrounding environment and do not provide accurate 3D reflections. Second, they are tedious to set up, so most of the screenshots you see in Leadwerks are not using them.

    Voxel ray tracing overcomes these problems. The 3D voxel structure provides better reflections with depth and volume, and it's dynamically constructed from the scene geometry around the camera, so there is no need to manually create anything.

    I finally got the voxel reflection data integrated into the PBR equation so that the BRDF is being used for the reflectance. In the screenshot below you can see the column facing the camera appears dull.

    When we view the same surface at a glancing angle, it becomes much more reflective, almost mirror-like, as it would in real life:

    You can observe this effect with any building that has a smooth concrete exterior. Also note the scene above has no ambient light. The shaded areas would be pure black if it wasn't for the global illumination effect. These details will give your environments a realistic lifelike look in our new engine.
  14. Josh

    Future Ideas

    By Josh,

    Here are some of my thoughts on how a future engine might look. I am not devoting any time to this, and it would not come to exist for several years, but it's fun to think about technology and design:
     
    I've been fascinated with the game "Fuel". This game has an enormous playable area that is streamed from the hard drive. You can drive for hours and barely cover a fraction of the map. For some reason the game has been given bad reviews. I played Motorstorm on the PS3, and I think Fuel is a lot better than that game, not even considering the impressive technical features. Anyways, I love the large open world. Fully dynamic lighting was one holy grail of game development, and I think a continuous open world is another.
     
    I would start this with a concept of "regions". Each region is a square on the grid, perhaps 1024x1024 units. The region has a terrain heightmap, terrain normal map, and an SBX file for all entities in the region. As you move around the world, regions are loaded from the hard drive in a square of playable area around you. Maybe there are 16 regions active at any given time. This number should be adjustable. Only physics and scripts of the entities within this active region are updated. When a region goes out of the playable area, it is saved to a file, and this new file is loaded if that region re-enters the playable area. So you aren't going to have enemies fighting and moving around when they are a million miles away. The engine just updates the regions nearby, because it would be simply impossible to update millions of entities. The AI in STALKER actually uses a technique similar to this, and I think they originally were planning on a huge continuous world but weren't able to pull it off. Each region can be culled on a separate thread, so this design lends itself to multithreading.
     
    So far what I have described is a big challenge, but it seems feasible. The real nightmare begins when we talk about networking. If your friend walks ten miles away and interacts with a person who's attitude towards you changes based on the interaction, well the server needs to be running two simulations. One simulation is for you and everything around you. The other simulation is for your friend and everything around them. What your friend does will change the world outside your playable area, so that when you enter that region it will be different than when you left. Now consider physics. Due to the massive distances, there would need to be two separate physics simulations running. Then they would need to be merged together when you approached each other. Wow, no wonder no one has done this yet! Fuel has a multiplayer mode, but it's just a racing game. Your actions don't have any permanent consequences on the world around you. An FPS, adventure, or RPG game will be quite different. I'm not even sure this is technically possible, without severe restrictions in flexibility.
     
    Fortunately, real-time rendering is not going to change much in the next ten years. We'll be able to do more as hardware advances, but I think we'll still be using the same basic techniques for a long time. That means that every feature and technique we add now will still be useful for a long time, even in a new engine.
  15. Josh

    Initial VR Implementation

    By Josh,

    As you probably noticed, I've been playing around with the Oculus Rift DK2 and it's really neat! With Klepto's help I was able to get it running and integrated into the engine very quickly. Beta support will be added soon so you can play with it yourself. Why is it beta? Because it is possible some behavior may change, particularly the way head rotation is handled. Also, it only works on Windows at this point. I'm waiting for OculusVR to add direct HMD rendering for Linux, because without that it's not a very pleasant experience.
     

     
    The renderer has been modified so that directional lights are only re-rendered once per frame, instead of re-rendering directional shadows once for each eye. The speed of the Leadwerks renderer also helps here. I noticed my VR apps feel noticeably smoother than most demos I have tried. Leadwerks by default uses direct HMD rendering with display mirroring turned off, so it's the fastest possible mode the rift allows. This is important because latency = nausea, and I and others can be affected pretty strongly with simulator sickness.
     
    Enabling VR in your game could not be easier. Just use the Window::VRDisplay creation flag when you create your game's window, and you're done. Really, that's all it takes:

    Window* window = Window::Create("My VR Game",0,0,1024,768,Window::Titlebar|Window::VRDisplay);
     
    Or in Lua:

    local window = Window:Create("My VR Game",0,0,1024,768,Window.Titlebar + Window.VRDisplay)  
    You can also call VR::GetHeadRotation() and VR::GetHeadPosition() to track the player's current orientation. Camera rotation and translation are handled for you automatically, though, so this is really only needed for adjusting your direction of movement and things like that.
     
    This will be available soon on the beta branch on Steam.
  16. Josh
    The built-in level design tools in Leadwerks3D are great for quickly sketching out a game level. Most of this remains unchanged from the design of 3D World Studio, with a few extras like smooth groups and new primitive types:

     
    When a point entity object type is selected in the side panel, the object creation widget changes to a simple cross hair:

     
    The selection box with tabs that CSG brushes use are great for quickly moving, scaling, rotating, and shearing brushes, but they aren't that great for point entities. That's why I'm implementing a different control style for selected point entities. A 3D widget like 3DS Max uses will appear in the 3D and 2D viewports:

     
    To give the user more control, they can choose between global and local coordinate systems to move and rotate entities:

     
    We think this will provide the best combination of fast level editing with CSG brushes, and quick object manipulation for other types of objects.
     
    --EDIT--
     
    Here's an updated view of the 3D control widget. Of all the implementations of this I have seen, I like the Crysis Editor's the best. The next step will be to make the widget change appearance when the mouse is hovered over it. As has been requested in the past, the widget stays on top of everything drawn, and always scales to appear the same size at any distance.

  17. Josh
    A default Steam controller configuration has been created for Leadwerks Game Engine and Leadwerks Game Launcher. It is recommended that you use the keys listed here for controlling your games. This will ensure that your game can be played seamlessly with either a keyboard or Steam controller.
     
    WASD: Movement
    Left shift: Run
    C: crouch
    Tab: Map, inventory, etc.
    Escape: exit game or main menu
    Mouse wheel down: next weapon
    Mouse wheel up: previous weapon
    R: Reload
    Left mouse button: shoot
    Right mouse button: alt fire or other action
    F: Flashlight
    R: Reload
    E: Use / interact
    Space: Jump
     
    There are many games that won't need these exact actions, but if you use these keys your game will work with Leadwerks Game Launcher on SteamOS. This will allow you to publish your games to Steam Workshop and play them in the living room on your TV. You don't even have to have a Linux PC to develop games for SteamOS.
     

  18. Josh

    Project Manager

    By Josh,

    The Project Manager lets you manage multiple Leadwerks projects. A project includes assets, scripts, code, code projects for Visual Studio, Xcode, and Eclipse, along with your game's executable. The Project Manager lets you view and switch between your different projects.

     
    Projects can be exported into a .zip file for easy sharing and archiving. You can even have Leadwerks3D scan all source code files and only include the asset files that your game actually uses. (I'm still adding the password field to encrypt them):

     
    You can import projects back from a .zip file:

     
    And of course you can create new projects, for any supported language, with multiple platforms supported by each:

     
    Here's my list of things I have either recently gotten done, or postponed for some reason:
    X -Window order(?)
    X -Convex cast app (postponed)
    X -Script execution
    X -Script SaveAs, SaveAll, New, Open, etc.
    X -Directional light destructor bug
    X -Occlusion query / octreenode bug
    X -Delete thumbnails when folder deleted, if in deleted folder
    X -Send files/folders to recycle bin instead of deleting
    X -Project import from zip passwords
    X -Project switching
    X -CRC32 zip password checks
    X -Improve project import events and process
     
    And still to go:
    -Add password export zip field
    -Animation
    -CSG Editing
  19. Josh

    Louie, Lua

    By Josh,

    Below is raw output from the Lua debugger. It displays all variables, tables, and functions in the Lua script call stack. This will be displayed in a nice treeview interface that looks much better, but I found this terribly exciting.
     
    You'll notice that tables don't get expanded, even though I have the ability to display all the values in a table. The reason they don't get expanded is because tables can contain tables, including tables that might be found elsewhere in the program. This can easily cause an infinite loop of tables leading to tables leading to tables. This is why the Lua debugger must be a networked program that talks to the running process. When the user opens a treeview node to view the contents of that table, the main program will return all the values in the table so you can view them, but not before.
     
    Here's what the Lua script looks like:

    print("Script is running...") local a = 2 local b = 3 someglobalvalue = "hello!" someglobaltable = {} local mytable={} mytable.color = "red" mytable.mood = "happy" mytable.subtable = {} mytable.subtable.n = 9 function dostuff() local test = "dog" RuntimeError("An error has occurred!") end dostuff()
     
    This will allow you to examine the entire contents of the virtual machine of any Leadwerks Engine 3 program built with debugging enabled, regardless of what language the main loop is coded in. The Lua implementation in Leadwerks Engine 2 was well-received, but we found in advanced programs we needed better tools to debug and analyze scripts. The script debugger in Leadwerks Engine 3 will make everything perfectly transparent so you can easily identity and fix problems. It also gave me a start on networking, because networking commands were needed to set this up.
     
    My plan for the networking API is to have commands for sending raw data with a message id:

    bool Send(const int& message, Bank* data=NULL, const int& channel=0, const int& flags=MESSAGE_SEQUENCED)
     
    As well as a few game-oriented commands to easily set up basic behavior:

    bool Say(const std::string& text) bool TeamSay(const std::string& text) bool Join(const int& team)
     
    The real magic is the entity syncing, which handles networked physics and makes it so any command you call on the server affects the corresponding entities on all clients. If you call entity->SetColor(1,0,0) to make an object red, it will turn red on all clients. I've tested an earlier prototype of this, and it worked well, even across continents. This makes network programming fairly easy, and a lot of fun.
     
    I'd really like to have a simple open-source tournament shooter game the whole community can play around with. Only by building a good networking base with a high-level entity syncing system does this become convenient and easy to modify.
     

    http://www.youtube.com/watch?v=7Vae_AkLb4Q
     
    ---------------------------------------------------------------------------------------
     
    And here's the debug output displayed in a tree view. The tables each get one blank child node, and when the user expands the table, the debugger will send a request for that table's data:

  20. Josh

    Day One

    By Josh,

    After a much-needed vacation I'm back, and ready to rock.

    IGDA Summit
    Everything at the IGDA Summit was mobile, mobile, mobile. Based on this kind of behavior in the industry, you'll have to forgive me for thinking at one time that mobile was the next big thing. There's two problems: Perhaps half the companies there were support services to help you monetize your app. I haven't heard the word "monetize" so much since the height of the Social boom, when people had huge numbers of free users and were looking for a way to convert them into paying customers (which didn't happen). I take it as a bad sign. If you are a corn farmer, and a bunch of door to door salesmen come to your farm offering to help you monetize your corn selling business, you probably have a problem.
    At the same time, all the indie developers unanimously said they were having trouble making money, and that the market was very crowded. The general consensus was that it wasn't enough just to make a good mobile game. You had to have a way to promote it. One developer told me his marketing plan was to create a Facebook page. I guess he had never gone that far before, and was confident it would be the answer. Another guy complained he couldn't even give away his totally free game, with no ads or in-app purchases.

     
    So to me right now mobile looks like one of those things where a bunch of companies operate at a loss for a few years in hopes they will get acquired by EA, and then 90% of them disappear. Does not feel like a promising place if you are actually trying to provide goods to customers in exchange for money. (Of course there will still be some major successes, but those seem like the exception.)
     
    I was the only Linux developer at the event, as far as I know. Based on the strength of our recent Kickstarter campaign, Linux is arguably our lead development platform now. Which I would not have guessed a year ago.

    Leadwerks 3.1
    Development of Leadwerks 3.1 for Linux and Steam begins in earnest now. I'm focusing on graphics and terrain first, since those tasks cannot be done by anyone but me. Linux and Steam integration can be performed by the other devs, and I will just contribute to those depending on how much time I have. I made a lot of progress on terrain recently, and my goal is to have the terrain editor implemented by the end of the week. This will be included in the 3.0 version and rolled out when it is available. 
    I will also be attending to any outstanding bug reports. Having the current version 3.0 in use before the graphics upgrade in 3.1 is a great way to evaluate out the editor and make sure everything is solid.
     
    So I am looking forward to the development of 3.1 over the next few months. After all the recent excitement, some quiet coding time sounds great to me.
  21. Josh

    Success!

    By Josh,

    You did it! Leadwerks 3.1 is coming to Linux.
    As traditional gaming platforms are becoming more and more restrictive, software developers, hardware vendors, open-source coders, and gamers are working together to build a better future for gaming on the open platform Linux. I count myself fortunate to have found my place in this movement, and am very grateful that over 700 Linux gamers believed in this idea.
    What now?
    I'm driving over to the IGDA Summit today to sit in on a few sessions. Then I'm going to take a much-needed couple of days off and we'll hit the ground coding Monday morning. There's a lot of work to do before December, but our requirements are very clearly defined and the major technical hurdles have been knocked out. I have a pretty open development process and enjoy explaining the cool stuff we implement, so you'll be updated at every step along the way. 
    It's clear that the visual GUI designer stretch goal is something many people would like to have. The idea could probably use more refinement, and I'm not going to make spur-of-the-moment development decisions, but the feature is a very good candidate for future development.
     
    Physical items will be shipped in August. I'll post an update here when items begin shipping. A poll will be sent out to gather shirt sizes and any other needed information.
     
    For near-daily updates you can add Leadwerks on social networks:

    Facebook: http://www.facebook.com/Leadwerks
    Twitter: http://www.twitter.com/Leadwerks
    Google+: http://plus.google.com/105110099393641532044
    YouTube: http://www.youtube.com/Leadwerks

     
    Once again because it can not be said enough, thank you for backing this project. This is a win for not only the Linux operating system, but for PC gaming, which is finally getting the priority it deserves on Linux.

    Acknowledgements
    The following organizations helped achieve this outcome: HackerLab
    SARTA
    OUYA
    Canonical
    Valve

     
    And of course, thank you to Kickstarter for providing the platform to support this funding model.

  22. Josh

    Next Steps

    By Josh,

    I've got the basic GI algorithm working but it needs a lot of work to be correct. I tend to do very well when the exact outcome is well-defined, but I am not as good at dealing with open-ended "artistic" programming. I may end up outsourcing the details of the GI shader to someone else, but the underlying data management is solid enough that I am not scared of it anymore.
    There's a lot of aspects of the design I'm not scared of anymore. We worked out smart pointers (including Lua integration), physically-based rendering, and most importantly the crazy ideas I had for the super efficient architecture work really well.
    At this point I think I am going to put the GI on hold, since I could play around with that endlessly, and focus on getting a new build out to the beta subscribers. We're going to just use a single skybox for ambient and specular reflections right now, and when it's ready GI and environment probes will provide that. 
    After that I think I will focus on the physics and navigation systems, exposing the entire API to Lua, and getting some of the outsourced work started. There's a few things I plan to farm out:
    Visual Studio Code Lua debugger GI details Weather system Water and clouds systems Everything else is pretty well under my control. This started out as an idea for an impossible design, but everything has fallen into place pretty neatly.
  23. Josh
    The beta of Leadwerks 3.3 is now available on the beta branch on Steam.
     
    Two new entity classes that extend the model class are present. Sprites are a quad that can face the camera, a specific direction, or can rotate around one axis. These are useful for lighting effects and the axis rotation is great for making laser beams or tracer rounds.
     
    The Lensflare class extends the sprite class and adds a simple glow effect for lighting.
     
    The editor now support shift-drag to select in the main window viewports.
     
    Vehicles are supported. However, the vehicle class is not documented and there are no examples yet. Expect updates that demonstrate how to use these before the final version is released.
     
    On Windows, the main window now uses resizable splitters so you can adjust the size of the side panel and program log, or click the separator to show/hide them. You can also right-click on a file or folder in the Asset Browser and select the Properties menu item to bring up the Windows file properties dialog.
     
    A surprise bonus I did not anticipate until a few days ago is a reworked, easier to use Workshop system. Files are now extracted into a subfolder in an "AddOns" folder in your project's directory. This makes it so scripts and shaders work properly, and prevents broken file linkages we were experiencing with more complex Workshop content. The system for uploading Workshop items has also gotten more intuitive and friendly. The change was not as dramatic as I feared; all Workshop assets and games still work with no changes. After working with this approach for just a couple of days, it feels so much faster and easier to use than keeping everything in encrypted zip files all the time.
     
    Finally, the publish dialog will now export a copyright-protected game using zip file encryption. This works with both Lua and C++ games. A cross-platform game folder is now exported instead of an installer, so you can use Inno Setup or another free program to make your own installer.
     
    The community has provided some really good feedback lately, and I'm really proud of how 3.3 is turning out. I think you'll find Workshop is a lot more useful now.
  24. Josh
    I was sorry to hear the news of Stonetrip's liquidation earlier this month. Shiva3D pioneered multi-platform publishing, and I enjoyed killing zombies in "The Hunt". I know that many of you are wondering what to do next. So, let me just get it out on the table that Leadwerks might be an option for your team.
     
    We just released Leadwerks 3, our first cross-platform product for mobile. Leadwerks 3 is completely redesigned to accelerate developer productivity with new advances in tools and workflow. These include native code and Lua support, a new rapid art pipeline, automatic asset reloading, built-in level design tools, plus many others.
     
    I'd like to extend an invitation to any former Shiva users looking for a new home. We're offering a 30% discount on the Leadwerks 3 add-ons for iOS and Android this month to Shiva developers. Enter the coupon code "SHIVA3D" at checkout before June 1, then just email us your invoice from your purchase of Shiva3D, and we'll process your order.
     
    Leadwerks doesn't support all the platforms Shiva did, but we provide "write-once, publish everywhere" deployment to the most important ones: iOS, Android, Windows, and Mac. Shiva developers will feel right at home with our Lua integration, complete with debugger, code stepping, and a built-in script editor. We've even taken Lua a step further, with a built-in flowgraph editor for visually connecting scripted objects. And when you're ready, you also have the option to write games in pure native code with C++, for maximum performance.
     
    Leadwerks 3 is new, but it's built on the lessons learned from our history of delivering high-end graphics on PC since 2006 We provide lots of advanced features, but are able to maintain a competitive price. I welcome you to join other "Werkers" as we move forward. This is going to be a very exciting year for the game industry, and we have some big advances coming down the pipeline.
     
    I realize that it must be a shock to see the predicament that Shiva is going through right now, but for you and your team, it doesn’t have to be the end. I welcome you to join our community and trust that the steps taken above will underscore our commitment to helping out the best we can.
     
     
    Regards,
     
    Josh
    CEO
    Leadwerks Software
  25. Josh

    iOS 6 Blues

    By Josh,

    Apple's problems in iOS 6 aren't limited to maps. Their OpenGL drivers in iOS 6 are absolutely non-functional.
     
    First I was experiencing a BAD_EXC_ACCESS error when rendering certain surfaces. Feedback on the Apple dev forum suggests I am not alone in this. I took a guess and switched my position vertex buffers to use vec4s instead of vec3s, and it appears to have solved that problem (even though both should be fine).
     
    Second, all 3D objects just stopped appearing, completely. I've debugged it to the point of absolute barebones, and still can't get anything to show up...but only on the iPad 3 device itself. My iPhone 4 (also running iOS 6.01), the iOS simulator, and even my HTC Evo all appear fine, running the same code.
     
    My guess is that the Apple driver team was given a directive to get the speed of their graphics chip up to be competitive with the latest 12-core NVidia Tegra, and that they gained speed by fine-tuning the drivers for specific applications they were testing with, at the expense of compliance with the OpenGL ES specification.
     
    In a world where the graphics device performance between all targeted hardware can vary by 1000x, compliance with the OpenGL spec is paramount. Performance at the cost of reliability is not an option.
     
    I also have come to the conclusion that OpenGL is just a fundamentally flawed API. Programmable shaders have been around since 2003-ish, and the vendors still can't write drivers that work. I take this as an indication that the OpenGL specification is just too complicated.
     
    Anyways, this is one of my more emo blogs, and I will solve the problem, but that's where I'm at today. Considering the amount of non-working **** we deal with on both Android and iOS, it's clear to me that for most developers, cross-platform development is just infeasible. I'm glad we can figure this stuff all out for you, so you can just use our API and not worry about all the mistakes third parties make with their APIs, drivers, and tools.
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...