I’m working in a team for the 2015 NASA Space Apps Challenge and this year, like last year, we’ve run into a billion and a half problems working with Unity3d and git with more than one person. After some searching I found an awesome website that included a gitignore file that seems to do the trick. I’m not trying to rip them off, but I’m incuding the gitignore file here for my own future sanity (and just in case their site goes down).
I understand the need for a warning when loading an app for the first time off of the Oculus Share store, etc. but as a developer it’s insanely annoying to have to go through this thing every single time you run your game. So, if you’re working on an Oculus Rift app and you want to get rid of it while you work on it, here’s how to do it in Windows.
1. Create a text file called “oculus3d.reg” with these contents and run it.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Oculus VR, LLC\LibOVR]
2. Open the Oculus VR Config Tool and click on the “Advanced” button underneath the player height field.
3. Check the box confirming you don’t want to see the warning any more.
4. Develop your game faster by being able to save 10 seconds every time you test your game.
When showing someone your start-up/product/service, it’s easy to let them guide your thinking unconsciously. It feels like there’s an inverse proportion of weight given to feedback to sample size, especially if it’s the first time taking the cover off.
Here’s a really great example of why one should always take every bit of advice as advice and not gospel:
I know it seems I’m like 15 hours late to the party, but really I’m not. I’ve been trying to come up with a good idea for my game this Ludum Dare. In the mean-time I’ve been playing other people’s games and chit chatting/lurking on their IRC channel.
Now that I’ve finally got my idea, I’m ready to get down to work.
I’m taking a few hours tonight to go through the archives and put up some of my finished/unreleased/unfinished game jam projects onto github. Ludum Dare 26 is next weekend and I want to have a simple URL to send people to to try out my stuff.
I took a bit of time recently to take apart two of my Atari Jaguar joypads. The rubber/plastic screwhole covers, over time, had disintegrated and melted into a gooey, sticky mess on the backs and front of the joypads. It was gross.
If you’ve got old videogame equipment (10+ years) and you’ve noticed the rubber/plastic screwhole covers on the backs of the units or controllers getting soft, I recommend taking them off and avoiding the cleanup you’ll be facing in the next couple years. Otherwise, you’ll have to do what I did and use Goo Gone. The good news is that Goo Gone is amazing and it’s fairly cheap.
I’ve been planning out my first game. I’m going to call it Barf. Simply, it will change your view in whacky, unexpected ways whenever you move the headset (and sometimes even if you don’t). Online leaderboards (probably powered by Google App Engine or something of the like [is that thing free still?]) keep track of who has gone the longest before ralphing.
Unity 4 was released three days ago, on the 12th of November. I installed it as soon as I saw that it was available. Unfortunately, it overwrites any previous version of Unity you have installed, so I lost my install of Unity 3. To make matters worse, I could not find any download link on the Unity3d website.
Thankfully, the official @unity3d twitter account pointed me toward the installer for Unity3D 3.5. Here it is.
Here’s an image.
Now onto actually designing the level and making the game.
Guelph Game Jam #4 just started. I’ll be liveblogging here, tracking our progress on our Rogue-like. It’s Michael Hoyle and Me, along with a touch of art asset assistance from Amy.
The theme of this game jam is Growth.
We’re still trying to figure out how that will be implemented in our idea for a Rogue-like, but our first few ideas are pretty promising.
If we’re going to do this, we’ve got to be ruthless and pull the plug after those two hours and switch to the game. If we let it slip and say “we’ll do one extra hour on the engine” we’ve lost.
My go-to IDE for everything for the past 5 years has been Netbeans, so to switch to Eclipse is something new for me. But, Eclipse is insanely popular, so there’s got to be a good reason for it.
Google seems to love it, too, and it’s always great to be in tune with them. I used to develop stuff for the Google App Engine and it was the same thing as it is with Android this go-around: if you didn’t use Eclipse, it was a bugger to get going. Relying on a third-party plugin from Kenai to access a closed system was just too much of a reach-around and I got out of there.
So, Eclipse. Excited.
Why Android? Well, this recent hullabaloo about Ouya has got me excited. I’ve been toying with game development now for years and after completing a few games in the past few Ludum Dare/7dfps/Guelph Game Jams, I can safely say that the idea of getting my games up on the TV screen with a controller turns my crank.
Playing games on a PC/laptop is just not the same as on a console. Don’t get me wrong, I’ve got hundreds of PC games and love them dearly. But, there’s something special about a controller in your hands and a big TV screen in front.
I’m looking now through the Youtubes and Googles for Android development stories, tips, tricks, hints, tutorials, cautions, etc. If you’ve got experience in this area and would like to share your story, I’d love to read it.
Syrup Dispensers From Hell is coming along quite well. I’ve decided to use the Legend of Sadness base for the game, which plays and looks a lot like a Legend of Zelda title. Instead of having our hero travel into a cave, he’ll be travelling into a breakfast restaurant to save us all from horrid syrup dispensers.
This time around I’ve got a lot more experience working with Akihabara so I’ve been able to work harder on gameplay and graphics rather than learning how the game engine works. Designing tilemaps for a game, as a programmer, is tough work. It’s not that I dislike working on art or even that I’m not artistic, but what looks great in The Gimp looks like shit when it’s tiled a hundred times.
Doing graphics for a game is basically incrementalism combined with healthy doses of iteration. You tweak a pixel, test it in-game, hate it, go back, tweak another pixel, hate it, go back, and so on.
A neat feature that I discovered today was Akihabara’s ability to scale the size of the game display by a value that is less than 1, meaning that it does not need to zoom to an integer value. Currently I’ve got the game displaying at 320×240 with a zoom of 2.5, making that actual output 800×600.
The second Guelph Game Jam has just started at the ThreeFortyNine co-workspace. The goal? To make a game in less than a day. We have about 8 hours to design, build, and test our games. Then the last bit of time is spent playing everyone else’s game.
I did this a few months ago and thoroughly enjoyed it.
The theme this time is ‘Monsters.’ The game designer can take that in any way, whether it be about monsters, being a monster, defeating monsters, etc.
As was the case last time, I’ll be live-blogging my progress here and on my BitBuilder game developer Twitter account.
As of this posting it’s a very early version with still much of the stock artwork and enemy types. But, it’s fun and playable. Go Akihabara!
The story goes that you’re a BastardBlaster, conscripted to battle everything in the world that’s annoying. Flat tires, Blue Screens of Death, when you go to eat pizza and there’s none left… the list goes on and on. If it’s annoying, you shoot it.
I’ve got the anime-ish characters (Terry and Skylar) in, but since I’m a programmer and I’d like to spare you my attempt at drawing artwork, I’ve asked Margaret Gissing to help out with the 2D sprite pieces.