Jump to content

BLaBZ

Members
  • Posts

    135
  • Joined

  • Last visited

Blog Entries posted by BLaBZ

  1. BLaBZ
    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. BLaBZ
    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
    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.
  4. BLaBZ
    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.
  5. BLaBZ
    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!
  6. BLaBZ
    Developing a failure sucks. You spend hundreds, sometimes thousands of hours on a project only to find out that it's a complete flop and nobody wants to use or play it.
     
    As independent game developers we have a unique situation and challenge. Our resources are limited and our conditions are that of extreme uncertainty.
     
    Acquiring certainty of the success of a project by collecting feedback early on is great way to determine whether to continue, change course, or drop the project. You'll waste less time when you know you're heading in the right direction.
     
    Concepts from the book "The Lean Startup" by Eric Ries discuss the rapid iteration process of developing, getting customer feed back, and making forward motion based on the feedback.
     
    It talks about producing a minimally viable product, something not necessarily complete that may have potential bugs and modifying it till you find something that your target audience actually wants.
     
    I love the concept and hope that developers keep this in mind when developing their projects.
  7. BLaBZ
    Time invested into a game doesn't determine it's sales.
     
    This is an important fact to acknowledge if you decide to enter the wonderful world of independent development.
     
    If I had to do things over again I would create a simple game and focus on addicting game play and mechanics.
     
    The real question I've been asking myself these last couple of weeks is what do people buy when it comes to games? And how can I incorporate these into a game the would only take a few months to create.
     
    What's your approach in making an effective independently developed game?
  8. BLaBZ
    While I should be finishing my game and engine a notable epiphany has hit me like a ton of bricks, the kind of epiphany that's worth writing about so the next time you decide to dedicate 3 years of your life to a programming project you don't forget what you learned the time before.
     
    My project has consisted of 3 sub projects - The Engine, the Level Editor, and the IDE.
     
    I've been working on "RTS Creator" for awhile, and it's a full suite of tools to make your own Real Time Strategy game with little to no coding knowledge.
     
    The project is 90% complete but the last 10% seems to be taking the longest, which could have been preventable had I known what I know now.
     
    Having a solid foundation before you begin development can really make development move along much more easily, and the things I would suggest tackling before even beginning development of your game are the following -

    Graphics API\Engine - In this case Leadwerks is a developed and tested solution.
    GUI - Having well tested User Interface api will make life much easier.
    Saving\Loading Mechanism - Writing saving and loading functions can be a huge time consumer. Using Serialization(Or Reflection to create serialization) you don't have to worry about updating your saving and loading functions when you make changes to your game.
    Resource Management - It's not uncommon to change your mind about some of the assets in your game, don't let the removal or addition of a resource create a world of work for you.
    Modular Development\Isolation - Create an architecture that's easy to add\remove functionality. Make the core game framework raise the events you need to for your modules, and make those modules raise their own events. Develop the modules in complete isolation from your game.
    Inheritance\Polymorphism - Make good use of polymorphism but don't overuse. Finding a way to use inheritance for your game that supplements you can make a huge difference.
    Take Your Time - Taking the time to design a good architecture can save you time in the long run. Code smart not fast

     
    These are the things that I've learned over the last 3 years and if I had known to do these things before and well enough I'd probably be done by now.
     
    Happy new years!
    BlaBZ ouT!
  9. BLaBZ
    Since the birth of the internet, web sites have been constructed from HTML(HyperText Markup Language). Displaying web sites was a simple process that consisted of taking data and rendering static information to the users screen.
     
    Things have become much more complicated, with animation, AJAX - a method of getting data from the server without reloading the page, and CSS (how web pages are 'styled'/themed'), yet the method in which these pages are displayed haven't changed but have been expanded. We still use HTML.
     
    As of March 2011 with initial participation from Apple, Google, Mozilla, Opera, and others the Khronos Group released WebGL, which enabled browsers with support for HTML 5 to access a computers GPU(Graphics Processing Unit).
     
    What does this mean exactly?
    It means that powerful graphics card in your computer that renders your video games can now be used in a web browser. This is a huge advancement in web presentation that has yet to be fully utilized.
     
    The Problem and the Opportunity:
    WebGL is based off of OpenGL and is an API to make low level graphics calls. There isn't a framework that exists yet to simplify these calls and support web like presentation abilities.
     
    Imagine if facebook or google had the ability to present information in a 3d world with any effect you can think of or imagine.
     
    If you've ever tried to "style" a web page you know how tedious it can be just to add rounded corners to a box or to get something to look a particular way. It's difficult and imprecise.
     
    A good exmple of what's possible can be seen here:
    http://www.ambiera.c...yard&mode=webgl
     
    If I wasn't working on my game engine I'd be all over this.
  10. BLaBZ
    Approximately 3 years ago I quite my job out of frustration and began a project I didn't realize would consume almost 3 years of my life.
     
    A lot has happened in the last 3 years including acquiring a new job and getting my hands on LE.
     
    40,000 lines of code later I'm finally coming close to finishing this project.
     
    This has been an incredible learning experience in the world of OOP and OpenGL and even helped me to land my first programming job.
     
    From learning, to dedication and determination, I could not be more ecstatic about my first business venture and intellectual property.
     
    This has been a dream of mine and seeing everything come to fruition couldn't have me happier.
     
    I'm planning on releasing the full software December 1st, which I think is a doable date. It wasn't made with LE unfortunately, and I'm not sure I'd be able to release a software like this considering the legalities and the support for scripting included in the RTS Creator engine.
     
    Feel free to checkout the website! (Inspired by Leadwerks decision to go with IP Board)
     
    http://www.infotread.com/rtscreator/index.php?/page/rts_creator.html
  11. BLaBZ
    I had this thought today about Leadwerks and its origination, and the company that wrote the language the original Leadwerks was developed in (BlitzMax, Blitz Research Limited) and how Leadwerks and Blitz Research limited started in similar places, took unique approaches yet have similar goals in their products, being cross platform compatibility.
     
    Blitz Research Ltd developed Blitz3D, which was one of the first languages/libraries to have a well working standardized set of 3D commands. Later on Blitz developed BlitzMAX, in which Leadwerks 1 and 2 was developed.
     
    Leadwerks has a very similar command set to Blitz3D plus many more functions to take advantage(with simplicity) of newer technologies such as shading and physics.
     
    I believe the biggest feature and hurdle for Leadwerks 3 is targeting all platforms, which is similar to what Blitz Research's "Monkey" also focuses on.
     
    With Monkey you code once and can deploy your code in multiple languages, which makes me wonder...
     
    Does Leadwerks have multiple code bases for each platform?
    Would Leadwerks be able to produce Leadwerks 3 more quickly if developed with Monkey?
  12. BLaBZ
    As a game developer and programmer one of the most frustrating things can be choosing a game engine or graphics library.
     
    It seems this day and age there's a library of options but non of them seem to fit the bill. What am I looking for when I assess a graphics library/game engine?
     
    Compatibility - I want my product to be as usable as possible and reach as large of an audience as possible. I want to see my game on PC, PS3, XBOX, PSVita, Android and iOS.
     
    Flexibility - If you're lucky enough to find an engine that works on all platforms you're typically restricted to the language of that platform, it's great programming in c# for PC but now I have to convert that C for my iOS.
     
    Features - Shaders. I love shaders. Shaders and artwork seem to make the difference from a game that looks like it was made in 2000 or 2012.
     
    This is where I know it becomes a far fetched fairy tale....
     
    Openness - If something doesn't work right, fast enough, or is missing I want to be able to go inside and change the source code to get it right.
     
    I haven't yet been able to find a library that meets the compatibility or flexibility I'm looking for let alone the features.
     
    I'm crossing my fingers that Leadwerks is it.
  13. BLaBZ
    If you're not familiar with the Pareto Principle than you may have heard it referred to as the 80 / 20 principle.
     
    The Pareto Principle states that roughly 80% of the effects come from 20% of the causes. This is a pattern that can be seen in many places such as income, sales, wealth, etc.
     
    I've continually found this principle to take effect in my game development projects. Once I'm about 80% complete the effort to push forward seems to be just that much more.
     
    Continually inspiring myself to create this project seems to be half the battle.
     
    If you're feeling out of juice, what helps you to become re inspired and motivated?
  14. BLaBZ
    For every project, a coder is ultimately caught between 2 opposing ends of the spectrum. The first end is the goal, the purpose for developing the software. The other end is how the machine implements the code. I'm realizing that through development, we're trying to produce code with a balance between efficient implementation, readability, and of course the ability to accomplish the task it was designed to do.
     
    You could say the most efficient implementations would always be written in some sort Assembly language, though this doesn't necessarily promote readability, and in todays fast paced world isn't always ideal. Good OOP techniques can improve readability though hinder performance.
     
    As a programmer, one of my inspirations for coding is the challenge to produce "perfect" code, clean, readable, and executes seamlessly.
     
    I've noticed as my projects have become bigger this has become more of a design challenge then anything. I've had to think long and hard as to how to make a larger project truly modular and completely decoupled.
     
    I'm definitely no pro yet, but I've learned a lot in the last week. I've known about casting, pointers, inheritance, and polymorphism for the longest time though this week things definitely "clicked" into place as to how these things fit into the design picture.
     
    Because of this, coding has taken on a new life
  15. BLaBZ
    So I'm the guy who writes 7k lines of code only to find out that "I'm doing it wrong." If you haven't been there then you probably haven't learned much.
     
    This is going to make me sound like a complete idiot, but damn! I really feel like one. After coding as a hobby for 3 years I'm finding out now I never really knew how OOP worked and how fantastically useful inheritance and polymorphism really is.
     
    It seems like everyday I'm learning something new about programming, languages have so much flexibility it's really just a matter of being aware of what it's capable of.
     
    I love programming and I'd really like to do it professionally some day, but it seems like I'm constantly learning new things that are essential to programming.
     
    How do you know when you've "conquered" a language and are ready to use it "professionally?"
  16. BLaBZ
    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.
  17. BLaBZ
    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)
  18. BLaBZ
    I have a bunch of books on coding that I like to approach slowly. Everyday I read a section or two from a book and let the idea's resonate so I can really understand them and see where they're applicable in my own work.
     
    The latest book I'm reading is "The Pragmatic Programmer" by Andrew Hunt and David Thomas. It's a book full of concepts and ideas to make you a better programmer. One of the things they discuss is a principle called "Don't Repeat Yourself" or DRY.
     
    When I initially read this chapter I thought "Hey! Of course! That makes sense, I'm sure this concept will be quite applicable." What I didn't realize was that as I continued to code, more and more of that code could be reused if I made it possible to change just a couple variables.
     
    So to make that code reusable, I simply put it in a function/method in the parent class.
     
    It sounds simple right?! Maybe for the more experienced programmer. I've found noticing you're repeating yourself isn't always evident because you may not be repeating yourself EXACTLY.
     
    It seems like the better I get at coding the funner it is. I love finding new ways to make programming complex tasks simple.
×
×
  • Create New...