I've been doing a few non-virtual projects lately when I've had some free time. I've been building/programming a quadcopter and experimenting with 3d printing, and I really like the new (to me at least!) open hardware movement.
For designing parts and models, I'm using the easy-to-use CAD web app Tinkercad. It's not especially feature-rich at the moment but I really like the design desicions they've made and I belive they have a great base to build upon.
I recently wanted to print an adapter for a microphone but could not find any good libraries for threaded screws. So I took the plunge and spent an evening coding one myself, using the wikipedia page on ISO metric screw threads as reference.
I made a small web experiment using Dart to see how suitable the language is for game/graphics/physics programming.
The demo is an example of point-masses and stick-constraints using the verlet integration; Thomas Jakobsen's excellent article "Advanced Character Physics" introduced me to the concept and got me interested in physics programming several years ago.
- get rid of the underscore prefix and introduce a proper "private" keyword
- optimize the VM for vector algebra and immutable types if you don't want to introduce "value types"
- integrate WebGL
Here are a couple of things I believe are bugs that I encountered while making the demo:
- Assigning a variable through a get method actually compiles, for example: instance.getMethod = 5
- Some expressions are not considered constant and won't compile if used in a static statement, for example: static final var strings = ["hello", "world"] - See the comments
When developing games for Android devices using Unity 3.4, Unity seems to default to a 16bit backbuffer format and there is no easy way for developers to use a 32bit format. Most 16bit formats do not include alpha channels and the low bit depth may cause color banding issues. Here is a short guide (based on this post) on how to create a plugin that enables a 32bit RGBA backbuffer on devices that support it. Note that the file paths are not exact, just indicators, and that everything is case sensitive!
- Create a temporary working folder
- Inside the working folder, create folders in series to match your package name in the Unity Android build settings. The tree should look like this: /workingfolder/com/companyname/productname/
- Copy the UnityPlayerActivity.java file located in /Unity/.../PlaybackEngines/AndroidPlayer/src/com/unity3d/player/ to /workingfolder/com/companyname/productname/
- Rename the copy in the working folder to MyUnityPlayerActivity.java
- Open MyUnityPlayerActivity.java
- Change the class name to "MyUnityPlayerActivity"
- Remove the line starting with "package" if present and add the following lines at the top of the file:
- package com.companyname.productname;
- import com.unity3d.player.*;
- In the onCreate() method, change the "boolean trueColor8888 = false;" line to "boolean trueColor8888 = true;"
- Compile the MyUnityPlayerActivity.java file using the javac command line tool and the following options:
- Use the Unity classes as classpath: "-classpath /.../Unity/.../PlaybackEngines/AndroidPlayer/bin/classes.jar"
- Use the Android SDK as bootclasspath: "-bootclasspath /.../Android SDK/platforms/android-11/android.jar"
- Package the new MyUnityPlayerActivity.class using the jar command line tool: "jar cf classes.jar com/companyname/productname/MyUnityPlayerActivity.class"
- Copy and paste the new classes.jar file to /Plugins/Android/ in your Unity project
- Also add this AndroidManifest.xml file to /Plugins/Android/ and modify it to fit your build settings
- Build & Run your Unity project
If you follow this guide in order to use the Shadow Volumes Toolkit on Android devices, remember that Unity does not force the backbuffer format and it may revert to a 16bit format on lower-end devices, causing shadow artifacts.
The beta version of Unity 3.5 adds the option to force a 32bit backbuffer in the build settings, making this guide obsolete!
I've been following GAMESTORM for a while and I really like seeing the concept sketches people make, it's a great idea for a website! Here is my contribution, some concept sketches I made while working on Seaside Racing.
For the past few weeks I've been working on a few small projects. After working on Seaside Racing for a period of almost 2 years, with no side projects, it's fun to finally be able to experiment with new ideas! (I decided early on to not start side projects so that I could finally finish a larger project, and it worked, although while being difficult.)
The screenshots above are from two projects that made it into a playable state. The first one is a "defend yourself from an increasing number of enemies" game. The rocket is controlled like in an asteroids game but I couldn't come up with gameplay that was interesting enough. I do love the art style I managed to achieve though, and I will try to use it in a future project if I can't innovate the current game somehow.
The second screenshot is from a quite unusual game, basically you play as something that behaves like a wing (a red cube at the moment) and propel yourself forward by grappling onto balloons scattered across the sky. It is fun to play but I have not yet created a goal or a scoring system.
One thing I've learned while making these prototypes is that it is fun to make random creative things, but it is important to do what you really like to do. The games above was made as infinite highscore-based games because I wanted to keep the development time down, but the problem with this approach is that I realized that I usually don't like infinite highscore-based games! I also had the iOS and Android platforms in mind while creating the games, which I think restricted my ideas. So, from now on, I will try to make exactly what I want to make and not let any other factors (monetizability, development time) affect my decisions. If the development time gets long it is always possible (I hope) to work on several projects at once.