Jump to content

BLaBZ

Members
  • Posts

    135
  • Joined

  • Last visited

Everything posted by BLaBZ

  1. BLaBZ

    The Magic Bullet

    It's been 15 days since the official launch of my first software and so far it has been an incredible learning experience. You can't predict the future, but you can learn from your mistakes, and with that I'd like to share my number one discovery. When your product releases it reaches a number of unique people who each have a unique age, position and disposition of your product. There will always be a myriad number of reasons a person might want your game or product but it's rare that this has been their dream product or something they've been following for awhile. What I've discovered is that the users who have purchased and taken their time to understand the product are the users that have always wanted a product like this or dreamed of the results they could create through using this product. There is an educational curve that, unfortunately, surpasses the attention span of the average downloader curious about the product. The lack of instant gratification deters a trial user from moving any further into discovering the products capabilities. It's a lost opportunity. What's obviously essential in creating games is finding that perfect combination that keeps players interested and hooked. They play for hours on end and can't help but tell their friends about it. Then you have a game that's becoming viral. I never thought to truly apply this concept to software. To me, software development has always been about creating a useful tool to solve a particular problem. Designing a software in terms of instant user gratification has always been an afterthought. The lesson: Most users want a magic bullet that gives them instant gratification, do you best to give it to them. -Ben
  2. In the midst of my late night insomnia set on by inspiration and excitement, I read the talk “AI is possible .. but AI won't happen: The future of Artificial Intelligence” by Mark Humphrys. http://computing.dcu.ie/~humphrys/newsci.html This is a great read for someone interested in the current state of AI. It’s far less impressive than someone might hope, but far more realistic. In summary, when computers were invented people generally believed we had the tools to create brilliant artificial intelligence. What we misperceived was that the simpler things, such as walking and spatial navigation, have proven more difficult to create then an unbeatable chess AI. If we can create AI that has the ability to perform fundamental tasks, like that of a toddler, it may provide the foundation for the advanced AI we so often imagine in movies. Why I believe this is such a great read for game and software developers as well as technologist is that it also identifies the large gap between where we are today and where we’re going to be when we have true AI, which the author believes will be another one to two centuries. If you take the time to creatively imagine what technology might need to be in place to produce true AI you could see there’s a huge opportunity for innovation. New software’s are abstracting and automating processes that were once difficult, Leadwerks is an example of a tool that now makes tens of thousands of lines of code easily usable and accessible. As we continue to abstract and automate more complex things, we become that much closer to creating a learning machine. The point I’m ultimately trying to make, is there’s a lot of opportunity for innovation if you can see the sky, and one of the highest goals we can hope to achieve is true AI.
  3. BLaBZ

    Inspire your Players

    A focus that's received a lot of attention in the world of productivity has been motivation. What motivates people and how people are motivated in turn results in all of the worlds output. By boiling down motivation we can separate all types of motivation into 2 separate and opposing psychological sources. "Away from" motivation are ideas and situations a person is trying to avoid. For example, you don't have a job, you're running out of money and you're unsure how you're going to continue to put food on the table. The fear of not surviving motivates you to get a job and ensure your survival. You're trying to get away from the idea of not being able to survive. "Toward" motivation consist of ideas and situations you're trying to attain. If you have a game or software, and distinct vision that inspires your motivation, every time you work to attain this vision you're working towards an idea. What I've found fundamentally instructive about these distinctions is the quality of output based upon the inspiration for our motivation. Another word choice for these opposing forces could be "Fear" versus "Inspiration." RTS Creator was founded on Inspiration from day 1. Every day before I put code into the machine, I take the time to recognize what I'm doing and why I'm doing it. What's the vision for this software, why is this vision great? How do I want people to feel when they're using this software? The feelings and ideas I get from asking these questions fuels excitement, and motivation. I want to enable people to bring their ideas to life, to get excited about the new possibilities that are now at their finger tips; to experience the awesomeness of making a world of war that consists of factions and armies of their own imagination. This is the inspiration RTS Creator was founded upon and I hope to inspire that same inspiration in the users of RTS Creator.
  4. This is great news! I haven't used Noesis, but based on everything I've seen it looks like you guys are on your way to becoming the Gold standard in game UI. Great work and wish the best for you guys!
  5. BLaBZ

    Refocusing on the PC

    A quite insightful post. I wonder if this was largely due in part to the fact that Leadwerks was Greenlit which the user base primarily consist of PC users. Discontinuing mobile sounds like it's ultimately good news. You have momentum in a particular direction and now it's all about feeding that momentum. If you can dominate the PC indie game dev market segment it will then be easy to bleed into other market segments, when it could become profitable to support mobile. Impressive stuff Josh!
  6. From what I've experienced there's a huge performance boost by both not supporting prior OpenGL versions and the newer OpenGL api. Not supporting legacy means no structuring or checking for mitigation, +1 for performance. The newer api reduces latency and communication between the app and the gpu +1 for performance.
  7. BLaBZ

    Leadwerks 3.1

    Great work Josh! I'm sure there's a very rewarding feeling finally getting to use Leadwerks for its intended purpose. What are the limitations of Leadwerks for steam vs the kick starter backers? Looking forward to playing the demo
  8. BLaBZ

    Dynamic properties!

    You could serialize your game data as well. There are a lot of benefits to this technique.
  9. BLaBZ

    Dynamic properties!

    This would give you the ability to reflect! Could come in fantastically handy if you ever wanted to wrap a GUI around your engine to make edits.
  10. There have been a lot of lessons learned now that I’m finishing my first large project. RTS games continually push the limit on unit and structure counts and with the latest OpenGL features I would argue it’s now possible to have hundreds of thousands of units. The strategy is simple, the implementation can get tricky. Keep all movement and calculations on the GPU and use textures as data structures (optional). The concept borrows a similar idea of a lot of modern particle systems in that each unit is treated like a particle. The limitation is communication between units. An example would be one unit firing upon another or a unit searching for the nearest unit. This can be timely and may require multiple draw commands or shader logic updates. A rough high level overview looks something like this – Create the following textures to represent the corresponding data. CurrentPosition CurrentRotation CurrentDestination Use the textures RGB values to represent xyz and Yaw, Roll, and Pitch. Pass1 update each objects position and rotation to get nearer to the destination and store each units new location in the textures. Use OpenGL’s glDrawElementsInstanced command to draw lots of units very quickly, using gl_InstanceId to represent each units information in the textures. If you strictly plan on deploying to a PC you can disable the Rasterizer in the pipeline, use transform feedback, as well as texture buffers to improve performance even further. Using these technologies can be tricky but exemplifies a strategy for computing mass warfare. My intel laptop with a Passmark benchmark score of 340 can update and render about 50k units. The GTX 780 with a score of 7,952 theoretically could handle 1.1 million units. (Units were pyramids consisting of 4 vertexes, no textures and nothing else drawn or updated)
  11. BLaBZ

    Stretched Thin

    How many simultaneous projects can you manage until your productivity begins to drop? This has been inspired from my own decisions and mistakes of over dedicating myself to numerous projects ending up ultimately being very unproductive. If I have 4 projects and I split my available time evenly across these 4 projects the productivity is not split evenly. Additional time is taken closing previous projects and opening and prepping other projects. Will power, state of mind, and vision for each project requires a mental shift when shifting projects. The simple lesson in this experience is dedicate yourself fully to as a few projects as possible for maximum productivity.
  12. As a single developer on a relatively large project that has taken much time to develop, the progression of technology can prove to be quite an enemy. 4 years ago the technology considered cutting edge is now legacy and the dependence on such technology can prove to be quite a headache when attempting to upgrade. A common practice when the underlying implementation of particular technology is expected to change is to create interfaces that act as contracts all implementations must abide by. This is a phenomenal technique if you want your "engine" to withstand the test of time. If your project scale is fairly large and you plan on upgrading from Leadwerks 3 to Leadwerks 4 in the future I highly suggest doing this. I didn't start with Leadwerks, but if I implemented contracts my game would currently use Leadwerks. The ultimate point is if you want your code to stand the test of time write it in a way that anticipates technological change.
  13. BLaBZ

    Linux Graphics

    lol this guy...
  14. Coincidentally I was just building a pc for the first time in 2 years yesterday. I last built my pc 3 years ago, and while the benchmarks are still relatively good by today standards support for the latest OpenGL drivers is no longer available and I'm stuck at v3 I'm also hesitant about the assumption that more cores means better performance. Not all games\applications take advantage of all cores, and you'll always have you main thread managing the rest. But at the same time, a lot of modern games are far more GPU intensive then they are CPU intensive. Are you using a SSD hard drive?
  15. BLaBZ

    A Red Letter Day

    I love the idea of SteamOS taking a punch at the traditional "console" market but I fail to see how this is truly "better" than using a Computer or and existing Console. It seems like this is basically "Steam on TV." I'm excited about it, but I don't really see it competing with Xbox or Playstation. I feel like only extremist gamers will be using SteamOS. Releasing a console every 6 years is really beneficial for developers and users. Games are highly compatible with the hardware and users will know which games will run on their console. I hate reliving the nightmare of purchasing a video game only to find out your computers specs create ungodly lag and poor graphics. The deferred renderer looks fantastic! And what the heck is a blur kernel? Is that native OpenGL?
  16. We're talking about 2 different things, and I think you're both right. Microsoft changes the DirectX API constantly and attempts to be exclusive by forcing people to use DirectX on Windows machines. Windows to this day only ships with OpenGL v1.1. This is a truly pathetic play in the world of forward motion and is still the only reason DirectX is viable option. If graphics cards only had to support one API things would be much simpler on all fronts. By all means, Leadwerks being developed with OpenGL is obvious decision. On the other hand, the .NET libraries are phenomenal and Microsoft excels when it comes to Organization management ie: Microsoft Server, Active Directory, and the way security almost seamlessly integrates with these systems. If you've ever used LINQ you'd realize you never want to work with datasets in an application without it. Microsoft does somethings great(.NET) and somethings just land in the ****ter (DirectX,Internet Explorer).
  17. Sorry for asking this ignorant question, but how does terrain exist differently from other meshes? I know terrains are usually generated based on a height map and contain the expected vertex and triangle information but how are they rendered in Leadwerks and most game engines vs Meshes? Is the primary difference in how the Camera culls unnecessary triangles? Why are terrains more efficient for landscapes than meshes? Thanks for answering my silly questions
  18. I would say this is easier said than done. I wouldn't do this with expectation that things will just "take off" because it's the only software like this. People need to become aware of it(marketing) and that can take time and dedication. If it's not something you're passionate about or believe in then I wouldn't start, but if you are then you will have no problem dedicating yourself to this. Just because it's a "good idea" without the drive and passion behind it it won't necessarily become or be a success.
  19. Nope. You only have 1 serialize function in which you pass a list of objects that includes everything you want to save. The function then - 1. Uses reflection to determine object composition("has-a" relationships) adds dependent objects to the list then sorts the list from most dependent to least dependent. 2. Using reflection enumerates through each objects properties and saves them(xml or some other format). You also need a deserialize function that then - 1. Reads the xml. 2. Enumerates through each object, and using reflection, instantiates each object and its properties. 3. If you're loading things into video memory as with Leadwerks you would then need to call the appropriate LoadMesh and LoadTexture functions. I'm actually kind of suprised SaveGame and LoadGame aren't functions that already exist in Leadwerks.
  20. Great points Flexman! I'm really glad you mentioned this and this should definitely be on the list. I'm a huge fan of the concept of Test Driven Development (TDD). Unit testing creates a big win for code quality. Writing all your tests before even starting development ensure thorough planning and quality.
  21. 3 Years and 35,000+ lines of code later I can look back and see many things I would of done differently. I started my project more than 3 years ago which was when Leadwerks was at version 2.2x and unfortunately I was in to deep to switch to Leadwerks. My software is a game creation tool that is specific to creating Real Time Strategy games like Command and Conquer and Starcraft. I've learned a few lessons about developing game creation software that if I were to do it again I would not skip any of these. Sharing some of these is almost embarrassing but it shows how far I've come as a developer in the last few years (I started programming 4 years ago). Serialize - It's the simplest, quickest, and lowest maintenance method to save\load projects and game related data. I will never again manually code saving mechanisms. Inheritance - Smart use of inheritance reduces code duplication and can also reduce "spaghetti code" when used wisely. Silly me, I didn't even have a base class for all game objects. Mutators - I cannot emphasize enough the rigorous re factoring caused by not using getters and setters. This makes it a pain if you want to add additional logic when a value is changed and you don't have a setter method. It also makes your application more tightly coupled and difficult to replace classes. Bad me. Bad. Modular Coding - Code each component separate from your game\project! Code your GUI interface in one project, code your gameplay in another then combine. Keep things loosely coupled so it's never to big of a challenge to replace components! Reflection\Metadata - This is more specific to creating tools, but had I known what I know now the main editor would basically have built itself by reading metadata in the game engine module. So much time has been wasted hardcoding how to treat\populate gameobject properties in the editor when all of this could have been controlled by metadata. Interface Contracts - This is more of a "good idea" and Microsoft enterprise application best practice then it is a necessity but I note it anyway. Have an Interface or Abstract class that contains all of the classes required methods. If you later decide to swap out a class you then have all of the methods that class must implement in order for your game not to break. I could of saved a lot of time had I known what I know now! Hope this is useful for you and thanks for reading!
  22. BLaBZ

    Launch Day

    Thank you Josh for making the price feasible!
  23. BLaBZ

    Developing for Success

    not exactly; the post is entirely about that "completely separate consideration"
  24. BLaBZ

    Developing for Success

    @Red I think there's a difference between personal success and business success. I feel successful when I finish a product, but it's not necessarily going to put food on the table.
×
×
  • Create New...