The Third Kind is an unsettling text based point and click experience that takes you on a short and surreal adventure that feels like a near-death nightmare.
Playing like a cross between a point and click adventure and a text based visual novel, you simply read the descriptions and choose one of the three options from the interface below. The Third Kind manages to create a truly nightmarish atmosphere through it’s simple CRT-style UI, full of flicker and distortion effects.
There’s a dark and ominous feeling throughout The Third Kind’s short 10 minute playtime, and you’re never too sure what’s real and what’s not. A creepy, freaky, fever-dream experienced though a half broken CRT monitor.
Hey, great blog! What will you be doing during your internship at nasa??
Thanks!! :D I’m working on something known as Core Flight Software. I’ll give two explanations for this:
I’m working with low level systems libraries and using already existing NASA system libraries for Linux (CentOS 6.x and Debian 6 or 7 or 8) flight computers. I personally prefer Debian. I build small applets with these libraries. These will need to communicate over various LANs (WAN? maybe not on a spacecraft. I’ll have to ask my mentor tomorrow) on spacecraft such as Orion and the Space Station. What I do is utilize and write in C and run batch processes to simulate communication between the flight computer and the on board mechanics. I then pump this information to a graphics display so that the Astronauts can manipulate and monitor the spacecraft. That’s another beast I haven’t tackled yet.
Also I should mention that I’m part of a big team. I am mostly focused on Audio transmissions.
This is open source so anyone out there who is familiar with Linux, C, Bash, JAVA, and some Python can check it out here (At least these are the ones I have running right now):
I’m basically a coding machine. All day today I sat in front of a computer terminal and stared at green text overlaid on a black background. I like it though! - My hardware engineering friend was really freaked out by this. I have to program this way because I need to build very low level computer systems for space craft. NASA doesn’t like to use unnecessary tools when sending stuff into space. Too many extra programs would take up valuble space on the ship’s computers, so we keep it minimal. I program in C and use the Linux operating system (links in case you want to learn more). My programs can be used on space craft such as the Orion or the Space Station. However, the software I use is versatile enough to be used on almost any spacecraft and that’s what is so awesome about it.
Missing Translation is a fantastic puzzle adventure with beautiful black and white pixel art animation, a secret language and an intriguing world with over 100 logic based puzzles.
Even though Missing Translation has only just been fully released, it’s already won and been nominated for multiple awards, and within the first few minutes of play you can see why. The fantastic art style, audio and world design make the strange world of Missing Translation a joy to explore. The beautifully crafted game world is completely open, so you can wander around solving puzzles in whatever order you like and collect the pieces of a mysterious machine.
All the puzzles are intuitive and logic based, starting off simply, but getting fiendishly tough as they go on. There’s even a Fez-esque secret language to decipher to further test your grey matter. It’s not just the puzzles that make Missing Translation such a great gaming experience though – it’s the whole package. You can’t help but feel you’re playing something special as you explore and solve this perfect pixel art puzzle adventure.
A hand animated action adventure game being developed for PC, Mac, Linux, and Wii U (and possible more). I’m so in love with the art, and I’m definitely a little biased with this post as I backed the game on Kickstarter last year.
“As the enigmatic Hollow Knight, players will journey through the depths of Hallownest, a vast and ancient kingdom buried deep underground. Though long fallen to ruin after a dimly-remembered catastrophe, explorers and thieves still brave its dark roads, its caverns and towers, searching for riches and wonders.
“Lately though, something has changed. Villagers and explorers venturing into the caverns have stopped returning. The caverns throb and tremble with a savage energy. A sweet and sickly poison is drifting through the hollows, sending creatures mad with rage and robbing explorers of their memories.”
Survive is a tough little wilderness survival game, played out entirely on a single options menu.
You must survive and travel as far as possible through the wild terrain, battling freezing cold conditions and hunger. Gameplay is fairly straight-forward, with you building camps, gathering firewood, fishing, lighting fires and resting - all while trying to move as far from your original location as possible.
It’s a very tricky balancing act, with no room for error. Spend too long fishing when you should be gathering firewood and you’ll be a human popsicle in no time!
Check out IndieGameStand’s new release, AdvertCity!
AdvertCity is a cyberpunk advertising tycoon game. Explore a massive procedural city, and plaster your adverts all over it. Float around cyberspace and post links online. Watch the economy of the city evolve with the effects of your decisions.
Massive procedurally generated cities in a procedural landscape. Switch between meatspace and cyberspace at will to get a different perspective. Manage an advertising empire, posting ads online and using physical advertising. Choose your clients and adverts wisely, as you have a reputation to uphold. Influence the economy and growth of the city with your advertising choices. Buy buildings and upgrade your headquarters to expand your influence. Hire employees and unlock new advertising technologies. Take over megacorporations and make the city yours! Simultaneous synchronised soundtracks, an hour-long original music score featuring postrock, jazz and glitch elements. Roguelike single-save system. Beautiful graphics but runs great on older computers - it will even run on that old notebook where nothing else will! Download for Windows, Linux or OS X.
Porting the Unity Editor to Linux: Stuff I Wish We’d Done Then
At Unite Europe this year, we at Unity released our public roadmap. And while it’s super cool to be able to share all of the amazing stuff we’re doing at Unity, one thing that is close to my heart is the Linux Editor.
The story behind Linux port of the Unity Editor is a lot like the story behind Linux runtime support, which was released in Unity 4.0. It’s basically a “Labor of Love”; some of us at Unity have been working off and on to port (and maintain the port) of the Unity Editor to Linux for quite some time (it’s pretty much the poster child of Unity’s internal developer hackweeks), and I must say, it’s coming along quite nicely. Our plan is to ship an experimental build Soon ™ to let you try it out.
Porting the editor to Linux is a lot of work – much more work than porting our runtime. This is because the editor is where the majority of our actual tech lies (including most of our complex 3rd-party integrations) and because of the asset database, it’s the place where case sensitivity problems really show up. Our editor consists of:
A lot of C++ code, much, but certainly not all, of which is shared by the runtime; this is of course compiled natively.
A lot of C# code, which runs on top of Mono.
Various 3rd-party libraries and middleware, all of which must be compiled for Linux.
Now that we are this far along, let’s look back on a few big things Na’Tosha “wishes we’d done then”…
1. Cared About Case Sensitivity
Unity does not properly run on a case-sensitive file system (which is something that Unity users have discovered if they’ve tried to install and run Unity on a case-sensitive HFS+ file system). This is primarily due to Unity’s asset database, and how it stores paths to map them to GUID values. Of course we tried to be smart in the early days, but if you don’t set up a way to actually verify that what you’re doing works on a case-sensitive file system, then it will never fail that some well-intentioned programmer throws a toLower() in somewhere and ruins the party.
This is definitely something I wish we’d cared about in the past because fixing it after-the-fact is difficult and tedious.
2. Didn’t #if WINDOWS #else OSX
A non-trivial amount of our early work porting the Editor to Linux involved dealing with stuff like:
#if UNITY_WIN // Some Windows-specific codepath #else // Some Mac-specific codepath #endif
Conclusion: If you want to write portable code, always do something sane (read: future-proof) in the #else case.
3. Just Didn’t Assume
The above-two points are the big ones. A few other, smaller, things include:
Assumptions about compilers. An example is our bug reporter in Unity 5, which is in many ways separate from the main editor and is written using some C++11 features. The C++11 standard is, ahem, vague in some places and different compilers choose to interpret the standard, well, differently. This makes porting something using C++11 to a 3rd compiler a pain. Lots of compilation errors that involve this-c++-template-thingy-with-lots-of-angle-brackets does not match that-c++-template-thingy-with-lots-of-angle-brackets-that-has-a-const-somewhere-in-the-middle.
Assumptions about native applications. This includes what sort of stuff goes in the application menus automatically (on Windows, for example, you get some stuff added to the application menu for free (Copy/Paste/etc)). We had to go through and add this stuff in for Linux, because GTK applications don’t get these for free. To be fair, most of this stuff doesn’t come ‘for free’ on OS X, either, but the way it was implemented falls into the #if WINDOWS #else OSX trap I wrote about above.
Assumptions about how file dialogs work. Other platforms have callback systems, for example, so the parent application can tell the dialog if something should or should not be select-able. The default GTK widgets don’t work this way.
Assumptions in general. Conclusion: assumptions really are the root of all evil. :-)
All that being said, the project has definitely been a lot of fun, hindsight is always 20/20, and these are actually the kind of problems I’d expect anywhere when porting a codebase the size and complexity of Unity to a new platform.
Just for fun, I’ll also mention that throughout the porting process, we’ve gone back to the drawing board on a couple of things:
The first pass used raw X11 for windowing/event handling because we were trying to avoid a dependency on either GTK or QT.
Because of (1) the early menu system was actually a menu system written in Unity GUI. I still think this would be pretty cool if we did it someday.
In Unity 5.1, CEF was embedded as the embedded browser system, and this had a dependency on GTK, so we switched to GTK for window/event handling and for the menu system.
But other than this, we haven’t really had to do any re-work.
So what how is the Editor going to work? Here’s what we know:
Only 64-bit Linux will be supported
Same policy as with our runtime; in order to keep our own sanity, we will officially support Ubuntu Linux. Other distributions are on their own, but it will probably work other places.
We’ll most likely support back to Ubuntu version 12.04 (it’s what we’re building on in our build farm currently)
Features reliant on 3rd party stuff (e.g, Global Illumination) should work
Installer will (most likely – it’s one of the things we didn’t do yet) just be a .deb package.
Some of the model importers that rely on external applications (i.e, 3ds Max and SketchUp) won’t work. The workaround is to export to FBX instead.
Anyway, that’s it for now.
Here’s a teaser:
Our Networking demo 2d Shooter being exported to Linux from inside the Linux Editor.
Unity Labs running in the Linux editor. It’s running here on a Retina MacBook Pro, which is why the fonts are small.
Are you excited about the Unity Editor on Linux? What are you going to use it for? What platforms do you want to export to from Linux? Tweet me at @natosha_bard and tell me what you’ll do with it!
Daniel, Cody, Avi, and I (Cassidy) just left San Francisco and the GNOME West Coast Summit. It kicked off Monday morning at 9 AM at Endless, makers of the recently Kickstarted Endless computer.
XDG-App and OSTree
Monday, we were given a demo of XDG-App, a way of sandboxing apps and providing known runtimes to app developers. Dan Nicholson, a developer at Endless, set aside time to sit down with Cody to explain the benefits of OSTree, a filesystem versioning control system that XDG-App uses. XDG-App and OSTree are both things we’re looking forward to when they are ready.
elementary OS doesn’t fully support HiDPI displays right now, but it’s going to get better soon. Daniel worked with GTK+ developer Alexander Larsson (and a HiDPI display) to investigate how to get our icons working perfectly with @2x pixel-doubling. We’re testing an update to the icon set that should make icons draw beautifully crisp and resolution-independent, exactly how GTK+ itself is drawn. We also discovered several bugs in the way we’re using icons across elementary apps and have filed the appropriate bugs. Fixes should be coming soon!
Tuesday, Avi, Cody, Dan, and I had a session with several GNOME developers and Mutter developer Jasper St. Pierre regarding building shells on Mutter. As you may know, our window manager/compositor Gala is built on LibMutter, the shared back end that powers GNOME Shell. Jasper wanted to get us together to collaborate on features in Mutter itself that make all of our lives easier and prevent duplicated effort. We had a very productive session and now our Gala developers are working more closely with Jasper. He is also investigating several items we brought up with fullscreen and shadow rendering, plus he is rewriting tiling window support to allow for more specific and powerful shell-specific user experiences. We look forward to working more closely with Mutter to help make elementary OS, GNOME, and other desktop shells better.
Daniel and I worked with GTK+ developers Matthias Clasen and Cosimo Cecchi to discuss improvements to GTK+. We decided to add a height property to GTK Switches which should give GTK+ stylesheet designers more control over how switches appear. Specifically for elementary OS this means we can move away from using images for switch styling and fully use CSS. We also discussed improvements to entry placeholder text: it will be able to be styled by the GTK+ stylesheet, giving us not only the ability to show the placeholder text when the entry is focused (but empty), but also the ability to use any CSS styling such as font families/styles, color, and animations.
We spent a lot of time with Christian Hergert, the developer behind GNOME Builder. He demonstrated Builder and its awesome progress. It’s already an extremely impressive IDE for GTK+ development and we are very interested in making it available for elementary OS. We also discussed the current state of build systems, including cmake (which we use for elementary OS) and automake. Our takeaway: the current state is somewhat of a mess, but each have their benefits. Builder will support automake out of the box and Christian isn’t opposed to accepting cmake support if someone proposes the code.
First of all, a huge thank you goes out to Sriram Ramkrishna and Endless Mobile. Sri, a GNOME Board Member and community organizer, helped get everyone together in one venue—Endless Mobile’s San Francisco office—to collaborate on several elements of the stack. Endless provided an awesome meeting and hacking space and was extremely welcoming.
We were able to attend GNOME West Coast Summit because of the support we’ve been getting from our users, fans, and Patrons. Several times we had breakthroughs that would have made the entire trip worth it on their own: building relationships with GNOME, GTK+, and Mutter developers; making strides with HiDPI; hammering out the UX of potential tiling window features; wrapping our heads around XDG-App and runtimes; etc. If you want to help us continue attending summits and meetups like West Coast, you can always get involved with funding elementary.
GNOME and GTK+ are important projects for elementary OS and we want to see them continue to mature and improve. Please also consider Donating to GNOME. Funding is necessary for good infrastructure, new hardware, and getting designers and developers to meetups like West Coast Summit.
Lastly, working with GNOME has been an incredibly valuable experience. Increased collaboration between the two projects will help improve each individually and the greater open source ecosystem as a whole.
Blitz Breaker is a simple, tough and very addictive little twitch puzzle platformer in which you can only jump and air dash, charging ever forward until you collide with an obstacle.
Each level in Blitz Breaker is lined with deadly hazards. It’s up to you to figure out the best route, and time your movements perfectly in order to reach the portal at the end. The hazard-filled levels do initially look like a daunting prospect, but once you figure out your routes and get to grips with your little robot’s controls it’s a little less deadly (though you’ll still die a lot!)
A fun, fast paced and fiendishly tough twitch platformer, with that all important ’one more go’ factor.
Butcher is a fast-paced and brutal 2D pixel art shooter harkening back to the classic contra-style shooters of the early 90’s, that gives you one objective - kill everything that moves.
You play a cyborg who’s sole purpose is to eradicate all organic life on the planet, using any means necessary. This generally entails lots of blood-splattering combat as you blast your way through hordes of puny humans, with some satisfyingly OTT weaponry.
The prototype features three levels and eight different types of powerful weaponry to blow away enemies with. It’s a fun, and delightfully gory game, that coats everything with the bloodstains of your fallen foe. You may manage to eradicate all life from the planet, but the clean-up bill afterwards is going to be huge!
Zugegeben, ich bin nicht der Schreiberling vor dem Herrn. Trotzdem ist dies quasi der Nebenblog zu wearetheco.de. Ich bin seit jeher von Computern begeistert, da sie uns als Werkzeuge in vielerlei Hinsicht dienen können. Wir können sie benutzen, nicht sie uns. Leider ist dies in der heutigen Zeit nicht unbedingt selbstverständlich, denn … Moment ich hab grad eine WhatsApp … bekommen … äh … wir lassen uns, ja also eigentlich lassen wir uns ja nicht benutzen. Also, die anderen ja, aber ich doch nicht. Ich bin souveräner Nutzer. Sklave.
Meine Generation hat von einer Uhr geträumt, mit der man sein Auto herzitieren kann, weil Michael Knight das ja auch hatte. Wahrscheinlich sind wir heute davon nicht allzuweit entfernt. Auf jeden Fall haben wir kleine Computer in der Hosentasche, mit denen nahezu alles möglich ist. Aber das setze ich jetzt mal als bekannt voraus. Viel spannender finde ich da, Dinge® selber zu bauen, von programmieren rede ich jetzt mal nicht.
Der Raspberry Pi ist eine ganze Zeit lang an mir vorbei gegangen, unerklärlicher Weise. Meine Linux Kenntnisse hielten sich bis dato auch auf einem überschaubaren Level. Ein A6 Notizzettel hätte vollkommen ausgereicht um „Meine“ Linux Enzyklopädie niederzuschreiben. Naja … 1999 habe ich mal in einem 24h Marathon ein Erfolgserlebnis gehabt, da gelang es mir die grafische Oberfläche von SuSE Linux kurz auf dem Monitor zu sehen, sehr kurz. Dann hatte ich erstmal genug davon, aber losgelassen hat mich der kleine Pinguin nie so richtig.
Endlich hab ich also wieder etwas zum spielen, und zum basteln, und zum Geld ausgeben, und zum verzweifeln, und zum Jubeln, und zum … Nervt´s?
Wie auch immer … Ich werde der Welt ab jetzt meine Projekte und Fortschritte mitteilen, notfalls auch mitten in der N8.