Jump to content

Growing Leadwerks

Josh

964 views

blog-0865846001425325077.jpgAs of this morning, the most recent Steam sale is now complete. The sales figures were excellent and we picked up a lot of new users. Most importantly, we've got a lot of new data on how people behave and what can be done to make them happy.

 

There's three stages a new Leadwerks user goes through to become a happy productive developer. The first is to actually buy the software. The main ingredients here are the demo, website pages describing the benefits of our approach to game development, and the intro video on the Steam store page. Above all, the basic promise of ease of use has to resonate with them. I've learned to not try to convince people who insist they need the most features, the biggest worlds, or want to make an MMO like World of Warcraft but ten times bigger...it's just not worth trying to make them happy. Leadwerks is about ease of use and the right blend of features to make game development fun and enjoyable.

 

Although we've done very well with my home-made video on Steam, and the website looks better than it ever has, the production quality is lacking that intangible extra polish, and it is unlikely I will ever be able to achieve that myself. A revamp of some aspects of the website and store page is being planned, with help from an external firm that specializes in this sort of thing. A slicker sales pitch that focuses more finely on the basic premise of Leadwerks will increase sales dramatically...but additional work is needed to make sure the user experience matches the expectations of new users.

 

The second stage is to learn how to use Leadwerks. This is accomplished with our documentation and tutorials. I think our programming documentation is nearly perfect. The layout is clean, attractive, and there are hundreds of small self-contained examples. The documentation on using the editor needs some updating, as much of it was written for the release of 3.0, and we've changed direction considerably since then. Finally, there is a lack of connection between what commands do and how to turn that into gameplay. I don't think we have to explain how to make every game in the world, but some more game-centric lessons that get into the guts of simple Lua scripting would make things easier.

 

To optimize this process the entire documentation is being revised and designed with a top-down approach. Instead of adding explanations of how to do something here and there, we're designing the entire sequence of learning before any of the material is even written. This will provide a better flow, with a linear sequence of lessons listed on a single page that teach you everything you need to know. This is being done with the help of a third party, and more information will follow.

 

Finally, the last stage, once users own Leadwerks and know how to use it, is product development. This basically boils down to three factors: new features, repair of discovered bugs in existing features, and maintenance of third party technologies (i.e. filing bug reports for drivers problems or the occasional Steam issue). This mostly falls on me, and is what I am most effective at. However, there are plans to accelerate the implementation of a few key features with the help of another party.

 

So basically that's my view of Leadwerks and my plan to gradually start farming out some of the functions that others can do better than me. I'm being vague because a lot of legal and financial stuff is still being solidified. I think this is a good way to grow gradually without too much risk, and you'll see the results of this over the next six months.



1 Comment


Recommended Comments

Thank you for the transparency! I love seeing updates like this.

 

I look forward to seeing these things become a reality. :D

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 0
      I'm back from I/ITSEC. This conference is basically like the military's version of GDC. VR applications built with Leadwerks took up about half of Northrop Grumman's booth. There were many interesting discussions about new technology and I received a very warm reception. I feel very positive about our new technology going forward.

      I am currently reworking the text field widget script to work with our persistent 2D objects. This is long and boring but needs to be done. Not much else to say right now.
    • By Josh in Josh's Dev Blog 4
      Here are some screenshots showing more complex interface items scaled at different resolutions. First, here is the interface at 100% scaling:

      And here is the same interface at the same screen resolution, with the DPI scaling turned up to 150%:

      The code to control this is sort of complex, and I don't care. GUI resolution independence is a complicated thing, so the goal should be to create a system that does what it is supposed to do reliably, not to make complicated things simpler at the expense of functionality.
      function widget:Draw(x,y,width,height) local scale = self.gui:GetScale() self.primitives[1].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) self.primitives[2].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) --Tabs local n local tabpos = 0 for n = 1, #self.items do local tw = self:TabWidth(n) * scale if n * 3 > #self.primitives - 2 then self:AddRect(iVec2(tabpos,0), iVec2(tw, self.tabsize.y * scale), self.bordercolor, false, self.itemcornerradius * scale) self:AddRect(iVec2(tabpos+1,1), iVec2(tw, self.tabsize.y * scale) - iVec2(2 * scale,-1 * scale), self.backgroundcolor, false, self.itemcornerradius * scale) self:AddTextRect(self.items[n].text, iVec2(tabpos,0), iVec2(tw, self.tabsize.y*scale), self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end if self:SelectedItem() == n then self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos, 0) self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) + iVec2(0,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 2].color = self.selectedtabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,-1) self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,0) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,0) else self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) self.primitives[2 + (n - 1) * 3 + 2].color = self.tabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,2) if n == self.hovereditem then self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor else self.primitives[2 + (n - 1) * 3 + 3].color = self.textcolor end self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 3) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,2) end self.primitives[2 + (n - 1) * 3 + 3].text = self.items[n].text tabpos = tabpos + tw - 2 end end  
    • By 💎Yue💎 in Dev Log 5
      The prototype of a four-wheeled vehicle is completed, where the third person player can get on and off the vehicle by pressing the E key.  To move the vehicle either forward or backward, is done with the keys W, and the key S, to brake with the space key.  And the principle is the same as when driving the character, a third person camera goes behind the car orbiting 360 degrees.

      I don't think the vehicle is that bad, but I'm absolutely sure it can be improved.  The idea is that this explorer works with batteries, which eventually run out during the night when there is no sunlight.
      Translated with www.DeepL.com/Translator
       
      Mechanics of the game.
      I'm going to focus on the mechanics of the game, establish starting point (Landing area), after the orbiter accident on Mars where all your companions died, now, to survive, you will have to repair your suit, oxygen runs out, good luck.  This involves replacing the oxygen condenser that is failing and the suit is stuck.

      On the ground and performance.
      The rocks, the terrain and the vehicle kill the SPF, but there is a solution, and everything is related to the chassis of the vehicle. That is to say that if I put a simple collision bucket for the vehicle, the yield recovers, something that does not happen if I put a collider of precise calculation for the car. This has the advantage of better performance but is not very accurate, especially when the car crashes with an object in front, because the horn of the car has no collision. And the solution to this, is to put a sliding joint, as was done with the area in which the player climbs the car and descends from it.


       
      On the rocks, I am trying to make them with the slightest polygons and the most distant from each other. 
      Obviously on Mars I can not create canyons, high mountains, is because the terrain does not produce shadows on itself, that's why the terrain tries to be as flat as possible, simulating a desert with dunes. 

      That's all for now.
       
×
×
  • Create New...