Jump to content
Ultra Engine Community

Josh

Staff
 View Profile  See their activity

  • Posts

    23,457

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Josh

  1. Josh
    The 3.6 Release Candidate is now available on the beta branch. Since the last update, this adds camera render targets. You can set a texture to a camera's render target in the editor camera properties, and with the new command Camera::SetRenderTarget(Texture* texture). Render targets work both in the editor and in-game.
     
    A terrain offset map has been implemented in the physics system, but it is not yet integrated into the engine.
     

  2. Josh
    Miniaturization has been a big trend over the last five years, but it isn't limited to mobile. It's impacted other areas of technology that I find much more interesting than cell phones. Previously, I wrote about the changing PC form factor, and how my current rig is a no-compromises full-size PC packed into a form factor about the size of a bread box.
     
    I happen to have my hands on a few pieces of technology that are brand new, unreleased, or things I myself am creating. All these technologies together make the living room experience really different from anything we've seen in the past.
     
    Before I talk about the new stuff, let's review your common living room setup. This will consist of a big-screen television, some kind of home stereo, and a game console. They were huge, heavy, and still couldn't compare to the experience of seeing a movie in the theater.
     

     
    Optimization of size means that the processing volume of a device decreases and the interface elements become larger, or stay the same size. My PC today has a smaller volume than ten years ago, but my big 27" monitor provides a larger visual interface. This is the evolution of devices. Based on this rule, we should expect the same to occur in the living room. And it quietly has.

    Pico Projectors
    Texas Instruments has pioneered a technology called DLP. DLP stands for Digital Light Processing, and it allows the development of very small "pico" projectors. Although the technology has been around for a while, it's made big improvements in recent years. You can now purchase a mini projector that fits in the palm of your hand and can throw the equivalent of a ten foot screen (about three meters) up on a wall. So the visual interface has increased by about twelve times in size versus most HD TVs, while the actual mass and volume of the processing unit has gone down an order of magnitude or two. The resolution of this unit is 1280 x 800 which looks great with a huge picture. 


    Sound Bars and Players
    Computerized music has brought about the rise of sound bars and mini-sound players. These have basically just been reduced to the volume of the speakers, with very little else there. Although the sound quality is not as good as a high-end system, small music players like the Bose SoundTouch give you 80% of the quality at 10% the size. You can also connect the output from a projector into the line-in jack to get big sound in a very small form factor. I'm a bit of an audiophile, but even I have to admit convenience is king. 


    Steam Machines
    Finally, SteamOS is set to revolutionize console gaming. With form factors much smaller than current-generation console, SteamOS wins on all fronts: Performance, size, and costs are all better with Steam Machines. 

     
    Pull all these technologies together and what do you have? Big sound, a giant theater-like picture, and superior gaming performance, all in a package you can easily fit into a backpack.

    Publishing to the Living Room
    Finally, Leadwerks Game Launcher is about to open up the living room for content creation for the first time. You can publish your game straight from Leadwerks Game Engine on the PC, then sit down and play it on a big screen with the Steam Controller. Ever since the days of the Nintendo Entertainment System, game consoles were strictly a consumption activity, It's literally taken twenty years for the living room to open up so you can play your own games in a relaxed and casual atmosphere. A new era of creativity is upon us, and the living room is about to get a lot more interesting. 

  3. Josh
    We're going to release a version 3.6 early with decals and the other enhancements I've recently made. This is scheduled for Monday, August 17th. At the same time we will be releasing Leadwerks Game Launcher as a free early preview title. So you've got exactly two weeks to prepare any other games you want to show off. I'm happy with the lineup we have of 25 games, and am looking forward to the launch so we can show your werk off to the world!
     
    My market positioning with this product is going to focus on the variety of creative experiences users can try, things that they don't normally see in a super-polished AAA game. The target customer is someone who is looking for something a little off-the-beaten-path, and will enjoy the chance to communicate directly with the game developer on the Workshop forum.
     
    The application will be free, and provides a never-ending stream of new experiences, courtesy of you, the Leadwerks community. I think there are players out there who would love to try something different. Furious Frank, for example, had over 20,000 downloads on our old website. Not everyone knows about IndieDB or feels comfortable downloading an installer from a website. I think the convenience of Leadwerks Game Launcher on Steam will allow us to pick up a lot of players who tired of the same old thing, and give you a chance to build a fan base on Steam so you can easily get through Greenlight.
  4. Josh
    An HTML renderer for Linux has been implemented. This adds the welcome window and full Workshop inteface for Linux. This will be available soon for testing on the beta branch.
     

     

     

  5. Josh
    An update is now available on the beta branch.
     
    A new decal entity type is available. Decals are used to project an image into surrounding geometry. A decal requires a material using a decal shader, located in the "Shaders\Decals" folder. The FPSGun.lua script has been updated to add bullet marks and gunshot wounds to objects a bullet hits. You can also place a decal in a map for adding large details to walls, terrain, or anything else.
     

     
    Decals are rendered similarly to the way a deferred light works; they are rendered onto the screen gbuffer. This allows them to work on any geometry, including animated models and GPU-generated details like tessellation. They will also map onto any surface, based on the direction of the surface normal. There are two new commands, Decals::Create() and Decal::SetRenderMode().
     
    Because decals render onto the scene gbuffer, a way to differentiate pixels is needed. Otherwise, a scene decal will appear on objects that pass through that area. The Decal::SetRenderMode(int mode) command can be used to indicate whether a decal should be a static scene decal (mode=0) or a dynamic decal, like for a bullet mark (mode=1). Materials also have a new parameter for their decal mode, which can be 0 (static), 1 (dynamic), or 2 (none).
     
    The blending of decals required that I modify the channel allocation of the gbuffer, and the lighting and model shaders have changed. Previously, data was stored like this:
    0: Diffuse RGBA
    1: Normal XYZ, specular
    2: Emission RGB, material flags
     
    Now the gbuffer is storing information as follows:
    0: Diffuse RGBA
    1: Normal XYZ, material flags
    2: Emission RGB, specular
     
    Any modified model shaders or shaders that are rendered before lighting need to be changed to accommodate this change, as well as any post-processing effects that read the specular value or material flags.
     
    Particle emitters will now use simple collision if the emitter has a collision type other than zero. This is a nice touch that makes bullet shrapnel bounce off floors instead of going straight through.
     
    I previously talked about four big features I was researching, terrain tessellation, terrain horizontal offsets, deferred decals, and vegetation. I made headway on each of these, but discovered that deferred decals were fairly easy to wrap up, while the other three features were more involved. Based on this development, I am revising my plan to release a new version in August with decals and the other recent improvements, then focus on finishing the vegetation system for a subsequent update. The important thing is to have the final update with vegetation out by November 1, at the latest, although that could end up being much sooner if things go smoothly.
     
    I also expect to release the game launcher in August, as an early preview release on Steam.
     
    (Build #691949 was update to #711604.)
  6. Josh

    Leadwerks 3.6 Roadmap

    By Josh,

    I've got a pretty good idea of what features I want to pack into Leadwerks Game Engine 3.6, and I'm ready to share them with you now.
     
    Just about all the simple easy features I think I can implement are already built into Leadwerks, but there are some bigger more involved things I want the engine to support. Instead of doing these one at a time, I am doing research on them all, and changing my focus when I get stuck. I've got a big block of research done that all revolves around creating new possibilities for map design.
     
    The vegetation is developed far enough that I can see my new ideas will work well and provide a more powerful forest rendering system than even Leadwerks 2 provided.
     
    Terrain tessellation is a work in progress, but it's promising. We need some high-quality textures to really show it off.
     
    The terrain horizontal offset I talked about previously is a really nice touch but more work needs to be done to make physics match the visual geometry.
     
    Finally, I've decided to use deferred decals rather than decals cut out of model geometry. The reason for this is that we have several types of geometry that are dynamically generated or modified on the GPU (terrain offset, tessellation, animation). Deferred decals work by rendering a volume on top of the scene gbuffer, and work regardless of the underlying geometry, so these are more appropriate for modern graphics techniques.
     
    I'm setting a conservative release date of November 1 for this release, but many of these features will be available for testing on the beta branch before then.
  7. Josh

    Beta Update available

    By Josh,

    Things are very good on the business side of Leadwerks, so I wanted to take some time right now for some research and development so I can give you guys some new and shiny features. It's very interesting to me how the design of Leadwerks 3 has laid a foundation that allows us to do lots of new things that have never been done, and now I am getting to dig into some of those areas and explore.
     
    I've decided the area I want to focus on is all under the banner of "outdoor rendering". The vegetation and terrain systems work together to provide a lot of powerful options that make it easy to create realistic outdoor environments. Rather than try to add one "checklist" feature at a time, I want to develop all these things together so we can get the most out of their combined capabilities. For that reason, I am going to hold off on terrain tessellation for now, and do some more research on the "offset" terrain tool idea, which would allow crags and overhangs on heightmap terrain. I'm fairly sure it will work now, but there are still a few issues to resolve.
     

     
    The vegetation and/or terrain enhancements I am developing may also be featured in an upcoming book, so that is very exciting.
     
    Changes
    Added two new terrain layer texture mapping modes, vertical and trilinear. This is great for cliffs.
    Added setting in options to control terrain clipmap resolution. The corresponding command is world:SetTerrainQuality(quality). Use 0, 1, or 2 for the quality setting.
    Added new higher-resolution clipmap (using quality=2 or "High" setting in options.)
    Temporarily disabled terrain tessellation while I figure out what I am doing with this feature. It will definitely make it in, but we need some high-quality texture maps for this, and I may be doing some work with an offset vector on the terrain, so I don't want to roll this out until I see how those work together. The terrain tessellation shader from the previous beta will still work if you want to use it now.
    When your game is launched from the editor, you can press F12 and it will automatically take a screenshot and display the screenshot uploader when the game ends. So now you can easily upload in-game screenshots, and they will appear in the Leadwerks Game Engine community hub. (This took a little cleverness to set up because the launched process inherits the Leadwerks Game Engine app ID, which has the Steam overlay disabled.) I hope to see lots of screenshots from your games now!

     

  8. Josh

    Beta update available

    By Josh,

    A new build is available on the beta branch with the following changes:
    Fixed sidepanel tab switching bug.
    Improved compatibility with intel graphics.
    Fixes instance rendering bug with instance count over 256.
    Added terrain hardware tessellation.

     
    To enable hardware tessellation, select the Tools > Options menu item, select the Video tab, and set the tessellation value. Terrain layers much have a displacement map to display displacement mapping. Each terrain layer has an adjustable displacement value to control the strength of the effect. Displacement maps look best when they are rendered from a high-polygon sculpt. The terrain wireframe shader has alsod been updated to visualize the tessellation in wireframe view. You must update your project to get the new versions of the terrain shaders.
     
    At this time, terrain will always use tessellation when it is enabled, even if no texture layers contain a displacement map. This will be changed in the future.
  9. 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.
  10. Josh

    Vegetation

    By Josh,

    There's basically two kinds of vegetation, trees and grass.
     
    Grass is plentiful, ubiquitous, dense, but can only be seen at a near distance. Its placement is haphazard and unimportant. It typically does not have any collision. ("Grass" includes any small plants, bushes, rocks, and other debris.)
     
    Trees are fewer in number, larger, and can be seen from a great distance. Placement of groups of trees and individual instances is a little bit more important. Because these tend to be larger objects, they have physics collision.
     
    Now figuring out how to take advantage of modern GPU architecture with both of those types of objects is an interesting problem. I started with geometry shaders, thinking I could use them to create duplicate instances on the fly. This geometry shader will do just that:

    #version 400  
    #define MAX_INSTANCES 81
    #define MAX_VERTICES 243
    #define MAX_ROWS 1
     
    uniform mat4 projectioncameramatrix;
    uniform mat4 camerainversematrix;
     
    layout(triangles) in;
    layout(triangle_strip,max_vertices=MAX_VERTICES) out;
     
    in mat4 ex_entitymatrix[3];
    in vec4 ex_gcolor[3];
    in vec2 ex_texcoords0[3];
    in float ex_selectionstate[3];
    in vec3 ex_VertexCameraPosition[3];
    in vec3 ex_gnormal[3];
    in vec3 ex_tangent[3];
    in vec3 ex_binormal[3];
    in float clipdistance0[3];
     
    out vec3 ex_normal;
    //out vec4 ex_color;
    out vec3 ex_jtangent;
    out vec3 ex_jbinormal;
    out vec3 ex_jjtangent;
     
    void main()
    {
    //mat3 nmat = mat3(camerainversematrix);//[0].xyz,camerainversematrix[1].xyz,camerainversematrix[2].xyz);//39
    //nmat = nmat * mat3(ex_entitymatrix[0][0].xyz,ex_entitymatrix[0][1].xyz,ex_entitymatrix[0][2].xyz);//40
     
    for(int x=0; x<MAX_ROWS; x++)
    {
    for(int y=0; y<MAX_ROWS; y++)
    {
    for(int i=0; i<3; i++)
    {
    mat4 m = ex_entitymatrix;
    m[3][0] += x * 4.0f;
    m[3][2] += y * 4.0f;
    vec4 modelvertexposition = m * gl_in.gl_Position;
    gl_Position = projectioncameramatrix * modelvertexposition;
    ex_normal = ex_gnormal;
    //ex_color = ex_gcolor;
    ex_jjtangent = ex_gnormal;
    ex_jtangent = ex_gnormal;
    ex_jbinormal = ex_gnormal;
    EmitVertex();
    }
    EndPrimitive();
    }
    }
    }
     
    I soon discovered some severe hardware limitations that make geometry shaders unusable for this type of application. There's a 255 limit on the number of vertices that can be emitted, but there's an even harsher limit on the number of varying you can output from the shader. Once you add values for texcoords, normals, binormals, and tangents, geometry shaders actually only allow 16 instances per render...making them inappropriate for this purpose.
     
    What's really needed is an "instance shader" that could control how many times an object is rendered. This would simply discard an entire instance if it isn't in the camera frustum:

    uniform vec4 cameraplane0; uniform vec4 cameraplane1;
    uniform vec4 cameraplane2;
    uniform vec4 cameraplane3;
    uniform vec4 cameraplane4;
    uniform vec4 cameraplane5;
     
    uniform objectradius;
     
    uniform instancematrix[MAX_INSTANCES]
     
    bool PlaneDistanceToSphere(in vec4 plane in vec3 point, in float radius) {}
     
    main ()
    {
    mat4 mat = instancematrix[gl_InstanceID];
    vec3 pos = mat[3].xyz;
    float radius = objectradius * max(max(mat[0].length(),max[1].length),mat[2].length);
    if (PlaneDistanceToSphere(cameraplane0,position,radius) > 0.0) discard;
    }
     
    I realized I could render a number of instances without actually sending their 4x4 matrices to the GPU, and just generate the positions along a grid. This would start with an n X n grid and then add some noise to randomly rotate and scale each instance. The randomized positions would use the object's XZ position on the grid as the input, so I could dynamically generate the same orientation each time, without ever storing the object's actual position in memory. (This is why some Leadwerks 2 maps could be hundreds of megs of data.)
     
    Here is the code in the vertex shader that randomizes object scale and rotation:

    #define ROWSIZE 15 #define SEED 1
    #define randomness 3.0
    #define density 3.0
    #define scalevariation 1
     
    int id = gl_InstanceID;
    int x = id/ROWSIZE;
    int z = id - x * ROWSIZE;
     
    float angle = rand(vec2(SEED-z,SEED+x))*6.2831853;
     
    //Random rotation
    mat4 rotmat = mat4(1.0);
    rotmat[0][0] = sin(angle);
    rotmat[0][2] = cos(angle);
    rotmat[2][0] = -sin(angle+1.570796325);
    rotmat[2][2] = -cos(angle+1.570796325);
    entitymatrix_=rotmat*entitymatrix_;
     
    float scale = rand(vec2(SEED+z,SEED-x));
    float sgn = sign(scale-0.5);
    scale = (abs(scale-0.5));
    scale *= scale;
    scale = (scale *sgn + 0.5);
     
    scale = scale * scalevariation + 1.0-scalevariation/2.0;
    entitymatrix_[0] *= scale;
    entitymatrix_[1] *= scale;
    entitymatrix_[2] *= scale;
    entitymatrix_[3][0] = x*density + rand(vec2(SEED+z,SEED-x))*randomness;
    entitymatrix_[3][2] = z*density + rand(vec2(SEED+x,SEED-z))*randomness;
     
    Here is the result with trees randomly oriented entirely on the GPU:
     

     
    Of course you can have issues like no way to prevent two instances from being too close together, but a random seed, density, and randomness values are adjustable. It would also be possible to calculate a neighbor's position and use that to weight the position of the current instance.
     
    There are still many questions to be answered, but I think this approach is going in the right direction to design a more powerful and lower overhead vegetation rendering system for Leadwerks 3.
  11. Josh

    Vegetation Research

    By Josh,

    The Leadwerks 3 vegetation system is being designed to side-step the bottlenecks that limited the Leadwerks 2 vegetation system. The Leadwerks 2 system involved large collections of 4x4 matrices for each instance, resulting in hundreds of megs of data stored with the map. Eliminating this data results in small map sizes and reduction of memory usage.
     
    Here we have 10,000 trees being rendered (with no billboards), for a total geometry count of 14 million polygons. Memory usage is...zero!
     

     
    The framerate for this is 130 in debug and release mode, which tells me it's hitting the ceiling on the GPU vertex shader. Obviously we will use billboards to reduce the polygon count, but this tells me we're on the right track.
  12. Josh

    The PC is changing

    By Josh,

    PC towers have been about the same since they became popular in the 1990's, replacing the previous horizontal form factor:

     
    Cases have gone from beige to black, but very little else has changed.

     

     
    PC towers tend to be designed for the old ATX style motherboards, which were first introduced in 1995:

     
    PC cases are still designed primarily for this form factor, ignoring the fact that many internal components have changed.
    The sound and ethernet card are now typically built into the motherboard.
    Motherboards that support full-power components can now be purchased cheaply in the Mini-ITX form factor, with an area of just 6x6 inches.
    Hard drives have shrunk in size.
    3.5" floppy drives are long gone, yet most cases still include a slot for these.
    Optical drives aren't even necessary anymore, although they are still the most cost effective and reliable solution for data backup.
    Graphics cards, unlike other components, have gotten bigger, hotter, and thicker. I'm not sure a GPU can even be referred to as a "card" any more. With giant heat sinks, they're more like a "graphics block".

     
    Clearly, an update to the desktop form factor is needed to respond to these changes. There's been a lot of interesting developments in desktop / home theater miniaturization, which involves making a PC with "good enough" specs and a much reduced form factor. The Steam Machines have driven some of this interest, but it's been going on for a while. The utlimate result of this trend is the Gigabyte Brix Pro. Any smaller than this, and it would be a choking hazard:

     
    What about the full-size desktop PC though? Can we find a design that uses full-size components, but packs it into a form factor more suitable for modern hardware design? I set out the following critera when starting this project:
    The case must support a full-size PSU and GPU.
    The GPU must be easily accessible for quick changing.
    At least two hard drives and an optical drive.
    Airflow sufficient for the big hot PSU and GPU it would contain.

     
    Most Mini-ITX cases are designed for small home theater setups, and do not support full-size components. A few can accommodate a full-length GPU, but do not support adequate cooling or power requirements. The Antec ISK600, for example, is a disaster waiting to happen, with a closed side blocking airflow to the GPU:

     
    Other cases may have adequate cooling, but are too tightly packed for frequent GPU switching:

     
    The Bitfenix Prodigy is one popular case I considered, but it's not much smaller than a micro-ATX tower. When you consider the wider footprint of the case, the space savings are debatable:

     
    In the end, there was only one case that offered the hardware support, cooling capacity, and ease of access I was looking for. I give you the Cooler Master Elite 130:

     
    This case packs all my previous components into a volume a little smaller than a breadbox. The lack of a heavy steel case makes the machine much lighter, and the low profile feels safer than a heavy tower I am afraid could tip over at any minute. The GPU and PSU have better access to cool air from the exterior, and a large fan in the front blows air through the entire machine. An optical drive fits seamlessly into the case, under which is a clever mechanism for an SSD to hang sideways.
     
    On the down side, the front of the case under the optical drive is a mess of cables that impede airflow from the front fan. Removing the GPU requires a stick to press the release latch. Removing the SSD requires removal of the PSU, unless you have a very short screwdriver. I also broke the USB pins on my Zotac motherboard, but it's only $50 to replace.
     
    As an added bonus, my motherboard has built-in wifi connectivity. Coupled with the extreme portability of this unit, I am sure that will come in handy at some point.
     
    The net result is that my desktop PC is now portable in a way it's never been before. I could realistically take this with me on a weekend trip or to a LAN party, whereas I would never consider doing this with my tower. At last, we're seeing real technological innovation that isn't just a reduction of capabilities, but a real move forward towards something that was better than the old way.
     

  13. Josh
    It's been an eventful first half of 2015, and the second half promises to be just as exciting. I'm happy to say the Steam summer sale was a big success. I haven't done the calculation yet, but this year's sale did a lot more than last year, and we keep adding more and more new users. So that makes me feel very good about the future.
     
    I've begun researching a way to create our own built-in store based on Workshop and Steam microtransactions. This is the same system that TF2 uses for in-app purchases, but we have to do some fancy things for the file delivery system. If you are interested in publishing items to be sold, you can submit them now in the Workshop and you will be prompted to enter your bank information in Steam to receive payments directly from Valve.
     
    I think this is also a good time to give the user base a few things they want, so I implemented resizable viewports for Linux on the beta build. It seems to work just fine.
     
    I know vegetation is something a lot of people want, and I have begun researching this. My goal is to generate instances procedurally on the GPU without having to pass entity 4x4 matrices to the shader, which is the main bottleneck. This should make the new vegetation system a lot faster than what Leadwerks 2 had, and allow for much denser growth with basically no rendering cost. I think you'll see very very dense vegetation on screen with framerates that seem impossibly fast, up to a certain point.
     
    The screenshot below shows an array of trees generated from a geometry shader. This just requires one instance of the tree to be rendered, and then the other trees are procedurally generated by the shader:
     

     
    More information will follow as I learn more.
     
    I'm also buying a new motherboard and condensing my main development machine down into a mini-ITX case. The best one I found for my purposes was the CoolerMaster Elite 130, which packs full-size components into a fairly small volume. I'll write about this once I get my parts and assemble it:
     

  14. Josh
    An update is available on the beta branch with the following changes:
    Implemented "CollisionMesh"-named limbs in models.
    Added "Strip vertex colors" option in model editor.
    Workshop items can now be submitted as free or curated paid items, although no mechanism is in place yet to actually purchase items.

     

     
    Curated items appear in the Workshop and can be voted for, but cannot be downloaded.
     

     
    You can enter your bank information for receiving payments, and you can even create a revenue split between multiple people.
     

     
    Although purchasing items is not yet supported, this is a first step that allows you to prepare for when it is implemented. Any paid items you submit will be viewable, but cannot be used or downloaded by other users yet.
  15. Josh
    The beta branch has been updated with experimental support for resizable viewports on Linux, including an option to switch to a single viewport. The object bar buttons have also been fixed to display tool tips properly.
     

     
    You can try this now by opting into the beta branch on Steam. Let me know what you think.
  16. Josh
    I've set the release date for Leadwerks Game Launcher to Tuesday, July 21, right after the Summer Games Tournament ends. Your games will have the highest visibility during the first week the application is launched.
     

     
    This is a great chance to demo your best ideas. Remember, you don't need a full finished game, just a simple playable concept. The goal is to make something fun!
     
    Leadwerks Game Launcher is a unique application on Steam. The closest thing to it is the built-in game playing capability that GameMaker has. Unlike GameMaker, our game launcher is a standalone application for the sole purpose of putting your WIP games in front of an audience on Steam. Free self-publishing on Steam Workshop is a groundbreaking idea, and we are fortunate that Valve is trusting us to be the first with this. So let's show off what this community can do!
     
    I've also set up a deal with Arteria3D to make it easier to get 3D models for your games, so you can focus on the gameplay instead of making art. During the Summer Games Tournament you can get access to all Arteria3D's existing content for $75. Their models come in FBX format, which means they will work easily with Leadwerks:
    http://arteria3d.myshopify.com/products/leadwerks-special
     
    The Leadwerks Workshop also has a ton of free content available.

    Marketing
    The first step of marketing is to know who your audience is. There's a certain type of user the game launcher is aimed at. Someone who just wants to play Call of Duty isn't going to be into this, but there's other people who are interested in creative indie experiments. The type of user who would try games on Desura is who we are aiming at. Our store page will make it clear that these are in-development, incomplete, creative experiments. The kind of user we're targeting is looking to participate in the development of new and interesting game concepts, and will be pretty forgiving of bugs and rough edges if the game is fun.
    Promotion
    Any screenshots taken in Game Launcher games will automatically appear on our site here:http://www.leadwerks.com/werkspace/page/screenshots
     
    These will also be automatically reposted to a new social media account for Leadwerks games:
    https://twitter.com/LeadwerksGames
     
    I plan to add automatic tagging so that your game's title is tagged in the image. I will also add a simple web API so you can automatically display a feed of screenshots from your game in your own social media page or on your game's website.
     
    I'm requesting an "Early Access" release. The marketing budget for the final release will be based on the initial reception of the game launcher. If people like playing the games, I can promote this in many outlets, because it really is a groundbreaking idea.
     
    That's all for now! If you run into any trouble post on the forum, and ask me if you have any other questions. Good luck!
  17. Josh

    Icon Design

    By Josh,

    I've recruited a professional designer to create a new icon set for the Leadwerks UI. This will provide us with a more consistent visual interface, with a similar look on all supported platforms.
     
    My first instructions were to go bright and multi-colored, with colors similar to Lego pieces. We also included Windows 10 style icons as an influence. These looked good, but when plugged into the program the interface lost its visual consistency.
     

     
    We next experimented with some grayscale and heavy black and white icons. These were visually consistent but unremarkable.
     

     
    Finally, we tried a single-tone set using the default perspective viewport background as the base color. This produced the best results.
     

     

     
    We're proceeding with this style. We'll start with a pure one-tone set of icons and then add limited amount of color in. For example, the delete and selection mode icons will have some red added to them.
     
    Toolbar icons are going to be changed to 24x24 to show off the art and make them easier to find. Some of the current icons aren't very clear about what their function is, like the 90-degree rotation buttons, so redesigning them will make their functionality a little more clear.
  18. Josh
    Last week I tried implementing a new method of controlling entity script fields. I was not satisfied with the current drag and drop from the scene tree method. I tried a system that was based on the entity name, which is how we used to do things in Quake mods.
     
    Several people pointed out that this had a negative effect on their workflow, due to the difficult of copying and pasting groups of linked objects. So I began implementing a system that would create unique names when needed.
     
    I started to second guess this approach for two reasons. First, selecting different objects and switching between the name and script tabs to copy and paste names was not terribly efficient. Second, the design was creating new feature requests. My rule is that features that lead to more feature requests are usually a sign of bad design.
     
    I am reverting this behavior back to the original design for now. In the future I plan to try adding a button next to the field with a tool tip that says "Select Object". When you click this button, the button will be toggled on and your mouse can then be used to click on an entity in one of the viewports, and set the script's field. This will allow you to easily choose the entity you want, without switching any tabs.
     

     
    However, this is being saved for Leadwerks 3.6, due to upcoming events.
     
    The update is available on the beta branch now. Impact to your project should be minimal, but it is possible in the last few beta builds some connections could have been lost.
     
    Thank you all for your feedback, and if in the future a change has a negative impact on your workflow, don't hesitate to let me know.
  19. Josh
    A new update is now available on the beta branch. This is a refinement of the new entity script fields, which rely on the object name, rather than the awkward drag and drop motion that was originally implemented. I've modified the code so that when a map is loaded, any targeted objects will be renamed with a name that is unique in the scene. For example, if two objects named "WaypointA" exist in the scene, and one of them is linked to from another object, the object will be renamed "WaypointA-1".
     
    This even works with copy and paste operations. Let's say you have a platform that travels between two waypoints. If you select the platform and both waypoints, then copy and paste them (or CTRL+drag) the waypoints will be renamed with unique names, so your copied assembly will all work together.
     
    This does not mean that all objects in a map will always have unique names, but that is something that may be implemented in the future.
     
    Your old maps should be usable with no changes. Please let me know how well this design works for you.
  20. Josh

    Beta Update Available

    By Josh,

    The creation of our complete tutorial series, written with the help of Aggror, has had a really good effect because it gives us a specification saying "this is how to use Leadwerks". Instead of having different approaches and opinions scattered around, we can all discuss the user experience and be on the same page. This has led to improved user feedback, as we are able to more easily identify any small hangups or inefficiencies in the workflow. I'd especially like to thank the user Malachi for his thorough reporting as he has gone through the lessons.
     
    An update is now available on the beta branch that includes various fixes and improvements.
     
    The behavior of the file requester on Linux has been improved. I found it sometimes did not start in the correct directory, and improved this behavior.
     
    Right-click zoom in the texture editor is fixed.
     
    The .map file extension will automatically be added in Linux when a file is saved, if it is not specified (although technically this was not a bug, just the way the GTK file requester works).
     
    Some missing files have been added to the tutorials project and the documentation has been brought in sync with the samples.
     
    A bug that could cause the model editor to crash when closing the window and then saving the model has been fixed.
     
    You can now load any image file as a terrain heightmap.
     
    These changes are available now on the beta branch on Steam.
  21. Josh
    In the next beta update, the way entity fields work in the script properties will be a little different. Instead of dragging an object from the scene tree onto the field, you will type in the name of the object (or copy and paste the name from the object's name field). This is being done to make the behavior more intuitive. After working with both approaches, I find the new way much easier to use.
     

     
    This does however mean that an object that is used in this manner must have a unique name, since that is what is used to make the linkage. Additionally, prefab limbs can now have their names changed without breaking the prefab, in order to accommodate this design.
     
    Your existing maps will be unaffected until they are resaved in the editor, but if you have multiple target objects with the same name, your map will need to be updated.
     
    Alos, the texture list in the material editor is being reverted back to its original design, which was a bit more obvious in its presentation and usage.
     

  22. Josh

    What's Next

    By Josh,

    Here's what's next for Leadwerks Game Engine.
     
    Game Launcher
    Leadwerks Game Launcher will be released in early preview mode when 50 games are reached. Right now we have 13. Filling the content up is a high priority, and the Summer Game Tournament will bring us closer to that goal.
     
    I am mentioning this first because I want to emphasize that the number of games posted is my measure of how well I'm doing. Every action should be considered in terms of how it helps you guys publish more games.
     
    Usability Improvements
    Since the learning process for Leadwerks is now very well defined, we're able to identify and improve minor hiccups in the workflow. I'm getting a lot of great feedback here. The tutorials have helped y giving us a common reference point we can use to communicate how things should be done, and what can be improved.
     
    Documentation will continue to be improved as we gain more experience. I am holding off on recording any videos until we get the materialize finalized.
     
    Here are some of the things I want to modify or improve:
    New icon set
    Improve 3D control widget
    Use name in script entity field instead of drag+drop
    World:FindEntity() Lua command
    Revert material editor texture list to old style
    Implement web browser in Linux GUI for welcome page and Workshop.
    Add built-in help window for better documentation layout (will still pull data from online pages)
    Improve project manager and new project window, using web interface.
    Research is being performed on improvements to the script editor.

     
    Game Templates
    The 2D and 3D platformer templates are the easiest to make and are good examples for learning. These will likely come next. A racing game template is fun and simple, and may come after that.
     
    DLC
    A soldier pack would add a lot of new options to gameplay. We saw with the zombie pack that many people were able to use these items in a lot of different ways, and it added a lot of depth to gameplay. I think a soldier pack with characters that can fight against or with the player, or against zombies, each other, etc. would be a great addition.
     
    New Features
    I make decisions on new features based on the following question: What will result in more games? The things I think are important are a vegetation system like Leadwerks 2 had (but better), decals, and some built-in GUI commands. It is likely that the vegetation system will be the next big feature.
     
    Built-in Model Store
    We have some setbacks on this, but we're researching another way to make this happen.
     
    That's quite a lot of different stuff.
     
    As always, any of these items are subject to change.
  23. Josh
    The design of the App table in Lua was originally created to work with mobile, which has a more restricted program flow. The application calls App:Start() once to initialize it, and then will continually call App:Loop() until the function returns false. These two functions are found in the file "Scripts\App.lua".
     
    Since we are focused on the PC now, it does not make sense to keep this structure. It also makes it more confusing to teach scripting. A conventional program layout with one main script is much simpler than having two functions that are called by the interpreter itself. We are going to transition to a conventional program layout in a way that doesn't break compatibility with existing scripts.
     
    First, if you do nothing and keep the App.lua script as it is, your program will continue to work. However, your App.lua file no longer is required to contains the App table, or the two Start() and Loop() functions. If your App.lua file just contains text like this, it will work just fine:

    window = Window:Create() context = Context:Create(window) world = World:Create() local camera = Camera:Create() camera:Move(0,0,-3) local light = DirectionalLight:Create() light:SetRotation(35,35,0) model = Model:Box() model:SetColor(0.0,0.0,1.0) while true do if window:Closed() or window:KeyHit(Key.Escape) then return false end model:Turn(0,Time:GetSpeed(),0) Time:Update() world:Update() world:Render() context:Sync() end
     
    Doesn't that code look simpler?
     
    Second, we are going to introduce a new file called "Main.lua" into the project template, and remove App.lua from the original template. If both App.lua and Main.lua are present, then App.lua will be called. If only Main.lua is present, then it will be used. This means that new projects will use our preferred method of calling Main.lua, but existing projects will be unaffected, even when the project is updated.
     
    All existing code examples in the documentation will continue to work when pasted into App.lua or Main.lua.
     
    TLDR: Changes are coming but it won't affect your existing projects.
  24. Josh
    I'm working to move our Workshop implementation over to the newer SteamUGC API. There were recently some things updated, and that is still being sorted out. I'm also finishing up the game player.
     
    The first incarnation of Leadwerks Game Launcher was pretty utilitarian (and ugly):

     
    I realized this was pretty drab for a product aimed at consumers, so I designed a more outlandish colorful interface that was purely web-based:

     
    This one looks nice, but you can tell it will start to feel dated quickly. I'm also concerned about the user's perception of this product. It is meant to be a software application, not a thinly wrapped web page. I'm also sensitive to the danger of this product being associated with garbage like this, enough so that I decided to get rid of the "Game Player" name and call it something else. The name "Game Launcher" is more closely associated with initialization interfaces like the one used in Amnesia. It's just more of an acceptable PC gaming thing:

     
    My design also took up a lot of space and looked a lot like the iTunes App Store. It is not my goal to build a redundant marketplace within Steam, and that is what this looks like.
     
    So with that in mind, I came up with a third design that makes better use of the GUI and minimizes the web elements:
     

     

     
    The buttons in the left-hand lower corner are unicode characters, interestingly.
  25. Josh
    A new update is now available on the beta branch. This completes our migration to the newer SteamUGC system for Workshop content. Downloads should be working reliably now, but please let me know if you experience any trouble.
     
    Steam protocol calls are now supported on Linux. Most notably, the Steam interface will open the Workshop now, instead of it opening in a web page.
     
    An extra color option for the perspective viewport has been added, as well as several new color schemes. Select the Tools > Options menu, then the Colors tab, and press the Load button to see them all.
     
    Leadwerks Game Player has also been updated and should work reliably.
     
    (Build 611789 was updated to 620411.)
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...