Irrlict
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.
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:
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'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.
0
Sign in to follow this
Followers
0
7 Comments
Recommended Comments
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 accountSign in
Already have an account? Sign in here.
Sign In Now