[WIP] UzeJump

Use this forum to share and discuss Uzebox games and demos.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

[WIP] UzeJump

Post by ry755 »

This is my WIP game called UzeJump. It's like a mix between Doodle Jump and a platformer. It's nowhere near being completed, and the three levels that are there are just duplicates. But I thought I'd still share it so I can see what you guys think of it so far.

Image
(Thanks to my sister for most of the sprites, I can't draw to save my life :lol: )

The green character is the main player, and the purple one is an enemy (the enemy doesn't do anything yet)
I haven't worked on it much lately because I've been busy with school 'n stuff. But I do have lots of ideas of how to improve it. I will eventually add scrolling and powerups. Also, the intro before the main menu is meant to look like the old tape loading screens on some retro computers. I think I might either shorten it or just get rid of it because it can get pretty annoying, especially when I need to keep resetting the game to debug stuff.

The source code is pretty messy. I might have to rewrite some of it eventually. But it's my first real attempt at programming in C, so I can't really complain :D

Please let me know what you think, and any suggestions for improving it.

Source code: https://github.com/ry755/UzeJump
.HEX and .UZE attached.
Attachments
UzeJump-2018-01-24.zip
(43.93 KiB) Downloaded 366 times
Last edited by ry755 on Thu Jan 25, 2018 4:21 am, edited 5 times in total.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: [WIP] UzeJump

Post by L4rry »

Good job and congrats! It's a nice feeling releasing your first Uzebox game build :)

I've never played the games this is based on, but I like the premise of a constantly jumping player having to get the timing right to progress left or right. That's a fresh take to me. I also like the animated borders you did on the 'ry755' screen. I'd like to hear how you implemented it. Also, what video mode did you use? I don't have many suggestions, I'd just like to see how you progress on this. But here are my 2 cents based on general experience. Hope you find it helpful.
  • Don't get rid of your intro screens. I like it. Rather have a button press shortcut you to the menu screen.
  • Don't worry too much about ugly code for now. You'll never get it perfect first time round and you might just become frustrated. Improvements should suggest themselves as you develop and your second game will always have better code then your first. Rather focus on your game play and content
  • Focus on your game play first before you start improving things like animations and graphics. A good game will be fun to play regardless of how it looks. Once you have the 'fun' down, you can add the bells and whistles.
  • If the game is fun to play for you, it's probably fun to play for a lot of other people. Back yourself in your game design.
Anyway, looking forward to seeing this one progress!
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: [WIP] UzeJump

Post by nicksen782 »

To add to this.

Yes, intro screens are AWESOME! I have one that I really like. D3thAdd3r has custom ones for many of his games. Yours is really 80's. Making it skipable is a good idea though.

You are managing your states and such with individual global variables. I've been told that this is actually faster but it is harder to keep track of. Functions that take arguments also take more instructions to implement... But that is micro-optimization at this point. Don't worry about it. If you can keep track of it, then do it. You could also use data structures as well. Nice thing about structures is that you can name the members in a structure. For all the enemy movements you can loop through the array.

I've often made the mistake of focusing on all the cool stuff I could do and then once it is done I can't make a game out of it. Keep your focus, make things work. You can refactor later if you have to.

You are off to a great start! I played all the levels that were available. Bouncy!
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: [WIP] UzeJump

Post by ry755 »

Thanks! I'll make the intro skipable, and also make the fade in/out transition between screens a little bit faster.

L4rry wrote: Mon Jan 08, 2018 7:03 pm I've never played the games this is based on, but I like the premise of a constantly jumping player having to get the timing right to progress left or right.
Here's a screenshot I took of Doodle Jump (with the retro theme selected): https://i.imgur.com/xMG105o.png
I was originally going to just make a direct clone of Doodle Jump, but then I decided to mix it with a platformer type game. I don't even have the whole game planned out yet, I'm just going with whatever I think would be fun. :)

There are also platforms that the player can walk on, without jumping. Since this is also a platformer, there might be times where you don't want the player to always be jumping.

L4rry wrote: Mon Jan 08, 2018 7:03 pm I also like the animated borders you did on the 'ry755' screen. I'd like to hear how you implemented it. Also, what video mode did you use?
The animated borders are tiles that quickly alternate. https://raw.githubusercontent.com/ry755 ... ileset.png For the video mode, I'm using mode 3 with scrolling enabled. I haven't implemented any scrolling features yet, but I want the levels to be somewhat big. Now that I'm thinking about it, I should probably add some kind of map so the player doesn't get lost. Maybe holding down a button could show an overview screen or something.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: [WIP] UzeJump

Post by Jubatian »

nicksen782 wrote: Mon Jan 08, 2018 7:33 pmYou are managing your states and such with individual global variables. I've been told that this is actually faster but it is harder to keep track of. Functions that take arguments also take more instructions to implement... But that is micro-optimization at this point. Don't worry about it. (...)
I don't really think so, at least my experiences with studying the compiler's output not necessarily reinforce it. The most critical hit in performance is a function call, usually often used states ended up global variables in Flight of a Dragon due to that: if you have a getter function, and only that is being called in another, that will still cause an avalanche of pushes and pops as even if the function merely returns a given RAM location's contents in r24, it still marks r18 - r27 and r30 - r31 clobbered, so the caller immediately ends up in a critical register shortage. It would be very useful if the compiler had a small function ABI (with fewer registers marked clobbered), but it doesn't have.

Anyway, otherwise what Nicksen says is valid: make good code first, and optimize it later (in FoaD the globals originally mostly were setters & getters, in some modules this transition is still observable). Try to avoid globals to prevent a later spaghettification where the usage of some globals get completely out of hand (by the way grep -r "symbol_name" is often useful to find where something is used in a larger code base).
ry755 wrote: Tue Jan 09, 2018 1:22 amThe animated borders are tiles that quickly alternate. https://raw.githubusercontent.com/ry755 ... ileset.png For the video mode, I'm using mode 3 with scrolling enabled. I haven't implemented any scrolling features yet, but I want the levels to be somewhat big. Now that I'm thinking about it, I should probably add some kind of map so the player doesn't get lost. Maybe holding down a button could show an overview screen or something.
I see you are currently using 28 tiles width. Just a reminder: you may use RESOLUTION_EXT to cram a little more tiles horizontally in the same area, then you could have 30 visible tiles for a horizontal scroller (you can have that without RESOLUTION_EXT as well, but the screen then is too wide to fit on most displays). The wiki has some info on how to use this.

I liked the intro, it somewhat resembles to a VIC-20's tape load screen, although the VIC-20 seemingly didn't use rasterbars for the process too often. However it normally had a 20 characters wide screen.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: [WIP] UzeJump

Post by Artcfox »

Looks cool! A couple thoughts. Maybe keep the buttons consistent for selecting the menu items and continuing. Sometimes I have to press Start, and other times that doesn't work and I have to press A.

Also, have you considered using a real physics engine that has acceleration due to gravity, and a terminal velocity, etc?
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: [WIP] UzeJump

Post by ry755 »

Artcfox wrote: Tue Jan 09, 2018 5:53 pm Looks cool! A couple thoughts. Maybe keep the buttons consistent for selecting the menu items and continuing. Sometimes I have to press Start, and other times that doesn't work and I have to press A.

Also, have you considered using a real physics engine that has acceleration due to gravity, and a terminal velocity, etc?
Yeah, I know the buttons aren't consistent. Most games I've seen use Start/Select for the menu options. I'll change it so you can use either Start or A in the menus.

I've thought about physics, but I've never tried to implement it just because I have no idea how to. Is there a physics demo somewhere, or a game that has good physics code that I could look through?
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: [WIP] UzeJump

Post by ry755 »

OK, this should be really simple, but I can't think of a way to make it work. Maybe I'm too tired :roll:

Here's the code for the intro (line 65): https://github.com/ry755/UzeJump/blob/m ... jump.c#L65 I'm trying to make it where pressing any button will skip the intro. But with all the WaitVsyncs that are in there, when I put button checking code in between all the waits, I have to keep pressing a button repeatedly, until it passes the WaitVsync that it's on, and detects the button press.

Is there a way to detect a button press while in a WaitVsync state? Or would it be better to just rewrite the intro a different way?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: [WIP] UzeJump

Post by Artcfox »

I implemented a physics engine in my game Bugz, and if you look through the Git history for the game you can see a simplified version without all the optimizations.

For all the WaitVsync calls, try just having a loop with a single WaitVsync(1) call in it and increment a counter each time through the loop, then implement a state machine that changes states based on the value of the counter. If you want an example of a state machine implementation, you can look at my NECIR code. (It decodes IR pulses from a remote inside an interrupt, and uses a state machine to keep track of what part of the IR signal it is currently decoding/processing.

Look in necir.c inside the ISR, my states are stored in an enum:

Code: Select all

static enum { NECIR_STATE_WAITING_FOR_IDLE, NECIR_STATE_IDLE,
                NECIR_STATE_LEADER, NECIR_STATE_PAUSE,
                NECIR_STATE_BIT_LEADER, NECIR_STATE_BIT_PAUSE,
                NECIR_STATE_PROCESS, NECIR_STATE_PROCESS2,
                NECIR_STATE_REPEAT_PROCESS, NECIR_STATE_REPEAT_PROCESS2 } state;
and you can see how I use them, and transition between them. The ISR is set up to be called repeatedly, but if you have an infinite loop with a single WaitVsync(1) in it, the stuff inside will get called repeatedly once every frame, so you'll be able to maintain a counter for transitioning states.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: [WIP] UzeJump

Post by CunningFellow »

VectorGame / Asteroids has very simple physics in the "lander" level.

Gravity is pulling the ship down. You can thrust to keep it up, and air resistance slows you down in any direction proportional to speed.

This is all done in fixed point for speed reasons, so you might get some ideas on doing simila
Post Reply