IGE - what's bad about it?

[PeterM]

Hello,

The aim of this thread is for me to identify and fix IGE's problems from the perspective of my target audience - the independent game developer.

I've had a few people say "Hey, that looks pretty neat" about IGE, but nobody has said "Hey, I'm definitely going to use this for my next game". I want IGE to be the cross platform solution for indie games, so I need to fix the things which are stopping people from adopting the library.

If I were a customer, the following problems could stop me using IGE:

It's not cross platform yet.
This is true, I'm currently working on the Mac version. This will take time, since I'm new to Macs. I am however experienced with GCC and I'm quick to pick up new APIs, it's just the Mac-isms that stall me. Don't worry about waiting for Mac support before developing your game. It will come, and it'll work fine.
The pricing structure isn't known yet.
Also true, but I don't want to sell an incomplete product. Should I just go ahead and set up the eCommerce side now, or should I wait until I release v1.0? You could easily make and sell an IGE game now.
It doesn't operate in the way I want.
If this is the case for you, please tell me. I want IGE to be your dream library.
I don't want to use IGE's graphics, I want to write my own OpenGL, DirectDraw or Direct3D renderer.
In the next release of IGE, you can do that. I've separated IGE's concept of a Window from its Graphics object. I've also separated out creation of an OpenGL context, so IGE can do that for you if you like.
I can't embed an IGE graphics context inside my level editor, or another app I've written.
You will be able to do this in the next release. Graphics objects are now created by passing a "native window handle", a HWND on Win32.
Having a watermark in the demo version sucks.
I know - it was a stupid idea - and it'll be gone in the next release. I'll be changing the license terms to be much more user friendly too. Basically, there will be no "demo" version. Users will indeed have to "buy" IGE before shipping their game, but technically they will already have the full version. Of course IGE will be free to use for non commercial purposes.

Won't that lose you sales?
Possibly. But I'd rather you were able to use the library more freely, without being annoyed by a tacky watermark. I will also trust you not to release your game without paying!

I don't like the license terms. If you contact me, we can arrange more suitable terms. I want to make sales, so I'd rather compromise and get an extra sale than lose one.
I want the source code. I'm undecided on this. I'd really like to have a source control (SVN or CVS) server on saurusgames.com for people to get the source. But this opens up the possibility that people will snag the source, compile as a static library, and not pay.
I've already got a good library. Don't worry, I won't try to make you switch. I'd like to know why you prefer it over IGE though.
IGE doesn't work with my compiler. This is possible, but I do want it to compile, and I'll endevour to make it work on as many (modern) compilers as possible. I've not run VC6.0 in years, but a friend of mine pointed out that it has a problem with one of IGE's templates. A lot of people still use this old version, so I'll reinstall it and fix the problem for next release. I've also recently made sure that IGE compiles and links using Dev-C++ (MinGW).
It's not proven yet. I want to see IGE powered games in the market before I spend time with it. I'd also love to see this, but it will take time.
That's a fairly big list of issues, so IGE's definitely not without problems for the user. So if you've taken a look at IGE and thought "it's okay, but it's missing X", please tell me what's missing. Or if you've not managed to get it to work with your compiler, please post on the saurusgames forum, or send me a PM or email, so that I can work out a solution.

Thank you for taking the time to read this, and thanks again for any comments you can offer.

Peter

[Rainer Deyke]

Speaking only for myself... It offers nothing compelling. This is by far the biggest problem. Looking at the website, I can find no feature that would make it worth my effort to investigate further. In fact, I can't find any proper feature list at all. What does it actually do?
It's not cross-platform (yet). Before I seriously consider any library, I need it to be available on Windows, Macintosh, and Linux at the very least.
Browsing through the documentation is highly uninspiring. A bunch of general purpose C++ templates that look like they were taken from boost.org, but have been moved into the ige namespace for greater incompatibility. An application class. Do people really still use those?
On the specific subject of font handling: I am currently on the lookout for a good text layout engine. I want it to handle correct character reordering for complex scripts, right-to-left scripts, kerning, context-dependent glyph substitution, and the other basic features of a text layout engine. ige apparently doesn't even offer basic unicode support.

[PeterM]

Thanks for your reply.

Ouch. If the general consensus is like this, then I've got a lot of work to do!

It offers nothing compelling. This is by far the biggest problem. Looking at the website, I can find no feature that would make it worth my effort to investigate further. In fact, I can't find any proper feature list at all. What does it actually do?It's a library for making games, but I'm sure that's obvious. It sounds like I need to add a feature list which outlines the basic components of the library. Does anyone else agree with that?

It's not cross-platform (yet). Before I seriously consider any library, I need to be available on Windows, Macintosh, and Linux at the very least.I will probably not release IGE for Linux, unless someone else does the port. I'd not considered Linux as a commercially viable platform. At least nobody I know of has Linux and buys software for it. But I do realise that many developers use it for programming. Does anyone else think that not having a Linux version is hurting me?

Browsing through the documentation is highly uninspiring.It's documentation, what do you expect? ;-)

Seriously though, is there anything that the docs are lacking? It's sometimes hard to get Doxygen to behave the way you want, but I can easily add more docs if I know what to document.

A bunch of general purpose C++ templates that look like they were taken from boost.org, but have been moved into the ige namespace for greater incompatibility.Two of my classes (IntrusivePtr and SharedPtr) borrow heavily from Boost, but that's it. Of course I don't think it's sensible to reinvent the wheel, but I also didn't want to lengthen the library's install procedure by asking users to build and install the Boost library, which is complex enough. I think that's a good reason to borrow Boost's intrusive_ptr and shared_ptr. IGE and Boost can also coexist without any trouble, so to me it's a non-issue.

An application class. Do people really still use those?Why not? The Application class is there for people who want to get up and running quickly, but like the rest of the library, nobody has to use it. IGE is designed so you can pick and choose the components you want. If you want to build your app from scratch, or add IGE to an existing application, that's fine.

From your previous comments it seems that you didn't really look at the docs for very long, and I don't blame you for that - Doxygen doesn't make pretty docs.

But it does make me think that I need to tell people what the library can do before they wade through the docs. Either that or try to get Doxygen to link to the Modules section on the front page.

On the specific subject of font handling: I am currently on the lookout for a good text layout engine. I want it to handle correct character reordering for complex scripts, right-to-left scripts, kerning, context-dependent glyph substitution, and the other basic features of a text layout engine.This sounds like it's outside of the scope of any game library, not just IGE. Do these features generate enough game sales to make it worth the effort for game developers to implement?

ige apparently doesn't even offer basic unicode support.This is true, and it does bother me. IGE will have Unicode TTF support, but it's not as high up on the todo list as the Mac version. There are also texture handling changes that I need to make before I can support baking strings onto textures.

Thanks again for your reply. I hope my reply has helped somewhat.

Pete

[Jason Colman]

My feeling is that with a product like this you've got to make a lot more effort with the documentation. The documentation is as important as the class library itself.

The class list in the API docs doesn't seem to be sorted in any order at all. I guess this is a doxygen feature but it's no good. It's just a random list of classes.

Sorting the list won't help though. It's not useful information.

Here's what I think. Your job now is to effectively write a book describing how to use your library. It needs to be readable and chock full of examples. You need a quick start guide telling users how they would use your library to get started and get something working within a few minutes. You needs lots of example code where we can change things, recompile and see it working.

Sure the Mac port would help sales I suppose but without decent documentation noone will be interested anyway.

Have you seen the documentation that comes with, say, MFC ? And that's still not enough, there are loads of books about it too (well there were, I guess I'm a bit out of date :) )

I expect the class library is useful enough for plenty of people as it is. But noone will realise if it isn't clearly documented. Remember "Sell the sizzle, not the steak" ? :) The biggest thing on your web site should be a list telling people how they will save time using the lib.

[Savant]

You'll also need some games that are using it. That's part of the sizzle. If I can download some examples of games that people have made using it, I'll be more apt to believe the marketing hype and feature lists. Until then, I have to take your word for it and that's not really very compelling since I don't know you from Adam.

[PeterM]

Thanks for your reply Jason.

You're absolutely right - there are a lot of things about the docs and the website which are just plain bad. They don't teach the user how to use the lib, and the docs are useless unless the user already knows what they're looking for.

What would be the best format for tutorial documentation? I'd love to have a wiki, but I don't want to have to guard it from spam all the time, if that would be a problem.

I will get to work on writing some tutorials. How to install the lib, getting a simple app up and running, and so on. The only documentation of that kind at the moment are the examples in the Doxygen docs, which aren't as visible, or verbose, as I'd like.

I'll also work on the "sizzle" list!

Thanks a lot, you've really helped me out.

[PeterM]

You'll also need some games that are using it. That's part of the sizzle. If I can download some examples of games that people have made using it, I'll be more apt to believe the marketing hype and feature lists. Until then, I have to take your word for it and that's not really very compelling since I don't know you from Adam.This is true. There's an example which comes with the lib which almost resembles a game, but no actual games.

Could anyone suggest a game which could be knocked together quickly to show off the lib? I've got part of a Tetris game done, so I can work on that.

My workload is getting pretty high now, so this isn't going to happen that soon.

Thanks also for your input. I'm finding it very helpful to hear all your comments, swallow my pride and admit that I've got some work to do before people will be leaping to use IGE.

Pete

[baegsi]

The first question for me when I see a new game engine is: why should I use your engine instead of

PTK
T2D
Popcap
Blitzmax
Pygame
<insert one of the other dozens 2D game engines here>

What makes your engine unique? Since you are starting out, it can't be number of proven games, stability, community...

[PeterM]

In the UK it's really rare for a TV ad to say "Our product is better than X", and I think it would be bad form for me to do the same with game libraries. If a library does what you need it to, in a way that you like, then it's a good choice.

I think the best thing for me to do is make IGE an attractive option as possible, document it well, get some decent demos going, and hopefully the user will make the choice to go with IGE.

[Jack Norton]

Two essential things of any engine:
1) cross-platform. TRUE cross-platform, proved, not like "Yes you CAN compile it on MAC OS X.... blabla". Working example and libs.
2) PRODUCTS USING IT. I think that more product you see using that engine, more reliability you have. Having seen Atlantis do so well recently with PTK (while I still have to see good games using T2D) made my decision to keep using it for all my future games :cool:

[Jason Colman]

You don't have to directly slag off any competitors, but you can have a features comparison chart, where you can show that IGE is at least as good as the rest. Of course you need some kind of unique selling point. If it was me I would make it "shortest dev time".

If there are no games currently using IGE I suggest dishing out incentives to some developers. Of course give them IGE for free, but maybe also cold hard cash to get the ball rolling. Just a thought.

[baegsi]

In the UK it's really rare for a TV ad to say "Our product is better than X", and I think it would be bad form for me to do the same with game libraries. If a library does what you need it to, in a way that you like, then it's a good choice.I didn't mean that you should directly compare your engine with other's. However, the question still remains: there're so many other well-established engines available, why should I pick yours? If you can't give me at least some ideas why I should pick your engine, I don't see much incentive to spent hourse trying out your engine. Then I'll do a safe bet and pick an engine that has already proved that it can be used to create good games.

I don't know how to answer that question, but I think it should be answered.

Good luck!

[PeterM]

You're right, it's not an easy question to answer at all!

(deep breath)

The problems I had with other libraries were usually one or more of:

The library's DLLs make the game installer quite large, possibly discouraging players from downloading demos.
The library doesn't do sprite scaling, rotation, blending, etc.
The library doesn't use hardware 3D.
The library only uses hardware 3D.
The library needs the newest version of Direct3D.
The library isn't cross platform.
The library isn't very fast.
The docs aren't very good.
The code isn't well organised, or has been hacked together instead of getting refactored.
The library is too intrusive, stopping it from working well with other libraries, or making the programmer work in a particular way.
It takes too long to get up and running. For example, I have to download STLport, which messes my existing projects around, and build STLport and the game library from source.
IGE aims to address all of these issues. Obviously it's not there yet, but it will be. I hope this answered the question, or at least sidestepped it in a satisfactory way! ;-)

I will make a feature comparison table paraphrasing these points.

Thanks again for your comments guys.

Pete

[Jason Colman]

What would be the best format for tutorial documentation? Have you seen any of the tutorials at gametutorials.com (http://www.gametutorials.com) ? All the tutorial text is in the code as comments. I think that's a pretty good way to do it.

[luggage]

And follow Microsoft's example. For each feature of your engine write a small demo application which only does the bare minimum to show off that feature.

Say I want to figure out how to rotate an image - I'd just crank up the imagerotate demo and not have to worry about digging my way through tons of other source code.

A user guide for the documentation as well. Some docs, and Sony's are quite bad for this, just detail each of the functions and what they do. They don't give you an overview of how things fit together.

And, obviously, a few tutorials for simple game types. So you'd have tutorial 1 which involves creating a window. Step 2 involves loading images to the game. and so on. Maybe have an indepth one such as this for just the one type of game but throw together some examples of other types to show it can handle them.

[PeterM]

Good ideas, thanks for the tips guys! :o

[dntoll]

I think this thread shows that you are prepared to make a good lib!
I will definitivly check it out when I make 2d prototypes for our next game... :rolleyes:

[dima]

Hello PeterM,

I think your library has major potential, but indeed needs some work to get there. I agree on the documentation remarks, IGE needs clear introduction, a FULL list of features, not just the major ones, a good set of tutorials, and obviously clear documentation. All that would be a great start. I did take a look at IGE a few times actually, but was turned off by the docs and the current lack of cross platform support.

Again, I haven't fully looked over everything, but from what I've seen here are my thoughts;

One of the major points and features of IGE is geometry batching, so this should be on top of the feature list. Not many realize how important this feature really is for any game that goes beyond a few hundred sprites on the screen. Currently the only library that properly does this is HGE. Others just plain don't do it at all and brute force all the rendering. This is fine for some games, but anything with more detail and you got issues with those libraries. I tried PTK and BMAX, and they both plain stink performance wise, specially with the DX7 renderer. Atlantis and KaiJin barely run on my laptop (which btw runs Warcraft 3 with almost no problems) due to the lack of geometry batching. So again, this is a HUGE feature, if only everyone fully understood it's importance.

IGE code is structured well and fully utilizes C++ features. This is another plus, everyone needs a good framework (the Application class) to quickly and painlessly control the application. I haven't looked in depth, but IGE code seems up to date. I should look over it some more and see what's the deal.

The cross platform support is very important. Making sure that my game will compile and run on other platforms without modifying code is a huge deal. I really want to write my game, and not worry about any platform stuff at all. BlitzMAX is probably the best at that, but it's not as practical as C++, and definitely not as fast (why wasnt batching implemented?). PTK would be a thought for me, but after seeing there was no batching implemented, I gave up on it. I've never developed for any other platform than windows, so I don't really know what goes into it, but I would think it's more than just Endians. Technically Windows, Mac, and Linux should all be able to work, so you should aim for all 3. Big selling point is having support for the 3 major platforms, althought Linux isn't the best place to sell games.

This is what I need from my dream library: True cross platform. OGL and DirectX rendering support with proper batching. Everything else is secondary. As long as my game can run on different platforms (with proper input, audio, and graphics) and run fast, I am willing to learn new ways and maybe even think different. I like how BitxMAX is handling things, but I dislike the syntax, lack of proper batching, lack of being able to render quads (in MAX2d) and a few other problems like IDE. C++ is the best language I've ever coded in, and I wold love to stay with it if I had a great library to use.

HGE (www.relishgames.com) is probably THE best library I've used for Windows. I would recommend taking a look at it and maybe stealing a few ideas. The only true 3D hardware 2D engine, which is faster than any other, all due to batching :)

So basically, I need a library that can take care of all the system things on the 3 platforms, give me an interface to be able to set up my own viewport (2D or 3D) and render arrays of vertices (2D or 3D). This way I can pretty much do anything including 3D, do it well, and have it fast. No need to support non-3D accelerated, 3D is the way to go now. OGL and DX8 for maximum 3D pipeline efficiency. All the rest can be dealt with. But I really need the possibility of sending huge amounts of geometry through the pipeline and be able to make true 3D.

Either way, I am interested in IGE and the possibility of using it. Hopefully soon enough.

[Emmanuel]

ptk doesn't support geometry batching as it targets DX7 and 2D games. As far as I know, batching requires DX8, and that may be pushing it in terms of customer environment.

This said, you're right that the DirectX renderer was a lot slower than GL even for modern 2D games, when using a lot of sprites, and it has been majorly optimized about a month ago, and now merged in the version of ptk currently for sale - there were other bottlenecks besides batching that got removed. Still, you won't display thousands of sprites at full framerate. You can indeed do that with HGE provided that it's OK to require DX8. I understand that its author is stopping development, though.

Best regards,
Emmanuel

[dima]

As far as I know, batching can be done in DX7 as well as 8 and OGL. In OGL it's the vertex arrays, and in DX it's the dynamic vertex buffers that do the trick. In any case, it's possible even in DX7, thought 8 has better pipeline.

HGE really is one on the best I've used. Not only because of batching, althought that is a big thing, but also because of the simplicity of the API. Getting a program running take a few minutes, and from there on everything is easily accecible, without using templates or applications classes (although I had to implement my own game state machine). The rest is very well organized. The core takes care of the system stuff and the rest is handled by the helper classes. End result is you get maximum performance throughput. HGE has it's problems though. Major one is that it's not portable. Using DX8 as a renderer I don't consider a bad thing. It's true that 7 is better compatible, but 8 is better suited for performance. Also, for small games there are already plently of tools available like PTK and BlitzMAX, but those cannot handle big loads of geometry.

PTK is the only one that comes close in terms of simplicity, but lacks the performance. I need things such as batching and being able to do custom 3D if I wanted to. (PTK can do the 3D with direct OGL) With HGE I could get a pointer to the Device and do anything I wished with DX8 including true 3D. I believe that this would be harder to do with multiple rendering APIs, but I also think that if I could send an array of custom defined vertices, anything could be possible.

I think anyone who is making small games is better off using BMAX or PopCap framework. Those already provide a rich set of features for programmers, but both lack the ability to be extremely fast. I do thought like how PopCaps have it so you can use any size images which internally get sliced into proper sizes so the end user doesn't have to worry about texture limitations. This would be something very useful as a feature, but would break batching for specific textures. For things like background images this would be perfect, as I could load an 800x600 image and not worry about it's size at all, leaving that to the game library to handle. (I am surprised on how many games neglect texture sizes, and just use irregular sized images, wasting alot of vram) For things like particles and game objects, best to pack everything into larger textures so batching fully applies.

BlitzMAX has the right idea. You can get a program running in seconds, only a few lines of code to get stuff on the screen and it will work on all platforms. It is difficult though to manage larger projects, weird syntax to get used to, and there is always the rendering limitations (no batching, no quad rendering).

So gimmi ...

[PeterM]

Hello,

Thank you dima and Emmanuel for your detailed replies! I'm incredibly grateful that you took the time to type all that. While it's way too much for me to reply to point by point, I can say that I agree with all of it.

Thanks for trying out the lib, dntoll!

It sounds like the main problem with IGE at this point is documentation. I need to improve it in a big way, and write some good tutorials. That way I can take some of the pain out of trying the library out.

Regarding batching, I wrote the Blitter and BitmapFont interfaces in IGE to make the user not have to think too much about batching, but to have it come naturally. Basically, if you find yourself calling begin() a lot with the same texture, you're not getting the best frame rate. In the examples I batch things up as much as possible.

IGE uses both OpenGL and D3D7, and the D3D7 back end almost runs at the same speed as the OpenGL back end. It's a bit slower because under D3D I need to keep a copy of textures and vertex buffers in system memory, which is used as a backup when surfaces are lost. Also the fact that OpenGL uses RGBA colour, while D3D uses BGRA, so I need to swizzle the colour components when uploading to the card.

I'll have a look at HGE, to see if there are any concepts which can give IGE a leg up.

Thanks again for your help guys.

Pete

[Pyabo]

An easy-to-use but feature-rich set of GUI controls might make your engine stand out. This is something most game libraries completely ignore or just implement badly.

[dima]

The way batching is set up now works just fine and makes sense. The only other way I would think of doing this is making an internal scene-graph type of thing, where you keep adding quads or arrays of geometry with no particular order or texture used, and expect them to draw properly and batched at the end. But as long as I can manually do it, it's all good :).

It is good news that you already have OGL and DX7 renderers working. I looked over the include files real quickly but didn't see where and how to use different renderers. Also, I didn't see anything about render targets or switching from fullscreen to windowed mode and back at run time. Also, would be nice to be able to switch renderers at run time as well. This is where documentation would come in handy. One look at current docs, and I am confused at what I am seraching for, but you are already aware of that.

I would also love to see some more examples. Nothing major, no need for crazy tilemap demos or playable games, but examples of technical features. Current shootemup is not bad, but more is needed. I need a tiny example that shows me how to pick renderer, switch fullscreen/windowed at run time, render 5000 small sprites. Then I need an example that just shows how to set up a perspective (3D) and have a 3D spinning cube (or a thousand) that demonstrates how to send custom geometry. (The custom 3D should be easy to implement with the current setup, as long as I can manipulate the 3D transformations) Another example would be render targets and some GUI stuff. That would do it for me at least :).

Keep up the good work,
Dima

[dima]

O, and some answers to your original questions...

1 - It's not cross platform yet - Indeed an important feature. Probably should have been the first thing to complete. Full Windows, Mac, and Linux support is required for a portable library. Everything should work on those first and things like endians and other differences between platforms should be worked out before any additional features were implemented.

2 - The pricing structure isn't known yet - You should at least let people know what the price will be when the library is released. I mean if I start making a game, and then find out that IGE will cost me $500 or something rediculous, I might think again. Also, the price should not probably exceed $100, as there are many tools already that are full of features. So please be reasonable.

3 - It doesn't operate in the way I want - Not yet it doesn't. Or maybe it does, hard to tell without proper docs. Either way, I need portability, batching, audio, input, render targets, run-time window/fullscreen switching, resource management (ZIP files), other goodies. Soon I hope.

4 -I don't want to use IGE's graphics, I want to write my own OpenGL, DirectDraw or Direct3D renderer - This may be a bit complicated for some. Also why would anyone want to write their own renderer if yours does everything that is needed? As long as I can send custom geometry to IGE without knowing which renderer I am using, it's all good. With an array of verts I can do 2D, 3D, implement MD2 file loading and animation, whatever I desire.

5 - I can't embed an IGE graphics context inside my level editor, or another app I've written - Good idea to implement this.

6 - Having a watermark in the demo version sucks - True. But without one people might just 'steal' your library and use it commercially without paying. Take a look at HGE to see it done well. You get an HGE logo at startup, which disappears and your application takes over. The logo is gone when you buy the product.

7 - I don't like the license terms - haven't even looked this far yet. First I want to figure out if IGE is what I need for my games.

8 - I want the source code - I personally could live without it, as long as the library does what I want it to do and is flexible enough, no need for the sources.

9 - I've already got a good library - There are some that are good, but none have exactly what I wish for. Portability is #1, then performance and ease of use and stability.

10 - IGE doesn't work with my compiler - Can't say anything here. Haven't tried compiling anything yet, no idea what's going on, need better docs and samples/tutorials.

11 - It's not proven yet. I want to see IGE powered games in the market before I spend time with it - This might be a problem, since there are no games on the market yet, and hardly will be unless someone uses this lib. As soon as docs and samples are improved, people will see what's possible.

[PeterM]

Hello,

Thanks Dima for posting on the Saurus Games forum while Indiegamer was down. I've answered the questions that you've posted there.

Pyabo, a GUI module is in progress, but it's early days. With GUIs and audio it's hard to make a module that works to everyone's tastes. Of course it will be modular though so people can use it or not, depending on how they prefer to work.

It seems that currently the Saurus Games server is having trouble - I think I need to find a new host, since I've been getting increasingly more problems with them. Sometimes the site works fine, sometimes it's slow, sometimes it just doesn't respond.

About the pricing, no it definitely won't cost anything ridiculous like $500. I'm thinking more between $50 and $75. Depending on how much you value your time ($ per hour) I think that works out as good value.

I may add a splash screen if I find that lots of people are selling games using the library without paying for it. I'd rather not punish the honest majority of users though. I mean, the people who aren't going to pay for IGE before selling their game probably wouldn't have bought the library anyway.

Pete

[tentons]

Also consider if IGE will be a game engine or a tightly focused rendering library. I'm not sure which it is meant to become in the final version.

The best engine IMHO is one that I don't have to think about using. Ie, I don't want to have to match up begin() and end() calls or any of that. I guess "high level" is the term that applies. I want to work with sprites, not surfaces and quads. Some people probably want that level of control, but IMHO it has limited use and slows development.

PC and Mac support is a must, but Linux seems it may not be the best ROI unless it's trivial to port to. I have no data on that, though, and I'd love to be wrong about it. :)

As probably mentioned before by me, Python, ie, dynamic language support is a huge plus. Having a DLL with a C interface is great.

DX7 support isn't that much of an issue to me, just like 5 meg demos and software renderers. If DX7 support is needed, please make it optional and kick in more modern features if the dev opts not to use the ancient APIs. I understand that there's a legitimate need for it for some kinds of indie games, but "indie games" does not mean "match-3 soccer mom games" only. So please remember that not all indie games will be in that style. :)

As for 3d in a 2d engine, I've never understood why people want that, and if it was my engine I would not consider it. There are some fantastic 3d engines out there that can do 2d (with batching!) if you really want it. It might dilute your feature set to support something that most people are not looking for in a 2d engine. (Just to consider ROI again.)

Best of luck, I hope to IGE turns into a great indie tool.

[Sharkbait]

In line with tentons' comment on calling the library a 'game engine': If you intend it to cover all, or at least the main aspects of game development functionality, I think it is quite limited as it stands now. I see no support for audio and networking is only hinted at. Also, I see no support for software rendering as a fallback.

If it is of any help, these are the things I'd like to see in an 'engine' API:

Graphics: hardware rendering, software rendering and the ability to dynamically detect HW and switch to SW on absence. Sub-pixel rendering for HW. Also, support of scaling, rotation, per pixel and/or per image transparency. Some basic support for GUI functionality. Special rendering effects would be a plus.

Audio: Multi-channel mono / stereo sfx and at least one channel of music - 3d sound and multi-channel music is a plus

Networking: support for basic TCP and UDP sockets and higher level support for HTTP (particularly handy for highscore posting etc.)

Scripting: some form of scripting language with the ability to interface native code. Having the API entities already visible to the script is a plus. Support for an object based / object oriented script would be a plus.

Timing: functionality for measuring time, frames per second etc. I noticed you already have this covered quite thoroughly

Resource managment: ability to load resources (images, audio, scripts etc.) straight from disk or from an open / custom archive format. Ability to load resources directly from memory or to implement custom loaders would be a plus.

[PeterM]

Hi guys,

Thanks for the feedback. It's getting to the stage now where I've got a heck of a lot to do. I don't mind that at all, but if I do it all before a release the library will not be released for a while.

I'm going to do what a couple of people have suggested - I'll write a roadmap of the features I'm going to implement and the version of the library they're planned for. That way everyone can see what features are planned and when they're likely to appear.

Sharkbait:

I'm also reluctant to call IGE a game engine at the moment, because it's obviously not comprehensive enough, and I won't try to fool anyone into thinking it is a complete game engine yet.

But it will be, so I chose to stick with the name IGE instead of first calling it IGL and having to rename it to IGE later.

Regarding software rendering, it does indeed have software rendering when hardware doesn't exist, so that feature's there. (Phew!) It also has all the graphical effects you mentioned (Double phew!)

A GUI module is in progress.

Audio isn't implemented at all, neither is networking. They will be added, but it will also be possible for users to use their favourite 3rd party networking library, or their own code.

IGE will have scripting language support. I plan on having an extension library for Python and perhaps one for Lua, depending on how things work out. I'd love to have extensions for all your favourite languages. I may write them myself, but I'd be more than happy to accept submissions.

As for timing, there is already decent support for timers. MrCranky pointed out that there was no indication of how big a Tick really is. This is true, and I should have said so in the docs. In case anyone is wondering, a tick is a 1/1000th of a second.

Support for resource loading is in early days. At the moment you can load files through an Input object from disk, or memory, or you can provide your own source. Official .zip support will be added later, but in the meantime the framework is there for you to roll your own if you wish. I've yet to find a scripted resource loading scheme which will be universally appealing, so I'm still on the lookout for that.

I hope I've answered all the outstanding queries, please tell me if I've missed something.

Thanks again for all the great comments,
Pete

[Pyabo]

Another thing I would like in an graphics engine.... seamless support for windowed and full screen modes, without having to worry about what bit-depth the client's desktop is set for.

Is that too much to ask for? :)

[PeterM]

That should work fine at the moment.

Pete

[wazoo]

Hi PeterM,

Great effort with IGE. Now that I know about it, I'll keep it in mind for future projects.

Not to be really anal or anything, but if it was me, I'd have the IGE page as the default page on your domain.

Not to imply that Indies are lazy or can't read, but it helps to sell something when the customer doesn't need to dig through submenus to find stuff.

Once you create other projects or games using IGE, then you can restructure the homepage or whatever. But for now, I'd make it the default. Put it in the customer's face ASAP. :)

Even though most of us are all one-man shops, I might also change your text to "we" instead of using "I".

ie. "If something doesn't work, we can fix it." etc..

If I can use Direct3D7 or OpenGL1.2, how come I can't use Visual Studio 6.0?

Also, does anyone care if your site is W3C verified? I don't.

Again these comments are all my 2 cents. Maybe I'm barking mad, I don't know anymore. :)

hth,

[PeterM]

Hi Erik,

Thanks for the kind words about IGE, I'm glad you'll consider it for future projects.

I've now made the default page for Saurus Games the IGE page. I didn't know I could do that! Thanks for the tip! I've done this by adding a temporary redirect in cPanelX. I presume this is the right way to do it.

I'll change references to "I" to "we". I just feel bad about kidding that there's more than me.

In theory you can use Visual Studio 6.0, but I need to fix a bug in the template syntax. You can use the library with VS 7+ and Dev-C++/MinGW, but I've not installed VS6 for a while. I will do it and fix the bug.

Not many users will care about W3C verification, but it helps me check my HTML is ok. I could set up an alternative method to check, but it works. Does it annoy people?

Oh, I don't think you're barking mad! Thanks for the comments!

Pete

[PeterM]

Hello,

I've added a roadmap (http://www.saurusgames.com/developers/ige/roadmap/) to the IGE site. Hopefully I've not missed anything out, but please tell me if your desired feature isn't there.

The ordering of tasks is also fairly flexible.

I also wanted to say thank you to everyone who has participated in this thread.

Pete

[tentons]

One other suggestion: resolution-independent coordinate system. That is, screen size doesn't matter when specifying a position. It should be translated for you by the engine. So if you specify (100, 100) that would be a "world unit position relative to camera" rather than "pixel position of current screen resolution". Torque2D does this, and it's amazingly great to not even think about resolutions. :)

PS. I'd be willing to test things on Mac (and PC) for you. Especially Python support! :D

[PeterM]

Hello,

Thanks to OpenGL and Direct3D's projection matrix, coordinates are already resolution independent (Yay!)

From example.cpp:
// Set up an orthographic (2D non perspective) projection.
const ige::math::Matrix projectionMatrix = ige::math::Matrix::orthoRH(0.0f, 640.0f, 480.0f, 0.0f, -1.0f, 1.0f);
graphics.pushProjectionMatrix(projectionMatrix);Th is sets a logical 640x480 screen, no matter what "physical" resolution the window is.

Pete

[Octopod]

Hello PeterM, and hello to all the fellow indie creators,

IMHO, with no offence, it is not really reasonnable to create a game engine that aims to be used by people without having elaborated it on REAL games. If I were you, I would create cool little games (no matter the number of levels, hours of play, etc) which will make your engine evoluate over their development, features & tools being needed for them. Tutorials, documentation, support, forum & so will come after.

People seing your games should then think 'Yeah ! I would like to do games as cool as them, humm.. they have been done with a library that is available for download, hey why not using it and doing my own game !'

Proof your engine with games and everything will go on..

IMHO, cross platform is not need, but a big plus. Don't lose your time on it for now, keep it for a future version.

I'm also sharing the idea of making the engine really easy to use with simplifyed function such as CreateWindow ( EWINDOWED|E640x480 ) even if a CreateWindowEx ( reso, bit depth, z depth, antialiasing, etc... ) also exists.

Also don't forget that community and engine/site updates are a must, and take a LOT of time. I myself done an free engine for 2D games in Java (jade.pautrot.com (http://jade.pautrot.com/)), but because of the lack of updates and news, I think the number of people that have been interested by it is really small (20 or so). And I never saw a game done with it, except mines.

Hope this helps..

Alexis.

[PeterM]

Hi Alexis,

Thanks for the feedback. You've hit some very good points. Probably the biggest drawback for IGE is that it isn't proven.

After a couple more releases (detailed in the roadmap) I will work on a couple of very small (but full of eye-candy) games to help show off the library and what it can do.

Hopefully that would help encourage potential users of the library to try it out and see what it can do.

I was also thinking about a promotional deal for early adopters of the library. Something along the lines of "the first 5 people to make a game with IGE don't have to pay for it".

Do people think that such a thing would encourage developers to try the library? To be fair, the $50 that it costs to buy IGE when you've finished your game will be nothing compared to the time you've spent working on the game anyway.

Thanks again for your comments Alexis.

Pete

[Octopod]

Hi again Pete :-)

From what I've learn from my work, a generic fully featured engine that covers all part of game creation asks a lot of time. Too much time for me. In addition, I myself don't like fully featured engine because I feel restricted and I'm more interested in tools & libs programming than in game programming (as many developpers I think).

Now, I plan to create tools that can integrate into someone else engines. A tool to export skyboxes from Max, a font generation tool to have bitmap fonts, a localization tool to have texts in excel files, a tool to create UVs used in GUI, a portable GUI framework, etc... Breaked into different components so that people can use and integrate only what they need. This way, I can spend more time on what I know and do well rather than losing time on part on which I'm a noob (for example skeleton animation, shader programming, etc...).

About the price, I have no idea, all I can say is that I might spend up to 15/30$ for a tool I really need, but not for a full engine, because it do not fit my needs. I'm not a good candidate because, in fact, having external tools/sources rather than a full engine is for me a liberty I'm ready to pay for.

Alexis.