UFO:Alien Invasion
General => Discussion => Topic started by: TerraAnt on July 16, 2008, 06:29:17 am
-
First off, congratulations to the developers of this great game. Years ago I used to love to play XCom (I used to have so much more free time), and my hat goes off to those who decided to make that game into what you guys achieved here. Projects like this keep us, old gamers, coming back.
Before writing this post I went through some of the discussions on your forum, just to see what other people think of this game and any issues that might have popped up in the past. One of the posts mentioned something about the limitations of the Quake game engine (in particular, the fact that the size of the human bases is rather constrained). I was wondering if this issue has been resolved.
The reason I am asking is that, while reading that post, I remembered reading about a game engine that is free to use by anyone, and all based on 3D. I'm sure many members of this forum have heard of Blender 3D (www.blender.org). It is a free 3D model-generation software, described by some of its users as almost as good as Maya, and apparently comes with its own game creation engine. I've never used the program myself (don't have the time for it right now), but some of the animations and videos that I've seen come out of that thing look incredible. Here's a link to their art gallery page for those who would be interested in such things: www.blender.org/features-gallery/gallery/art-gallery.
I guess my question is if UFOAI could be ported, or somehow adapted, to run on Blender's game engine (maybe sometime in the future) and possibly alleviate some of the current limitations of the Quake engine. Here's a page I found that describes some of the features it uses: www.blender.org/features-gallery/features (game creation engine section is right at the bottom of the page).
-
When you say size of human bases is constrained. What do you mean?
Number of base squares or the size of maps for base attacks?
Steve
-
I meant number of base squares (5x5). Personally I don't have a problem with that (certain limits make games more challenging), but there was a forum post where players expressed a wish to have that grid increased somewhat, considering that most of the grid space gets taken up really quickly with base facilities that are absolutely necessary for it to become operational. Space that gets left free doesn't offer much for customizing base layout or functionality (perhaps that was the reason for making the grid size only 5x5).
The discussion concerned itself with either increasing the grid size, or making it multilevel. If memory serves me right, one of the replies mentioned that Quake engine posed limitations on the grid size. That's why I wrote this post, in hopes that using a different game engine might alleviate some limitations the designers could be faced with when using Quake. I'm not a coder myself, so I have no idea if switching from Quake to Blender engine is even possible or too much work and hassle to bother with. I'm just thinking that if it is possible, it might be worth it if in the long run it means the design team gets a better tool to work with, instead of around it.
-
Sorry to burst your bubble, but Blender doestn actually make the game, but can be used to make the in-game stuff. Many of its features are there to make the models fit into the game as much as possible. I dont think that Blender would be the best idea for this project. Maybe for making weapons and other models, but not for the game itself
-
Actually, the Blender people do have a game engine - it just isn't called Blender. It's called CrystalSpace3D. And since a lot of the frequently asked questions relate to problems and limitations of the archaic Quake2 engine, at least look at it before shooting the idea down.
-
Actually, the Blender people do have a game engine - it just isn't called Blender. It's called CrystalSpace3D. And since a lot of the frequently asked questions relate to problems and limitations of the archaic Quake2 engine, at least look at it before shooting the idea down.
At this point in development we need an engine change like we need a shot in the head. Without masses of extra support, actual progress on the game would grind to a halt for months while such an engine change occurred, so it's not going to happen unless a lot of people with a lot of free time volunteer to start coding it.
Consider it shot down until further notice.
Regards,
Winter
-
Engine changes kill. Starsiege 2845, for example. Hell, there was a playable alpha, and it wasn't even an open source project. Once you have something playable, making good progress, and fun for that matter, you need an engine change like you need a slug through the head.
-
it's not about the code - it's about the content and artwork - we are not missing coders, but artists
-
it's not about the code - it's about the content and artwork - we are not missing coders, but artists
That too. Work on the new GUI is still progressing, but painfully slow.
Once I get the image source files from Blywulf for the work he's done so far, we'll be able to knock up more screens at a better rate.
Regards,
Ryan
-
Grid squares? :-)
The thing i'd like to see most would be very expensive extra layers below a fort :-)
So i can dig down and send those aliens into a high security guarded cellar area hehe
-
Doctor J brought up a good point. I've been seeing a number of posts dealing with problems of Quake 2 engine. I do realize that migrating to another engine would put the project back quite a bit (possibly more than a bit), but might be worth it at the end. I found the websites for those game engines that were mentioned in another post, and their gallery shots look amazing. Some of these engines are used by commercial game developers, Disney included, and by a lot of gaming fans developing their own stuff. Here are their links, for those who'd be interested in checking them out. They all have either gallery or screen shots links, and a lot of info on their features.
Crystal Space: http://www.crystalspace3d.org
IrrLicht: http://irrlicht.sourceforge.net
Panda3D: http://panda3d.org
Ogre3D: http://www.ogre3d.org
Some of the more interesting examples of features I found on Crystal Space (didn't have time to go through the others yet):
- support for multiplatforms, including Linux, Windows and OSX
- 2D and 3D graphics modules
- OpenGL renderer
- wide variety of shaders
- bone based animations
- real physics and collision detection
- 2D and 3D sound rendering
- importing support for a wide range of file formats of 3D meshes, texture maps and sound
The point is that moving to another engine might get rid of the problems and limitations of Quake 2 that people gripe about and coders get stuck on, and it might enable destructible environments, something that few people mentioned already. Personally, I'm just happy I found UFOAI, and I'm very interested in how this project develops in the future.
As for the issue that Mattn brought up (considering the lack of artists), I know there are a lot of websites offering free 3D models and textures to the public. Could that be used as a possible source of material for the game (with respective artist's permission, of course)?
TerraAnt
-
believe me, we all know these engines - but there won't be any engine switch before we reached version 10.0 ;)
-
But if you can re-implement UFO:AI on another engine to the extent that it's equivalent to current trunk, you know the patch tracker.
-
Maybe a bit of sci-fi here but instead of changing engines, would it be possible to use two? What I mean is, a modified existing or custom engine being written just to run the destructable features and changed lighting, overlaid on the maps. The only information the Q2 engine would need from it that I can think of is changes in where objects can pass and changed lighting values.
Silly idea perhaps but I see no other option that may be acceptable. :P
-
I suspect it all comes down to resources and inertia.
To change engines, I think three things would need to be shown.
1) That the new engine offers desireable features (where everyone is focused, but remember there's "desierable to the player" and "desireable to the developer".
2) That the resources exist to migrate to the new engine.
3) That the migration won't cause the project in general to stall.
Personally, and given the result, I think we might have done better to have used a far simpler engine (say one similar to Fallout Tactics), and been able to devote more time to (easier to create) graphics.
In my more pleasent of dreams: Nival offers the SilentStorm engine over, which is not only awseome (the house falls down if you destroy enough wall), but already a squad-based tactical shooter with working AI that would mostly only need new graphic resources, maps, and the global view/controls added.
I've not looked at the code here (perhaps I should stop saying "we", since I've done nothing but play and make a few posts), but I'm hoping it's reasonable modular (OO); in which case I would recommend to someone who wanted to change engines that they develop a proof of concept.
-
I've not looked at the code here (perhaps I should stop saying "we", since I've done nothing but play and make a few posts), but I'm hoping it's reasonable modular (OO); in which case I would recommend to someone who wanted to change engines that they develop a proof of concept.
It's C, which is not object oriented. Not that object oriented code has anything to do with stuff being modular.
-
JerryLove
4) A UFO:AI developer with a desire to such a thing.
Zero, unless you want to do it JerryLove there isn't enough motivation/reason to change engines. The time taken to achive this it better spend bug fixing/adding new features to the existing game.
Steve
-
It's C, which is not object oriented. Not that object oriented code has anything to do with stuff being modular.
While encapsulation is not unique to OO, it is a trait of OO.
Essentially I was mentioning that, if the engine is an object that interacts with other objects through exposed interfaces, then replacement of the entire thing could be done separate of most other development. As long as it takes expected input and produces expected output, the rest of the game has no idea what is going on.
If encapsulation has not happened... if various parts of the code interact directly with the methods of the engine, then replacing the engine would be nigh-impossible.
Zero, unless you want to do it JerryLove there isn't enough motivation/reason to change engines. The time taken to achieve this it better spend bug fixing/adding new features to the existing game.
I agree with you: but that is exactly what I was discussing... what conditions would make that different.
Obviously a coder who just decided to do it would just do it regardless of any other conditions.
-
I think the happy medium here would be to get everyones opinion on an engine and then a bunch non dev members can throw UFO AI together on that different engine. I don't see it happening but it could work.
You would just need a team of skilled anti social teenagers to catch up to the trunk version. I would love to take that project up when things settle down over here, I can't put and hold together a team though thus the problem with even trying it.
Another problem would be the second skilled anti social teenager team getting a place to store all their work and upload it to. As much as I would love to see a sub UFO AI forum on this site dedicated to the secondary team it would probably not happen.
All in all it's a lot of work and you would need dedicated people to do it. You don't find many people who take their hobbies or interests as seriously as I do (Having no life is awesome ;D).
-
If there were a serious group interested in porting UFO:AI to another engine, I'm sure a different subforum and a new SVN branch could be arranged. That leaves the issue of finding skilled people who are really motivated to do this as opposed to improve the existing game (we would prefer the latter), and I predict that that issue will remain unsolved indefinitely.
-
Considering how many people are actually skills AND want it ported...I agree that I just don't see it happening. But it definetely deserves a workover at the least. After all if you can get a up to trunk date version on another engine that would be easier or better to work with it's worth a shot.
-
While encapsulation is not unique to OO, it is a trait of OO.
I am not sure that this is an inherent trait for OO. For example to me the core of OO is about objects and messages.
The encapsulation is something I see as "artifical", like the discussion of multiple inheritance vs "mix in behaviour" in Ruby.
Personally I'd love to see a pure prototype language like Io, but with a nicer syntax (more similar to ruby and python)
I think C and C++ are rather complicated compared to either ruby or python. C is still on my todolist but pointers
and memory handling confuses and bores me :( I spent 5 years with ruby so far and do not regret it, except that
there really is so much in C and C++ in the Linux world... hardly a way around it. Game engines include that I guess
(Ogre3D is in C++ and crystalspace too afaik)
-
I've not been following the projects too closely but about 2 years ago I took a look at a UFO fansite which listed over four projects which showed promise. Progress was so slow on them, I never got why the teams didn't get together.
Xeocide has a superb graphics engine but IMHO the gameplay is rather underdeveloped. AI has great gameplay but the UI is a bit primitive for some people (not my opinion).
I'm going out on a limb: what are the odds on the two teams getting together and helping each other out? I'm not talking about merging the projects but it strikes me that there's plenty of experience that could be shared.
-
We don't want to, and besides we're not license compatible anyway.