@Ray_fowler Either there’s a bug with colony ships not colonizing, or I can’t settle 2 planets for an unknown reason. Is there any reason I can’t colonize a jungle planet with a basic colony? Or a steppe planet? I bring my basic colony ships there and nothing happens. In case they can’t do it, there should be some message to explain it.
I’m also getting a bunch of crashes.
Love the game though! MOO is such a great timeless design, and you’ve only improved it.
What version are you running? There was a bug, pre-2.02, where the game would get in a state where the notifications (such as colonizing) would not display. Closing and restarting the game would fix it, but it should be gone in 2.02
OK I updated the game through itch.io. All the notifications came up at once – turns out I wasn’t getting science notifications either. Thanks!
The first week after a beta release is always a little hectic because I am both a one-man development team and a one-man QA group. Bugs slip in but I aggressively fix them asap after a release. There are so many dedicated players who quickly report any bugs they find and it’s like a personal goal of mine to fix bugs within 24 hours of them being reported.
It doesn’t hurt to keep an eye on the subreddit to see if an update fixes a problem you might be having.
Well, you’ve done a beautiful job. It’s really addictive, and the design is so elegant and streamlined. Thanks for your work on it!
Thank you for those kind words! It’s not finished. I am working now on improving the Diplomacy AI and giving the player more options to play with.
But most importantly, I need to write up a document on how it all works. I suspect that it’s more involved than most players realize and, once they understand how the AI thinks, their interactions will make more sense and players will have a better sense of agency
Sorry, I missed this question earlier! Currently there is not a plan to make the game fullscreen. This has caused some consternation among players as to why, and some even suggest the simple two lines of code needed to make it happen as if the thought had never occurred to me.
The issue is that the game relies heavily on Petar’s beautiful artwork for many of the game’s background. His artwork is obviously a fixed aspect ratio, so the game plays in that ratio. Switching to fullscreen would stretch that artwork according to the whims of whatever each player’s monitor resolution is set to.
In 1993 when MOO1 was released, this was not a concern. But now it is and that’s why all 4X games just use a HUD over the game map to pop up whatever dialogs you need to do research, trade, diplomacy or whatever. It’s also why pretty much all space 4X games look so similar now.
When I decided to modernize MOO1, I made a conscious design to go back to the original MOO1 UI layout and NOT look like every other space 4X game. That means a fixed aspect ratio instead of fullscreen.
I still think it’s a good idea. Anyone who knows the space 4X genre would immediately spot the ROTP screenshot in a lineup of twenty space 4X screenshots. The game feels less generic because of this, imo.
However, the code is open-sourced so it’s pretty easy for any intrepid modder to fullscreen the game, regardless of the artwork.
Well, I love the artwork, so I think your decision on aspect ratio is perfectly reasonable. I’ve done some illustration work, and I know how long it takes to make a big, detailed image like those in your diplomacy screens. I’m enjoying looking at them.
I’d be ok with a full-screen option that put in black bars where appropriate to keep aspect ratio.
Hades does this (with artwork there instead of black bars, but same idea) and it works out fine on my ultrawide.
OTOH for a passion project like this? Not sure it’s worth the cost compared to other things Ray could be doing with his time.
Looking forward to giving the new beta a spin! Thanks @Ray_Fowler!
The dirty little secret behind those simple little check box options is that there’s sometimes a lot of code that has to be rewritten to make it work.
:P
I have no problem if it’s too hard – just laying out what I think is a good compromise position theoretically. I think SDL2 has support for these things natively, but I guess with Java it might be harder.
It’s not that Java is harder. I just made the choice to write the entire game in straight Java (like C, but with garbage collection). I’m not using any Java game libraries or anything like that. So if it needs to be done, I have to write it.
Ouch. Seems like a lot of reinventing the wheel, no?
Or fun? One of the most satisfying things about computer programming is figuring out how to solve problems. Why should I let other people have that fun when I can do it myself?
I mean sure… but then you’re wasting a lot of time solving problems that have been solved many times before rather than designing the game. Simple features become hard to add, etc.
I guess it doesn’t matter that much at this point, since the game is mostly finished and it’s fairly modest technically, but if you were to create a realtime 3d game, you’d quickly be swamped with technical issues that would prevent you from making any real progress.
I’ve done software development for many years and I’ve seen the trade-offs. When you use an external library, you save yourself coding time but there is a very real cost to it – unwittingly incorporating bugs (and code inefficiencies) written by other people, climbing a learning curve for integration, and then staying up to date with their revisions.
There is no such thing as a library that you drop in and forget about. Code that you have written personally is much easier to tune and debug.
I don’t think it’s worth arguing about. ROTP is a wonderful, but modest project. I’ve worked on and observed many projects. There are reasons for doing everything from scratch - ScummVM is a good example, where the project can still run on a Dreamcast, PS2 or DS, but just barely. But the tradeoff is that you’re never going to have the testing power of a popular library, and upgrading capabilities is very hard. And at this point, once ScummVM is established, every new engine is being ported to the ScummVM platform precisely because it has become a framework/library for all retro games.
I’ve seen Soldak games struggle with maintaining their aging engine in the face of advancing technology. And then I’ve seen what can be done with a popular engine like Unity or Unreal – it blows away anything the ‘all the way down’ folks can do. People using those engines benefit from bugs reported by the entire ecosystem without having to lift a finger.
As another example, my current focus is machine learning, and I’d never want to reimplement pytorch or tensorflow myself. It’d be a huge waste of my time to do so. The benefit of a language ecosystem is precisely all the libraries that it provides, each supporting each other.
no no, I totally get and appreciate all of that. The downside is that a game like Lord of Rigel lost at least two years on their schedule because they realized, too late, that the engine they had chosen was not going to work out so they basically had to retool and switch to a new one.
Pre-written libraries are great, especially when you have seen applications similar to yours already succeeding on those engines. In my case, I had no expectation of using 3D graphics (it is a 4X tbs, after all), so I wanted to target lower-end machines – even those that do not have graphics cards.
Basically, if you have a CPU and a JVM, you can run ROTP. It runs on a Raspberry Pi.
That’s great. Can’t wait for an Android port :)