Radish Engine (SMBX Engine Remake)

[Cadwyn]

Sounds good, but I think getting a run-time level editor up and running would be the best first step. Don't worry too much about sprite replacing at this stage, as it's still closed testing. I'll do what I can on my end, but I'll have to first check out SMBX and then try to recreate that in GM, so don't wait up for me. Still new to the community and game making, but I'm excited to do what I can for this project.

[warioeagle]

Sounds good, but I think getting a run-time level editor up and running would be the best first step. Don't worry too much about sprite replacing at this stage, as it's still closed testing. I'll do what I can on my end, but I'll have to first check out SMBX and then try to recreate that in GM, so don't wait up for me. Still new to the community and game making, but I'm excited to do what I can for this project.

You're probably right about the editor. I have been wondering if I could make an editor that would save the map and levels in a way that GM would be able to create rooms from them with the proper blocks. I guess that should come before working on the stores since it'll just be blocks or a menu for buying stuff.

And you're right about replacing the sprites, but if the engine you linked is as complete as it appears, there won't be much to work on after that besides the editor and linking them together to test the levels from the editor.

[sschol]

I remember the Hello Engine pretty fondly. It used to be (maybe still?) popular on mfgg. You're definitely going to want to mess with slopes, if I remember the engine correctly.

[warioeagle]

What do you mean mess with the slopes? Does the engine not support slopes or do they act strangely? If that's the case, I can merge the engines together and make modifications to both until I have something that works properly.

[TheVipper75]

I would suggest you to use the Mario Builder engine instead of the Hello engine.
The physics are 100x better + a lot more stuff.

http://sandbox.yoyogames.com/games/1089 ... -exe-maker

[warioeagle]

I'll check out both engines once I get Pro. The main thing is I want it to be SMW physics, not SMB3, so I'll likely have to edit either one. If worse comes to worse, I'll use all these engines to create my own the way I want. Since it's possible that I may convert Radish back to Java at some point, it will help if I understood exactly what was going on in the engine.

The reason I may convert back to Java is for the easy modding abilities I want to have. I don't want my choice in blocks/enemies to be the only things you can have. I do want people to be able to add custom stuff, like you can with ASM in rom hacking, which also means not everyone will be able to do it, but those with related knowledge will.

[Cadwyn]

Playing around with Mario Builder, the editor is really neat and comprehensive, but at least when I do test plays the controls are really sluggish and hard to manuver, ala SMB1. Hello Engine plus tweaking is probably the way to go, gameplay-wise. That said, my amateur attempts at coding a prototype editor room this weekend went pretty shakily (but then again, this is literally the first time I've coded outside of schooling, so I guess that's not a surprise...) so I think it'd be smoother to try and adapt Mario Builder to the Hello Engine environment, and tweak it to SMW-level control, rather than try to do a proprietary editor from scratch. Main reason I wanted to do that originally was to utilize the ReadFile DLL rather than the file reading GML functions, but it seems it'd be easier to modify Mario Builder to use the DLL.

[warioeagle]

I should be getting Pro later this week, so sometime near the end of the month/beginning of next month. I'll start messing with things then. I'll play around with both engines, mix together if needed, tweak some stuff, then build some demo levels to get something out for some sort of progress.

I will be adding my own things, such as the death/demo counter and stores, so it won't be purely what the engines give you. I'll also need to edit at least a few sprites with the ASMT/A2MT equivilants, which I'll replace at least some of the Mario sprites for Demo.

As a side note, I will be giving credits to the engine creators that made any engine I use, no matter how much tweaking I may make to it. I may need to get a hold of some of the ASMT/A2MT music peeps and get permission for their music to be added as well. I don't think they'd mind too much, but I still rather ask before just using it regardless.

Edit: After watching a video and remembering that the cape's flying/floating and spin attack powers were already planned to be serparate, I've decided that I will still go with this plan. Probably one cape collar for one and a different cape color for another, unless I get completely different sprites for both. Video I was watching and was actually plugged (Man I've been trying to do this thing for a while, thinking about it): http://www.youtube.com/watch?v=XDFOmW437l0

[Cadwyn]

It sounds like you have a pretty good handle on how you wanna proceed. I'm still willing to help out, so keep us posted if you run into road blocks or need to delegate something.

[Alice]

Edit: After watching a video and remembering that the cape's flying/floating and spin attack powers were already planned to be serparate, I've decided that I will still go with this plan. Probably one cape collar for one and a different cape color for another, unless I get completely different sprites for both. Video I was watching and was actually plugged (Man I've been trying to do this thing for a while, thinking about it): http://www.youtube.com/watch?v=XDFOmW437l0

What about separating them into the SMB3 leaf and the cape? You wouldn't need to change how the leaf functions since it's not really overpowered and with the cape you could just do like some hacks do and disable the flying ability so it just gives you a super jump at full speed and keep the spin attack.

[warioeagle]

What about separating them into the SMB3 leaf and the cape? You wouldn't need to change how the leaf functions since it's not really overpowered and with the cape you could just do like some hacks do and disable the flying ability so it just gives you a super jump at full speed and keep the spin attack.

That may be an idea. I think the tail has a spin attack too though. I planned to keep the SMB3 style of flying regardless. I think that's a more balanced flying system, so getting a leaf then wouldn't mean fly through every level for the rest of the game. I do like the idea of a leaf and feather as two different things though. I need to find out how Terry's sprites are coming along though since I'm using the same sprites from the content replacement.

Speaking of Terry's content replacement, I think more ideas are needed for some replacements.

[sschol]

what I meant is that they act strangely. It's been a while but I recall that you get caught at the end of a slope and lose your momentum in full :(

[warioeagle]

I'll look into it when I get the Pro version. If anything, I'll tweak it then. It might be alignment of slopes and ground or something simple. It depends on how it's all coded, really.

[Alice]

I think the tail has a spin attack too though.

It does but it doesn't have the same range as the cape and isn't nearly as powerful.

[Cadwyn]

In light of SMBX's notorious sound issues, I wanted to post this now for when optimizing sound becomes relevant in this project down the line.

Somebody made a Fmod wrapper for Game Maker that seems to do everything you'd need for video game sound, including function replacements to convert an existing project to Fmod function calls, encrypted one-time loading of music and sound effects, and I think most relevant

Fast no delay rewind of looped sounds. (Requires Loop Points for files other than wav)

As has been demonstrated in the Megaman: DL series videos, it sounds like a genuine NES playthrough with no fade out loops.

Only possible issue might be the licensing, but unless we have serious prospects of selling the final product it should be free.

[warioeagle]

Well, I got the Pro version of GM and been messing around with the engines. Hello engine seems to be great physics wise. My only problem was my keyboard, not the engine. Marios are not meant to be played with keyboards when you can only hit two buttons.

I can't get MarioBuilder to work though. It loads up and takes me to a screen that I'm assuming is meant to be the engine, but I can't make it do anything from there. No buttons I pressed do anything. I tested it from GM. Does it only work from a standalone EXE or am I doing it wrong?
Edit: The file I got was meant to work with the actual builder. I got it to work now. As far as editor, I think it does a great job, but I'm not a big fan on the physics. The info on the engine says not to just plugin Hello engine, but I planned to tweak them both until they worked together, not just combine them and hope for the best. Still planning on leaving the editor out for now as tweaking them to work together will definitely take the most time to make work properly.

At the very least, I expect MarioBuilder to be the level editor part and Hello Engine will likely be the physics. Codes from both seem to be easy enough to follow. It shouldn't be hard at all to tweak things. I think I might change Hello Engine's spin jump though. It's currently set to holding up while jumping, but I think it will be easier to just give it it's own key. I'll also tweak the strength, so it's not going to provide as much immunity compared to SMW.

As far as updates/demos are concerned, I'm only going to provide the physics engine with some changed graphics at first. I believe changing physics will be easier than tweaking the editor and adding in all the items and have any sorting systems I may want to use, like how LM and SMBX divide up different things.

[Zaidyer]

About physics:

Hello's are the worst of the worst. You'll have to come up with something new.

Nobody has gotten Mario physics right yet, because they didn't have these reference sheets.

I suggest using the one for SMW since that's the favorite around here.

Note that his measurements for subpixels are kind of overcomplicated. In SMB3 and SMW, subpixels are a one byte hexadecimal measurement.
For example, Mario's walk speed is written on the guide as "0140", which means one pixel and 40 subpixels out of a possible FF subpixels. In Game Maker, you can render this as a math expression, "$40/$FF+1". (GameMaker will read a number as hex if you prefix it with the $ symbol.)

[warioeagle]

That is definitely some interesting knowledge there. Maybe Hello's downfalls are more obvious when you can press more than two or three buttons (stupid keyboard limitations). I didn't like how it was organized at all though and was planning to basically recode it to be easier to follow personally.

However with the highly detailed physics chart you linked, it might be possible to tamper with making my own engine like originally planned. That would push back the project pretty much to the starting point again. It's not really that bad since I still need a lot of replacement sprites and didn't really want to release Radish with A2MT still being wrapped up.

I'll see what I can do with the link you gave me. I've never had something that detailed and reasonably easy to follow before. Maybe something very close to SMW will come out of it.

[Cadwyn]

Since you seem really keen on the physics engine side of things, I was wondering if it would be okay if I spear-headed the editor portion. Now that the STTB LP is concluded, I'm thinking that game should be more or less the benchmark we should aim for in terms of what can be done (otherwise might as well stick with SMBX as is). In terms of coding I know at least I wanna make heavy use of scripts to hide the implementation. I should be able to not have to worry about how you're implementing the physics side while working on the editor, and vice versa with you. Basic OOP principles, y'know?

To that end, putting together something resembling a design document would be in order. I've never done one before, but good a time as ever to learn I suppose. Also will be getting my hands on a copy of Head First Java soon, so I can at least follow along with and possibly contribute to the programming side once we incorporate Java.

I also tracked down the original talking times forums and plan to ask them about what sort of features/improvements they'd like to see, and what issues came up constantly with SMBX. If I can at least get SpoonyBardOL to talk, that would be a big help for us in knowing what to expect of this project in the end.

[warioeagle]

That may not be such a bad idea to split up the two like that. We should be able to combine them fairly easily, I think. Just need to connect the proper sprites in the editor to the objects and physics in the physics engine and all should be good.

I would assume adding custom stuff was an issue as Terry and I even had some issues replacing graphics (added a code for one of the Goombas to work, though didn't animate correctly still). I've heard that they're actually creating their own replacement for SMBX using SMB3 physics. Don't know if they have a thread for things they want to see improved over SMBX or not though.

If/When Radish transfer to Java, it shouldn't be too much of a hassle. Assuming everything works out in GM, I believe it should transfer over fairly well. Some tweaking would be needed from GM scripts to be proper Java code, but I don't think it'll be much of an issue. The biggest thing would probably be graphics (reason why I wanted to work in GM first), but once a good system for that is figured out, I think things will be fine.

[Cadwyn]

So I asked over at the Talking Time forum and almost immediately got feedback from both Zaidyer and SpoonyBardOL. So, awesome. Using that input I wrote the skeleton of a design document for Radish, starting with the points I've been mulling over this weekend.

First, the link: https://docs.google.com/document/d/166i ... KpTIo/edit

Let me know if you want to contribute, and I'll add you as a collaborator. I'll also be updating it whenever I get the chance and we've had some brainstorming and/or need a technical issue worked out.

Anyway, on to the two major points I've been pondering: nailing down the screen resolution, and addressing the overworld path issue.

First, the resolution:

I came up with two proposals on how to handle the issue of game resolution, both Standard Definition and sized so that a single screen view is X number of blocks wide and high precisely.

The first is 320x240:

This will create a view 20 blocks wide and 15 high. By automatically porting it to double size (640x480) we'll avoid the problem where other mario fangames are too tiny in Windowed Mode. For comparison, here's Super Mario World:

And 320x240, ported to double size:


The second is 512x384:

The main advantage is it has the largest display (32 x 24 blocks!) but the sprites look a bit small. If we had the option of hitting F2 or F3 to double the Window size, that's still within modern monitor standards (1024x768) without getting too big. Here's the standard size for 512x384:

And here's Super Mario Bros X for comparison:


My question is, which do you prefer? I like 512 myself as I think it has the biggest potential to level builders by having so much screen real estate, and the large size isn't much of an issue with modern monitors.

The second point is mostly a slightly technical explanation for the Path Layers I came up with for the overworld map:

The main issue with map paths in SMBX is when you clear a level, all paths connected to that exit are revealed all at once. This means, for instance, the inability to do tricks like in SMW's Chocolate Island 2 which had a normal exit looping back to the level, requiring the secret exit to reveal a path leading through the loop to the next level. In SMBX, revealing one path reveals both, and there's no workaround for that.

My proposal is Path Layers. Essentially, every level has 4 layers associated with it; Layer 1, Layer 2, Layer 3, and the rarely used Layer 0.

When an exit is cleared, it clears the associated Path Layer, revealing any path tiles placed on it. As you can guess by the image, there's the potential for up to four exits per level, but most levels will only ever use one or two. By default Layer 0 is reserved for the path leading to the level, but you can assign an exit to it. If an exit ever opens a path that's already revealed, no animation occurs. If multiple paths lead TO the level (rather than away) they're filled in starting with Layer 0, then 3, 2, 1. Since 4 is the max number of paths leading to or from a level, that's the hard limit for exits, though you can place additional rewards within a level.

Furthermore, since each Layer is independent, they don't care if they cross over.



The cross-sections can be accomplished by making the path segments objects that check for collisions across layers if said layers are revealed, and substitute the appropriate sprite index to show they now cross.

There's even more potential in this system if we allow the editor to freely dictate which layer a path segment belongs to. This can let you make "multi-exit paths" that require finding two or more exits to create a full path to the next level. You would simply put some path segments on, say, Layer 1, and the rest on Layer 2. The player needs to clear both exit 1 and exit 2 to get to the next level. May not be a good idea, but that's game design decisions I'd prefer to leave up to level designers.

[warioeagle]

That looks like a good document you've written up. I have no complaints about it. As for screen resolution, I like the first option a bit better, but no one said we couldn't include all the options. I don't know about GM, but I'm sure I can work something out in Java for that. The path issues could be a little trickier, but I think that layer thing you suggested could work out. Four layers aren't really needed and one of them would be a dummy exit anyway as it would just be the path that led to the level to begin with.

I would like to say that I'm thinking a SMB3 style map would probably be what we use since it's easier to code straight lines than curves (like SMW has). I think it would also be easier to keep that style for checking purposes so people can't glitch up a map, like they can with SMW with map exits done incorrectly.

[Alice]

For screen size I'd recommend something like 1x, 2x, 3, and 4 or maybe even 5x zoom then letting the player set whatever resolution they want. Especially if it has a full screen mode. It may show a larger area than you'd want but limiting players to just a few preset resolutions isn't the best of ideas.

[Cadwyn]

The purpose of the 4 layers was to accomodate the 4 possible directions that paths could take from a given level, and to allow for, say, a "hub" level that had 4 exits, each leading to a branching path that went to a different part of the map. That said, I do like the idea of a SMB3 map, but would it have hidden paths or "found" paths like in SMW? The problem with the found path was my main objective in solving, it could work with SMB3 graphics too if that's what we decide on.

As for resolution, I'm fine with supporting multiple scaling, from x1 to x5 plus full screen. My concern is how large should the screen's layout be? One of the things people recognize immediately about SMBX is the size of the view, and it's not just because it's ported to 800x600, in terms of screen real estate Mario is almost half the size as in SMW, so levels are noticeably bigger relative to the character, and you can see a lot around them. That's my concern; what is the "x1" window size going to be?

I feel that the gameplay is tied to the relative size of the UI (see how SMW plays differently than SMBX, and not just in the control physics), such that it shouldn't vary at will. I can see it being set in the editor (maybe as a game setting on the worldmap), but that can create conflict with any levels you add to a given game, and I think the modularity is an important aspect to keep to encourage collaboration. So either there should be a set "minimum resolution" that serves as the basic "size of Mario relative to the screen" measurement, or said minimum can be set per game, and levels that were made under a different assumption will just look weird. Either way you can scale it up of course.

[warioeagle]

What I meant by the SMB3 style map is that Mario/Demo will move say two blocks per direction pressed and it'll all be straight paths and corners, no curves. I was just talking movement wise. Path wise, we can still have everything hidden, so it could be like SMBX, but each exit only reveals the proper path it unlocks, not all of them.