Byte Ray (3D, Non-RPG)

Kryzon

Veteran
Veteran
Joined
Jul 2, 2014
Messages
49
Reaction score
14
Primarily Uses

An obstacle platformer with a fast-paced, challenging gameplay.
On an abstract world, you control a little machine named DAN that needs to get to the end of the stage to protect that world against a malware menace. Dash your way to the end and hit the byte ray beacon to win!

Version 1.1 includes improved graphics, bug fixes, an extra music track and based on user feedback, a checkpoint and a progress bar showing how far you are into the level.

The game instructions are in the "README" file in the archive.

Download:
Byte Ray 1.1.rar (18 MB) (Windows)

Original IGMC page:
http://contest.rpgmakerweb.com/game/view/id/263
 
Last edited by a moderator:

Wavelength

Pre-Merge Boot
Global Mod
Joined
Jul 22, 2014
Messages
4,702
Reaction score
3,963
First Language
English
Primarily Uses
RMVXA
Alright, just played this for the Secret Santa and I’ve got a lot of thoughts about it. I feel like I should just get this out of the way first, though: on the whole, I didn’t enjoy playing Byte Ray. I feel really bad saying that because I don’t know the limitations or difficulties of the platform that you made the game on, and I’m guessing that to put together the gameplay that you did (in a couple of weeks, no less) was probably a pretty big accomplishment. But there were two major issues – very slow play speed and player-unfriendly design – that came together to make the experience frustrating for me, rather than fun.

First, the speed. Everything in the game, including the short animations at the beginning, took a long time to play out. I’d estimate the game was running at about 3 or 4 frames per second. I don’t know whether that’s a necessary evil of the platform you made the game on, or whether the game speed will scale with my computer’s performance (I’m using a middle-of-the-line PC), but as a baseline, the fastest I could get from the beginning of the level to the narrow passage between the two giant walls was probably 30-40 seconds. I would aim for a pace of about 10 seconds if the player is going as fast as he can possibly go.

Such a slow pace took away from the “action feel” of the game. But just as importantly, it also made it feel far more punishing to be sent back to the beginning of the level upon dying. I already know how to navigate that first set of obstacles and I’ve already done so successfully and there’s nothing interesting to do there besides hit the spacebar three times to jump – so please imagine my frustration when, on my twelfth death later on in the stage, I’m sent back to the start to sit there for 40 seconds and hit spacebar thrice for the thirteenth time.

And that ties in to what I think is the even bigger problem – player-unfriendly design. You say that Byte Ray is a “challenging game” – but I would call it “punishing”. Every time the player does something slightly wrong, including just touching an edge, you “kill” the player, take away all of their progress (unless they’ve reached the one checkpoint, I guess), and tell them “do everything over, even if you don’t want to”. Now, I spent about 35 minutes playing the game, which I think was about 15 or 20 attempts, and I only made it about a quarter of the way through the stage. Had I not been forced to restart every time I touched the edge of a wall, I could have reached this point within a few minutes, and I would have constantly been seeing new and interesting obstacles. It would have been a relatively fun experience, even with the slow speed. But I was forced to restart every time, and each time it just made me feel more and more despondent. I just cannot emphasize enough how much this damaged my impression of Byte Ray.

It’s a real shame, too, because the few obstacles I was able to see were well-designed and cleverly-placed. They require the player to kind of combine different mechanics to figure out a way around them. For example, the place where you have to jump over a cube, then jump again over a gap. A short ways after the gap are three poles standing next to each other and you have to go around them. What’s really cool is that the player sees the poles a short ways away and thinks (“oh boy, I have to slow down or I’ll crash into them”). But at the same time, you need enough speed to make it over the gap, or you’ll fall into the void. You need to speed up to make the jump, then try to slow down as quickly as possible and get around the obstacle. That’s great design right there. The part where you have to quickly jump left and right between obstacle-laden balance beams really had me saying “oh snap!” and shines as another example of good obstacle design.

But my joy would once again turn to despair when I’d, for example, hit the very edge of the leftmost pole, watch my “character” grind to a halt, and shake my head as I was placed right back at the start of the level. Why not use a “damage bar” instead (and have the character recoil off of hits into walls and obstacles rather than halt entirely), and allow the player to continue along until they’ve taken too much damage? This would allow for a sense of mastery as you navigate the early parts of a level taking less and less damage as you get better, without feeling too punitive. Or better yet, go with the “Marble Madness” solution where the level is timed, and “dying” simply causes you to lose several seconds before continuing right where you left off (with the level only restarting when time runs out)? This would leave the player with the positive notion of “I made it this far, but if I had done X and Y better, I could have definitely completed it.”

One more thing I have to point out as player-unfriendly: the complete lack of in-game instructions. A few minutes after I started playing I did find that there was a read-me file that contained not only the instructions but the background story. Not everyone is going to read your read-me file, though, because most modern games don’t require you to. And even people that do might have trouble remembering what they read. Putting this stuff only in the manual is a very 1990s way of doing things, and even games that make homage to old-school 90s action try to be more player-friendly in how they get information across. In my first few attempts, I had no idea that Up/Down (or W/S) did anything, I didn’t know what the gauge at the bottom of the screen was, and once I intentionally banged into a wall to slow down my momentum. Imagine my surprise when I found out that was instadeath! Even if you don’t want to show all the instructions in-game, saying something like “Don’t Stop!” or labeling the meter “Brake Limit” would go a long way toward easing the player into the game.

The presentation was pretty nice. I really, really loved the music. It fit the theme of the game well. The graphics were nice in a clean, futuristic way, and I like that you used a lot of different colors. The only complaint I have is the black, horizontal edge that could often be seen at the bottom of the stage (way below the horizon) – it made me feel like I was in some weird cube rather than in the infinite deep space that I think you wanted to convey. If you have some way to blur out that edge, I think it would be a smart idea to do so.

For some reason, I couldn’t use the “up” movement, the “left” (or “right”) movement, and the “jump” movement all together near edges. When I was holding up and left (or right) and tried to jump, the ball would roll a bit and then fall, without ever jumping. When I held only one arrow and jump, it jumped fine. When I held both arrows and jumped but was not near an edge, it also jumped fine.

I liked that you mapped the controls in a similar way to RPG Maker’s. That was a smart design decision since a lot of people playing your game through the contest will be familiar with RPG Maker’s controls.

Finally, when I tried to exit the game, or the config tool, using the X at the top-right of the window, it told me “ACCESS VIOLATION”. I was still able to close it with no other apparent ill-effects.

Overall, Byte Ray felt more like a school project for a course on using a game engine, than it felt like an actual game. A lot of game design decisions were poorly made and there’s not a lot to divert the player during the parts where nothing is happening. I don’t think you should feel bad in any way about making this; I can appreciate what you were going for, and while I don’t know much about the engine you used, I have a feeling what you’ve done is a remarkable technical achievement, especially if this is one of your early tries with the engine. But if you plan to make it into a full game for the purpose of people enjoying it, there are three things I’d highly recommend, in order of importance:

  • Don’t make the player restart the level every time they hit an obstacle. A “damage” system, a timer system (probably the best option), or extremely frequent checkpoints are all ways you could get around this.
  • Speed the game and the action up, if possible, to about three times the current speed.
  • Add instructions to the game instead of just the manual. A tutorial level would be great if you plan on having multiple levels (I think the game is just one level right now, so a tutorial probably isn’t necessary; just some in-game explanation). Adding a bit of narrative into the game would be nice too, instead of having it only in the manual.
 

Kryzon

Veteran
Veteran
Joined
Jul 2, 2014
Messages
49
Reaction score
14
Primarily Uses
Hello Wavelength.


When I read your "I didn't enjoy playing it," I thought that by the end of reading your review I would be feeling down. But I was pleasantly surprised by your thoroughness and your constructive treatment.


It is clear that you spent a lot of time and effort in writing your review ("feedback" is a better word for it perhaps).


After I finished reading it I was glad to have been assigned to you. You have a "review philosophy" that is enriching to a developer.


It's unfortunate that the framerate was insufficient. I didn't expect that to happen.


As it runs here it has 30 FPS. I made sure to keep the graphics requirements as low as possible to avoid any performance problems, but I understand that certain OpenGL drivers are a hit-and-miss regarding efficiency.


I understand how it must have taken away most of the engagement that the game could have.


I'm not sure if you're interested in the backstory, but I started with a "bare-bones" OpenGL engine and I had to spend a lot of time programming what is called "boilerplate" code, functionality that performs trivial things such as handling the menu buttons, the transition effects, the loading of models and sounds etc. It is a tedious task and it takes away time for making more important game material.


After submitting the game with the deadline almost through, I said to myself "next time, I'll use Unity!" With something like Unity all of the "framework" is already done, so you just spend time making your game better, adding polish. I originally had a different design for this game -- to make it an experimental music\dance puzzle game with the "malware" enemy trying to kill you in several ways etc. -- but had to conform to that simpler design in order to deliver something before the deadline.


Regarding the difficulty level, I deliberately made the game in that "punishing" manner ("each failure is a restart") because I was concerned that if I had made it too easy, it would just be a "sight seeing" experience and ultimately boring because of that.


However, as you put it, I could have made it less extreme, such as grouping obstacles per "zone" or "section," and each failure would bring you to the start of the section that you made a mistake, and it would still be fun to play because there would be new obstacles ahead to keep you engaged -- I had not thought of that, so thank you for that enlightenment.


I'm glad that you liked some aspects of the game, such as the level design and music.


I produced all of the graphics and programming. The sounds and music were taken from creative commons sources.


The music in particular was the first asset to be collected for the game, and it guided the rest with that "futuristic" direction. The tracks used in the game are from the album "Wake Up" by Javier Suarez (I recommend the "Stars" track):


http://betterwithmusic.com/projects/wake-up/


Regarding the "read-me" file, I understand your point about having in-game instructions -- it is clearly a more convenient form and you can't rely on people looking through every file that was extracted from the archive. Most players won't look for a read-me file, especially if they're not accustomed with this practice (I was amused by your "1990s" remark).


Having in-game instructions is the modern standard, and when I make my next project I will include in-game instructions as well as in-game messages that tell you what to (not) do.


I'm glad that that "ACCESS VIOLATION" bug didn't interfere with the game or the configuration tool.


Thank you very much for your feedback.
 

The Prince of Sarcasm

Prince of sarcasm
Veteran
Joined
Apr 3, 2014
Messages
1,145
Reaction score
131
First Language
Sarcasm
Primarily Uses
I kind of want to double what the other guy said, but I have some different ideas too. I played this for secret santa also. It just seems weird to me that the player is controlling a smoothly rolling box. Also it seemed that the jump length was a little short. Some times I would be right on the edge of the first jump and jump and still hit the edge of the other side and die. Maybe I had to hold space longer. I also didn't like that running into walls killed you, in other games I played like this, running into walls just stopped you from moving until you got out of their way. I like the backgrounds, graphics and colors very much though. I'm not going to leave a ton of feedback because the other guy already did. I'd give it a 2.5/ 5 stars.
 

Wavelength

Pre-Merge Boot
Global Mod
Joined
Jul 22, 2014
Messages
4,702
Reaction score
3,963
First Language
English
Primarily Uses
RMVXA
Hi Kryzon,

It's kind of you to take my feedback with such grace, and I'm glad you found a lot of it helpful.  I appreciate your compliments.  I find it to be a great exercise to try to find areas for improvement in the design of games, and it was especially interesting in a game like this, which had a lot of things going for it but I felt was really brought down by a few specific problems.

The technical hurdles that you faced in making the game were very interesting to hear about, though not completely unexpected.  While I don't know anything about OpenGL, there was something about the game - maybe the way the graphics were good yet blocky? - that intimated to me that you probably had to do a lot from scratch for this project that most of us working on other platforms didn't have to.  I only know a little about Unity, but from what I've heard it's a great platform for this kind of game.

In the last couple days everything on my computer has slowed down due to memory leaks, so I did a reboot and started up Byte Ray without anything else open just to make sure the memory leaks weren't the source of the slow pace.  I don't think there was a big difference.  I timed a few things this time around to give you some perspective on how slow it might be for players - the "Malware" animation at the beginning took about 50 seconds from the time it started to the time the level appeared, and from the start of the level to the point where I was entered the narrow passage between the first big red walls (holding down UP to go as fast as I can) was just over 60 seconds.  Out of curiosity, about how long does it take on your rig?  If that first stretch of the level (start to red walls, at full speed) is taking more like 10-12 seconds when the game runs "smoothly", then I think that would be a fine pace.

Grouping the obstacles into "zones" (essentially creating a lot of checkpoints, right?) would definitely be a less frustrating way of doing it than the current method of "one hit sends you to the beginning of the level".  Whether you'd want to go with the zones, or a damage or timing system (where one hit doesn't kill you) like I described in the last post, depends on the type of feeling you're hoping to inspire in the player, but any of those solutions would be, in my eyes, far preferable to the current setup.  I'm glad you found the notes about in-game instructions to be useful, too.

Thanks for the link to Javier Suarez' music; I will definitely check out his stuff.  And once again, I can't compliment you enough on the great obstacle design, so nice job on that.

I'll keep up to date on your game if you decide to develop Byte Ray further, and if I can find a better platform to run it on, would love to give it a second run.  All the best.
 

Kryzon

Veteran
Veteran
Joined
Jul 2, 2014
Messages
49
Reaction score
14
Primarily Uses
I kind of want to double what the other guy said, but I have some different ideas too. I played this for secret santa also. It just seems weird to me that the player is controlling a smoothly rolling box. Also it seemed that the jump length was a little short. Some times I would be right on the edge of the first jump and jump and still hit the edge of the other side and die. Maybe I had to hold space longer. I also didn't like that running into walls killed you, in other games I played like this, running into walls just stopped you from moving until you got out of their way. I like the backgrounds, graphics and colors very much though.
Hello Prince,


thank you very much for the feedback, especially about the jumping.


I understand your point about the smooth rolling box. That form is a "residue" from my original design when the player had to make tile-based movements, and a chamfered box-like shape looked better at that.

 
Last edited by a moderator:

Kryzon

Veteran
Veteran
Joined
Jul 2, 2014
Messages
49
Reaction score
14
Primarily Uses
In the last couple days everything on my computer has slowed down due to memory leaks, so I did a reboot and started up Byte Ray without anything else open just to make sure the memory leaks weren't the source of the slow pace.  I don't think there was a big difference.  I timed a few things this time around to give you some perspective on how slow it might be for players - the "Malware" animation at the beginning took about 50 seconds from the time it started to the time the level appeared, and from the start of the level to the point where I was entered the narrow passage between the first big red walls (holding down UP to go as fast as I can) was just over 60 seconds.  Out of curiosity, about how long does it take on your rig?  If that first stretch of the level (start to red walls, at full speed) is taking more like 10-12 seconds when the game runs "smoothly", then I think that would be a fine pace.
Now that I compared with how it's running here, I'm sure it's driver related. The opening animation here takes about 10 seconds, and then from the start of the gameplay until your reach the red walls it's just another 10 seconds.


You can see a video capture from when I submitted the game, the speed is the same (and note how the graphics were "different"):





I'll keep up to date on your game if you decide to develop Byte Ray further, and if I can find a better platform to run it on, would love to give it a second run.  All the best.
I'm almost sure I won't be working on this game anymore, but I would certainly like to have your e-mail address at hand.


On a future project (luckily, with Unity) I'll let you know, it will be valuable to have your thoughts on it.
 
Last edited by a moderator:

Wavelength

Pre-Merge Boot
Global Mod
Joined
Jul 22, 2014
Messages
4,702
Reaction score
3,963
First Language
English
Primarily Uses
RMVXA
Now that I compared with how it's running here, I'm sure it's driver related. The opening animation here takes about 10 seconds, and then from the start of the gameplay until your reach the red walls it's just another 10 seconds.

You can see a video capture from when I submitted the game, the speed is the same (and note how the graphics were "different"):

I'm almost sure I won't be working on this game anymore, but I would certainly like to have your e-mail address at hand.

On a future project (luckily, with Unity) I'll let you know, it will be valuable to have your thoughts on it.
Yeah, that looks like a totally different play experience from what it was for me!  I'd say that's about a perfect speed - you can safely ignore my comments about speed of play.  I'm glad we were able to figure out the difference, because at this speed I wouldn't have gotten nearly as frustrated with being sent back to the start of the level, although with that being said, I would still highly recommend (in this or future games) not sending the player back so far for making a single mistake.  Even with a high play speed it would feel far less punishing to restart that "group" of obstacles like you've suggested, or to simply lose time/health like I suggested.

Absolutely feel free to reach out to me in the future if you want to bounce some ideas around or have me playtest something for you.  My email is blueshift14 (at) yahoo.com and it would probably be good to private message me here as well, just in case my email accidentally sends your message to the Spam folder.
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

Yay! One of my Youtube videos got to 100 views (in 2 days)! This Youtube thing is great, it's like the profile posts except I get to annoy entertain more people at once! Now I just have to practice my "Leave a like and hit that Subscribe button" shilling technique. :LZSexcite:
Just found out there is an about me page. I updated it and happy the way its looking!
Ladies and Gentlemen, I can't act like things will be ok anymore. It needs to be said: We have a Pandemic...
Release version of Pillow Hero is out on windows now! --> https://bit.ly/2USHKLv
Stream will be live shortly! Feeling like doing some Minecraft instead of DK64 since it has been a bit! Feel free to drop by!

Forum statistics

Threads
95,555
Messages
930,059
Members
125,838
Latest member
Kito_SK
Top