ORNA - An AR App Review

ORNA is a GPS RPG similar to Pokemon GO. Players explore the real world on their own two real feet to find virtual monsters and dungeon and fight them on their mobile devices.

---------------------------------------

Three things I like are as follows: 1. At the beginning of the games, player progression seems quick and does not require real world money purchases. As the game progresses I'm sure this model will return to something more akin to a traditional exponential progression system. 2. The UI is somewhat familiar even though I've never played this game before. The UI is definitely reminiscent of classic RPGs such as Final Fantasy and Chronotrigger. The inventory system however, leaves much to be desired. 3. Especially in this time that people really shouldn't be going outside, The game is being more than generous in spawning things to interact with around me. I'm unsure if this is a change thats been made because of the C-19 crisis and I am aware that Pokemon Go has already made changes. Although it is worth noting that the area I'm playing in was never a hotpot for Pokemon Go, Ingress, or Minecraft Earth

---------------------------------------

All other apps I've looked into seem to have a camera based AR system in place. In Pokemon Go you can see the Pokemon appear on an overlay of the area you're in by utilizing the camera. Minecraft Earth does something similar in that you can create structures out of blocks and you need to reposition yourself in the real world to view the structure from different angles. Ingress did not have any such feature when I last played, though that was years ago. As far as I've been able to explore, ORNA doesn't have any camera based AR features. Something else of note is that the map you are presented cannot be turned, as it can be in the other games I've looked into. Likely this is an artistic decision to keep the game true t5o its retro RPG roots.

---------------------------------------

Suggestions for ORNA: The radial menu used for the character information is a lot less intuitive than it could be. On one hand, it does eliminate the need for the user to scroll. Though on the other I find myself searching for things every time I open the menu. I also feel that some of these options could be reorganized.

---------------------------------------

Though it may break from the games that inspire this one's style, adding an option to slightly pan the camera, or to zoom out, would be welcome. As far as I can tell , there is no way to search the area nearby you for a point of interest, as there is in similar games. This would help users know which ways they should be traveling. Being stuck in my home as I am, I actually don't have a way of knowing if there actually ARE points of interest without searching on the internet.

---------------------------------------

The Unequip button is just in a terrible spot. The UI features an X button to close an equipment screen, as well as a large red button to unequip. The X button is static, and the Unequip button is always at the bottom of the current inventory. This can mean mis-pressing one button or the other. I would suggest to move the Unequip button to right side of the currently equipped item and always have that item at the top of current list of items.

---------------------------------------

I think this game is purely that - a game. It would be nice to see them expand the game to feature community events similar to Ingress and Pokemon Go to encourage play together I would give this app a 3.5/5. I think the game itself is nearly perfect in its functionality and play-ability. Most of the points lost come from some strange UI choices and a few on the UX front. Mainly the placement of some buttons are an issue on the UI side. From the UX view, limiting the user in order to maintain an old-school feel may be hurting the app more then the nostaliga is helping.

Click Me

Update 4: Simple Mechanical Rig

Entry1:

With my capstone centralized around a mechanical creature, I figured I would experiment with a very basic vehicle that only uses simple machines - the bicycle - and that I wanted to do it entirely without bones. I know this wont be a huge challenge, but there were somethings I felt I could play with Having already modeled one for my street corner. First thing I did was break the mesh apart into the pieces that would move: handle bars, wheels, pedals, etc.

Entry2: 

I set up very simple controllers, and used parenting to group the appropriate meshes together. I used the connection editor to drive the pedals into the back wheel (this time actually getting to use  the multiply node mentioned in the last post), ensuring that the rear wheel moved faster as its on a smaller gear. The handlebars control the front wheel, and the front wheel can rotate independently for the back.

The pedals were the part The I was most interest in: something I hadn't done before was create a part of an object the moved relative to a part its anchored to, but allow for its own movement. The solution turned out to be much easier than I expected and actually did not present that much of a challenge. I simply parented a locator to the pedal arm, and then parented the pedals to the locators. This makes the pedals stay level, no mater how the arms are rotated

All in all, this was actually pretty easy, though I was interesting to be working only with where the rotation point of the controllers was. There was a little bit of learning here, but I was able to intuit it through a little trial and error rather than research or learn from another source.

Update 3: Arms IK/FK toggle

Entry1

Something we've never really gotten around to doing with rigging in our classes is, well, rigging. We've gone as far as to place joints in relation to a mesh, but have done nothing past that. Today I will start by working out how to bind skin, create controllers, and be able to toggle IK/FK.

I found an arm from second year where we had placed the joints inside the mesh and I have added basic nurbs shapes for controllers.

Entry2

I have used parenting and constraints in order to make the hand locator and elbow pole behave as intended. I add a rotate chain solver IK handle connecting the shoulder and wrist. Finally, I have bound the skin using the Geodesic Voxel method, which seems to yield the best and quickest results. For the sake of this exercise, I will not worry about weight painting too much. Seen below, the rig is now behaving as intended

Entry3:

Next up is making the toggle for IK/FK. This will be done with a driven key. I've created another nurbs shape with an boolean attribute. This will drive the toggle between IK/FK, as well as the visibility for the controls. The connections are driven through the connection editor

Entry4:

Since I already have controllers for the IK mode, I need to still create some for the FK. I've often seen orbs made of three rings used in this place, but when grouping nurbs circles in the regular fashion they maintain a hierarchy. Reading through Rigging for Game by Eyal Assaf I have found that Python or MEL can be used to remedy this. The example given used MEL, so that is what I used as well. The jist of it is a line fo code reading:

parent -shape -relative [a list of the names of the shapes you wish to group, seperated with spaces] [the name of the object you wish to add those shapes to];

This results in a complex nurb shape where any part of it can be clicked without worrying about a hierarchy

Entry5:

This part requires me to be able to invert the boolean on the IK toggle, but I at first had no clue how to do this. I found that nodes can be created in the hypergraph, then thought I could use a MultiplyDivide node to multiply by -1 thus inverting it (forgetting thats not how booleans work all at the same time). One of these nodes is a reverse node. This node seems to be able to flip a fed boolean and does what I need. Connections are driven through the connection editor.

I had to restructure the parenting and constraints of many of the components involved, but the end result is as desired and allows the use to toggle between IK and FK, and remembers the last posion of both.

IK and controllers, working as intended

FK and controllers, with only one small hiccup

The only issue with this setup is that, when switching from IK to FK, the FK wrist orientation remains the same as it was when it was IK


Overall this seems to be a success, though I know there are other ways to get this working, one of which includes using multiple sets of joints for each type of control method.

Update 2: The One With No Subtitle

The last week has been busy, though I've found some small amount of time to put toward this research. After asking someone currently employed as a rigger and recently graduated, I was pointed towards learning Python scripting, and trying to work with an animator whenever I can. As the animator is the one who will be using the rigs, it should be tailored to them. The the time remaining, I'm sure I cannot get too in depth with Python scripting, though I will be sure to pursue this in the future. Letting animators use my rigs and give feedback as they are constructed is also a very helpful pointer and I will definitely be asking the animators in the class to play with and give feedback on any rig I create.

Update 1: Bits and Pieces

Brainstorming ideas for rigging proof of tech. Components include working out all the mechanical parts and how they function independently and as a system, exploring MEL and/or Python scripting and its application to rigging, and building useful controllers for a character rig.

Parts created include different piston setups, a simulation of a camera aperture, as well as pistons that maintain proper fluid volume relative to each other, regardless of how far apart the moving one is in any direction. This is achieved by constantly measuring the distance between two locators on the moving ends and translating the stationary piston based on the amount they are separated