Jump to content

L B

Members
  • Posts

    967
  • Joined

  • Last visited

Blog Comments posted by L B

  1. BLaBZ, this seems like the initial reasoning behind the change. But it doesn't take into consideration a lot of real-world constraints.

     

    Without offering any significant discount (who are we fooling here? 500$ is still one or two months of rent for a lot of indies) or a similar feature-set to its existing niche market, Leadwerks has to rebuild its audience from the ground up. Meaning, unlike the competition, that it has no reputation, no proven testing, and no games made (really, the contest which doesn't even pay for the engine isn't that interesting).

     

    Rebuilding an audience is possible if you have a competitive product at competitive prices. In the price department, Leadwerks 3 falls short: for an independent developer with no backing investor for upfront costs, free alternatives with royalties or publish-time-licensing (Unity, UDK, and even CryEngine now) are the predominant choices. As for the features, the balance doesn't weigh towards the Leadwerks 3 Beta either: no terrain, no networking, no GUI, no high-quality rendering, etc. And most of all, no guarantee that these won't be another paid update.

     

    Let's even pretend that these were free updates -- what guarantee do we have that by the time they are implemented, Leadwerks Inc. won't have gone bankrupt? As demonstrated today, prominent members of the community are in an ongoing exodus, and without investors backing Leadwerks Inc., nothing guarantees that the company will last long enough off meager launch-day sales to provide said updates or lasting support (because remember - we're buying a potentially buggy beta here).

     

    So essentially, the effort Leadwerks is asking its long term customers is to purchase an engine from 4 to 12 times the price of the previous version, with 25% actual rebate, with much less real-world, output features than the previous version, without guarantee of either affordable upgrades, nor even upgrades at all, nor lasting support?

     

    Leadwerks Inc. cannot expect its users to adhere to the venture capitalist, risk-taking mindset without doing it itself. Why would they? After all, indie games on little to no upfront costs have made millions.

     

    (Oh, and this post does not even begin to cover the inexcusable philosophy change of the predominance of business and quick profits for an indie engine).

    • Upvote 5
  2. While I agree that the "command" "pattern" (both in quotations intentionally) is ridiculous, the simple approach of saving every state of the program for each action is lazy (but that's not bad per se) and extremely memory consuming.

     

    What I'd do is have a reverse action for each action, push the action to a stack, and pop the reverse on undo. Tadah.

  3. The alternative to having a memory management system like this is either memory leaks or invalid pointer deletion crashes.

    That's not a fatality. Yes, with people who do not understand how memory management works and do not call delete, this will happen. If you code properly, it won't. In the same spirit, using your newly proposed system will lead to invalid reference count crashes or objects that stay in memory indefinitely when they shouldn't, because people forget to call "IncRefCount" or "Release" or call them too often.

     

     

    Also, why do we have the static Load() and Create() methods again vs using new? I know there was a reason but can't seem to remember.

     

    Constructors are not passable through a DLL for other languages, I think this was the reason. Also, in languages that require class wrapping (Java, C#, etc.), using static classes allowed to have 'Entity::Create' instead of 'Engine::CreateEntity', which is a nice syntactic sugar.

  4. I agree with Rick. It seems counter-intuitive to me to have to call IncRefCount. After all, why would I? I have a texture object, I want to use it, why should I do anything to it first? Similarly, using Release() instead of delete seems just as counter intuitive. Normal C++ would do exactly as in your first example.

     

    I understand you're removing internal classes this way, but for the end user, it's not prettier, not more intuitive, and will actually be a bother in the long run if we have to type this for every object.

     

    In the "source purity" aspect, this has the adverse effect of making me think this wasn't designed for C++, but just patched to work with it.

  5. Procedural content generation truly is the future of indie game development. Not having to worry about artists for your props, level or even characters would give developers a huge boost in base assets, and perhaps help unlock funds with the added credibility for future specific assets in their game or software.

     

    I have a tree generator side project that I develop when I get time off school and other work. Here's a screenshot for the curious: Procedural.png

    • Upvote 1
  6. Great. But let me complain about icons: Use one consistent set! The FatCow one I linked you has a Folder icon, and a Lightbulb icon. If you need other specific ones (e.g. 3D cube), ask an artist for help. I know a good hobbyist for this task, he probably won't charge a lot (<$100 for all your custom FatCow-like icon needs). I know he can work well with that set by experience. PM me if you want the details.

×
×
  • Create New...