Hi there!
Some quick notes on swimming after watching your video: you can use the movement controls to aim and the jump button to swim more slowly than charging. And, charging underwater can also be controlled with the mouse (both by right clicking to charge and moving the mouse to aim). There are also inputs settings (such as underwater up/down aiming inversion and axis mapping) in the menu.
Thanks for the feedback, and thanks again for sharing your gameplay footage!
Hi there! And, thanks for the feedback.
By default, swimming works by holding jump (for slow) or charge (for fast) and aiming with either of the two gamepad joysticks, a keyboard’s arrow keys, or a mouse (with inversion, look input coupling, and control binding options in the settings menu). That sounds like what you’re describing. So, perhaps there was just some misunderstanding with how the controls work.
Did you find the portal to and try The Scrapyard level? If not, there’s some challenge to be found there, as it represents a later stage of the game. Although, it will likely see a bit of a rework at some point to improve gameplay flow and polish some details. The demo’s starting area, being just the first hub world, is relatively simple.
In any case, it’s nice to hear that you enjoyed it. More levels to come in the final version, of course.
Likely because the zip file isn’t marked as a Windows executable in the game’s settings on itch, it cannot be installed via the itch player, and it isn’t listed on the site as a Windows game.
When using butler instead of directly uploading, the platform can be specified by including it the channel name. More info: https://itch.io/docs/butler/pushing.html
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog.
The placement of a change within a version’s subheadings is resolved by considering the perspective of returning players. For example, where an entry might make sense in both the added and the changed section of a version, the entry is more likely to be included in the added section if it could be perceived as an observable addition from the perspective of a returning player.
This project roughly adheres to Semantic Versioning. However, it has been modified to be more player-focused.
Format: major.minor.patch
Changes to the major version imply significant content changes. Usually, these will include the addition, removal, or replacement of entire levels. As such, players seeking new experiences should primarily focus on the major version when deciding whether or not to play a specific build.
Changes to the minor version imply additions or changes to existing content or gameplay. These may include holiday-related temporary changes. These iterations usually offer little to players seeking new content. However, for detail-oriented players interested in exploring the game’s subtle evolution, they may still be worth comparing with other versions.
Changes to the patch version imply particularly subtle differences that usually do not significantly alter gameplay. These are often related to bug fixes and tweaks. These versions primarily affect players who would otherwise be unable to play or progress through a section of the game due to bugs.
Initial release.
Awesome feature. With this implemented, a button to preview the result would be nice. Also, an option to convert rich text posts to markdown would be useful (assuming it doesn't take effect until applied, to provide an opportunity to preview the result first). Currently, it looks like old rich text posts are locked into that editing method.
The meta data (what you see when you click "More information") does not list platforms, and it is not downloadable via the itch player. This indicates that the files haven't been marked as operating system/platform executables in the project's settings. The itch player only allows downloading of games if the builds are marked as executables for the associated operating system.
These settings are also automatically applied if a butler upload's channel contains platform names. For more information, see "channel names" here: https://itch.io/docs/butler/pushing.html#channel-names
Aesthetically, this is quite nice. Definitely has the potential to become a fun, charming game.
As for the gameplay, it's mostly smooth. But, the input mapping desperately needs some attention. I know that you're planning to basically rewrite everything, but this demo's input mapping is exceptionally rough. So, even for a demo destined for obsolescence, I'd still suggest an input polish pass, for usability.
First, the binding. There's no way to bind camera movement to a gamepad's right analog stick or the mouse. There's also no way to bind actions to analog inputs (e.g., crouch to a gamepad's left trigger). And, axes are inverted (positive is down/right, negative is up/left). Although Unity's built-in input manager is far from ideal, these issues are all solvable while using it.
Then there's the default controls, which are nonstandard, to say the least. The default keyboard controls are the arrow keys for movement and WASD for the camera. Gamepad camera controls are pause to look up/right and select/back to look down/left. The camera zoom gamepad button is the bottom face button (A on an Xbox controller). Jump is the top face button (Y on an Xbox controller).
As a side note, if you want to automatically recenter the camera vertically, it should only happen when the player is moving. A stationary player is most likely looking around intentionally.
Finally, a couple of minor notes. I noticed while climbing a tree that the puff particles continued to emit while stationary on the tree. They seem to be set to emit over both time and distance. And, when you walk up the purple ramp near the start, you're stopped at the top by the corner of what I assume is the top terrain's box collider, which extends beyond the rounded corners of its mesh.
All that being said, thanks for releasing an early playable demo! I'm definitely interested in seeing where this project goes.
Movement - WASD / left analog stick
Camera - mouse / right analog stick / left and right trigger (L2 and R2)
Charge - shift / right mouse button / left face button / left bumper (L1)
Jump - space / bottom face button / right stick button (R3)
Glide - Press jump while in the air
Glide jump - Press jump while gliding
Zap attack - e / left mouse button / right face button / right bumper (R1)
Pause - escape / right special button / pause
Show totals - tab / left special button / back (select)
Toggle hat or mask visibility - H
Movement - WASD / left analog stick
Jump - space / bottom face button / right stick button (R3)
Dive - shift / right mouse button / left face button / left bumper (L1)
Rotation - WASD / left analog stick
Swim - space / bottom face button / right stick button (R3)
Charge - shift / right mouse button / left face button / left bumper (L1)
Toggle cursor lock - P
Toggle camera look - M
Toggle both cursor lock and camera look - L
Hide player - left control + H
Take screenshot (placed in game directory) - F2
Does the textless option that can be selected under accessibility features in a game's metadata settings include games that are textless in-game but have text-based pause and main menus?
What about level name labels in front of level portals?
Does textless simply imply that a game can be played fully without losing anything by not being able to read text?
Basically, to what degree does a game have to be textless for the textless metadata to be reasonably applicable?
:O Very detailed and well-written review. Thanks for writing and sharing it!
I noticed in your video that things were transitioning to lower levels of details (including disappearing) when relatively close to the camera. Do you still experience that with the latest version? Theoretically, that should have been fixed in version 2.2.5. So, I'd just like to be sure that it was, indeed, fixed.
There are some super secret hidden things. But, they're just more Easter eggs. There are also some world building mini-scenes somewhat hidden around the hub featuring semi-sapient mushrooms :P
Yeah, although it's been relatively low-priority, I do want to add a key indicator to the UI. I'll probably roll it into a general purpose system for level-specific indicators. So, it will take a bit longer to implement than simply adding an indicator for just the key, but it could then be used for any arbitrary level indicator or counter.
The player starts in a scrapyard in the final hub, moments after Nytro's creation, behind a gate flanked by two other hub world portals that are locked behind gear totals. The final boss door will also be locked behind a gear total. The story will be told implicitly (never explicitly stated). So, the player's introduction to the story is basically a world that seemingly sucks, a bunch of other worlds that illustrate the process worlds take as they transition to that state, and what seems to be the source of it all locked behind a gate.
The game is separated into 3 story arcs and their respective hub worlds. The first depicts nature as something worth protecting and invader robots as threats to nature. The second shows what happens when the invaders establish themselves in a world and change it to suit their needs. In the third and final act, the player arrives in the enemy's territory and discovers why the invaders wanted to leave their home in the first place.
And, no problem! It's cool to talk about. And, doing so helps with coalescing the otherwise jumbled up ideas I have.
I basically make stuff up as I go along, making it hard to know how much there is left to do in the Scrapyard until it's finished. So, I can't estimate remaining time with any real accuracy. But, it is quite far along in development and wouldn't need much to be technically complete (albeit not fully polished). I would say that the early Patreon version of the Scrapyard is actually pretty fun to explore, even in its current state. As it is intended to be an exploration-focused level, I'd say that's a good sign. After I get the save management and inventory menu fully implemented in the demo, I'll be returning to the scrapyard to finish it up.
When I think of Dark Souls, I mostly think of level design, such as the way shortcuts, side paths, and secrets are implemented. The scrapyard has a lot of that sort of thing going on. Spyro-style checkpoints will likely be placed in central locations linked to multiple shortcuts, similar to Dark Souls bonfires. And, the companion's health will be changed to drain 1 health point (not max health) per death. The original intent was for this to be a max health change, with Nytro leaving a spark of life similar to Dark Souls' bloodstains on death. But, I ultimately decided to not go quite that far for the base difficulty and instead limit the penalty to simply loosing a single point of non-max health. Although, I may implement the original idea as a difficulty setting later in development.
The particles at the top of the waterfall basically just hide the seam where the waterfall (and thus texture panning) starts. Although, I was originally going to remove it once I made the transition less noticeable, I found that I actually preferred the spray at the top as well.
The bolt counts for levels will be more uneven than Spyro's, because bolts are always worth 1, and I won't be adding or removing many bolts to reach arbitrary totals. Someone made a spreadsheet of how many individual gem items there are in Spyro, and it's even more uneven, like 78, 59, and 107, to name a few.
Overall, the active camera mode is a legacy mode that I generally don't recommend using unless you experience issues using other modes. The wobbliness is sort of an inherent quality of such an aggressive camera mode, and the answer that the problem manifested as the lazy camera mode. Active mode was also coded to not recenter when the player is moving directly toward the camera, as to allow looking at something while moving the opposite direction. Although, this functionality might no longer be necessary now that the lazy follow mode is available. So, I might strip that behavior out or add an extra checkbox in the settings to disable it.
The glide jump distance, like in Spyro, is based on how long you've been gliding before initiating the jump. This prevents players from using it as an unintended double jump, allowing them to reach places higher than a single jump would normally allow. This is the case in Spyro: Enter the Dragonfly, which doesn't scale the hover strength with flight time or distance and consequently has a bunch of sequence-breaking skips. And, the max hover force is unlikely change, because it's already too easy to make it to very distant platforms with it.
I've gone back and forth with the snail's speed a lot. But, this may be its final speed. The intent is for players to give up, play some levels, and then come back to the snail after becoming more skilled with the controls. This provides a sense of progress as a player that is otherwise difficult to achieve. Numbers can tell you how far you've progressed in a game, but nothing compares with feeling improvement as a player first-hand. Of course, that doesn't come across very well when there aren't any other levels to play :P But, I try not to design content intended to exist within a larger context in a bubble. I'll probably revisit the snail's balancing after there are more levels in the demo and I've accumulated a lot of feedback on it.
In general, I would say that Nytro is intended to be a more difficult game than Spyro. It is partially inspired by Dark Souls. So, it will likely be more merciless and require more skill and deliberate action than Spyro, even for equivalent jumps or glides. Although, despite that, I also wanted the controls to be smoother than Spyro's, as is evident from the lack of knockback when charging or gliding into surfaces, the ability to transition from glide jumping to charging, the lack of a falling state that prevents charging, and inertia not preventing instantaneous turns.
Save data can be cleared by deleting the save file in these platform-specific locations:
Windows: %UserProfile%\AppData\LocalLow\OhiraKyou\Nytro
Mac: ~/Library/Application Support/OhiraKyou/Nytro
Linux: $XDG_CONFIG_HOME/unity3d/OhiraKyou/Nytro
Spyro's looking around feature is something I might add very late in development. As it is made mostly obsolete by Nytro's extra camera freedom, it is of very low priority.
I named that rock snowman "Rockman" in the scene hierarchy, and now I'm thinking maybe I should give it a mega buster and blue helmet :P
I do have a page in my notes devoted to headbash. I've always thought it would be cool for Nytro to use her jet pack to create the force. But, it's such a niche ability that I would currently say it's unlikely to make an appearance, for the sake narrowing the scope.
Thanks for the feedback! Very detailed and useful. Even the bits I may disagree on now have the potential to ultimately change my mind, if I see them come up enough.
She's not alone in finding the underwater camera a bit hard to stomach. It's times like this when I almost wish I wasn't immune to simulator sickness (with the exception of low FPS VR); it would certainly help with debugging perceptual problems like that. My guess is that it may be due to the camera being farther away when looking/swimming down (a side effect of the way orbits are setup in the camera plugin I use), causing a sort of roller coaster effect while swimming down. I'd be interested in hearing if swimming purely horizontal—without going up or down—is easier to take. If so, I could possibly fix it by interpolating to a more uniformly spherical orbit while underwater. This would be possible to disable in the settings menu, because I personally quite like the pull back while diving down.
The good news is that the scrapyard doesn't have swimmable water. So, there's time to test ways to mitigate underwater sickness before I get into adding proper underwater content.
That aside, development's been going reasonably well. I started down the GUI rabbit hole, since I definitely want a functional menu system before the scrapyard update. And, I may push that into the demo before the scrapyard itself, given its importance.
Yep, I'm using Unity, modeling in Blender, and texturing in GIMP.
The first and most obvious tip when starting with 3D applies to pretty much any form of art: start with primitives and just shape and connect them until you have the complex shape you want. Need a pillar? Create a cube, add two edge loops, and scale those in. Bam, done! Need a robot? Jam some cylinders and spheres together and squish them around until it looks like a robot. In fact, if you push the concept of "primitives" into abstract territory, every single thing you do can be broken down into smaller parts, and those smaller parts are generally easier to manage. So, do it as much as possible.
Building on that, it's far more productive to just throw a bunch of primitive shapes around as quickly and sloppily as possible and then refine that later once you've settled on a final vision than it is to try building something piece by piece until it's finished. You waste far less time making stuff you'll just throw out when you change your mind, and your final product is much better as a result of the additional iterations it went through and the holistic vision it had before the refinement process.
Again, this applies to pretty much anything you could possible do creatively, be it modeling, writing, drawing, level design, or even planning. So it may not be new advice. But, it's always advice worth refreshing oneself on when starting new creative endeavors. Just get something tangible out there and worry about the details when the details actually matter.
The next best tip I have is to adopt an initial style that facilitates learning. Start with palette textures (images with nothing but solid squares of color). Just scale polygons down in the UV editor and stuff them into the squares to color them. This lets you focus on modeling first and nets you a nice and consistent cartoony style as a bonus.
Once
you're comfortable with modeling, if you find that palette textures are
too limiting, try using gradients instead. Just grab vertices and drag
them around in the UV editor to change the color for that vertex. They
combine the ease of definition and updating of palettes with the
smoothness of vertex colors. To quickly project the mesh into UV space, select everything, press numpad 1 (front view) and 5 (orthographic), followed by space > type "project from view." The other numpad buttons can help you get other views.
If you use Blender, I strongly recommend learning the most common hotkeys and forcing yourself to use them as much as possible. Don't even use the transform widgets, since the hotkeys are faster, don't require holding a mouse button down (a huge plus for people like me with a faulty mouse), and also work in the UV editor. At first, it's a bit of a hassle to deal with hotkeys in Blender. But once you get used to them, the interface melts away.
Selecting all/nothing (A), Creating edge loops (ctrl/cmd+R in Blender) and extruding (E in Blender) are easily the most common actions outside of rotating (R), scaling (S), and what I refer to as grabbing (G) for easy memorization. Also, pressing X, Y, or Z limits actions to specific axes; shift plus X, Y, or Z is the inverse of that; and typing a minus at the end of a specific value is just as valid as typing one before. You can also press space and simply type whatever you're looking for into the search bar.
There are also a couple of preferences that make working with Blender easier. First, I suggest going into your preferences and swapping the right and left mouse button's actions. That inverted default is entirely ridiculous. Second, Blender defaults the z key to toggle between solid and wireframe mode. But I find that I'm much more likely to want to swap between material and wireframe mode. That can be changed by going into file > user preferences > input tab > 3D view > 3D view (global), scrolling down to the Context Toggle Values that are assigned to Z, expanding it, and changing the first value from solid to MATERIAL.
Finally, I recommend creating a clean startup file by deleting everything from the hierarchy and going to file > save startup file.
That's about all I can think of at the moment. If you have any specific questions, let me know!
Hubs will likely be unlocked via golden gears, with levels being little more than a means to that end. There will be enough gears hidden around that you could potentially skip levels and still progress. In the ideal scenario, players would be able to progress through the game by playing only the content they enjoy the most. Global collectibles serve this purpose, allowing the player to spend more time in levels they enjoy and less time in levels they don't while still progressing.
Croc was one of my favorites as well!
In addition to bolts and gears, there may be a token in each level (such as a power core). When the player has collected the token from each of the levels in a hub, the hub's flight level (assuming they are added) can be unlocked. Although, this may be rolled into level completion instead.
There are also some secret, level-specific collectibles planned that don't affect progression but give the player something fun to play around with.
The current plan is for all creatures to be robotic. Some are native to their environment. Others are resource-mining invaders. But, they're all artificial. For example, the scrapyard contains nanomachine-infected zombie robots and pumpkin spider robots.
There should definitely be an update coming soon with the scrapyard level. My original goal was to get the scrapyard out before Halloween's end. There was a lot of AI foundation work to be done that significantly delayed that. But, even if I don't make the original target date, I'll try to get a rough draft into the demo as soon as the level design for the woods section is nailed down.
You can drop suggestions any time as new levels are added to the demo. And, feel free to throw suggestions my way as I post updates on the development to my Twitter as well.
Although I haven't yet, I very well may upload dev log videos when I hit milestones that warrant some reflection and commentary (such as after adding new levels to the demo). The upcoming scrapyard level would be the first of those significant milestones.
Currently, my Patreon has a text/image post on Nytro's character design history and another text/image post on how I modeled and textured the scrapyard's nanomachine vortex, which is textured the same way as everything else in Nytro. In addition, there are currently 3 early WIP level demos (woods, crystal caverns, and scrapyard), which I generally post as soon as I have a coherent whole to show (which is to say very early in a level's development, before their unique gameplay elements are even added). Since these aren't deleted as they become obsolete, they also serve a role as playable historical records.
I actually do prefer having all basic levels unlocked from the start. Since I'd still like to give players a good, consistent reason for collecting bolts (something the first Spyro game didn't really have), what I might do instead is add something that can be activated in each level to obtain something else for collecting all of the level's bolts. Simply rewarding a golden gear, the way Super Mario 64 rewards the player for collecting 100 coins, may be enough.
Hubs will be separated into their own scenes, bridged by portals or other scene transitions. This is to facilitate hubs potentially being very different from one another without overcomplicating level design.
I quite like the space idea, if only for a single flight level. One of the hubs will be based around desolate biomes (icy caverns, a desert, and mountains), and I can't think of a more fitting desolate biome for a flight level than space. So, I've just added that to the design notebook!
Now's a good time to make suggestions like this, because very little is set in stone yet. A lot of things will naturally fall into place as I implement new things and playtest the game myself. After all, I'm simply making the game I want to play and will immediately know when it includes something I don't like. But, some decisions may be far too late to change if they aren't brought up early on. And, level themes certainly fall into that category.
Thanks for checking out the game!
Nytro takes inspiration more so from the first Spyro game (Spyro the Dragon), as I vastly prefer exploration to mini-games. I also prefer platformers to be very light on story, which is closer to the first Spyro. In addition, I take inspiration from Dark Souls, which tells much of its story through its environment rather than through dialogue.
The game will be divided into hub worlds, ideally with 3 levels, a boss, and possibly a flight in each.
Level unlocking isn't 100% nailed down yet, but the original idea is for levels to be unlocked by collectibles and bosses to be unlocked by mechanisms that activate after activating each level's end portal. Think fluids, electricity, and minecarts going through portals and into the hub. This would also unlock additional secrets in the hub, such as jumping on a minecart to reach a new location. Flights, if they are included, would possibly be unlocked by a separate collectible that would be distributed as a single item in each level.
Assuming they are included, bosses will likely be more platforming-focused than Spyro's bosses, as I've always disliked combat-heavy bosses in platforming games that otherwise do not emphasize combat.
The impact-exaggerating pauses will be enabled by default, likely with an option to disable it.
When the scrapyard level is complete, it will be added to the demo and accessible likely from the dumpster portal. It's coming along pretty well, with progress updates being posted to my Twitter. Meanwhile, second tier patrons can download some level WIP's early.
Thanks again for your interest!
I just don't see why the two aren't combined. By the time a payment is eligible to be included in a payout, that should already be done. Again, if there's some sort of manual process involved, it could make sense. But, if not, there's no point in having two separate delays in the "collected by itch.io & paid later" method.
I appreciate that, but I use the "collected by itch.io & paid later" payment model, which includes a 7 day delay before a payment becomes eligible to be included in a payout for that exact reason. So, what makes the additional time special? Is there some sort of manual review process, or is it just additional time on top of the eligibility delay? If it's the latter, surely that should just be rolled into the initial delay when using the collected by itch.io model.
Whoa there. I thought I had totally eliminated ways to swim out of water. Since I couldn't reproduce it by charging out of water and holding the swim button, could I get some very specific details about how to reproduce it? Ideally, what buttons you were pressing, when you pressed them, if you were holding them when you got out, where in the water you entered, where you got out.
In the first camera system I made for Nytro, controlling the camera with the look input while charging was actually implemented that way, because I felt the same way about it. There's a pretty strong desire to steer with the look controls, and it feels pretty good on a gamepad (while using left bumper/L1 to charge).
But, it works poorly with a mouse due to it giving off a 0 to 1 value based on a change in movement rather than a constant value like you would get with an analog stick or button press. Since there's an intentional limit to how fast Nytro can rotate while charging, it tends to feel sluggish with a mouse. It's a lot like controlling a super slow turning aircraft in a flight sim using a mouse. I've thought of and tried some solutions, but it's pretty hard to make it feel solid.
That being said, I do still want to try porting steering with the look controls over to the new camera system with gamepads, at the very least. And, I'll try to find a reasonable compromise for the mouse.
Animations are definitely in the list of things to polish up, with some of them thrown together out of necessity while working out the basic movement kinks. Swimming uses existing dry land animations just to indicate a clear state change while testing, and the glide animation (which is temporarily used for multiple swimming states) is more like a glide frame of animation. For swimming, my current plans are to either add retracting paddle wheels around the thighs that extend in water or use the legs themselves as paddle wheels.
I may be misunderstanding about the character snapping forward suggestion, but if you mean that it's difficult to keep the character aligned to the intended movement direction while walking and rotating the camera, I agree. Although, rather than artificially bias the player's input to their original forward vector, I'll be changing the way the camera targets the player so that it's less wobbly, which should mitigate the problem as a side-effect. If that fails, I may, indeed, have to look into adding a movement input bias. But, I'll leave that as a last resort and possibly a user preference in the options menu.
Anyway, enough of my thinking out loud. Thanks for the feedback! Overall, most of the suggestions I've heard so far align pretty well with the to do list points in my notes. So, while they may not show up in the demo for a while (as I'll be focusing on content until I have a couple of decent levels and a proper hub world) they'll certainly make their way into the game eventually, in some form.
