Prince Of Persia FX- is it doable?

I would be surprised if it wasn’t. Anyhow, Jordan Mechner saw my Karateka conversion on the Arduboy and the Pokitto and gave it a big thumbs up! He didn’t care.

2 Likes

Does he hold the rights? Hah, yeah I mean, not super worried about it just curious.

Probably not anymore.

Edit: Looks like UbiSoft has bought the rights > Prince of Persia: Sands of Time Remake | Ubisoft (ANZ)

1 Like

Looks like it’s a trademark of Waterwheel Licencing LLC

© 2020 Ubisoft Entertainment. All Rights Reserved. Based on Prince of Persia® created by Jordan Mechner. Prince of Persia is a trademark of Waterwheel Licensing LLC in the US and/or other countries used under license.

Edit:
Which seems to be Jordan himself:
https://opencorporates.com/companies/us_ca/201005010361

1 Like

Time to start calling it Prince of Prussia then? :P

Nah, then we have Georg Friedrich suing Kevin :stuck_out_tongue_winking_eye:

1 Like

Given that Jordan himself seems to still own the trademark, and that he seems very supportive of previous demakes of his work, I think we’re fine. If the request came in to change it, I’d be happy to comply, but I doubt that will happen.

In fact, I’d love to share it with him, @filmote -style, once it’s ready.

1 Like

It’s good to be cautious. Being open to changing the name is good. I’ve dealt with game lawyers before I don’t want to go through it again.

The only concern would be if they hold any rights to the layout of the map. I think the artwork is ok since you drew it yourself.

(Henk Rodgers was a big fan of Arduboy, still had to fork over a lot of money. Lawyers.)

1 Like

Got the bulk of the character animation sprites converted (via imagemagick). It took a fair bit of tweaking the various steps to find a solid happy medium, but I’m really happy with this as a starting point. I can always manually tweak a few pixels here and there, but this is all automated and repeatable at this point.

Here’s a simple loop through all the sprites. I drew it over a typical floor tile with black background to make sure it looks good in the most common scenario. Note: the sword sprites were separate in the original. I’ll add those manually to the appropriate frames.

12 fps @ 200%
kid

12 fps @ 100%
kid

Sample original sprite for reference:
0407

5 Likes

That looks really good.

When do you start development?

Those animations have more life in them than quite a lot of modern games.

Things get a bit boring when everyone’s using the same plasticky shaders on their 3D models.

1 Like

Not for a little while. I start the Arduboy STEM program with the students in a week and a half, and I’ll be busy prepping for that.

Before I get into coding the game, I’ll also have to write some conversion scripts or plugins for Tiled to prepare the level graphics, along with the various object layers (spikes, gates, switched, etc).

I’ll also need to start educating myself about writing a VM to support animations from sprites on the FX, and perhaps even store some game logic instructions (i.e. maybe only have the general movement logic ‘in play’ while needed. Same with the combat logic (i.e. sword drawn state).

I have a work sabbatical I may start in July. That would be when the majority of the development would be done.

I’d suggest deciding what kind of logic you need first.

You might actually be able to get away with using state machines instead if it’s just a case of “play animation Y when character is in state X”, and how many different kinds of characters/entities you’ll have.

1 Like

Thanks, Pharap. Yes, I certainly need to start here. I’ve got a doc started, but I need to spend some more time going through all the known requirements before building anything.

I also want to spend a good deal of time looking at how the original code works, and looking at various adaptations to help me figure out my initial approach.

I’m guessing that it’s a big state machine in most cases, but there are a lot of states to track and transition from → to. More than I’d figured there would be (from what I recall looking at the original code base, but I didn’t dig too deeply and it was a while ago).

Another factor is that I’m basically unwilling to make any gameplay concessions. I don’t want to simplify any elements, if at all possible. I’d like this to be the sort of thing that a person who, for instance, speed runs this game, I want them to feel right at home on this version. I’d love for them to be able to put up similar times, and basically be a ‘perfect’ port as far as gameplay goes. Most ports, especially the console ports, don’t accomplish this, in various ways.

I also don’t really have a grasp of how much I can fit into an Arduboy game, but when I see how many games which are far simpler are getting close to the memory limits, I’m anticipating that I’m going to have to do a lot of optimizations to get this to work.

But… that’s the most fun part of this project. I program for a living, but primarily on web applications and standard application backend services. I’ve never worked on a game before, much less with these constraints, nor even with C++. But… I love learning new things. I’ve learned a lot already, and have a mountain more to learn ahead of me.

I think the constraints of the Arduboy are what really make it fun, not just from a programming standpoint, but even as far as design challenges go. It’d be much easier to have 2 (or 4) times the resolution, and, say 4 or 6 shades of gray, but it wouldn’t be as satisfying as it has been thus far trying to get things looking authentic and detailed at such a small scale.

1 Like

The FX chip is 16MB if I recall correctly.

As long as most of your states are immutable, you can fit a heck of a lot on the FX.

In particular, I’m thinking if you represented each entity’s current state as an integer index or pointer, with maybe a few extra variables if necessary for other things, then you could stuff all the states into the FX as some sort of linked list of states.

But I don’t really know much about the game, so I’m guessing by what little I’ve seen.
E.g. I have no clue what kind of patterns enemies follow, I’m thinking more from the side of running animations - a looping list of frame indices stuffed into each state seems quite simple.

Mostly games made before the FX was introduced I should point out.

We haven’t even begun to make proper use of the FX - you’re standing at the forefront of innovation with the rest of us.

I might be biased, but I definitely think you’re missing out there.

Even when this game is over, I highly recommend having a go at writing your own linked list class with C++ on desktop.

If you’ve never caused a segfault or memory leak then you’ve missed out on a true right of passage. :P

(I’m only half joking - those things give you real respect for how difficult memory management is and how useful GCs truly are.)

I’m just going to leave this here in case it’s of interest.

That should be the case. I need to look more at the FX libs and get my head around what I can and can’t do. But, yeah, thinking about it a little more, a VM is likely jumping the gun. I think most data should be immutable. There will be some logic for handling the various animation states, and the combat logic and related AI, but beyond that, it’s mostly just levels and a handful of object states (i.e. is the gate closed, closing, opening, open, etc). After that, there are a fair number of ‘special case’ sequences in the game that only happen in one place. I just need to make sure that I have enough space on the arduino to fit these all in. There are a few between-level cinematic sequences as well, but they could be essentially shown as ‘movies’ directly from the FX if need be (as opposed to programming/rendering the characters involved frame by frame), which was one of @filmote 's early suggestions.

I have 8MB storage on my DIY FX, but I wouldn’t need anywhere near that for this game. As long as I can store and use all immutable data there, this may not be too difficult to pull off. My main goal is simply to have everything I possible can on the FX to make sure I have space to include all the small details that really make this game special.

I’ll have to spend a little more time looking at how the states are managed in the original code - I’m not sure if a linked list will work, but it might, and if so, that’ll be a great way to manage it.

Thanks for the links. I’ll definitely have a look. Especially at the C++ stuff.

1 Like

Pico-8

3 Likes