[T-Bone]

Was Regent Park. Ironically I felt more safe visiting friends in the Jane and Finch area than I did going home. Though I will admit both communities I'd never hang around at night lol Especially not in the 90's.

This post has been edited by T-Bone: 06 October 2014 - 08:12 AM

[Graham]

Are you playing Mario world or Mario bros 3 as inspiration? Or do you know them so well it's not necessary? Or are you designing levels without that inspiration?

[T-Bone]

In terms of level design I've actually been (as of recently) referencing a lot from the New Super Mario on the Wii (and Wii U) as they seem to be a lot more linear and directional from left to right. But of course a lot of my research comes from playing SMB3 and SMB2 since many of the enemies, blocks and terrain come from both games. Also I find those two games had a lot more clever level design. So basically its an integration of all 3.

There are elements of Super Mario World in it however the levels in SMW were designed with the flying cape in mind. In Super Mario for MZX its more of a right to left type of platform which is more similar to SMB1, ultimately. There will be rare instances where the levels make use of vertical boards.

You will notice enemies from Super Mario RPG and the Wii games included as well. Some of which have never been introduced on a platform stage of Mario in the past. So really its a combination of SMB1, SMB2, SMB3 and New Super Mario Bros on Wii. Most of the dynamic sprites come from SMB2 and SMB3. I think I may have even included a few sprites from Super Mario Land in there as well that I have yet to integrate.

To directly answer your question, I felt inspiration from the original games, where otherwise the level design may not give the same Super Mario feel. I noticed that they have signature spacings for items, blocks and enemy placement. And basically an arch of difficulty as the levels progress but while maintain fun and rewarding elements in each stages.

This post has been edited by T-Bone: 14 April 2014 - 03:32 AM

[smilymzx]

Hope you can make it through the game release, I wish you good luck Mr.T!

This post has been edited by smilymzx: 13 March 2014 - 03:05 AM

[asgromo]

So i was reading my posts from ten years ago in this thread and they are pretty depressing

[T-Bone]

Here's what's currently got me busy. I'll continue to update this post till all the bugs have been cleared and features added.

BUG LIST

* Mario sometimes will appear in the ground after grabbing any type of pick up.
* Trouter does not lift small Mario.
* Sometimes when you hit a coin block that contains a powerup, the block will then appear 1 space lower.

FEATURES LIST

☐ There will be 100 coins in each stage (+hidden coins)
☐ Bouncing fireball physics
☐ Entrance and Exit Pipes (with animation)
☑ Ice Flower Power
☐ Star Man Power
☑ Stop Watch to freeze enemies and time (from SMB2)
☐ Hitting enemies with fireballs turns them into coin sprites
☐ Create Coin Sprite (might have this already scripted)
☐ Snowing animation for World 6
☐ Massive tree overlays for Forest Level.
☐ Flying Koopa Troopas
☐ Flying Goombas
☐ Boom Boom boss
☑ Wii/Wii U sound effects
☑ Center Status HUD
☐ Unique Mario death animation and sound effects
☐ Moving Platforms
☑ Hold Z to run (optional)
☐ Press X to jump instead of up arrow
☐ Assign one color from the palette to be used uniquely per stage.


Attached are some screenshots of the game's current visual progress.

Attached thumbnail(s)

• 
• 

This post has been edited by T-Bone: 22 December 2014 - 04:48 PM

[T-Bone]

Crazy to accept... that this thread is almost 11 years old.

[Graham]

T-Bone, on 16 November 2014 - 10:37 PM, said:

Crazy to accept... that this thread is almost 11 years old.

I must have missed the notification about your previous post. That's a lotta features. Are they all implemented already?

I'm glad you are still working on this. I know what it feels like to want to have it out there for people to play. If you want any help with any of the bugs, let me know. I'm pretty good at finding them in my own games at least, and the ones you've listed feel very reminiscent of the kind I've taken care of. I could even just consult with you about them, if you'd rather not reveal the game to me.

What is the progress with level design? Are you all done with that?

[T-Bone]

The features are all about quarter-ways implemented. The Level design is slow but its happening. I've taken extra care in the placement of many things in it.

After all this work with this game there is a feature I kind of wish MegaZeux had where you could within the editor tell it what board is using what .CHR character sheet. Switching boards would automatically change the .CHR character sheet (and .PAL) to what the board has assigned it. Bit late on that wish.

Sadly I'm now coming across even more bugs than what I have listed above. If I can't seem to find a ways around I may request help for sure when it reaches that point; which is most likely.

[Graham]

Do the best you can with the bugs, but realize they will continue to pop up until you are done designing, and that squashing them all would be a waste of time at this point.

Only when you are through designing and into beta testing can you begin to make headway in removing all bugs. And realize with a game that complex, you can never remove them all, it's just not possible. Just get it to a point you can live with. No game crashers, obviously.

The idea you mentioned should be added to the feature request thread, it's a very good idea.

[T-Bone]

Actually the bugs are what is holding me back from the design part in fact. The basic mechanics of the engine is breaking. So I may have to hold off on some of the features as they seem to be a couple of the causes.

The big bugs come from poorly putting together the engine model from the start. But there's no going back considering how far I've come with it. Realistically should have allowed Sprites to pass each rather than bump for the player. This has been where most of the issues come.

This post has been edited by T-Bone: 20 November 2014 - 07:44 PM

[Graham]

T-Bone, on 20 November 2014 - 11:40 AM, said:

Realistically should have allowed Sprites to pass each rather than bump for the player. This has been where most of the issues come.

That's not too hard to fix, actually. Give every enemy sprite (or whatever you want the player or other sprites to pass) a counter. when the sprite is being initialized, with the other counters you are already setting to define sprite parameter's, insert

set "spr&spr_num&_passthru" to 1

use the number of the sprite at &spr_num&

You probably have your robots checking for collision with other sprites using a loop similar to this

loop start
if "spr_clist&loopcount&" = -1 then "skip"
send "sprite('spr_clist('loopcount')')" to "touch"
goto "blocked"
: "skip"
loop for "('spr_collisions' - 1)"
goto "continue"

Just insert a line of code that checks if that sprite has the passthru counter set, like this

loop start
if "spr_clist&loopcount&" = -1 then "skip"
if "spr('spr_clist('loopcount')')_passthru" = 1 then "skip"
send "sprite('spr_clist('loopcount')')" to "touch"
goto "blocked"
: "skip"
loop for "('spr_collisions' - 1)"
goto "continue"

So then any sprite with this designation will be ignored when collision with it is encountered.

This post has been edited by Graham: 21 November 2014 - 05:21 AM

[T-Bone]

I may need to use a batch system to make some changes. Considering the amount of robots I have externally. Also hopefully I'll get sometime tonight or tomorrow to post my basic Gomba script so you can see where I'm with at least the basic enemy code.

The problem I've had in the past was checking what direction the collision came from to register either a stomp or mario hurt. So I had to avoid the collision list counter for some time due to this and simply use the if c?? sprite p01 at "x" "y" command. x and y being the enemy's sprite location with an additional sequence to check a direction.

This post has been edited by T-Bone: 21 November 2014 - 10:06 PM

[Graham]

T-Bone, on 21 November 2014 - 02:04 PM, said:

The problem I've had in the past was checking what direction the collision came from to register either a stomp or mario hurt.

Do you mean whether Mario stomped on a Goomba, or the Goomba hurt Mario? The Mario and Goomba programs should each be using their own collision routines.

When Mario is in the downward slope of his jump, I would have the program set a counter like "stomp" until he touches ground. That way the Goomba program can check if the stomp counter is set when he detects Mario is colliding at 0 -1.

Or else, whenever Mario is touching a sprite at 0 1, have his program send the robot controlling that sprite the label "stomp".

[Graham]

I guess it will have to work differently if it's set up using the if c?? sprite p01 at "x" "y" command, but it can be done.

I've heard from game developers on podcasts time and time again that your game is never done. It just gets to a state where you have to release it, it never truly gets to the level you wish it to be.

I'm still struggling with the desire to add more stuff to my game. I'm trying to get to a place where I'm ok with just finishing what I have and debugging it and putting it out there. I have a feeling that you are too.

[T-Bone]

Quote

When Mario is in the downward slope of his jump, I would have the program set a counter like "stomp" until he touches ground. That way the Goomba program can check if the stomp counter is set when he detects Mario is colliding at 0 -1.

That's pretty much exactly what I have going on. It sends stomp down and depending on what enemy it is, it reacts accordingly. Mario always sends a stomp down if he collides with a sprite.

Quote

I'm still struggling with the desire to add more stuff to my game. I'm trying to get to a place where I'm ok with just finishing what I have and debugging it and putting it out there. I have a feeling that you are too.

Yep!

Its funny how many times I've redone this game. Its been quite annoying. I started it when MZX was only in DOS with no sprites at the time and not many overlay counters. So its changed a lot. I am almost too exhausted at this point lol

Its hard to explain how it all works I guess without the other robots included. When I get some time I'll upload the engine.

Here is the example of the goomba script:

Sprite c00 is Mario and enemies generate their sprite number based on their name which is a number i give them on the board. A separate robot that builds the stages sends the label "March" to all robots once its done its sequence.

set "bot_goomba.txt" to "save_robot"
. "Brown Goomba"

: "respawn"
cycle 1
wait for 1
lockself

set "$string&rid&" to "robot_name"
set "local5" to "$string&rid&"

set "spr&local5&" to 1
set "spr&local5&_cx" to 0
set "spr&local5&_cy" to 0
set "spr&local5&_static" to 0
set "spr&local5&_overlay" to 0
set "spr&local5&_vlayer" to 1
set "spr&local5&_ccheck" to 2

. "Sprite Size"
set "spr&local5&_width" to 2
set "spr&local5&_height" to 1
set "spr&local5&_cwidth" to 2
set "spr&local5&_cheight" to 1

. "Sprite Drawing Space"
set "spr&local5&_refx" to 4
set "spr&local5&_refy" to 0

unlockself

end
: "March"

. "----WALK WEST"
: "wes"
if "spr&local5&_x" <= 0 then "eas"

if c?? Sprite_colliding "local5" at 0 1 then "morewes"
goto "fall"

: "morewes"

if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y'-'spr0_height')" then "stomp"
if c?? Sprite p00 at "('spr&local5&_x'+1)" "('spr&local5&_y'-'spr0_height')" then "stomp"

if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y')" then "ouchw"
if c?? Sprite p00 at "('spr&local5&_x'-1)" "('spr&local5&_y')" then "ouchw"
if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y'+1)" then "ouchw"
wait for 2
if c?? Sprite_colliding "('local5')" at -1 0 then "eas1"
dec "spr&local5&_x" by 1
wait for 2
: "wes1"
if c?? CustomBlock p?? at "spr&local5&_x" "('spr&local5&_y'+1)" then "wes"
if c?? CustomBlock p?? at "('spr&local5&_x'+1)" "('spr&local5&_y'+1)" then "wes"
goto "fall"

. "----WALK EAST"
: "eas"
if "spr&local5&_x" >= "board_w" then "wes"

if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y'-'spr0_height')" then "stomp"
if c?? Sprite p00 at "('spr&local5&_x'+1)" "('spr&local5&_y'-'spr0_height')" then "stomp"

if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y')" then "ouchw"
if c?? Sprite p00 at "('spr&local5&_x'+2)" "('spr&local5&_y')" then "ouch"
if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y'+1)" then "ouch"
wait for 2
if c?? Sprite_colliding "('local5')" at 1 0 then "wes1"
inc "spr&local5&_x" by 1
wait for 2
: "eas1"
if c?? CustomBlock p?? at "spr&local5&_x" "('spr&local5&_y'+1)" then "eas"
if c?? CustomBlock p?? at "('spr&local5&_x'+1)" "('spr&local5&_y'+1)" then "eas"
goto "fall"

. "---FALL"
: "fall"
if c?? Sprite p00 at "('spr&local5&_x')" "('spr&local5&_y'+1)" then "ouch"
if c?? Sprite_colliding "('local5')" at 0 1 then "skip"
inc "spr&local5&_y" by 1
if "spr&local5&_y" >= "board_h" then "killself"
wait for 1
goto "fall"
: "skip"
goto "eas"

: "ouch"
send "Hurt" to "#hurt"
wait for 1
goto "wes"

: "ouchw"
send "Hurt" to "#hurt"
wait for 1
goto "eas"

: "stomp"
sfx 5
give 10 SCORE
set "pounce" to 1
send "MARIO_ENGINE" to "#jumper"
set "spr&local5&_off" to 1
end

: "#bumpy"
. "bump comes from if mario hit a block from under this sprite"
play "&sound10.ogg&"
give 10 SCORE
set "pounce" to 1
dec "spr&local5&_y" by 1
wait for 1
set "spr&local5&_off" to 1
end

: "freeze"
: "#freeze"
restore "#freeze" 1
play "&key.wav&"
wait for 50
goto "#restore"


: "killself"
: "burn"
if "playerx" > "('spr&local5&_x'+'mario_ears')" then "skipsound1"
if "playerx" < "('spr&local5&_x'-'mario_ears')" then "skipsound1"
sfx 5
: "skipsound1"
give 10 SCORE
set "spr&local5&_off" to 1
set "spr&local5&" to 0
end

: "#pause"
zap "#pause" 1
end
: "unpause"
restore "#pause" 1
goto "#return"

This post has been edited by T-Bone: 23 November 2014 - 01:08 AM

[T-Bone]

I've made some serious progress with the game. Fixed a number of bugs and the first stage is completely playable and smooth from start to end. I'm getting really excited to pave out all the technical stuff and dive right into complete level design. That was my originally intent many years ago. Complete the mechanics of EVERYTHING and just be left with level design and it seems im almost there!

2015 should be when I start rolling out levels. Can't believe I started this game in 1998, My oh my.

[Graham]

T-Bone, on 16 December 2014 - 09:38 PM, said:

I've made some serious progress with the game. Fixed a number of bugs and the first stage is completely playable and smooth from start to end. I'm getting really excited to pave out all the technical stuff and dive right into complete level design. That was my originally intent many years ago. Complete the mechanics of EVERYTHING and just be left with level design and it seems im almost there!

2015 should be when I start rolling out levels. Can't believe I started this game in 1998, My oh my.

Great! now try to ignore the temptation to add any more features or ideas, lest you break the levels you just got working and introduce more bugs. Haha.

Glad you are making good progress again. One thing that helps me stay on track is a list of goals

Granted the goals in my list are rather broad and it helps to make smaller, more focused goals, but it's still helping me stay on track. I find I get a lot more done and have a method of measuring progress when I plot my goals like this.

Also about level design, I can rarely ever design a good level when I'm creating them in MegaZeux. It takes plotting them down on paper first, usually during break time at work, to come up with good ideas. Some times I do my best thinking away from the computer, its usually when I'm at work thinking about my game that I think of a solution to a bug, or come up with a cool idea for a level.

Keep going, you're almost there!

P.S.-How many stages are you planning? Is it typical classic Mario game length?

[T-Bone]

Believe it or not I actually use one of the boards in the game to just jot down notes and goals. I really like your idea of mapping out your level on paper! I used to do this all the time many millenniums ago. Should keep me busy while on work breaks and such and not at a computer. Thanks for the idea I'll totally use it. Be something neat to add to the documentary I'm working on with MegaZeux. Pretty much documentary the entire history of working on this game as it well establishes my relationship with MegaZeux from start to end(?).

Quote

P.S.-How many stages are you planning? Is it typical classic Mario game length?

I was originally going to go with 5 stages per world (8 worlds) = 40 boards.

This post has been edited by T-Bone: 18 December 2014 - 04:48 AM

[Graham]

You're welcome. =^)

T-Bone, on 17 December 2014 - 08:47 PM, said:

I was originally going to go with 5 stages per world (8 worlds) = 40 boards.

Have you reduced that number, or is that still the plan?

[T-Bone]

Due to the lack of activity on the forums lately, I may just reduce the stages to 1 or 2 per world. Meaning no more than 16 stages in total. If I see the game is received well by the community I would than go back to plug in filler stages. I may use Youtube to help promote the game once its closer to being completed. I noticed there is quite the nostalgia for all things Super Mario and even games with retro graphics. With this being 1 bit as opposed to 8-bit... it stands as quite a unique Super Mario game. I think I can use this advantage to advertise it as a "1-Bit Mario Game" and hope that it fairs well over on the twitter sphere and youtube world.

I really wish the front page of the website would get improved to highlight newly released games. I'd hate to see the game become just an update at 9 point size font, buried in a list. Very thankful we have started up the Facebook Page at the very least which can provide developers a great way to present their accomplished work and releases.

[Graham]

T-Bone, on 19 December 2014 - 02:21 PM, said:

With this being 1 bit as opposed to 8-bit... it stands as quite a unique Super Mario game. I think I can use this advantage to advertise it as a "1-Bit Mario Game"...

Could you explain what you mean by 1-bit? Is that in reference to MegaZeux's limited color palette or two-color characters, or they way MegaZeux executes code? Traditionaly it's meant to signify how many bits the processor can read per cycle right? By that definition all MegaZeux games are either 32 or 64 bit. Little confused here.

[T-Bone]

It was Exophase who once came out to correct us and say it was 1-bit and not 2; Which I originally had thought it was. I believe he was referring to the two colour characters since the back color was essentially not a colour and just an adaptive overlay of whats behind it.

Quote

Quote

smilymzx, on May 27 2004, 08:42 PM, said:
yeah man, some 8-bit --> 2-bit sprites are good conversions
_________________________________________________
super nes, gameboy, & nes sprites are good!

SNES sprites are at best 4bit. NES and Gameboy ones are 2bit. MZX ones are 1bit, except in SMZX mode (2bit there). But the consoles also have normal transparency, and MZX doesn't really. Anyway, getting console sprites to look good in MZX is challenging. I'd still prefer to see some new sprites for a change though..

- Exo

Though when I think of 1 bit graphics I think of monochrome...

This post has been edited by T-Bone: 20 December 2014 - 01:06 AM

[Graham]

Hmm, thanks. Good to know.

[Graham]

Hmm, thanks. Good to know.

[T-Bone]

Bug Fixes / Changes

- Fixed death animations
- Fixed powering-down and powering-up graphics
- Mario can no longer jump out of pits, avoiding death
- Fixed Mario shrinking into ground
- Changed all SAM commands to Play commands. Surprised I've still been using such an old command to play soundfiles.
- Converted most SAM files to WAV and MOD files to OGG.
- In game pausing fixed. You can now pause and unpause with "enter".
- Coins no longer return to 0 if you die or beat a stage.
- fixed holding left shift or right shift to look further (SMW feature)

Noticed a bug that could be related to MegaZeux itself (or just my lack of full understanding and usage of subroutines); Whereas robots are not always "#return"ing to their original programming after being sent a #pause state and then an "unpause" with a following "goto #return". So I'll have to add an extra "goto" command under the "goto #return" command for in these rare cases. I'm going to have to find a clever way to make this work correctly for turtles who have multiple start states for walking or in shell.

This post has been edited by T-Bone: 23 December 2014 - 04:31 AM

[Graham]

T-Bone, on 22 December 2014 - 08:47 AM, said:

Noticed a bug that could be related to MegaZeux itself (or just my lack of full understanding and usage of subroutines); Whereas robots are not always "#return"ing to their original programming after being sent a #pause state and then an "unpause" with a following "goto #return". So I'll have to add an extra "goto" command under the "goto #return" command for in these rare cases. I'm going to have to find a clever way to make this work correctly for turtles who have multiple start states for walking or in shell.

Check for proper syntax. Are you missing any #'s anywhere? Are all words spelled correctly? I sometimes gloss over those when I'm looking for bigger problems. Like I might spell return like- retrn and not immediately notice. Also sometimes I don't notice I failed to add the #. I know you are a seasoned programmer so you most likely already checked these things, but thought I'd mention it.

Also, are the robots receiving any other labels while they are paused, causing them to resume running in a different part of their program?

So far I have not had any trouble with this method of pausing and unpausing.

This post has been edited by Graham: 22 December 2014 - 09:59 PM

[Kuddy]

needs more piantas

[T-Bone]

Quote

Check for proper syntax. Are you missing any #'s anywhere? Are all words spelled correctly? I sometimes gloss over those when I'm looking for bigger problems. Like I might spell return like- retrn and not immediately notice. Also sometimes I don't notice I failed to add the #. I know you are a seasoned programmer so you most likely already checked these things, but thought I'd mention it.

Also, are the robots receiving any other labels while they are paused, causing them to resume running in a different part of their program?

So far I have not had any trouble with this method of pausing and unpausing.

Spelling seems to be okay and the hashtags. Though I don't use hashtags for sending robots to "unpause" which their command then follows goto "#return" after the ":unpause" label. Its odd... sometimes they work and sometimes they don't. Guess it all depends on what part of the cycle they are at when they get switched over. They seem to forget or not always retain where they are suppose to return to. When the game gets paused i use send "all" "#pause" making sure the robot doing the pausing does not contain a #pause label in it.


EDIT:

Update

I made 40 test boards with an end pipe in each to send Mario to each following stages and it seems to work out okay. Considering the difficulty and detail of each level when complete, the game could contain some fair amount of gameplay time. I've started making a level for each world so I can create a base theme template for each. Grassland, dessert, ice, forest, deadlands so far. There will be a boss stage in each (sadly no piantas).

Attached thumbnail(s)

• 

This post has been edited by T-Bone: 23 December 2014 - 10:57 AM

[Graham]

T-Bone, on 23 December 2014 - 02:44 AM, said:

Spelling seems to be okay and the hashtags. Though I don't use hashtags for sending robots to "unpause" which their command then follows goto "#return" after the ":unpause" label. Its odd... sometimes they work and sometimes they don't. Guess it all depends on what part of the cycle they are at when they get switched over. They seem to forget or not always retain where they are suppose to return to. When the game gets paused i use send "all" "#pause" making sure the robot doing the pausing does not contain a #pause label in it.

I'm trying to think of a situation in which the subroutine would fail to return to the spot after which it was called and I can't think of any. If it was already in a subroutine, it would still work because they nest. If it was in a loop it would still work because the loop count counter would hold the loop value until the program reached the 'loop start' command again.

If the program was checking for collision when the subroutine was called... No, it would still work correctly. For it to fail, there would have to be a cycle ending command between when it asked 'if sprite colliding...' and it used the 'spr_collisionN' counter. And if there was, it would fail to work properly anyway, regardless of whether there was a subroutine being called.

It should work they way you've set it up, 100%. Would you care to post up the code of the robots that are failing? There must be some way to test this and determine what is going on.

This post has been edited by Graham: 23 December 2014 - 03:50 PM