Blog post have almost seemed to stop as the project was heading into presentation week. The weeks prior to the capstone presentation slowed down due to a rather unfortunate issue addressed in the “Unreal Issues” blog post. As for the week of presentations, it was also without posts due to the said presentations. This post is going to catch the reader up on what I have done just before heading into capstone and address how I felt my presentation went.

First, what have I done since the last update? The last update addressed an issue with the Unreal Engine and the way my grass was implemented in 4.20. That issue was not resolved, but I have added several other features. Listed below are the additional features.

Timer: I built a timer using the FTimerHandler functions within Unreal. It just keeps a running count of how long the game has been played

Distance: I added functions to the mower to calculate the magnitude of the vectors it moves along. The actual distance the mower would be expected to move is much lower than the sum of the magnitudes. I fiddled around with a number that I thought I could divide by to accurately show how far the mower moved. The distance measure that I labelled the conversion was in feet because I felt it was the best representation. That said, this is not a true measurement of feet.

HUD: On the screen, I made a HUD to display the timer and to show a progress bar of the game as it progressed. This was my first HUD I built for the game and acts as the main HUD. A second HUD is the overlay for when the game finishes, either by parking the mower in the shed or by sinking it in the water. The shed will allow the player to back out and continue playing while the water will restart the game after 10 seconds. The second HUD displays the overall stats of distance traveled, time taken, count of grass cut, and grass cut by percentage.

Mower Handling: A small amount of code was added to keep the mower on a certain track while running at higher speeds. This not only feels more accurate to a real mower, but is actually easier to drive at higher speeds.

Mower Calculations: To the player driving the mower, this change seems almost pointless and wouldn’t likely have been noticeable. If the user wouldn’t notice a difference, why change it? Well, I will explain why this was bad to give a better understanding. Originally, I had only calculated the rotation of the tires in one order. This was bad due to the fact that rotations aren’t commutative and that caused the mower to inherently slide to the right without even meaning to. The user wouldn’t notice this however because the actual angle measure I rotated by was small enough that this was practically insignificant, but if the player would have gone straight for extended periods of time (much larger than the allowed area), the effect would have been noticeable. To summarize, since both the changing angle measures and the area of possible distance were small, it was unnoticeable to a player. What the new calculations really means is that the mower no longer moves properly because of smoke and mirrors, but rather because it actually moves as intended.

Sound: I added mower sounds to the game which add to the effect. I found the mower sound effects on OrangeFreeSounds.com. I also added a feature to toggle it on and off.

Camera: I actually added two different camera features. I added a top down camera that can be swapped to instead of first person. The button is a toggle that can used to switch camera mid game. Another camera feature I added that is only in effect while in first person mode is to look left and right with the two triggers of the controller. The trigger sensitivity determines how far you actually.

Additionally, I did some documentation and rearranged a big portion of my code. I actually made some new functions which allowed me to move some code outside of the Tick() function which made the program much more readable.

At last, I will address how I felt the presentation went and my thoughts as the class/project comes to a close.

To begin with, I would like to give a big thanks to Dr. Pankratz, Dr. McVey, and Dr. Meyer for helping me through the project. I feel as though I was in one of their offices once a week talking about the project and shooting off ideas or getting feedback. Without them, the project wouldn’t have come nearly as far in this time frame.

As for my presentation, I was excited going into it. I had asked my co-workers in the IT department to play it before I presented and they had good feedback and responses which was really heart warming. I have always been fond of presenting, so I wasn’t nervous going into the presentation either. Actually, in my early test runs, I found that I had too much info and had to cut a lot out. In the end, I felt that my presentation had a good flow without going to in depth, but also hit enough major points.

Overall, I am happy with the way it turned out. I definitely had more plans for the project that didn’t make it to the light, but I feel as though the current model is in a good state as a proof of concept. I enjoyed the project enough, I might just keep working on it.

“Its nice to look back at the grass after you are done mowing it. Really shows what you accomplished.”

I have several things on my list that I would like to start getting to, but I took a brief aside where I was looking into packaging the game. One thing that I have discovered is that when I play the game as a standalone, the grass will not be removed from the scene until I stop cutting grass. This can be done by either stopping motion of the mower, or cutting an area with no grass (sidewalk,sand,previous cut area). What I have discovered in my research is that the array that contains the grass meshes from foliage tool is redrawn every time that an instance static mesh is removed. I would assume this is done so to decrease the size of the array to make memory more manageable. What this likely means is that the redraw has a lower priority and doesn’t actually take place until it knows all of which entries it is removing or that the constant redraw is too slow. Either way, this directly hinders the ability to show that the grass was cut. Oddly enough, it runs fine in the editor, but not fine in the standalone window.

As for solutions, I have tried looking into changing the mesh of the object at runtime to avoid actually recreating the table. Perhaps a clever sneak, but this approach hasn’t turned up a solution since it doesn’t seem the mesh is changeable at runtime. Essentially, it doesn’t seem to have a function to do so. I tried setting a new instance transform for the object which would move the grass out of sight. This is a function, yet also yielded no success. Rather, it crashes the engine. I would assume that the crash happens from something on my end, but it may also be that the tedious tracking and movement of several grass meshes is too much. I plan to further experiment with this in my test environment. The last solution I tried was to only check if I was cutting grass every other tick, but this unfortunately doesn’t work for two reasons. The first is because the mower is still moving every tick and very rarely, but noticeably, it does miss some grass as a result. Stopping the mower every other tick creates unnatural driving simulations which is why slowing the mower down is not a fix. That said, even if I could slow the mower down one tick to accommodate the blade cutting speed, I also noticed that one tick still wasn’t long enough for the computer to update the graphics. This was shocking to me as I thought for sure that in the tick without checking the cutting zone that it would have been able to update the graphics. So this actually doesn’t work on two reasons and further slowing down the rates is dangerous in other ways (timer, mower simulation).

One thing I found really interesting about this is that in version 4.19, there was an option for a “dynamic vertex buffer” which essentially stopped the redraw of this table and allegedly fixed this issue that I have. This option has been removed in 4.20 and higher which is where I currently have my project. I have considered moving back into 4.19 but, for the actual capstone project itself, this shouldn’t be an issue since I can do my demonstration in an editor window. The two real concerns with the issue are how my professors can access it after I leave and how I could release this game should I ever find that I want to release it.

That is all for now.

For those who do this project after me or who are inclined to learn about the way I ended up doing some of the tasks in Unreal; here are technical layouts for how I accomplished problems and implemented them in Unreal. Note that this will detail the tools and implementations within the engine, but not the entirety of the solution.

Landscape: Landscaping was done using the built in landscaping tool. Textures for the landscape are taken from the various asset packs that I have from the Unreal Engine Marketplace, but are mixed and matched into a material asset that I built. The material asset I built had to contain all of the different layout textures that I wished to brush on the landscape such as grass, sand, and mountains. I used this tool to build most of the mountain landscapes as well as the “under/cut” grass and sand. Some of the rock cliffs come from the “Kite Demo” pack which is arguably the most useful of the assets I have.

Mansion: The mansion was built using the geometry tool. I used solid cubes to build the initial house and then I used cutaway cubes to build doors and windows. On a specific month, one of free assets given out was a material pack and one of the clothlike material textures I used to give off the curtain effect. Since the mansion was an aesthetic, I found that I didn’t want to waste time on splines and just used a solid block containing the clothlike texture. I also used a glass window pane to add to that window affect. The interior of the house, although very dark and hard to see, does have a carpet from using material from that same pack and also chairs and tables from the defaults pack.

Grass: Grass meshes are taken from free packs on the Unreal Engine Marketplace. I use the foliage tool to create the wide area of grass meshes that would later be cut. On my character blueprint, I have a long set of blueprint nodes that uses “line traces” to see if the grass is directly underneath where the blade would be. If these lines collide with a grass material, they remove the instance of the grass. This is how I amount to having a large number of grass meshes as well as how its cut at runtime. I can’t remember if I used the grass from the “Kite Demo” pack or if it was from one of the other various asset packs that I have, but I would like to note that its important to have a collision box on the static mesh itself to ensure that the line trace can collide with it. Checking the collision properties of both the mesh and the foliage instance are very important. I used a trace by visibility, so it is very important that the foliage instance has custom collisions such that it blocks visibility but allows for pawns and potentially other objects to pass through them. More on the mower blade mechanics in the lawn mower section.

Zero Turn Lawn Mower: The zero turn lawn mower doesn’t extend to the vehicle blueprint class. I instead chose to use a character blueprint. Choosing between a character and a vehicle was a semi difficult decision. I chose to use a character blueprint approach over a vehicle blueprint approach for a few reasons. The first reason is that I have more experience with the character blueprints over the vehicles. The second reason is that I found more c++ in the prebuilt vehicle model that I would need to strip out than useful. I am aware that I could have started with a blank vehicle template, but I didn’t want to take time setting up all the individual components. Third, I felt that the extra features for the vehicle template couldn’t easily be extended into my project. For example, the feature that the vehicle class had that I was most looking for was its speed. From my understanding, the speed required movement, but it may have restricted me to using the forward movement component which was my fall back plan. The more correct solution which is my current implementation is to calculate the point at which the lawnmower would be at after pivoting around each of its tires. This however doesn’t use the movement component and therefore is the final reason why I don’t use the vehicle template. To accomplish the zero turns movement I have collision boxes placed at each tire and use their world location to pivot the center point of the lawn mower. To calculate this new position, I used various linear algebra techniques such as change of coordinates and rotation matrices. This method finds the correct position but by setting the location manually I create the need to define collision bounds to stop the object from phasing/teleporting through thin hollow walls. I haven’t yet resolved this issue, and thus there will be no further technical discussions on the movement component in this entry. Finally, as for the mower blade cutting area, as mentioned in the grass section, I used line trace by channel to determine the area by which the mower would cut the grass. I used blueprint nodes to construct the trace using the “visibility” channel to check if their was any grass meshes directly below the mower. I used a total of five traces to calculate directly below the mower and the edges of where the mower blades would be. This model can be seen in the “Need Blades to Cut” Gallery image. Several other mower mechanics such as force and animations currently are not implemented and thus those will be saved for another technical update.

Water: I found some assets in the marketplace which contain water in them. Water is something that can be created various different ways, but the asset that I am currently using is a static mesh that has the basic rift properties already. I used this static mesh to make a simple pond that the player can sink their lawn mower in. Since the pond is only meant to be a trap, I don’t need it to do anymore than a simple collision check to see if the player sunk their lawn mower in the pond.

The following are the objective topics slated for the next “technical update”:

A.I Mechanics

Advanced Mower Mechanics

Win/Loss Conditions

Efficiency Calculations. (Distance/Time/AmountCut)

Spring break is to blame for my lack of blogging, but I return with good news. The week before spring break, we covered change of basis in my Linear Algebra class. After speaking with my professors, I learned how to do change of coordinates and some quick googling showed me how to rotate points using matrices. Within the Unreal Engine itself, rather than building the necessary matrices to do this conversion, I just wrote my own function which actively does the same thing. It does so as a stream of calculations rather than FMatrix functions. I am happy to see that the mower is properly moving about. Next on the list for mower mechanics include force, mower animations, and collision parameters. I am currently using SetActorLocation which is a near absolute position. I have a problem with clipping and phasing through objects such as walls since the object doesn’t “sweep” to its position. I am aware that “sweep” is an option in Unreal, but I don’t know that it can be done with SetActorLocation. I will look further into this implementation, but my current plan to solve the issue is to use line traces off my mower and see if an object is in its way. Either way, I don’t feel that this will be an issue for long. I additionally plan to several tweaks to the mower such as an update to my camera mechanics and balancing proper mower speeds.

Despite having plans for all the mower updates, outside of tweaks and collision, I plan to put the rest of the mower physics on the shelf for now. Aside from collisions, the mower currently moves in accordance with a proper mowing model and I would like to put time towards other portions of the project. For example, I would really like to begin working on an A.I obstacle that moves around. With the obstacles in mind, I want to start adding win/loss/exit conditions into the game. As such, I need to start working on various HUD’s with things such as the rules/objectives/stats and so on. Although I foresee this being a fairly easy task, I feel that it will be a time consuming task since it will require design.

At the top of my agenda is updating the gallery. I noticed that my “Angle Congruence” image never posted. I will get that updated correctly and I also intend to add several more pictures to the gallery. I likely will get to the mass gallery update tomorrow since its advisement day and I will have a good amount of time to work on getting images. Since its taken this long to get the “Angle Congruence” image, I will probably put in a small amount of additional effort to make the drawing in GeoGebra.

Time to start cutting the grass.

I haven’t blogged much recently because I haven’t made much progress. I came to a realization that would make the movement easier, but has alas, created another problem that although seems easily solvable hasn’t yielded any results as of yet. First I will try to do my best to explain the situation and the solution. The movement of a zero turn lawn mower when one handle is pushed is to rotate the tire on the same side by the opposite tire. Essentially, if the left arm is pushed forward, the left tire will move forward while the right tire is fixed in place. This will cause the mower to move in a circular motion. Now onto the realization. Try to picture that there is a radius of a circle from tire to tire with the center of the circle fixed on the right tire. The left tire is the point of movement around the circle. The direction of forward motion is the same as the tangent of the circle at the point the tire lies on. Choose another point on the circle and draw a radius from the center to that point. From here, take note of the angle between the tire axis line and the new radius through the chosen point. The angle of separation on these are the same as the angle formed by the intersection of the two tangents. (the second tangent being the one through the newly chosen point). I will post a screenshot titled “Angle Congruence” to demonstrate what this really means. Should the reader not believe this to be true, they can prove it themselves by extending the radius of the new point to intersect the tangent line of the first point. This can then be used to create a common angle between two triangles who also share a right angle. The remaining angle must therefore be the same. I may also include this drawing along with the angle congruence.

Whew, now lets talk about the problem. This has created a situation where I can know a starting point on the circle, the center, the radius, and the angle by which we are moving from the starting point. Essentially, I have created an isosceles triangle where I know two points on the triangle, the top angle (top defined to not be either of the base angles), and the length of the two congruent sides is the radius of the circle. I now should be able to find the coordinates of the other point, which I can using some trig from the axes, however I also need to consider that this lawn mower can be in any orientation within world space. That means that the two points may not align properly and thus I need a “for in general” solution. This means that I may need to look into un-transforming the lawnmower, finding the new point, and then apply that transformation to the new point. I unfortunately don’t have any intuition as to how that would be done as of yet. I am aware that I can apply linear transformations, but I don’t actually have a full understanding of how the matrix functions work within Unreal. My current implementations involve using FRotators, which is very useful for moving the object around, but I don’t know how to apply that transformation to a point. Alternative solutions could be to calculate the line that point lies on and find where it intersects the edge of the circle. The unfortunate problem is that I only have the center point for that line and don’t know the other point.

This problem is what is currently causing a large hang up in the process. If this doesn’t work, I do have my old back up approach which is rotating the object then moving it forward at a rational speed to simulate proper effects. With spring break coming up, I plan to put much more time into this project and maybe start working on other things. I am thinking about whether or not I want to do A.I first or if I want to implement a timer and start doing distance. I am leaning towards A.I because that is slightly more impressive and also I think it will be more “fun”.

The lawn will just have to get cut another week. By the time actually get to cutting the lawn, I will be cutting a jungle!

I have actually spent my entire weekend doing nothing but programming for capstone. Occasionally I stopped to eat and watch an episode of Lost, but then I wen’t right back to work. I am rather happy that I got the actual grass cutting down. I now have the ability to put grass into the level and mow it down. Admittedly, it took much longer for me to figure this problem out, but it would be a lie if I said that all I did was work on the grass. I have also been putting some effort into finer details such as actual map design. I have an area that I am starting to pen in with a mansion, shed, cliffs, and hills so that the player has a set area to play in. The mansion currently acts as a blockade, but it doesn’t have too much depth. I have been putting some time and effort into making the mansion look less like a giant block and more like a real home. This eventually lead me to build a really poor shed for the lawn mower. I actually really enjoy the fine tuning of making it look semi good, but I know that I don’t have too much time to spend on that. I would love nothing more than to continue detailing to perfection, but I need to spend time elsewhere.

One detail that I do plan to start working on sometime soon is the actual wheel physics. The Dune Buggy asset that I have from the Epic pre-made game actually had properly working wheels. I would like to have the wheels roll even if they aren’t rolling in the truly correct manor. The front wheels of a zero turn lawn mower are capable of 360 degree turns with the vehicle and require careful detailing. I don’t know that I want to spend time getting the wheels of the dune buggy to be that accurate, but I would like them to at least turn in the direction of travel.

With all that said, its a huge relief to have some grass that I can physically drive over and watch disappear. It came with several misfortunes along the way and I know more will follow, but I secretly enjoyed the challenged and its such a rush to have gotten over it.

If I am this happy just to remove grass, I can’t wait to feel the excitement I get from driving physics.

P.S. I am going to add a photo to the gallery with the debug testing for how I find the blade area of the lawn mower. I think its a cool screenshot and it will demo some of the current map design. That is all. Carry on.

I have been working on capstone for most of the entire day. I have put little thought into the movement section and have instead been working on map construction. I have hit several snares as of today. So far, I have been doing small scale testing with the tile layout. As it turns out, at significantly higher tile counts, which are necessary for a well sized map, I am finding frame rate performance to drop rapidly. This causes aggressive screen lag. To cut down on the lag, I had reduced the amount of grass per tile, which was effective, but didn’t solve the issue. I definitely knew going into this approach that the tile construction would be heavily taxing, but I didn’t expect it to do this poorly. My laptop has a considerably powerful graphics card for a laptop and runs games very smoothly. As a result, I find it hard to believe how much power is required for an actor object. With this in mind, I have been doing some research into how grass is made in big productions that have large scale maps. I found that the proper way to make grass outside of landscapes is a foliage brush which brushes static meshes into the world instance. I have yet to implement, but I found solutions online where people have actually converted foliage instances into actors and then removed that foliage instance. This would allow me to “cut grass” as I had hoped in the first place. Additionally, this could give me more power than initially realized. From my understanding, each foliage in the brushed instance has some kind of value for tracking. Hence this is how we know which foliage to remove. That said, if I can find out how to access the structure containing the foliage, which I believe to be an array, then I can check to see if any objects still exist in the structure. Another method I could use with this knowledge is to find out how many objects live in the structure and just keep a running tally of how many I remove. Either way, this would be great for determining when the game ends. Alternatively, if can’t find out how to access that information, I may be back to my previous solutions, which is either manually counting grass patches or using a countdown timer.

I have also added a new image that contains some experimenting from the tile setup today. The vehicle in the image is the default Unreal Engine Dune Buggy from the Advanced Vehicle Default Project. I decided that was the easiest, closest thing to a lawn mower. I colored it green for dramatic effect.

I guess the lawn isn’t getting mowed today.

This past week, I have been extensively working on getting a set of lawn mower physics down. I spoke to my Linear Algebra Professor to get some ideas and he came up with a different approach than I did. His idea was that a zero turn lawn mower will always turn in perfect circles at an instant. Essentially, if the lawn mower remained constant speed, with the exception of straight, we know that it will follow a circle. As such, we can calculate how the lawn mower would move along the circle at that individual instance (tick). In the next instance (tick), we can recalculate the next circle. I am currently logging and experimenting using FVectors and FRotators functions to find out how they affect the the objects in the world. Currently, I have a dummy, that when the left joystick is pushed, will run in a circle. I however do not have a perfect zero turn for him as I have yet to implement the circle path approach. I have some concerns with that method as to feel and accuracy. How I have visualized the problem is a result of how the joystick functionality is implemented in UE4. The problem I see is that each joystick has its own function, which means that each joystick will have its own circle path calculation. I worry that running each of these separately will either create jitter or put the mower in an un-correct forward alignment. To note, I don’t expect perfection, but I would like a fairly close interpretation. As a matter of fact, most simulator games are more fun when they aren’t perfect. The minor nuances in the mechanics often make for memorable experiences.

Moving on, last blog I talked about procedural generation for objects in the world. As it stands, I am still considering this approach for placing trees, rocks, and other obstacles at random, but I don’t know that I will use it to place the in game tiles. I found a video of how to place walls, which of course wouldn’t be a random placement, but overall tile placement took a backseat when I started working with mower physics. If need be I can manually place tiles in the map. Manual placement will actually earn me just as much freedom as programmatic placement. As a matter of fact, manual placement is more visual for me which helps reduce the amount of times code needs to be tweaked. The trade off is that I won’t know exactly how many tiles I placed, and I may need to count them manually as well. If this is the route I take, I have a strategy to place one tile, which I will clone. I then will copy both tiles at once, and clone them. I plan to continue doing this until I create the desired size map and thus I can know how many tiles. based upon the number of “clones”. Lets be honest, I mean just copy and paste a grouping of tiles over and over again.

Meshes are another topic that I have put thought into, but of course, I haven’t really had time to make a lawn mower mesh. Keeping that in mind, I did find this really nice dune buggy in the Unreal Assets that they offer with their prebuilt offroad simulator. I might re-texture the dune buggy and drive that around.

I am hoping that I will have some new pictures up in the very near future. I at the least plan to add a picture of my working environment to the gallery. I am using my TV as a second monitor and it is driving my roommate nuts since the screen resolution doesn’t perfectly align. Thus some of the screen is cut off. At some point, I may also add a screenshot with a snippet of my code and/or the engine itself.

First, I would like to state that I plan to start blogging more frequently, with more specific information. For now, allow me to catch you up to speed. Landscaping was the first problem in Unreal because it is the best way to develop large scale maps with textures. That said, the mesh on the landscape isn’t changeable at run time. The solution to that was building tiles that contain a mesh that can be altered on collision. This solution will work fine, but it has caveats to it. The biggest caveat is knowing when the entire lawn is cut. I need a way to keep track of how many tiles are able to be cut. I have been looking into making an array of the tiles where I can calculate the actual number of tiles cut by simple rectangular area. In the pursuit of this idea, I came across something called procedural generation.

Procedural generation is a way of placing objects in an algorithmic process that is either well defined or random. For placing some of the obstacles in the world, such as tress, I am hoping to make a random procedural process. As for tile placement, I don’t know that procedural generation will be worth the effort vs nested for loops. One problem I am thinking about into the future is how a tree could cover tiles in the area to be cut. Resulting from this, I need a formula that will take into account tilestobecut = totaltiles – tilescoverbyobstacles. The goal of the tilestobecut variable is so I can manually keep a count of each tile actually cut which allows me to say when the whole area is cut. Essentially, that cutting tiles underneath or directly next to trees may not be possible. Depending on tile and tree size, this can create some issues where the count might be thrown off by one or two tiles. Some hitboxes for a tile might be slightly outside of a tree, which would instead result in a problem where the player gets a +1 tile advantage. This could stack into a multiple tile advantage should multiple trees have this hitbox collision. This area of the project will probably just require various tweaks to get perfect. It also seems like something that realistically I could leave alone and say its a bug to patch later. That said, the completionist in me probably can’t accept that.

The second part of the project that is really important in design is the movement for the lawnmower. I have been looking into different movement and vehicle aspects. There appears to be a type of blueprint that already has vehicle mechanics built in, but I need to find a way to “hotwire” them into a lawnmower design with multiple joysticks. I know that you can start with a preset vehicle game design, but I have only been working from scratch. I plan to make a temporary vehicle project to learn some of the inner workings behind it. With that in mind, I have been watching a good majority of the official Epic Games Youtube tutorial videos for the engine. Epic’s official documentation and tutorial videos are a real gem. Within these tutorials, I found that they actually have a built in speedometer for vehicles. As of right now, I only saw that the speed exists inside of a debug command window, but I am hoping that I can access that information in a variable. If I can find a way to access the speed value, I can find distance with ease. The physics formula for distance is distance = speed x time. I already plan to build a timer, which I should be able to subjugate to a mini-timer that will keep track of start and stop time. This of course doesn’t handle change in acceleration. I might just cheat that by calculating average speed throughout the medium to find distance. I haven’t put much thought into that.

Finally, I am hoping that I can find some spare time to throw together a cheap blender lawnmower model so that I don’t drive a block around. I may find some free assets and throw something really chintzy together. Since I plan to make this first person, I may just have a seat with some wheels that casually roll around. Although, the front wheels also have some rotational physics to them, so I don’t look forward to that.

That is all for now!

This is the first of many blogs to come, hence the poorly translated Latin above meaning “more to come”. At least the internet told me that is what it means.

Moving on, lets talk about the project. Up until now, most of the accomplishments made have either been planning or throwaways. As you may have seen in the gallery section on the right hand side, there are two pictures.(hopefully more than two reading this at a later date). Those pictures contain my first workings on a landscape for the grass and plans for the physics behind the lawn mower.

I have encountered two problems:

1. The first issue comes with the landscape, which is not changeable at runtime. It is changeable at runtime given some changes to the engine. I found that this has been done by mainstream game studios who required it on a project, but alas, I don’t have time to change engine source code. My solution is create tiles that contain static meshes that can be changed upon collision with the lawnmower. This of course leads to other problems such as how big tiles are and how to determine how far the lawnmower has traveled in terms of distance. I have some theories on how to work that out but that will be for another blog.
2. Second is the problem of the physics behind the lawn mower. This of course also has mini issues to it. A breakdown of the idea first may help the reader understand the issue. The lawn mower operates with two handles each of which control the motion of one of the wheels (forward, backward, and how fast). The first problem is realizing that the lawn mower realistically has pivot points about which it turns. Calculating turn radius on the lawnmower via multiple pivots is not ideal. A solution to simulate this effect is to turn the object in relation to its velocity simulating a pivot. The coalescing vectors in a direction and in rotation should amount out to the proper feeling of the lawn mower if they are balanced on a solid ratio of speed vs. turn. Finding the right balance is one of the tasks at hand. The other task is to find out how to make the arms appropriate with joysticks on a controller. I would like the two joysticks on a controller to act as the arms of the zero turn lawn mower. This would give off a more realistic effect. That said, I need to find out how to use the percent threshhold on the controller to find out how much “force” someone has applied to either joystick. This in-turn would relate to what each arm of the lawn mower would be doing in game. I have a few ideas how to cheat this problem should I not be able to access the percent yield of the joysticks.

These are the current tasks and their worries on the project.