Jump to content
  • Advertisement
  • entries
    437
  • comments
    1000
  • views
    337276

Irrlict

Sign in to follow this  
evolutional

196 views

Irrlicht

After the last journal post I decided to download a copy of Irrlicht v0.9. All I can say is that it's matured a lot since version 0.6 or whatever the version I tried was. I approached it with open eyes, willing to give it a try and I am actually pretty impressed.

For starters, it does things in pretty much the way that I was doing things previously, except I was coding it all myself; sure, I passed out the windowing to SDL but the rest was all hand coded. It took me several months and I wasn't even anywhere near the current state that Irrlicht is in which is pretty cool.

From the first view it should be very useful to budding game programmers. The examples all use the engine in a very procedural way, but I'm going to structure it into my already familiar object oriented way of working. I created a very basic framework and had Irrlicht running, showing one of my models and responding to my key presses within half an hour of reading the tutorials.

If you're writing an Engine because you think it's the way you have to go about making a game, just STOP where you are and wrap your code around Irrlicht instead. It handles a fair amount of useful stuff:

  • File IO
  • Archive IO (zip/pak)
  • XML parsing
  • Model loading
  • Texture loading
  • Scene graph
  • Built-in GUI system
  • Event system
  • Particle systems
  • Terrain rendering
  • Various camera modes
  • Path following and animation
  • View culling systems
  • Plus a whole crap load of other stuff

    If you sit and think about how long it'd take you to implement all that stuff yourself you'll realise that you're saving yourself months of hard work. As it stands, I'm going to be spending that time bolstering the existing engine with stuff that I'm going to be needing:

  • Engine wrapper
  • Scripting system
  • AI
  • Expanding the event system
  • Game logic
  • Sound system
  • Possibly networking
  • Possibly physics

    Let's look at these extra components; at least 4 of these can be obtained from integrating third party libraries into the existing code and the Irrlicht site has examples of building in physics. The main brunt of the work is now concentrated on writing the game engine and not that core 'engine'. By 'game engine' I mean the layer that sits on top of these third party components and lets them work together. This layer is responsible for managing the loaded sounds, textures, game settings and all that normal application jazz. I typically built this layer on top of my past engines, so after a couple of weeks of integration work I'm expecting to be able to build the game logic and work almost soley on a game.

    Talk about accelerated development >_<

    Reasoning

    After the various discussions I've had around the boards, I do completely acknoledge that people will still continue building engines. I'll admit that I enjoyed it a lot in the past, but at the same time I also grew frustrated by it. If you're in it for the learning experience or for the pleasure of building an engine then please go ahead. Like superpig said in his journal once, sometimes there will be the need for a revolutionary technology and hence an engine to sit behind it. The number of people achieving this revolution is in the minority, most people seem to be reinventing systems - perhaps unwillingly. If this technology can be componentised then it should theoretically be capable of being integrated into an existing engine setup.

    One of the major points I have had pushed upon me from various sources is that technology should ideally be reusable; with this in mind, it should be the responsibility of these engine designers and engine enhancers to take note of this and make it simple to use their systems with third party components. In my ideal world, you'd have the hardcore engine designers and coders, the component writers (creating generic components for consumption) and the engine consumers (the people actually making the games). The engine designers and component coders should be wary of how each party works in order to allow integration of these various systems. The engine consumers are the dreamers, the people who want to make the games and will utilise various combinations of these engines and components to realise their dreams.

    So, with this in mind - if you feel like reinventing the wheel at least allow someone the option to change the tyres somewhere down the line. If you're someone who likes to make tyres then ensure that they will easily fit on the wheels that we have at our disposal. I know it's probably my 'dream', but I'm hoping that one day other people will want to realise it too.

    I'm going to leave this here for now. I have plenty more to say, as always.



  • Sign in to follow this  


    7 Comments


    Recommended Comments

    Quote:
    After the last journal post I decided to download a copy of Irrlicht v0.9. All I can say is that it's matured a lot since version 0.6 or whatever the version I tried was. I approached it with open eyes, willing to give it a try and I am actually pretty impressed.
    Yes...but can you pronounce it? [smile]

    Quote:
    If you sit and think about how long it'd take you to implement all that stuff yourself you'll realise that you're saving yourself months of hard work. As it stands, I'm going to be spending that time bolstering the existing engine with stuff that I'm going to be needing:
    Let me get this right. You're not going to start working on a game? You're going to build more engine code? I thought the whole point was to not waste time making engines and spend more time making games. Maybe you should just find a different engine that already has all of the things you need.

    Share this comment


    Link to comment
    Quote:
    Let me get this right. You're not going to start working on a game? You're going to build more engine code? I thought the whole point was to not waste time making engines and spend more time making games. Maybe you should just find a different engine that already has all of the things you need.


    Well, I'm not working on what I see as being the engine code - I'm working on components that make up the game code and typically, these components differ from game to game (level structures, game entities, etc). You'll notice that I'll using code that is already written where I can and slotting it into the framework to make up the game layer. For example, the 'enhanced' message system I was talking about, I can use code that I've written in the past, or even just take the basic class from the post that Drew Benton has made recently. If I was using a BASIC language, PyGame, or whatever I'd still need to build up this game layer as it's code that is specific to the game being made.

    My point is that by taking an existing core engine yo ucan bolster it with third party middleware components and have to only write the basic game layer in order to create your game. As I'm starting from a much higher base there is a good chance I'll progress further with my game rather than get tied down to detail at the engine core level. Working with components like these also entitles you to free upgrades when the author releases them, you are effectively simulating a working studio environment as a game coder working on the game code. For me I perceive that this will be highly beneficial and I am hoping that someone else at least realises this point, even if they don't effectivley put it in place themselves.

    Share this comment


    Link to comment
    Quote:
    For me I perceive that this will be highly beneficial and I am hoping that someone else at least realises this point, even if they don't effectivley put it in place themselves.
    I just meant that since you have decided to take the middleware approach (which seems to be the sensible one) you might want to look for another solution that encapsulates more of the components you desire to produce the intended result. This would mean having to integrate less components (say if the scripting and physics were already in) and less updates when the publishers release them. I realize what it is that you are doing and I'm just trying to help you see that there may be an even higher point that you could start from since you've decided to take this route. As to whether it will actually be beneficial to you depends on whether or not you achieve the before mentioned intended result.

    Share this comment


    Link to comment
    Indeed, I fully understand that =)

    At present such a market does seem slightly immature in terms of the number of solutions to choose from. Crystalspace, OGRE and Irrlicht (yes, I can pronounce it [grin]) are essentially graphics engines that are taking on filehandling, event management, GUI systems and platform IO. They're not 'complete' solutions at present, meaning we'd need to add on more third party components. The only real mainstream competitor to these seems to be Torque, which is out of my price league at present. Torque is a 'complete' toolset ready for games from the outset. There will be a few more out there, but they're not that well publicised, probably because of the 'roll your own' strategy that people often take.

    What I'm really waiting for is for people on GDNet to release their (complete) engines and allow others to become the engine consumers. Let's face it, there are a lot of people who have invested a lot of time in their own technologies but never really get off the ground with a game. At the same time we have people not capable or not interested in making an engine and want to make a game but don't know where to go. I'm taking a middleground, but I'm hoping that in the future we'll see much more of the crossing of the lines between the two camps.

    Share this comment


    Link to comment
    Quote:
    What I'm really waiting for is for people on GDNet to release their (complete) engines and allow others to become the engine consumers.
    You will be happy to know that I intend to release a public version of my engine. However, it will not be a complete solution for some time, maybe never. Also, because it's my personal toolset, it may only be a useful solution for me.
    Quote:
    Let's face it, there are a lot of people who have invested a lot of time in their own technologies but never really get off the ground with a game.
    I'm sure there are. Personally I manage to make engines and also make unique games with them from time to time. So the split between the two "camps" doesn't seem as obvious to me as it may to others. But I'm sure it's there. It takes a lot of commitment to do both.
    Quote:
    The only real mainstream competitor to these seems to be Torque, which is out of my price league at present.
    That's too bad. It looks like a nice solution. That's sort of what I had in mind. I guess you're probably on the right track then. I played around with Irrlict a while back and was impressed with what it had to offer and the community support around it.

    Best of luck and post some screens when you can.

    Share this comment


    Link to comment
    Quote:
    If you're writing an Engine because you think it's the way you have to go about making a game, just STOP where you are and wrap your code around Irrlicht instead. It handles a fair amount of useful stuff:


    But where's the fun in that?! [wink] Anyways, what genres of games would you think that could benefit most from using this engine? Just form what you have seen. I have not yet gave this engine a try out, because I want to make my own, cliche, I know, but still. [smile]

    Share this comment


    Link to comment
    Given that it appears (so far) pretty simple to extend the engine with custom node types, I'd say with a little finessing it could handle just about any type of game using a 3D approach. Probably wouldn't be too hard to do 2D games as well, though I'd have to lodge that firmly in the 'overkill' department. You see a lot of screenshots demoing the engine using a first person perspective, but that's just a matter of camera handling and I can't see how it would be any more difficult to implement an overhead camera for an RTS, a 3rd person following camera, etc...

    I'm still fiddling with the engine myself, though, so I'll need a little more work to be sure. So far it looks good though.

    Share this comment


    Link to comment

    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now
    • Advertisement
    ×

    Important Information

    By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

    We are the game development community.

    Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

    Sign me up!