0x10c becomes a community-developed game

0x10c

It’s official. [Notch], creator of Minecraft, has confirmed he’s shelved plans for 0x10c, the space-based block building and exploration MMO that features assembly programming as a core game component.

Over the last year or so since 0x10c was announced, a whole lot of programmers have picked up the in-game fictional CPU – the DCPU – by writing emulators and even emulating this CPU that only exists as a design document on an AVR. Needless to say, there are a lot of very skilled programmers that want this game to exist. Now, it seems, this community is forging ahead with this project without [Notch].

This is a truly massive undertaking by the community. Not only are the current plans to build an open world, procedurally generated, space-based MMO, it looks like these new developers will also be writing their own engine from scratch. If this were a commercial endeavour, it would require millions of dollars and many years to get to a rough alpha build, and the 0x10c community is doing this for free.

If you have experience in C++, OpenGL, and 3D game programming, the official signup thread is over on the 0x10c subreddit. Even if you’re not a programmer and only have experience in modeling, writing, your experience would be greatly appreciated.

Retrotechtacular: Bell Labs introduces a thing called ‘UNIX’

dennis

Modern operating systems may seem baroque in their complexity, but nearly every one of them  – except for Windows, natch – are based on the idea of simplicity and modularity. This is the lesson that UNIX taught us, explained perfectly in a little film from Bell Labs in 1982 starring giants of computation, [Dennis Ritchie], [Ken Thompson], [Brian Kernighan], and others.

At the time this film was made, UNIX had been around for about 10 years. In that time, it had moved far from an OS cloistered in giant mainframes attached to teletypes to slightly smaller minicomputers wired up to video terminals. Yes, smallish computers like the Apple II and the VIC-20 were around by this time, but they were toys compared to the hulking racks inside Bell Labs.

The film explains the core concept of UNIX by demonstrating modularity with a great example by [Brian Kernighan]. He took a short passage from a paper he wrote and found spelling errors by piping his paper though different commands from the shell. First the words in the paper were separated line by line, made lowercase, and sorted alphabetically. All the unique words were extracted from this list, and compared to a dictionary. A spell checker in one line of code, brought to you by the power of UNIX.

Retrotechtacular: How I wrote Pitfall for the Atari 2600

how-I-programmed-pitfall

This week we’re taking another departure from the ordinarily campy videos featured in the Retrotechtacular section. This time around the video is only two years old, but the subject matter is from the early 1980’s. [David Crane], designer of Pitfall for the Atari 2600 gave a talk at the 2011 Game Developer’s Conference. His 38-minute presentation rounds up to a full hour with the Q&A afterwards. It’s a bit dry to start, but he hits his stride about half way through and it’s chock-full of juicy morsels about the way things used to be.

[David] wrote the game for Activision, a company that was started after game designers left Atari having been told they were no more important  than assembly line workers that assembled the actual cartridges. We wonder if any heads rolled at Atari once Pitfall had spent 64-weeks as the number one worldwide selling game?

This was a developer’s panel so you can bet the video below digs deep into coding challenges. Frame buffer? No way! The 2600 could only pump out 160 pixels at once; a single TV scan line. The programs were hopelessly synced with the TV refresh rate, and were even limited on how many things could be drawn within a single scan line. For us the most interesting part is near the end when [David] describes how the set of game screens are nothing more than a pseudo-random number generator with a carefully chosen seed. But then again, the recollection of hand optimizating the code to fit a 6k game on a 4k ROM is equally compelling.

If you like this you should take a look at an effort to fix coding glitches in Atari games.

[Read more...]

The meaning of being a hard-core hacker from a 1985 recollection

6502-hand-assembling-and-programming

Gather ’round children, we’re about to hear a story about the good old days. Except that this is really more of a horror story of what it used to be like as a code monkey. [John Graham-Cumming] shares his experience programming a 6502-based KIM-1 machine back in 1985. Simple, right? The caveat being that there was no assembler or hardware for loading the finished code!

The machine in question was a label application tool for a production line. You know, product goes in bottle, label gets slapped on the side. But the slapping needed to be perfect because consumers shy away from packaging that looks shoddy. Computer control would end up being far superior than the mechanical means the factory had been using because it simplifies the ability to adjust calibration and other parameters. [John] started from square one by interfacing the KIM-1 with the existing hardware. It has a hex keyboard which is how the program was entered into the device. But first he wrote the software on sheets of notebook paper like the one seen above. It includes his hand assembled code, which was then typed in on the keypad. Kind of makes you appreciate all the tools you take for granted (like Eclipse), huh?

[via Reddit]

 

Interpreting Brainf*#k on an AVR

brainfuck

We won’t call it useless, but we will ask why [Dan] wrote a brainfuck interpreter for the AVR

It’s not generating code for the AVR; think of it more as a bootloader. To run a brainfuck program, [Dan] uploads it to the EEPROM inside his ATMega32, after which the microcontroller takes over and starts performing whatever instruction the brainfuck program tells it to do. Because the whole thing runs off the EEPROM, the code size is limited to 1022 bytes. Enough for any brainfuck program written by a human, we think.

As for why [Dan] would want an AVR to build an interpreter for a language that is nearly unreadable by humans, we honestly have no idea other than the common, ‘because it’s there’ sentiment. There are some pretty cool projects out there that use brainfuck, including this genetic algorithm software developer. Right now, though, blinkey LEDs are enough to keep us happy, so you can see a video of brainfuck doing its thing on a LED bar display after the break.

[Read more...]

Custom 3D printed designs with Makerbot’s Customizer

custom

Although having a 3D printer means you can create custom object of your own design, that doesn’t change the fact that most object printed on Makerbots and RepRaps are copies, or slight derivations, of already existing object. If you need a gear, just go grab an OpenSCAD file for a gear, and a custom smart phone case can be easily made by modifying an already existing one. The problem with this approach, though, is you’ll need to learn OpenSCAD or another 3D design tool. Enter the Makerbot Customizer, a web app that allows you to create custom versions of other people’s work right in your browser.

The idea behind Customizer is simple: someone creates an OpenSCAD file with a few variables like the number of teeth on a gear or the number of turns on a screw. Customizer takes this OpenSCAD file, puts sliders and radio buttons on a web page, and allows you to create custom objects based on user-created templates.

Already we’ve seen a lot of Hackaday readers send in some pretty cool customizable things, like [Bryan]‘s coil form for DIY inductors and [Greg]‘s customizable PVC pipe couplers. If you already know OpenSCAD, it’s easy to create your own objects that are customizable by anyone on the Internet.

Programming in 3D with 3DPL

cubes

Here’s an interesting tool for making simple 3D games. It’s called 3DPL, the 3D programming language, and it’s a real-time interpreted language that allows you to create cubes and other primitives that respond to user input and internal logic. Not only that, but you can build 3D versions of breakout and asteroids very simply with only a few lines of code.

3DPL is based on Unity with a lot of JavaScript influences. Building a cube in 3DPL is as simple as declaring it with a name and position in 3D space. There are a few functions that can be applied to these cubes – they can be made to rotate at the press of a key, or translated in space to collide with each other.

It’s still a very early build, but looks to be pretty interesting for an ‘introduction to 3D graphics programming’ perspective. You can grab a copy of 3DPL to try out over on [amigojapan]‘s github. Hopefully we’ll see a gravity method soon for a proper 3DPL Tetris implementation.

Follow

Get every new post delivered to your Inbox.

Join 92,115 other followers