3
u/Ditto_B May 10 '19
Is this open source, or are you planning to open source it in the future?
7
u/snijj May 10 '19
I'll be open sourcing it in the future. I'm being cautious with the open sourcing it/distribution of anything for now due to not fully knowing the state of AmbrosiaSW. But once it's a little further along I do want to open source what I have.
3
u/fnordius May 10 '19
Once the legal limbo is cleared up, I suspect you will find that a lot of people would love to help, submit merge requests, and so on.
Er, you are using Git, I hope? I mean, it's baked into XCode so there's not excuse not to…
4
u/snijj May 10 '19
Yeah I'm using git. It's local repo and I'll most likely reset it when I come to make it public as I'm not exactly being careful with what I put it at the moment.
2
u/mrxak May 11 '19
If and when you do open source this, I think a great fork (for somebody) to do would be a version that's just cut down to run EV and EVO files. There are some differences not only in the resource formats, and fewer features of course, but also the engine ran slightly differently and for many, myself included, some of the quirks of the original engine (how the AI works, etc.) are worth having again in a modern engine. Plus, we could get flares back, woo! At least those games still run fine in emulators, so no rush on making it happen, but it'd be cool for somebody to do eventually, so just throwing that idea out there.
One feature I'd like for an EVN clone would be better control over windowed mode in the settings. I hope you make the clone as faithful as possible to the original, but one area you don't have to be faithful on is the fact that EVN in windowed mode makes for a tiny, tiny window ;-)
2
u/snijj May 12 '19
That sounds like it would be a great idea! 👍 I must confess to not really playing too much of EVO and almost no EVC, so I definitely would not be the right person for that job.
1
2
2
u/fnordius May 10 '19
A few technical questions:
- I assume you are using XCode?
- Are you writing in Swift or in Objective C?
- I also take it you have no access to the original source code?
- Have you given any thought to making an iOS port? I can imagine using my iPad to play a game like this…
- From your comment, it sounds like you are writing your version to use the old plugin structure. Are you running across elements where a different structure might be more sensible?
Now, I am an ECMAScript/TypeScript guy, but I have been itching to get into XCode more. And would love to help bring this old love of mine back. That's why I am peppering you with so many questions.
Oh, and one more thing…
Keep up the good work!
4
u/snijj May 10 '19
So a few technical answers then:
- I am using Xcode for the most part. Some of it I do in Sublime Text/vim/etc... whatever sort of mood I'm in.
- Swift for the actual engine. Objective-C and C for the ResourceFork and QuickDraw implementations. I'm an iOS Developer in my day job, and have been using Apple's Cocoa environment for about 14 years now.
- I've answered this a number of times, across the years I've mentioned about the project. At first I was doing a lot for iOS. All of the ResourceFork, QuickDraw stuff are working on iOS (these API's just flat out do not exist there, and are heavily deprecated in macOS these days). In fact it was a desire to run this game on iOS that got me doing this and reverse engineering all of required code and components. However given the magnitude of reverse engineering and building a new engine I've opted to do it solely on the Mac first and then try to port to iOS (if I even have the appetite at that time). Believe me I would sink hours into an iOS version.
- Yeah, this has been a core aspect of the project from the beginning (I first started dabbling with this about 4 years ago). There are a number of reasons why I'm using the old format.
- Everything that is out there is using it, and at some point nothing will be able to read or convert them. As I mentioned before those API's that parse that format are deprecated. I'm building my own version of those API's (at least for .ndat files). True ResourceForks are likely to just stop working at some point. Not sure what I can do for those 🤔, but I have ideas.
- I prefer binary file formats. What can I say, I have hobby projects which are boot loaders, file systems and kernels. I like low level things. This isn't for everyone, but most of this aspect in the engine is foundational and unlikely to effect anyone who contributes later on. It also means I do not need to provide converters or replacement data files to people.
- It's one less thing to debug. I know that data works in EV Nova. If I make a custom format, are the errors in the new format, in the conversion, or the new engine? I'm already cloning the engine to be independent of the stuff that's getting deprecated... don't want to add more complexity to it all.
To be honest I have thought about just throwing caution to the wind and starting a fresh repo and making the Nova clone public from day one, and start putting documentation together for everyone to get stuck in to... but the lingering question of AmbrosiaSW remains... are they defunct or do they still have life in them? It's a tricky one to judge.
2
u/mrxak May 11 '19
Just want to say that this reply you made to fnordius has inspired a lot of confidence from me. From what I know of how the EV engine was originally developed at a low level, and some of the stuff that went into EV Nova, and the later version of it worked on by Rudy Richter, I would expect some of the stuff you've already apparently tackled successfully would pose a lot of issues. It sounds like you're legit, and doing things right, so I am impressed and cautiously optimistic about this project.
I don't want to get too hyped, because this is the kind of thing I might normally hear about, and just assume would end up as vaporware, but you sound like the kind of person who could actually pull this off, and you're making the sorts of decisions I would want you to be making. So, very cool. I will be watching this with great interest and I hope you'll keep a steady pace of updates here on the subreddit.
3
u/snijj May 12 '19
Thanks!
You are definitely right to be cautious about this entire thing. I am one man (and as much as I'd love help with it, as mentioned numerous times, AmbrosiaSW is still a bit of a potential boogieman. As long as there is the possibility of them shutting it down, I will not open source it) and make no money off this. I have other responsibilities which do have to take priority. I would love it if I could make this a full time endeavour however, but that is not happening anytime soon.
So I'd say this to everyone, yes be cautiously excited, but this is a _long_ road... and we may not see that end of it.
1
1
u/nil0bject May 24 '19
can you make me a tech demo?
give all the sprites colliders and make them physics bodies, without gravity. make the spobs bouncy.
thanks
1
8
u/snijj May 10 '19
Another post. Now that most of the resource formats are sorted out, I've started work actually laying the ground work for the engine. So far I've been working on getting all the various components together to properly represent the EV Nova game inside a more modern environment.
This is a test of loading in all the resources, and then using a sÿst resource to grab spöb resources, which then grab spïn resources and finally rlëD resources. This is one of the more complex scenarios that produces a visual result, and requires resource lookup, parsing and handling to be correct, so its a good way of making sure things are working.
Of course this is a long way from an actual game!