Also check out the games planet.
Erkosone is making available many songs of his creation in this post in the forum. There are different styles of music in many tracks that you can use in your games, no matter if they are free or commercial projects. The only condition is for you to give the credit to him for his music.
Wow, it’s been quite a week hasn’t it? I quickly put out a release and leave the website half-updated, figuring it’d give me a break as I needed to make way for university work, and before I knew it the website was bursting with activity. It’s like I had invited you all to dinner, but you show up early so everything is still dusty, my clothes are all over the floor the roast is on fire. And aliens burst through the bathroom and catch me with my pants down.
Anyways, first things first. Thanks to everyone who’s been spreading the word, especially Alec Meer and Phil Savage who wrote very nice articles about us and really helped boost our views. Usually I manually contact every press site and get nothing, but this time it all just happened organically. It really shows how much I don’t get this fancy Web 2.0 you kids are using. On that note, I should point out all the globe icons on the right that people miss. They take you to our various contacts/social networks! Try them! And if you have better ideas on how we should be using them let us know.
The website has now been fully updated to reflect all the new information and how the project has grown since its early days. Gone are the days when this was a mere one-man project!
Finally for everyone experiencing scrolling bugs and other issues, try the nightly builds and see if they solve your problem. And if you really want to increase the Battlescape viewport you can try increasing the baseXResolution but it’s highly experimental.
That should cover most of your issues, but I figure I should also answer some of the bigger debates here:
A lot of you still seem confused what OpenXcom’s real purpose is. Put simply, it’s a love letter to the hardcore fans of X-COM. The ones that don’t mind dusty graphics and a baffling interface, as long as they still get the gameplay they’ve always loved. It takes away the need for DOSBox, gets rid of all the nasty problems, makes it more accessible to more platforms, and tops it all off with various improvements to make sure you can keep on playing the original as long as you want.
It’s not meant to be the one remake to rule them all or a spiritual successor. I think we got enough of those, thank you very much. If you wanna mod it as such, that’s up to you.
As for why it’s 0.9 as opposed to 1.0, well, that’s just to give us some breathing room. It’s “feature-complete”, yes, but there’s always plenty of bugs that pop up when these things come out. And we’d actually like to take the time to go back and fix and refactor and improve everything, instead of keep on rushing features, before it becomes too messy to handle.
But we already have the original X-COM, there’s even patches like XcomUtil and UFO Extender, what more do you need? Isn’t it just kinda redundant and pointless? Maybe. Maybe.
Let me tell you this. How long have you been an X-COM fan? Been in the community? How many dozens of remakes have you seen flash past before your very eyes? I’ve seen a lot, for years and years. I remember when EDF was still new and fresh, and I was even part of the Xenocide development team at one point. But in the end, what’s the universal constant?
“It’s just not the same as the original”, everyone says. “They changed the gameplay too much, it’s not as challenging, it’s just not the same”, they say. “Why doesn’t just take the original and fix it up, instead of constantly screwing up the formula?”.
Well, that’s what we did. We took all the combined knowledge of the original X-COM community, and made something out of it. A fixed, improved, open-source version, for all to try. And we didn’t make another overambitious unfinished abandoned project in the process, and disappoint the community once for. That’s what OpenXcom is for. Maybe you’re happy enough with UFO Extender and XcomUtil. That’s fine. We’re not really trying to beat them, specially since it’s really hard to reproduce features just from looking at them and hoping we get it right, since everyone who develops these things vanishes into the ether leaving nothing to go on behind.
Maybe that’s not enough for you, you want a brand new HD state-of-the-art spirital successor remake-type thing. That’s fine, too. I like remakes. But I’d rather let someone else do that. I can tell you, from experience, reproducing X-COM from scratch is one hell of a challenge, and I imagine that’s where most fall apart once they realize this. But now they’ve got a stable open-source codebase to start from. They don’t need to worry about reproducing X-COM all over again anymore, they can focus on the important part, making their own unique vision and interpretation of it, making their own remake. So maybe we’ll see a lot more bold successful remakes now. At least I hope so. The series has a lot of potential, and it’d be great to see a lot more choices and variations for people to try, instead of the string of projects left to rot.
Apparently a lot of people are having this reaction when they play OpenXcom. That they wanna go back to the “easier original X-COM”. Let me put this bluntly. What in the actual fuck. I don’t wanna live on this planet anymore.
First, we can’t just port the original AI wholesale, we don’t have the source code. We had to write AI from scratch based as closely as possible to X-COM’s design. You can’t just turn a switch on and off to make it different, it’s a really complex system, and everyone has a different view on what consists “challenging”.
Second, “easier original X-COM”? Really? I never thought I’d be alive to hear such a statement. I don’t know what X-COM you were playing, but I can go back to the original and get half my squad killed on my first crash site on Beginner in a snap. Perfect visibility, ruthless aim, brutal reaction shots, that’s how it’s always been. In all my years as an X-COM fan, the original has been highly lauded for its brutal punishing difficulty, and every other remake has been massacred for “just not being difficult enough”. And now this. Maybe it’s different times, I heard people even had trouble playing the new XCOM on Normal. But for me, once X-COM is “easy”, I will never return.
Yes the AI is better. It no longer decides to just wonder aimlessly or get stuck inside some building somewhere. You can no longer reload the same game ten times until your shot finally hits. That didn’t seem like it was worth reproducing. I dunno, I haven’t seen any veterans have any trouble playing the game, a bunch of them have beaten it already. Maybe you just need to brush up on your tactics. Psi is still totally overpowered though, go nuts.
NavigationInfo.transitionComplete support. Demo model transition_multiple_viewpoints.x3dv shows how to use it to make an animated transition between a couple of viewpoints.
Thanks to Abou Al Montacir we will have packages with Castle Game Engine and view3dscene in Debian! Most of this software was developed by Michalis using Debian, so having my software in the Debian repository would feel really great for me :) See here for our forum thread, and here is the Debian bug marking ITP (Intent To Package) for engine: #706408 and for view3dscene: #707932.
For developers, new chapter of our tutorial describing network support is available.
Engine examples contain a simple tool examples/tools/to_data_uri.lpr that can generate data URI (to embed your texture, audio, model, etc. inside a VRML/X3D model, or a webpage, or other documents) from any file. It gets the file and guesses MIME type using our existing CastleDownload unit, so it supports local files as well as http links, and MIME type is retrieved from server or guessed based on file extension.
There is a demo data_uri.x3dv showing how you can use data URI to embed all kinds of things inside X3D file: textures, sounds, other 3D models (to Inline or Anchor to them), scripts etc.
MultiTexture.function support (forces shader pipeline rendering for given shape; there's no way to reasonably implement this using fixed-function pipeline). Demo in functions.x3dv.
A set of X3D multi-texturing tests is available, testing support of view3dscene and other VRML / X3D browsers for multi-texture features. This is part of my ongoing effort to improve X3D MultiTexturing specification.
There is a progress bar showing the process the downloading. The download is still blocking, but at least now you see what's going on :)
If you load or save image sequences using the syntax image%d.png, for example inside our extension Movies for MovieTexture can be loaded from images sequence: the new syntax to indicate counter inside the URL will be @counter(4), where 4 is the padding. For example image%d.png has to be changed to image@counter(1).png and image%4d.png has to be changed to image@counter(4).png.
For loading, you will have to use new syntax with @counter(<padding>) with new view3dscene / Castle Game Engine versions. You will have to update your VRML/X3D models, old syntax will unfortunately not work anymore (reasons below). For saving, the old syntax %d will continue to work for some time (along the new @counter(<padding>) syntax, and you're encouraged to upgrade to new syntax).
The reason for this is that MovieTexture.url is now correctly treated as an URL, and this means that percent character % needs to be escaped to %25. Inside URL the sequence %4d has to mean letter M (ASCII code 77, which is 4d in hexadecimal). So there is unfortunately no way to avoid breaking compatibility — we want to correctly support URLs, which implies that %4d must be interpreted as letter "M", not as a magic counter.
Looking back, it was an unfortunate choice to use percent character to indicate images sequence, since percent is special inside URIs. It was done for consistency with ffmpeg, that supports things like image%4d.png on the command-line (but not when using URLs; for example, ffplay /home/image%4d.png works, but ffplay file:///home/image%4d.png does not work, neither does ffplay file:///home/image%254d.png). So, one can say that it was ffmpeg that made a bad choice, but then ffmpeg did it for consistency with common string formatting functions (C sprintf, ObjectPascal Format)...
Comments about this change are of course welcome, through forum or any other means. Right now, I just don't see a way to avoid breaking compatibility. We made a bad decision to use %d to indicate image sequence, and it has to change in order to correctly support URL encoding in new versions.
A couple of bugfixes. Including bugfix to a quite horrible mistake in ShaderPart node, in some circumstances the shader code would be reloaded from file at every frame, causing a horrible slowdown. It's fixed now of course.
Here is the winner of the Screenshot of the Month contest for April: Zprg with his ”’Simple little logolike interpreter for voxelgraphics” screenshot. As always, you can find the screenshot and all contestants in the forum and the gallery.