2013 In the Studio Lab

December 31, 2013 · Posted in personal, projects, travel, work · Comment 

This year saw a lot of change for us.

Work

Starting in April, I took on a full time gig over at Hewlett Packard, working on their HP Flow CM solution. We released a few iOS and Android apps for clients (more info on this later) and have started on a few more. I’ve invested in some small things with hopefully large ROI. And finally, I finished my first semester teaching over at Boise State University teaching mobile application development on the Android platform. Next semester will be taught using iOS, which I’m looking forward to.

Ana has continued her Water Engineering job with much success, working on plants all over Boise and the surrounding cities and Twin Falls.

As an engineering family, we got a lot done, a lot of projects completed and were rewarded for all that effort by being able to crush the final student loan debt I’ve been putting off paying, and investing in new opportunities.

Travel

This year we finished up a month-long trip to Florida and Colombia. We also made it to New Jersey, New York City, Yellowstone and the Grand Tetons. We’ve put hundreds of miles of hiking and walking under our belt, but not as many rock climbing routes as we would have liked. However, we put up a bouldering cave in our garage to help.

Projects

The bouldering cave that we built in our garage turned out better than we could have imagined. We still need to buy some more holds to set up different routes, but it’s been a blast setting up routes for ourselves and friends’ kids that visit.

We also bought a house that was only two years old, but we’ve still a lot of time into making it home.

I’ve done a lot of work on my bike with the help of my friend Nick who runs a motorcycle parts company, near Boise. I helped him put the site together and he’s helped keep my bike maintained.

2014

Overall, teaching has been the best opportunity. While it paid a little bit in money, it paid a ton in satisfaction of knowing I’ve made a difference in the lives of the 28 students that I had for Fall Semester of 2013; some more so than others of course. I look forward to improving the teaching of mobile apps to students and can’t wait to see their apps popping up on the app store.

The rock climbing gym should allow us to stay better trained to continue climbing the 5.10b’s that we’re able to climb at places like Smith Rock and City of Rocks.

Now that Matyas is a bit older, we can hopefully travel more, like we use to before he was born, although traveling with him to South America when he was 1 month wasn’t a bad trip.

Rock Climbing Wall – Building a Climbing Wall in the Garage

October 28, 2013 · Posted in personal, projects, rock climbing · Comment 

My wife and I have been climbing for a few years and spending quite a bit of money for our monthly climbing gym membership. While we would usually go about 3-5 times a week, it was always a chore to get there in the first place.

In the past, I spent a few hundred dollars on some weights and since then, have never felt the need to sign up for a gym membership. Whenever I felt like it, I’d pick up some weights and do some reps. I’d do this fairly often and through out the day. So it started making sense to take that same idea and apply it to rock climbing. So we built a rock climbing wall, also known as a bouldering cave, in our garage.

Planning the Bouldering Cave

 

Measuring and planning out the bouldering cave

We have a 3 car garage but only one car, and we don’t have a lot of junk being stored in it. So when we first moved into our new house, here in Boise, our garage was feeling quite empty. The third car port didn’t have a garage door opener on it, nor did it feel like a car should go in there. The area itself just seemed perfect for a bouldering cave due to it’s U-shaped walls.

We did some research on cave designs and knew we wanted a 45 degree wall. Vertical walls are almost useless and a waste of effort. One problem was, we had a window on the left wall that we didn’t want to cover up. This would allow natural light to come in while we’re climbing and not have to burn electricity while we’re out there during the day. It would also allow cooling and ventilation in the summer so we just had to keep it open. It turned out to be a bit of a problem as a 45 degree wall would come right out and cover part of it up. We spent almost an entire day planing it out, thinking about pros and cons about different wall designs. We decided to make a 30 degree wall next to the window and a 45 next to it against the other wall.

We then decided to extend out and wrap around the dividing wall for some extra climbing surface. These walls are flat as we didn’t want them to jut out and take up more space, but they can serve as walls for kids or extra distance for traverse warmups.

Tools

We borrowed a lot of the tools from friends since there was a ton that we ended up needing.

  • Circular saw (a table saw is better to cut the longer plywood)
  • Chop saw – perfect for cutting angled 2x4s
  • Plug in hammer drill – the hammering feature helped drive in screws to concrete.
  • Power Drill – the ease of portability, the downfall of recharging batteries a lot
  • Hammer – for hammering in the T-nuts
  • Measuring tape – measure twice, cut once. Also great for planning and visualizing angles and how much material you’ll need
  • Clamps – When you only have two hands, holding up plywood and other pieces of wood becomes a lot easier once you clamp them in place before screwing it together
  • Drill bits – for various pilot holes, but also a special one for the t-nuts.
  • Belt sander – sometimes you’re a few millimeters off and instead of recutting, you can just sand off that extra length. We always cut a tad long, sanded it down and made everything fit with high precision.

Hammering in the t-nuts

Materials

We made a ton of trips to the hardware store. This was mostly because we ended up wrapping our wall out and around the dividing wall that was there so we needed more materials than we first expected. We also were generous on the use of screws since everything needed to be tight and snug. Any movement of the wall as we pulled and climbed on it, would be a jarring experience as rock shouldn’t ever move.

  • 5/8 inch plywood – We calculated the area, then added a few more for waste and extra features
  • 2x4s for the main structure
  • 2x6s for various structural componets such as tying into the ceiling and wall
  • Concrete screws
  • Wood screws of various lengths (2″ – 3 3/4″)
  • Liquid nails – to glue the wood to the concrete after screwing it in
  • Wood glue – ended up using vary little of this, but definitely needed it in a few places
  • 800 t-nuts – we put t-nuts every 6-8 inches apart in the plywood

Structure

We built a frame for the wall in front of the actual wall to allow us to get back inside to fix fallen t-nuts and inspect the structure in coming years. This took some space away for climbing as it made the inner area smaller, but it’s well worth it and necessary.

View from inside the wall, looking at the 45 degree wall

View from inside the wall, looking at the 45 degree wall

Once we were done with the framing, we could build out the angles. Using clamps to secure some 2x4s at a 45 degree angle, we prototyped what the wall would look like. We sat under it to get a good feeling for what it would be like to climb at that angle and height, and moved the 2x4s up and down, adjusted the angle by a few degrees both ways and got it to “feel” right. Once it felt right to us, we screwed in the 2x4s and took off the clamps. We did this for the 30 degree wall as well to get it to work with the window. We had a little less choice with that, since a wall that was too steep would come out and cover the wall, so we brought it out as steep as we could to hit the top corner of the window.

With the main structure in place, we finished up the framing of the angled walls.

Structure of the 45 degree wall

Structure of the 45 degree wall

Facade

Once the frame was done, we started measuring and cutting the plywood for the wall’s face. We tried to keep waste to a minimum while cutting and planned out the cutting of the 4’x8′ sheets. We actually made the frame 8′ deep and 8′ wide to best fit the plywood. You can’t reliably climb on a wall that doesn’t properly span studs. It’s just not sturdy enough, so each piece needs to span multiple studs.

Once the plywood was measured and cut, we had to plan out where the holes were going to go, keeping in mind any adjacent walls. We ended up putting holes about 8 inches apart, starting 4 inches in. This allows us to avoid any studs on the edges, while keeping holes 8 inches apart spanning sheets of plywood. On the vertical, we had to keep in mind the widths of the holds and also try not to put them too close to the top or bottom to make them unusable. We marked out the studs on the plywood so we wouldn’t drill into them. If our holes came close, we’d nudge the marks left or right to avoid them.

The planning for the holes took a long time but once we marked them out, it was quite quick to drill the holes out and hammer in the t-nuts. We placed some scrap plywood behind the board we were drilling so the back wouldn’t splinter and blow out.

Skinning the frame

Skinning the frame

Texturing the climbing wall

Having something in your house, especially something you built yourself, should a source of pride and beauty. We knew we didn’t want to leave a plywood colored structure in our garage. Besides, the splinters alone are a pain. Also, using climbing shoes on a flat wooden surface doesn’t simulate anything except climbing on plywood. Instead of just painting it (which would have solved the splintering issue) we decided to research some texturing. We found some recipes for mixing sand with paint and joint compound but that seemed like a hassle. We happened across some deck restore that will take old wood and apply a concrete-like layer on it for a hardened surface you could walk on. You can even color it too. We bought a small amount to test it out and it worked beautifully. It’s very thick and heavy so we had to apply it in thin layers but the end result is like climbing on rough granite. Smearing is awesome.

Texturing the wall

Texturing the wall

Crash Pad

Like most garage floors, our is made out of concrete: one of the hardest materials known to a human’s skull. Not wanting to use concrete as a cushion we commissioned  Baboon Climbing to build us a crash pad that could fit in the space we had. What they came up with was a folding mat that we could break apart in the middle and use the smaller pieces around the gym. They did a great job and while it’s definitely softer than concrete, falling from our 10 foot tall bouldering cave is almost enjoyable, knowing they’ll be a soft but firm landing at the end.

The finished climbing wall in our garage

The finished climbing wall in our garage

Climbing on our Wall

We’ve had a bunch of fun on our wall since finishing it, but I think the most fun is had by the kids that come over and climb on it. We left some flat walls for them and we plan on adding large features to the others to make them more interesting. As you can see, we have two flat walls facing each other that’ll let us add features, but there’s also two other flat walls that wrap around the original dividing wall that can be used.

Finished wall showing the wrap around section

Finished wall showing the wrap around section

Starting your own project or have questions about ours? Let me know in the comments below!

Game Dev Part 3: Starting the Game Framework

February 23, 2013 · Posted in game development · 2 Comments 

In our last post on creating the game architecture for our high level classes, we discussed a number of design decisions about our game. While the details will be important, almost all games have the same basic structure, so I thought we’d get started on creating that in parallel with our creative process.

Usually, I build out the skeletal structure as I’m doing the creative process details. As a reminder, here is our structure:

 

Game Class Diagram

Main.lua in Corona SDK

In Lua, everything starts in your main.lua file. Most people will probably put a lot of logic and variables in this. We use the main.lua file strictly to launch our application and leave the rest of the logic up to the Game Controller, which we’ll create a file for called GameController.lua.

 

main-lua

This is all we have in the main.lua file. It simply declares a function, and then adds an event listener that gets system messages for when the application starts, exits, suspends and resumes. For each of these states, we either save or load the data. For example, if we were in the middle of a battle and our game gets sent to the background, we’ll need to save the current state of the application to a file so that we can resume in the same place, even if the app quits completely. These might be things like current health, time, which enemies are still active, etc. When the application resumes again, we reload this data and we’ll check it later in the code to see what our state was, so we can handle the loading of that screen, just as if we never left.

If the application starts up, and there is no data, that means it is the first time we’ve launched our application. We call a special function in GameController.lua called firstLaunch() to handle this. You could put this logic in the GameController’s main function to make main.lua even simpler if you wanted but by testing for nil, we can handle it differently if your game had different needs.

First Launch

This first launch function might include a quick tutorial overlay to introduce the player to our game. Always after that, we save the data so the next time the app starts, data will be loaded in and firstLaunch() won’t be called. First launch may do other things like setting up and writing settings files, but we’ll want to separate out the logic for overlays and other things into other functions so that we can reuse them later, if the user wishes to go back through the beginning tutorial. In other words, if the user wants to revisit the tutorial via a menu item, we don’t want to run through all the first launch logic like creating settings files, user names, etc. We’ll simply want to call something like showTutorial() in order to bring that feature up. It’s important we separate out these steps for later use in the app. You never know what you’ll end up reusing or accessing from another execution path.

System Events

Finally, we print out the event.type variable if it is not nil, in case you’re interested in handling additional system events that Corona sends your way. In our case, I’ve simply commented out the print statement but keeping the handling of system events in one place is a good idea. In our case, we’re forwarding the handlers to our GameController since that’s acting as our master controller.

Game Stats

You may have also noticed we made a call to getGameStats() to serialize and deserialize our data. This returns the Game Stats controller that holds all the information about our game including character stats, level stats, scores, and everything else we want to keep. This will talk to our storage controller to read the file information and then put it into a format. We’ll also have a level loader, so we can load things such as those one at a time from storage.

Game Dev Part 2: Beginning Architecture

February 13, 2013 · Posted in game development, projects · Comment 

Now that we have the basic game play of our mobile game, as we discussed in part one of our game development series, we can begin to architect the game. We’ll start at a very high level and work our way down to the details. The way we do that is take the biggest chunks of the game and separate them out into their own classes that will perform specific tasks.

Overview

As we mentioned in our last installment, our game will be a turn-based combat system. I first thought about having the main character’s home be a sort of base to defend, in a tower defense-like sub-game with additional element such as exploring the surrounding area, along with our combat system. While some great ideas came out on paper, I could see it quickly got out of hand to begin to program that. However, I continued to create the “ultimate” game and didn’t let myself be too worried about the programming. After I had exhausted ideas and creativity (sometimes that happens pretty quickly), I pared down the offerings and got rid of the tower defense idea (maybe in the sequel) and the other fluff. If we had the budget and the manpower, we might accomplish that, but given the budget and the time constraint, we’ll make this simple and hopefully still fun. The exploring a map part came back to a game like The Adventures of Link or Final Fantasy, where the character walks around a 2D map encountering enemies. I’m ok with that and drawing inspiration from games that work is what started this whole thing. Our game won’t win any awards for originality but that’s ok too.

High Level View of Our Game Classes

So we have two main parts to our game: a part where the player explores the city and the combat system. As the foundation to our game, we have the following base on which to build our game:

Game Class Diagram

Game Class Diagram

 

  1. A Game Controller, the main controller of it all. This class will controller the main aspects of the game such as starting the game, which screens to present, and handling other organizational tasks. This is a singleton class that we can access from any other class to interface with it’s public methods. This is different from a global class in a number of ways. We’ll go into this in more detail later.
  2. A Storage Controller will control loading and storing various aspects of the game. We’ll tell the Storage Controller to get us things and we’ll tell it to save things. We don’t really care how the Storage controller does these things, just that it does and does them well. Likely, it’ll be to a custom file that we write that’s stored on the mobile device’s memory but it could just as easily be to a database, a network or external storage. By abstracting this system, we can plug it into our future games.
  3. The Display Controller will handle things like displaying items to the screen and removing them. We can build in some utility functions like fading in and out views. We’ll go through the Display Controller whenever we want to display our items. That way, everything that has to be displayed will be in one place. If your familiar with Corona SDK, under the hood, this controller will manage our Display Groups, animations and other display properties and organize them into screens.
  4. The Combat Controller will handle our combat scenarios. This has to be stand alone so that during testing, we can simply pass in a bunch of inputs and begin our battle. The way this will work is, we’ll launch the app, and instead of going through the usual paths, we’ll construct the data (enemies, player stats, level, etc) and then pass that all into the combat controller, straight to the fight. Then we can test the combat system and tweaking inputs without having to go looking for a fight every time.
  5. The City Controller will allow us to place our player in a city to explore. Again, this will need to be stand alone so that we can use different inputs to put our player into different scenarios. We can also manually change the files that the Storage Controller uses to advance the player through the game without having to play through it every time.

Of course, we won’t build everything into these controllers as they would become huge and unmaintainable, let alone buggy, but those details will be built out later. This is a good start and will allow us to start work on the individual pieces.

Our player will be either be in combat or exploring the map. Other interactions, like scavenging (this is a post-apocalyptic game after all), interacting with items and people or reading some part of the storyline are all secondary screens that will be shown on top of the combat or map. Menus and other things will work in a similar manner. These are sometimes referred to as modal windows since they will go on top our main display and capture all the interactions. These modal windows will likely have their own controllers or be grouped into controllers that make sense. These will all be organized by the Display Controller, so we’ll always know what’s on the screen and we don’t have to figure out if some lonely class somewhere deep in our game, is displaying something we don’t know about.

As we’re still in the planning stage, we’ll hold off on starting the code just yet until we build out some more diagrams. However, we won’t build out a diagram for every single class we need as things will likely change and will be better changed in code. Think of this as outlining a school report. These are just the main things we want to talk about and we’ll include some of the sub-items, but we don’t include every detail. Soon, when we start the coding, we can look back and see the general blueprints of how we build everything out.

Business Prosperity: Helping other small businesses

February 12, 2013 · Posted in indie, projects · Comment 

The mobile app development business here in Idaho is good. So good in fact that my student loans are disappearing, I’m investing more and more with Franklin Templeton (Roth IRA, 529 Savings, growth stock mutual funds) making about 9% on my best investment (after the sales charge), and having the new baby makes the world an even better place.

So after paying the bills, and paying down huge chunks of debt, I decided to give a little back and support projects that people are trying to do themselves. One way I thought of was to fund a Kickstarter or an Indiegogo project. These are donations to projects people are trying to create and they usually give some kind of gift based on the donation amount, often times sending you their product or service if you donate enough money.

These are ok, but they’re not really an investment and I really wanted to invest in a project. So I decided to try Kiva.org and lend $200 with the idea that, that money will be used to fund small businesses and individuals around the world to give them working capital for their ventures. I decided to invest in Colombia since that’s the foreign country I know the best, it has a hard working lower class, and has a great potential to make a difference. While Kiva doesn’t give me a return on the investment, and the people borrowing the money are borrowing it at the rates that most people in the US pay on their credit cards, it does have an impact on these people’s lives. The borrowers usually provide updates on their progress throughout the lending period and you can follow along with their story. It’s a great way to find out what life and small business is like in countries you’ve never heard the name of.

With Kiva, the principal is paid back to me over time, which I can reinvest, or withdrawal. There’s about a 1-2% of default and other fees, so over time, that money will dwindle down, but until then, you can reinvest and help other people, all along hearing their stories of success.

Should we be teaching these people that borrowing is a terrible idea? Probably, but if we call it investing, it’s ok, right? Well, I figured $200 was a good number to figure out what this micro lending thing was all about.  I’m still skeptical, but even if I eventually lose all that money (hopefully not for several years), it can be recirculated many times to continue to help fund different people’s small business ambitions.

If you’d like to start your own Kiva investments, sign up here and Kiva will donate $25 to fund a project. Minimum is $25, so it’s easy to begin. I’ll let you know how mine works out and what my thoughts are on the whole process.

If you know any other great ways to invest in small businesses and help get it started, let me know in the comments below!

 

 

 

Next Page »