Lander with HUD and Stuff

June 13th, 2017

There have been a few improvements made to the Lunar Lander 3D Unity game since my last post. The previous to-do list looked like this:

Add a particle system to draw rocket flames.
Add a landing pad and detect a successful landing.
Add an explode-able version of the lander and blow it up if the lander lands off the pad or lands too hard or too leaned.
Sounds.
Terrain.
A game management system to load multiple levels and to provide a start screen and stuff of that sort.

The latest version of the code has four of those items mostly working.

Latest Lander Test

The particle system for the flames comes from the Unity Asset Store. It is a low-poly particle system resource I bought for a few dollars. I think that I really only need to write the code for a particle system once I need something custom. I suspect that the code is minimal anyhow since the Unity particle system handles most of the work.

The landing pad is a low-poly (low-polygon-count) cylinder with my own graphic added. The lights are the ends of small cylinders that have their light set to “unlit” or some similar setting that keeps the tiny bit of their sides or the edge between top and sides from being a different color from the top. The flashing is just a few lines of C# code to change the color every so often.

The rocket sound is another purchase, this time from a sound effects site called soundsnap. Although I bought a particle emitter that I could have written myself, I have no idea how to get or make sounds for the game. Purchasing is the only way to get what I need for the sound effects. The script for the lander adjusts the volume based on the thrust level, making it good for throttle feedback. And since the emitter changes the rocket flame emission from the thrust level, flying is pretty easy with a joystick.

image

Game Controller

Something that wasn’t on the original list was joystick support. It was easy to hook an Xbox One S Bluetooth game controller to the PC and use that. I use the right trigger for the throttle and the left stick for the lander tilt.

On a side note, I had a discussion with my dad about using the left stick for the pitch and roll control and the right trigger for the throttle. When I use a full size joystick and throttle control that I have for the desktop computer to fly with MS Flight Simulator X and other games, I hold the stick in my right hand and throttle with the left. And if I’m flying a helicopter in a game with that stick and throttle, I reverse the throttle so I’m pulling back/up on it to increase the throttle, just like the cyclic control in a real helicopter. And finally, in a real airplane like a small Cessna, which I have flow and have have a proper license to fly, I would always hold the yoke in my left hand with my right hand near or on the throttle. So there is no “right” way to pick which hand or finger uses which control stick, knob, or button. They all seem to feel right and completely natural to me.

Also on the original list was detecting a successful landing. This was hard. Really hard. To detect a landing, the code needed to get called when a collision is detected between one of the lander feet and the landing pad. I unfortunately call the lander feet “pads” making it a bit hard to tell what’s going on at times. I’ll need to fix that. Anyhow, instead of trying to deal with calls to OnCollisionEnter(), which seems obvious, I opted to write code for OnCollisionStay() which is called every frame and describes all of the colliding objects. The reason why OnCollisionEnter() doesn’t work is because there is no way to use OnCollisionExit() with it to keep track of collisions. What I ended up doing is naming my feet with a number and then when there is a collision in one of the child objects, like the collider objects inside of the feet, I move up the object tree and get the number for the foot. I then set a flag in an array for that foot so I can later figure out how many feet are touching. The tricky thing is that when OnCollisionExit() is called, it doesn’t seem to tell me which collision object is no longer colliding. I just clear the array and set a flag to an “I don’t know what’s touching” state to avoid incorrectly making sounds when a foot is already touching. It’s probably all wrong but it was the best I could do given no knowledge of what the collision detection functions are supposed to tell me. At least it is possible to tell with the array if all four feet are down!

I was also playing with some terrain related Unity features. I created a height map using some other programs and make sure that the terrain is flat along it’s entire edge (all four edges of a square). The terrain sits on a box of the same color making this look like the tile-in-space that I wanted. It’s nothing to brag – the terrain is boring at this point. But at least it works.

image    image

Indicators

Oh yes, and I added a HUD or GUI, whatever you want to call it, to show fuel, various speeds, angles, and other info. After the video was made is when I added a lean angle indicator. The 2D elements are super easy to work with in Unity, especially since I could create a game object to hold the entire right-side indicators and then place each individual part inside of that with relative positioning.

Writing a Unity Game

May 27th, 2017

In the last few years, I would visit the B&N bookstore and look at the game programming books. I once had aspirations to build a highly detailed railroading game with more realistic train and car movements than any retail game of that sort. I even worked out some of the logic for managing trains, cars (boxcars, not Toyotas), track, and destinations, while having clever path-finding mechanisms, etc. But my more recent inclinations have been to just get anything working in a 3D rendered world.

Image result for rectorsquid train

Image result for rectorsquid railroad

Train Game Experiments

This is where Unity comes in…

I’ve played more than a few games programmed using Unity. Most recently it was Human Fall Flat, a game that is hilarious fun for two people. I finally broke down a few days ago and installed the Unity tools.

Image result for human fall flatI was surprised that Unity is not a framework like a C++ wrapper of DirectX or a cross-platform toolkit like QT. It is actually an IDE driven construction tool where you can create a fully runnable program without writing a single line of code. At least I think so since I have not tried to build my project yet and run it as an executable. But you can defined enough of the environment and objects to have something interesting happen while only dragging-and-dropping objects into the editor and then clicking on properties to make them do basic stuff. No code is needed to make a ball roll down a hill.

image

Unity IDE

I worked through some of the Unity ‘Tanks’ game tutorial that is shown in something like 8 parts on YouTube and with the project files all available with Unity when it is installed. After tiring of it and making a mistake that I didn’t feel like fixing, I decided to try something of my own. This is where 3D Lunar Lander comes in. Read on…

Lunar Lander was a stand-up arcade game in the 1980’s that used a vector graphics display and some custom controls. The game displays a small lunar lander vehicle that is clearly falling from orbit over a rugged non-moon-like landscape. With limited fuel, the object is to land on a landing pad to score points. Do that and you get a new landscape and another chance to land on a different set of pads. All of this is shown like a side-view platform game drawn in thin lines. Eventually, there is no fuel left and the game is over.

image

Atari Lunar Lander

The first challenge in using Unity was to get something moving. I opted to put a cube into my scene and a flat surface for it to land on. This was easy and hitting the play button in the Unity IDE resulted in the cube falling onto the surface. I Added a script to the cube so I could add inputs and some values for thrust, pitch, and roll. The Thrust was easy to handle by just applying a force vector to the RigidBody part of the cube. A RigidBody make a game object respond to stuff in the game world. I think that buildings and rocks don’t need a RigidBody. Hitting the play button and then hitting the up arrow resulted in the cube rising above the surface. Voila, a game is born!

First Unity Experiment

The next challenge, that I spent hours on and is the most interesting part of all of this, is the lander controls. I wanted to pitch the lander when the A or D keys are pressed (forward and backward respectively) and roll the lander when the W and S keys are pressed. This doesn’t work like I wanted because the built-in rotation math rotates the pitch and then the roll. But after the pitch is changed, the roll axis is tilted and the roll doesn’t wok as expected. After a good nights sleep, the idea came to me to think of this differently. Think of it like trying to mimic the movement of a joystick. A joystick may have pitch and roll numbers coming out of the electronics but superficially, the stick is tilted in a direction and nothing more. The clever idea was to create a game object and stick the lander in it. When the keys are pressed, the pitch and roll values are used to come up with an angle to lean and an amount to lean in that direction. I simply rotate the game object to the desired angle and rotate the lander inside of it the opposite direction. the end result is that the roll axis is rotated to be along the direction of lean and applying just a rotation of just the one axis on the desired amount works perfectly. The lander never seems to rotate but the axis of the lean rotates.

First Unity Experiment

Of course there were other challenges to this. If the code does interpolation (LERPing) then the changes to the lean direction and lean angle can screw things up and cause jumps in the movement. If the amount of lean is changing to zero, I simply leave the direction of the lean at it’s previous value. That way, leaning to a straight up position from the leaned backwards position doesn’t cause a glitch when the new lean angle becomes zero.

The next steps in any order will be to:

Add a particle system to draw rocket flames.
Add a landing pad and detect a successful landing.
Add an explode-able version of the lander and blow it up if the lander lands off the pad or lands too hard or too leaned.
Sounds.
Terrain.
A game management system to load multiple levels and to provide a start screen and stuff of that sort.

Speaking of terrain, I have not figured out a good way to make terrain. I want to go with a low-polygon style for the terrain in case I decide to build this for mobile platforms. Right now, it’s just running on Windows. I tried to use the built-in Unity terrain system and it’s ok. The problem is that I have no idea how to add sides to a small section of terrain to make it look like a “tile.” In the image below, you can see that there are sides to the terrain (someone else’s) but that’s not that easy to achieve, so far.

image

Terrain ‘Tile’

image

Low Poly Terrain ‘Tile’

I think I’ll worry about the tile terrain thing after I get the landing pad system working. In fact, I can worry about the terrain tile thing last if I want to. But I would like to solve it so the game starts to look like I expect it to look when finished.

It will be an interesting challenge to finish the game even if it has just one level and no start screen or level selection.

Wherever this takes me, it’s been a few few nights getting the lander to fly!

Linkage 3.5 With “Servos” and Pinnable Actuators

May 6th, 2017

The new Linkage 3.5 is now available. It has connector settings to make a rotating input anchor oscillate between two angles (the first always being zero) with a settable starting position that also gets set automatically when pinning the mechanism.

image

There is also a new start position setting for linear actuator links. This also gets set automatically when the mechanism is pinned or can be set in the link properties.

image

Links to the download files are here: http://blog.rectorsquid.com/linkage-mechanism-designer-and-simulator/.

These are brand new little tested features so please report problems if you see them. I opted to release this instead of doing a beta test because no one uses the beta versions but me. Anyone interested in testing these features for me can just try them and see if anything goes wrong!

New Linkage 3.4.7 With Oscillating Inputs

April 25th, 2017

Get it here: http://blog.rectorsquid.com/download-linkage/

I just added an Oscillation Limit Angle to the connector properties. If set to something above zero, the input will oscillate back and forth to that number of degrees and back. This number is always positive so you must use the RPM value sign (positive or negative) to specify the direction of rotation, not this limit.

test (3)

Writing Software For A Living And For Fun

April 19th, 2017

Last week, I spent an evening fixing some bugs in the Linkage program. It’s a bit buggy since I added a bunch of complicated features like gears and fastening. Writing software is hard to do well but not hard to do badly. I once had to tell someone, in regards to some software having a bunch of bugs, that the software in question had more moving parts than the space shuttle and was written by one person over a few years. the effort put into the software was probably 0.00001% the effort put into building the space shuttle.

I forgot to publish the Linkage update so I’ll do that tonight. A few of the bugs were just annoyances that cropped up due to my not writing good code. For instance, I had added data to the linkage files that listed the selected connectors and links in order, instead of relying on a flag on each connector or link. But then the software processed the list front to back and ended up reversing the selections when doing an undo operation. I simply forgot at the time I wrote that code to check the order and do it right. It’s hard to do that sort of thing right when there is nothing in the code that is a reminder that the order is meaningful or that it might ever be backwards.

I did a little research last night on how I might make a simulation of a board game using HTML5. HTML5 is a shortcut for “JavaScript using HTML5 and maybe CSS3 features.” It’s the panning and pinch-to-zoom that is the hard part. I might just use SpriteKit for iOS. Speaking of iOS, when I typed “iOS” in an email using Outlook 2016 on Windows 10, the text got changed from “iOS” to “Ios” and then the stupid software automatically turned on the caps lock. WTF is with that? I should mention that a board game simulation is really just a computer game that is limited to interactions that could also be done with physical pieces on a physical table. It’s not really any sort of simulation.

The boss just asked about the time I would need to port a Windows client-server business app to iOS. I recently finished 90% of a project to port the same app to the web and the last 10% is being a bitch. The JavaScript to display the app UI was fun and the Java on the server to create the pages and deliver the data was almost fun. The feature to let users save their data and then load it up later, is not being so much fun. Mostly, it’s difficult to put a lot of effort into what seems like a badly-thought-out feature. I just can’t come up with an elegant architecture for this.

I am not prolific like some software guru types. There are people out on the internet that have published large numbers of interesting software experiments. But I still write a lot of software for fun on the side. I knew programmers that didn’t even have computers at home – it was clear that they were not really interested in programming and just worked in that capacity to have a job.

So the plan is to finish this web interface to the client-server business app, write an iOS version of the app, keep the Linkage program up-to-date, write a board game style app for iOS, keep working on the physical version of the board game (I’m designing the game itself while using the simulation as a way to test it), and do non-programming stuff like finish an almost done RBS, work on a new RBS, and play a bit of Forza Horizon 3. It’s going to be a busy spring and summer.

New RBS “Thrown Together”

April 12th, 2017

No, it’s not titled “Thrown Together,” that’s just a description of how I started it. As you can see in the video, the base is the working-platform for a previous sculpture (now sitting on a sheet of acrylic) and the motor mounts are just wood bits.

First Full Test

image

Solid State Track Switch

image

Solid State Track Switch

This machine has a solid-state track switch. It is “solid-state” because it has no moving parts. The momentum of the ball keeps it moving along the outer upper track until after the two tracks are merged into one. But when the ball travels back through the switch, it does not have the momentum to stay against the outer upper track and it follows the lower path. There is no noise because the tracks meet gradually and the ball never falls from one track to the other – it is simply on both tracks at the same time for a moment. Any clunking noise in the video is coming from the motorized lift picking up a ball and a new ball falling into place at the start of the track. it is unfortunate that the clunking sound happens at about the same time as the ball going through the switch.

After taking the video and pictures, I removed the sticker form the motor and blackened the casing. I also blackened the track. Once the sheet of clear acrylic is ready at the plastic shop, I’ll be one motor-mount and on-off switch away from being done.

Gears for Lifter #3

March 21st, 2017

image

The next lifter needs a crank that oscillates for about 200 degrees of a circle. The only way to achieve that is to use a motor crank to drive a crank on the big gear that then drives the small gear and its crank. 100 degrees of movement of the crank on the big gear is then 200 degrees of movement of the crank on the small gear.

See the video if it doesn’t make sense:

https://www.youtube.com/watch?v=RpJbGZhRH5E

Send Complex JS Data In A Web Page

March 17th, 2017

I had a dilemma; how do I send a bunch of complex JavaScript data within HTML without using AJAX. The server is running Tomcat and the HTML content is generated by some Java classes triggered by a servlet. The funny thing about this is that once I solved the problem, I realized that I had solved it once before back when I created my trip log map page. But this new problem seemed on the surface to be different so the solution evaded me for a day or two.

image

Trip Log Page

The requirement is that a web page be sent to the browser and that a bunch of processing be done to manipulate HTML form content in the browser with no further server interaction. The data consists of rules for when to show and when to hide various form fields, as well as data to populate lists in the form conditionally on the selections from other lists. Imagine a web site where you pick the make of a car (Ford, Chevy, Toyota…) and then the next list contains only models from the selected car company (Bronco, Mustang, Corvette…). How would all of the models of all of the car companies be sent to the browser so that an extra query isn’t needed for the model field each time the make selection changes?

The company that I work for uses AJAX for another “product” but this seemed impractical since generating the web page takes a lot of processing time to get and parse data from a database. Doing that parsing each time a single field changes is not at all efficient. Plus, the other “product” usually has a few large lists on a page and my forms might have a hundred.

Options

Option 1 was to use data attributes available in HTML5 and store all of the extra stuff that way. I opted against this because I would need to convert a two-level tree structure into some form of string that I could parse on the client. I hate writing code that parses or compares strings over and over again because I was schooled in writing very efficient code back when I worked on high speed search algorithms in the biotech field. In that field, writing one extra “if” test in a loop could make a product too slow to sell. This option would have made it easy to find the data content while looking at the visible tree of form fields, which would have been a nice side-effect.

Option 2 was to use the DOM by storing the data in div elements as if it were just more HTML content. The data elements would be hidden and would just be available to be read by the JavaScript when needed. This seemed like a pretty good idea because the data would be human readable during the development process. I rejected this option because I have no idea how a lot of extra hidden content would affect the page rendering. Like the first option, this option would have made it easy to find the data content while looking at the visible tree of form fields.

Option 3 was actually a bunch of failed ideas that never got past the first threshold of analysis. For instance, I could store XML data in an HTML5 data attribute or in one of those weird data elements that I have never used before. Or how about having a separate HTML select field for each variation of a list and then just displaying the one that has the appropriate data? That’s just another way to use the DOM and would add some work to hide and disable the unwanted “select” fields.

Option 4 was to generate some JavaScript code and pass it that way within a script element. It’s funny that this was not the first option since the trip log page does almost that exact thing. And now that I am writing this, I see that I didn’t do the best possible job on the trip log page because I generate, in PHP on the server, a JavaScript function that creates an array of trip information and calls functions to add data to the trip object. With this new Java project, I am just generating a global variable declaration and initializing it using literal data. I was just not as aware of how to declare and initialize a tree of complex data objects in JavaScript before now.

Above is a rough estimation of what the data will look like. This is taken from a working test case that doesn’t have a lot of content. But the idea of declaring the global variable and initializing it to literal objects, should be fairly clear. I manually added a lot of space and indentation to make it a little more readable in this example.

The final step in this development task is to write a JavaScript function that finds each of the form fields on the page and actually store a reference to the appropriate field object in this tree. Or maybe I’ll do it both ways and add a reference to the input field within this tree. That way, when a function gets called that a list selection is made, it will be easy to step through the form fields and change the field contents appropriate. It may not be obvious but the HTML form fields all have an “id” attribute that matches the “id” in this data structure. So making the cross reference won’t be hard at all.

Game Review: Unfair

March 14th, 2017

image

We backed Unfair by Good Games on Kickstarter having no idea what it would be like. But any game that shows a roller coaster on the box is my type of game!

I’ll get right to the point of this review: Unfair is a really fun game.

Now for some details and some pros and cons. The game is a card collecting game of sorts. But not like deck building games where you use some type of action to give yourself better cards in your hand. I haven’t played deck building games other than a few rounds of Dominion and it is nothing like that. But it’s not a board game either. it is a little bit like 7-Wonders and Sushi-Go in that you are trying to make sets of cards that go together in useful ways. but unlike those games, the mechanics of how you gets cards is very different.

image

Pirate Theme Cards

When we opened the box, we found that it was much bigger than needed. There is room for more sets of cards to be added later. Cards are in sets that each have a theme park “theme.” The different sets have a variety of strategy and difficulty. The sets have a bunch of different types of cards, and once the appropriate number of theme decks are picked (based on player count), cards from each deck are combined and shuffled into decks of the different card types. We discovered, hopefully correctly, that the theme decks that the cards came from means nothing during play. More on that later.

imageRobot Theme Cards

The types of cards are Park cards, Event cards, Blueprint cards, and a few others. There are lot of park cards, a lesser number of Event cards, and lesser still of the others. Each player gets the one Main gate card of the theme that they want (from one of the theme decks picked for the game). I won’t describe the entire game in this review; suffice to say that there are other things to do in the game than the few things I describe here. Players have a bit of game money to start with and anything thing that is built in the park and any employees, need to be paid for.

imageTypical Board and Player Setup

So onto the play. The starting player changes each round. There are typically 8 rounds to play. In order form the start player, each player takes an event card and saves it for a moment. Then one City card is drawn that has a global effect for the rest of this round. The City cards are just a way to throw in some random changes that affect all players. The players then in turn order play event cards until all players are done playing as many events as they want. This is an interesting part of the game because the event cards almost always have two options, one that affects the player that played it, and one that lets the player affect someone else. Simply put, there is an event card that lets you take half of someone else’s money if you want to play it that way. My family doesn’t do that sort of thing much.

Play continues with three or four sets of Park card plays. This part of the game is where you buy or build stuff in your park, or hire staff. All of the things you can build, including new attractions or upgrades, as well as staff you can hire, are in the form of Park cards. During these Park steps, you can also get new Event cards as well as Blueprint cards. Blueprint cards describe plans for your park that if you meet them, you get a bonus. Failing results is some points lost, so it’s not always wise to pick a really difficult Blueprint card.

imageNice Step Tracking Marker

After the three or four steps of dealing with park stuff, players essentially count guests in their part and add up bonuses to get more money. there are then some cleanup steps, like all players discarding cards if they have too many, and then the starting player changes and the next round is played.

My family has thoroughly enjoyed the game. Although we don’t play events that hurt other players (too often), the game doesn’t feel like group solitaire at all. The amusement park theme of the game fits with our like of amusement parks and the game is well designed and plays well enough that we stopped looking up instructions after the first one or two games. As a contrast, we still sometimes get out the instruction book for Firefly: The Game.

But there has to be something wrong with the game, right? Well, there are very few unclear instructions. In the setup, one step mentioned placing some City cards into a temporary pile. temporary? What does that even mean? it means that you are making a City card deck/pile and that you need to just start that deck/pile with some red city cards. There is a single other cards added into that deck/pile and then four blue City cards are placed on top of that. The word “temporary” didn’t make any sense because that deck or pile of cards isn’t temporary, it gets used in the game. Or maybe I just read it wrong.

What else is wrong? The instructions didn’t make it clear that the tiny theme icon in the lower right corner of each card is only there for you to sort the cards back into theme decks when the game is done. They don’t means anything during game play (although each player does get to pick which theme they use for their Main gate card, Loan card, and cheat-sheet card). It is only the large icons in the upper left of each card that have any meaning related to theme during the game (and other stuff depending on the icon).

Oh, and the different theme decks are not all cut on the same card cutting machine so some of the decks didn’t shuffle together easily.

Those are really moot points since we figured out that stuff during the first game and we were sure about all that by the end of the second. And there are many ways to shuffle a deck if needed.

imageTypical Employee Earning You Extra Income

The game is very pretty, well designed, and has a very usable board in relation to the space you need for laying out the cards that you play. The instructions are awesome compared to some games that I have. Play is competitive and very well paced. Siskel and Ebert would give it two thumbs up. If it were a hotel, it would be a five star hotel.

I must say, the Kickstarter page has a very good overview of the game and a link to a video. Ignore anything I said about game play and just check it out there:

https://www.kickstarter.com/projects/1960349413/unfair

Lifter #3, Maybe?

March 3rd, 2017

Here’s a picture of a lifter ideas I threw together. The cool part is that the ball is lifted almost straight up – this is a straight line approximation mechanism – without a typical elevator or chain lift.

image

The line where the ball goes up is drawn for analysis bit when done, there will be no vertical supports in that spot. The ball will be lifted straight up along that path.

I am also going to build a lot more track around this lift. The lift is interesting but I’ve spent too much time on mechanisms lately. I want to build some track so I can design in a solid state reversing mechanism.

It’s funny how the picture looks like a bicycle design. Those circles, just like the vertical line the ball lift follows, are just drawings in the simulation and won’t be in the final work.