achrystie

So I bought Leadwerks 3.0 early on, back in May of 2013. It was pretty bare bones, relatively buggy, and quite frankly ran like ****. Since then there was the Kickstarter, then the whole Steam release without C++, then an upgrade on this site that was priced well above the Steam version or the KS version, then it wasn't clear there was even an update available that supported C++. Now there is NO storefront on this site to upgrade my copy, at all. I've essentially ignored/waited rather than buy anything else because I didn't want to get burned again on a price that might change drastically a few months later while Josh decided that his $1000+ engine was a $200 engine that charged for point upgrades, but is now a $66 Steam release with free point updates? Paid? Who knows... Can I ask what the deal is? It would seem I purchased, early on, in good faith, at a higher price, at the worst time possible time, and now have a completely obsolete product that doesn't have a storefront or upgrade path. If I had waited for the Kickstarter, or the Steam release (had I known it was even coming), I would have spent far less and had an actual upgrade path as well as the various benefits the Steam version brings. Is it basically that there is no Leadwerks storefront anymore and people are expected to "rebuy" the engine on Steam to get any sort of product updates or is there a way to convert my license to the Steam Standard version? Can someone clarify what I spent my money on two years ago and how, if I choose to, I'd actually make that purchase into something again?

Well, it's hard to say how many LW 2 license have been sold since it was created, but if we estimate thousands, based on forum members, Josh probably figures he only needs to push a few hundred at the new price point to make the same total, if he sells more, that's just money to add people with or take in profit. 5000 license at $200 each is equivalent to 333 licenses at $3000 each. So really it just comes down to finding 333 small indie teams, or individuals/hobbyists with more money than sense, to buy it, which is probably conceivable. I just know I won't be one of them. What's interesting is the $999 price for Windows/Mac only. There are literally TONS of other engines, both free and much cheaper, with similar or even better features, many of which are quite easy to use, that can generate an executable for Win/Mac, and even Linux in some cases. Hell you can get better lighting and shading, physics, logic bricks, scripting, C++ capability, and a FULL set of 3d content tools in Blender, for free, and output a pretty decent looking game from Blender using default game engine, as well as OgreKit, to produce the final executable. In fact you can even get the Ogrekit plugin to run on iOS. Not to mention the free Torque 3d license, Shiva, Unity Free, C4, etc. The Win/Mac of LW3 is literally NOT competitive IMHO, no matter how nice the API or Flowgraph are, and no CSG modeling or pipeline tools will ever equate to a full 3D modeling/bone/animation system built right into the tool. However, as I said, my opinion doesn't matter, particularly if there are a few hundred people out there willing to pay this amount, for whatever reason. Given how many people there are out there making games, it wouldn't surprise me if Josh can drudge up a few hundred customers, and that's probably enough.

Looks good. I'd like to see the following to make the search as useful as possible by creating references with as many similar terms as possible. One thing I find the hardest to deal with in new programs and/or code libraries, is knowing what I want to do, but not knowing what word(s) to search for to find it. As an example. You're calling them CSG primitives created in the 3D view "brushes", or maybe it's a brush that draws them. Either way, if I was relatively new to the program and/or CSG modeling tools, I wouldn't know this, but I would know what a 3D shape, or a primitive, or a polyhedron was from basic geometry. So..having results come up for multiple keyword searches, is, IMHO a key feature of good documentation. Another good approach is being able to sort things in multiple ways, such as, what it does (physics, rendering, etc.), and alphabetically, and by it's class/code hierarchy if it's code. The second thing I'd ask for is that the API reference have decent descriptions of what things do, what the parameters and returns are, and at least one small code snippet to demonstrate basic use. It drives me bananas when the docs are just some doxygen dump, filled with programmer pseudo descriptions that often just repeat the name of the class or function.

Well, I would think that having one script per entity wouldn't be such a bad thing if there is a way to hierarchically parent one entity to another entity. Is that possible? Also, it seems as though you are trying to tackle one of the big problems Unity presents to new users which is, "how do my components talk to each other", with the flow graph? Which is good, but I don't know if that is worthwhile if there is some major tradeoff associated with it that makes everything else more difficult to create/understand. Parsing the code examples you've posted has helped, but is there a way that you can create a higher level schematic diagram and description of how things will "work" at the entity level and from entity to entity, and how things run in the game loop with some sort of update, fixed update, startup, onload functions? In other words, I'd like some idea of how I'm going to piece everything together in a understandable way, while still having my entity scripts (components) as compartmentalized and specific as possible, and how those things will actually run in the engine. For instance, if I have something that has a set of animations on the 3d model, and should interact with the in built physics, and needs to be controlled by the player with keyboard/controller input, and needs to do some sort of raycasting, and has to track or change data (health bar or something), is that all written in one script, with it's own load/create/game loop functions, and just the outputs and inputs are fed through the flow graph to whatever is external to that entity and needs to see the changes? What does that even look like from a flow/functionality standpoint?

Congratulations on finding a closet to stuff yourself in. I'll expect a MASSIVE increase in productivity as a result.

Well, iTunes, is a brand name, which is quite ubiquitous, and forum categories are not. Honestly the software iTunes is a horrible example IMHO of organization. I actually "do" have trouble finding things in iTunes because the movies and the music aren't separated in a very efficient way. I understand the need to have less forum categories, and in particular sub categories. I completely agree, but lumping music/sound with graphics doesn't make ANY sense to me.

The problem is, the categories still aren't "catchy" and are still generic. If you want to go the iTunes route, you should think up a neutral catchy name for each category, such as: Lead:Code, or LeadCode. Lead:Art or LeadArt. etc. Right now it's non catchy names that "also" don't make sense for all the items that would be placed in that category.

See I don't think that has to do with the amount of programmers they have, I think it has to do with the amount of processes they put in place to reduce the risk of someone releasing code that screws their program up. When they had 100 customers they could afford to screw up. When they have 100,000 customers, screw ups cost you more as it kills your reputation. They probably have to do change controls, then 3 people have to approve, a code check has to happen, then instead of making new releases every day they wait and package them together because nothing pisses people off more than having updates every single day because changes are it'll break something for you. These things are what you do when you are a big company to reduce risk and what you don't have to do when you aren't. That has nothing to do with the amount of programmers you have. The number of programmers you have, assuming your statement to be true, which I agree it probably is, directly affects the number of potential errors there can be, and lead programmers ability to watchdog, those issues. Many hands, often spoils the soup, and the rate at which you can cook more soup does not increase linearly with the number of pots, stoves, and cooks, particularly if you have to make sure the soup is just as good, and tastes the same, in every pot, which inevitably has to be done by one master chef or a master and a very select number of understudies. Another way to say it is, I think you are right, but it is a contributing factor, and what you are saying is compounded by the number or programmers, and is not an either/or counter to what Josh is saying.

I agree completely, and have experienced this myself when I was doing engineering. You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit (but probably not as badly as some because I think they do a good job at hiring people), and in many cases they've just bought in or licensed tech instead (beast, umbra, etc.). The only way that large companies can stay really efficient is if they have a real brainchild managing the project who can layout every system ahead of time and delegate work to a bunch of really good "day to day" single task coders. People who can do that are few and far between.

Well, one step forward, two steps back they say. Regardless, a good game is a good game, advanced technology or not. Thanks for the information on mobile, I certainly have interest, but I think without a timeline to go on it's hard to commit.

Hmm, so if I get this straight, if I decide to use the assets I've been making to code the game in Leadwerks 2.43 in Lua, instead of Unity, I can submit the game to you when it is close to/finished, and you'll work with me/us to get it running on iPhone in whatever form Leadwerks 3.0 is at the time? Assuming that is true, my two questions would be: 1) How soon, theoretically, could this be launched? My goal is, I want to be submitting to the app store in November. 2) Can you make a list of the features in Leadwerks 2.43 that we should stay away from, that would make the port too difficult in a shorter timeframe and/or won't be available on iPhone?

Well, I think it's pretty cool. I haven't used Fortran since 1995 or so, in college. That was my second language after Basic, (which I taught myself when I was about 11), but I learned Pascal around that time too as it was a combined course for engineering use. Fortran is a great language. It's actually used a LOT more than people think, it just hasn't been used much for things that the majority of people talk about. Very few people sit around in awe of CFD, FEA and actuarial analysis, so no one really thinks it's useful. In other words, it's not usually used for games, or commercial software development because, up until recently, it's been relatively limited by its non object orientated nature, and once people grab hold of something (C++) or a big company is promoting something (C# and VBA), a lot of other things get overlooked. However, with a lot of object oriented features added in the 2003 and refined in the 2008 spec, and some additional stuff for parallel processing (which is hitting its stride now), it's certainly a viable choice and even optimal in some instances. The one thing I"m unsure of is complete implementation of the 2003 or 2008 standards on these free compilers (or paid ones for that matter form Intel or other companies, which cost a pretty penny btw). As far as I'm aware, none of them FULLY support the newer standards. I'll look forward to seeing your progress with it and finding out if there are any hitches. Good luck with it.

Ok, some questions. 1) Is the LUA code for your relay attached to/reside within the specific node in the flowgraph called relay, so I can just double click that and it opens up my code IDE so I can edit it? 2) You have a second set of code that shows creating the relay and making it an actor, where does this code reside? Is it automatically created if I make an object (probably a null) in the scene editor called relay and assign some parameter to it to make it an actor, or is it created when I decide to add it as a node in the flowgraph, or am I writing a separate code file somewhere to create this thing and make it an actor? 3) Along similar lines, where does the code to create the button and the door reside, in a separate file, in/attached to each node that is made, or is it just a parameter I can flag for those object inside the Leadwerks scene editor for the physical models I've loaded that are a "door" and a "button" in that given scene? 4) Are there event functions inside the button.lua file and the door.lua file that is attached to the button node as well, like actor.Start(), etc.? 5) Is each node shareable as a file type, so we have some sort of flowgraph node repository on the site here that people can tap into? 6) Can I package the whole flowgraph up into a node of its own and reuse it, or share it? 7) Can I track and adjust the variable changes in the flowgraph and can I at least temporarily tweak constant values somewhere while the game is running? To put it more simply, can I expose the delay on the relay to the editor and change the value based on my observation as the game runs and I click the button in game? In general I think this is a good idea, and if you read other forums, how objects communicate with each other/pass variables, has been a sticking point for people in the past who are just starting out trying to make a game.