 We begin our next session with Axel Thielman. Axel Thielman is a manufacturer based out of Hamburg and is a part of the hacker fulfilled team which develops computer games and today he is going to be talking about hacker fulfilled which is a game that was developed during before the 33 C3 and he would be talking about the updates and the new features that the game has. Can we have a round of applause for the speaker? Thank you very much. Hi, I'm Axel, I'm from hacker fulfilled, we're a small indie game label from Hamburg and over the last half year we built a mobile game console or started building one and we'd like to show you. We are a bunch of retro developers, three people are involved in the team, there is Rick who unfortunately couldn't come today but he does the main development environment coding, there is Christoph who is sitting in the back who does all the graphics and design aspects and who also created this great presentation so you don't have to suffer through latex slides built by me. And yeah, I'm Axel and I do mostly the hardware development and low level coding. We've done a couple of releases, mostly retro games, you can see them on our website, they are all available for download, some of them you can even play online and this is puzzle cave for example and I think that's fuffle by on the right. Yeah, we all grew up in the 80s with 80s hardware, some of us with home computers, some of us with game consoles and we always loved these systems and of course mobile games were around at that time but they weren't really that great, they were kind of clunky, really bad battery life, they were very expensive, you couldn't get many games and sometimes if you wanted one you actually had to order one from Japan so I never really had a mobile game system, this might also be because there was no mobile C64 but yeah. But yeah, well fast forward 30 years later, so much has changed, like electronics has changed a lot, so much interesting stuff coming with the internet of things and small electronics now. The maker scene has evolved and suddenly you have access to really professional manufacturing for DIY products or projects and of course maker spaces have happened and suddenly you can just go to your friendly neighborhood maker space and use a laser cut or a 3D printer, so these days you can do projects that were completely impractical and really expensive just 10 years ago. And also retro gaming is really booming, there's lots of DIY projects out there, all kinds of things, people building their own systems, there's a bunch of crowdfunding campaigns out there who really get really big funding and even all the old big companies like Nintendo and Sega and Atari are coming back and re-releasing some of the old systems and they're really well received for the Nintendo systems they usually sold out before they're even on the market. Yeah well at the end of last year we sat at the attractor maker space and well we kind of just started talking about all these systems coming out and what we liked about them and well many martyrs later, long story short, we decided hey let's build our own, let's build the mobile game console that we always wanted and never had. And we kept talking and kept talking and yeah another few hours later we had all these design sketches, some are more serious than others. I really like the multiplayer ones and that's also, that's one of my favorites where you connect your game console to your mobile phone over an audio cable and can maybe just download games from the audio track of a YouTube video like you did with audio tapes back in the 80s. Yeah so we had a lot of crazy ideas and we're pretty hooked on the thing but what did we want to build? Yeah we wanted to build a mobile game system but on really modern hardware just really see where what we loved about these systems where this could be in well 2017. We wanted to add lots of sensors that maybe have never been tried on a game system, I really love sensors, I'm a hardware guy so this is kind of my thing and we wanted to build it as completely open hardware and open source so building a system like that in mass production is really quite complex or difficult so what we went with what we wanted to make a spasible design basically saying if you have the PCB and you have a little bit of soldering experience you can just go to your maker space and the design will be done in a way that you can just use a laser cutter or a 3D printer and after a weekend or so you have your own system. But this would also enable people to remix the system if you have access to all the design files all the stack down all the all the developers everybody who has access to that can also build the console they always wanted or maybe maybe just change some little thing that always bug them about it but most of all hello most of all we wanted a true retro system I've been saying this word quite a lot what does it actually mean for for us retro was a lot more than just like games with big pixels and flashy colors and sometimes there's even a flash game behind it so now this this is not what we wanted and also retro games usually focus on on the player on the on the experience the player had and on typical game mechanics and a certain aesthetics but in the 80s owning a computer was also being a developer coding for this this was right in the manual the c64 manual starts and really immediately tells you how to do low level programming and there was a whole development side to to retro gaming that that we were interested in and that we wanted to keep alive because the the old hardware system slowly but steadily die they or they just get put in a museum where you can't code on them and all the old developers where they don't don't really die but they move on to other things and so there's there's a whole developer community and yeah that we that we wanted to to help build forward and and yeah see where this is going so what's retro for coders for us it was the simple simple interfaces simple graphics functionality that you can get into easily small dev teams like in the 80s when when computer games were usually done by one to maybe three person and we wanted to have a have a manageable no manageable project size so not like today when you have tens or hundreds of people working on a big game so what we were aiming at was kind of a one developer one weekend kind of thing if you if you had an idea for a game that you could start and finish finish within time and one of the really important things for us and in retro was was restricting complexity and back in the 80s all these systems were really really restricted but that's that was not a conscious design decision as least needs not for for the game it was a restriction because of financial reasons or practical reasons this was consumer electronics usually aimed at kids and you had to be able to buy the whole thing for maybe a few hundred dollars so these these systems were really really restricted but yeah purely for for financial reasons but this also this this kind of restriction became sort of the the identity of these these old systems and it also led to a sort of recognizable aesthetics for for each of those platforms for me for some of the platforms you can see a screenshot and you don't know what game is it but you can tell from the from the screenshot which platform this is simply because that's the that's the graphics engine of this in this system to give you a bit more of a sharp metaphor for us like we felt retro gaming was like going camping because for for camping you just get your stuff started point a go out into nature and enjoy that and you accept that the temporary discomfort of sleeping in a sleeping bag and a and a tent but you really like you're out enjoying this and it's not really about getting to point B and the the gear you did that you take tent stove backpack when this was invented this was also not invented for fun it was invented so people had shelter and food and like could gave get from A to B and and these days camping is a lot it's a lot nicer a lot more technology in this we have self-pitching tents all kinds of high-tech materials and before you know it you're on a on a camp with with thousands of strangers and and power and ethernet in your tent so the the experience has been cleaned up a little bit and this is this is sort of what we wanted to do with with retro development we wanted to keep the core alive but slowly try to clean it up and try to remove the things that were just annoying for example weird hardware behavior that was just there because the graphics chip needed some data like it was on the on the c64 we also wanted easier interfaces and offer a bunch of modules that especially newcomers could use at that would sort of enable to use a certain development technique rather than having to develop everything your own and we removed assembler so of course all these old systems they used assembler coding and you had to learn that and removing this is a bit of a contradiction but we felt yeah that maybe this this would put the learning curve a little bit too high and what we also wanted we wanted this system to be inviting to play around with and this meant choosing the right level of complexity and we wanted to do this on hardware for software and for graphics for graphics this means low resolution fewer colors because even even for a pro designer if you have to pixel something that's that's thousands of pixel per side that's quite a lot of work and this this can put you off especially for a for a hobby project or you'll just never finish it and toss it aside and yeah so you would never get your game finished for the software it meant having a modular s but also restricting the the number of modules the number of interfaces and make the the system a little bit easier to learn so and and also for for the for the whole design we wanted it to be not so uniform and polished and like perfect because this might intimidate people who are really just just learning about this wanted a little bit to be a little bit rough so yeah people can just take it and do whatever they want with it so we wanted to have a good number of parts on all these levels and and once you have that something interesting happens if you restrict the complexity the newcomers will will find it easier to to start with the system and the the people who are more advanced will really see this as a challenge how can I what can I do with this how with this within this restriction within these rules this is kind of like like board games like chess these games have been around for literally thousands of years and people are still discovering new things and as these these these board games really become a place of competition or yeah just just comparing what you can do with this and for the c64 for example now it's almost 40 years since it's been out and people are still discovering new things and really still improving graphics so this is what you get for the pros if you restrict complexity yeah but onto a few more specific goals that we want to have we didn't want it don't to clone edit like directly clone anything no emulators no big os below us just the game os on on hardware we wanted complete to completely do new hardware and software co-developed in iteration so we could figure out what would work and and what didn't wanted a small low resolution screen and we couldn't really agree on on the type of system or the error of the system that we wanted to to base this upon and again this was a good thing because now it's a bit of this and a bit of that and it's yeah it it has to be recombinable so we settled on on a tft of about three inches to a 40 by 160 resolution 16 fixed colors meaning you could guess just these 16 colors you can't change them in any way plus one color which is transparency we want a true 60 Hertz screen refresh rate so nice smooth scrolling nothing jerky like it was on the again on the c64 for controls we settled for the usual d-pad and and buttons a combination for now well this is tried and true and people intuitively know what how to use it and for graphics functionality the starting set was two modules one was the was a tile engine with eight by eight pixels and the other one was a sprite engine with a 32 by 32 pixels yeah so a tile engine this this is probably one of the most iconic graphics techniques that came out of these old systems and it's it's really quite simple you start with with a what's called a tile sheet which is just a bunch of small rectangular graphics like here and then you sort of stamp them together to form a larger graphics and if you do it in in this top-down manner you get this really this this sort of checkerboard structure and yeah a lot of similarity and you get a get a very recognizable aesthetics on the other hand if you do it bottom up which as far as I know was done for Maniac Manson and they started with full drawn pictures and then had a had a program figure out what the optimal tile set would be and just calculated that and put put that on the into the game and there you can see that this is this is really mainly an efficiency technique because it saves a lot of time copying stuff between places and RAM which you don't really have on a on a low power system it saves RAM and it saves floppy a game like Maniac Manson would not have fit on the on the floppy sides that it was if this this were really bitmaps it's back the other one is sprites and for sprites that's even more just just an optimization technique the the graphics chip will allow you to program small rectangular pieces of graphics and you can just program a register where you want that sprite to be and it will take a care of handling the transparency because it's not rectangular blend it with the with the with the background and once you move it remove it from there and put it somewhere else and a sprite engine would usually also handle collision with other sprites or with a background so you know when well you might be hit by a projectile or touching a monster or something and again you can all do all all this in software there's really no reason other than performance to do it in hardware okay so building hardware what it's what what's the basic structure most of these old systems have a sort of not very remarkable CPU usually usually these were selected for price and the hard the identity of systems like that was really in the in the graphics chip and if you really build a game console what all these companies did was they developed a specialized ic and then attached it over to an exposed system bus to the to the cpu and so the cpu could just write or had the had the interface to the graphics chip in main memory and it was easy from a program to just you write to him a specific memory location and stuff would happen for the graphics engine yeah this this of course only will work if you already know that that you will sell a few millions of units so this was kind of ruled out for us there's another way to use reconfigurable hardware like FPGAs where you can really build your own graphics chip but this would have made the hardware really expensive to because FPGAs are quite expensive and also they are sort of hard to develop for and it takes a long time and we wanted to iterate quickly to to try out concepts so what is left is basically doing everything in software which is a bit boring or go look for a microcontroller that has modern graphics functionality and see if we can use this yeah and this was about half a year ago at the ccc congress in hamburg and yeah we we just just wanted to start building so we selected this something that would roughly fit we wanted a very very fast microcontroller so we had enough compute power to do whatever we wanted to try out we wanted to want to support for good low-level graphics and a tft interface and this is what we went for and that's a board with an stm32f7 which is one of the fastest microcontrollers that stmakes and they sell these in these very nice they're called nuclear boards they are really well engineered have lots of lots of interfaces and they're really really cheap the the cheapest ones are about 10 euros the biggest ones are about 30 euros and yeah these are nice to develop with because if you put them to the side you almost have the the form factor like you would need for a for a mobile game system and has a has a connector here so we thought yeah well for the first prototype let's just put another pcb on top of it with controls in a screen and we're good to go and the microcontroller on it is is very powerful it has it's it's around 200 megahertz half a megabyte of ram two megabytes of flash and it has a lot of interesting peripherals looking at the at the documentation so we wanted to try these out and the first peripheral is called dma2d and dma2d is really just dedicated circuitry to copy bits like rectangular bits of of graphics between parts and memory and you can do this either like in the top line just just copy graphics data from someplace to someplace else or you can do it with with online conversion and if you do it like this the the source memory really is just an index into a color lookup table and the the dma2d circuitry will automatically convert this into the actual graphics data and it can also handle transparency and and format conversion and all kinds of stuff and it's really fast we did a did a speed check like at the camp a few days ago and it turned out we could do like 240 000 copies per second so yeah that's very powerful we thought okay we'll probably good with this let's just use this and um yeah well the the rectangular screen parts i think this was mainly meant for having windowing systems so the your rectangles would be windows or icons moving around but hey we just wanted rectangles we wanted a tile engine this is a perfect match and it's it will also give us the the palette indexing in hardware for free so this was a really good fit and the second peripheral that's really nice was the LTDC which means LCD TFT display controller and it's it's really just a just a regular graphics controller to to attach a tft but it's integrated into the micro controller and this means that the timing is synchronous meaning the display controller runs synchronous to the main cpu and the cpu can know exactly how many cycles have passed um what the display controller is doing and like um it was with the Atari 2600 the the proverbial racing the beam you get something like this um directly um if it's directly integrated so we had this this nice timing timing integration and this would allow you to use a bunch of techniques um that uh that the old systems had for example um updating the picture when you know um it's currently not anywhere uh where the where the graphics controller is drawing or you can can get an interrupt um at a certain line and switch graphics modes while the screen is drawing and having a different graphics mode uh for the playing field then for example for the menus so yeah this was this was also a great fit um the the interface is something called a raw interface which means you have to continuously pump out data if you stop for for uh yeah anytime that the screen will go white immediately um so things like uh screens like that are really just practical if you have an integrated uh display controller and you have 24 data lines which is just um rgb um 8 bit color um synchronization two lines for horizontal and vertical uh and a clock and this runner at around uh 10 megahertz ah okay so um yeah next thing we needed was a screen and like I said to use the LTDC we needed uh this raw interface not something um with an integrated display controller and it turns out um buying screens or sourcing screens is really kind of a pain in the ass um first of all people are pretty spoiled by mobile phones they expect really nice screens high dpi's very nice colors um and for most non-trivial products um screens are are are custom made so you cannot buy them there is a there's a lot of uh generic screens out there but they are not very nice and they're usually um uh targeted towards a very specific product and all the small screens they were made for um initially for small mobile phones for very low power mobile phones and since mobile phones um are very low power and uh don't have a display controller all these small screens had a display controller integrated but didn't offer the raw interface so this kind of um um yeah this we couldn't use the the really small screen so we had to compromise a bit um but in the end we found something for for the um just yeah we bought something that just was available and reasonably well documented meaning in English and not Chinese um and we could just work with it and yeah then then see yeah so we started prototyping at the at the congress in in Hamburg and it was really just about uh testing the LCD interface um this is the setup we had at the congress so it's really just a bunch of cables um attached to the screen um and uh yeah it took us almost three days until we had the whole whole software setup running but in the end uh we had the graphics engine was running and we're pretty happy about this so um we started building the the OS structure and and overall well at the end of the congress we knew okay this hardware plot frame was going to work we can do build a prototype based on this and um this is what the what the first prototype looks like at least half of it um because like i said it's a it's a shield that goes onto one of those nucleobots and combined it looks like this it has a nice height and um yeah it's it's really it already feels like like a mobile system um yeah the the PCB itself um if i turn it around this is the user facing side the the screen is currently missing but you have your your d-pad on the left um buttons on the right and uh here this this is this is actually not that much interesting circuitry it's mainly power it's a charging controller for the battery so the whole system would already be um completely mobile um the battery also powers the nucleobot below um we have uh yeah it generates three voltages for the for the tft controller and the backlight and the system itself um but what we already added was a was a cartridge slot uh this is a repurposed um uh sd card slot with a lot of pins but we really wanted cartridges because the old systems had cartridges um we added a second screen connector so we thought oh maybe it would be awesome to have a screen that only your opponents see when you when you play against them um and uh well yeah and a bit of debug circuitry so the um yeah we had the we had the prototype after three months or so it was working nicely and uh at the same time we were building um the the os or starting to to set up the overall structure um and uh since we figured okay there's probably gonna be more than one prototype uh let's have a head for hardware obstruction layer at the um as low as possible so the the actual operating system sits on top of that and we can can compile this for different hardware um but it also turned out that once you have that and you have the abstraction you can put the game os uh entire inside your development environment and um and maybe have an emulator or something like that for the for the game interface we initially started with c um a sort of restricted um cleaned up version of c um meaning no ellipsey and you would only have access to the functions that we would that um the game os explicitly um um gave you and um at least the the the the os wouldn't make you use uh dynamic memory or pointer arithmetic or things like that so um the the the functions were designed in a way that it's easier to to start with the development environment but once we had that we thought okay maybe we just want to put a lua uh scripting engine on top of this where you have the the same functions um and you can choose either to go with uh c or with lua you would have the the same programming model the same functions um but lua also um offers a few nice data types um again to get you coding more quickly so we had hardware we had software and we needed something to look at and the first thing of course is um is a palette of colors because like i said we had 16 fixed colors and um yeah i'm a hardware guy so um well uh these are the colors um made by by christoph and i hope i can can reproduce this correctly um the um the colors well they they are they start with the with the unique colors um for example for for grass and for trees and for people walking around so it would be nice for for making jump and run games but also uh since it's restricted you want the colors to be easily mixable and blendable and easily um to to arrange them in a way that you can go from from light to dark and um you can see the darker it gets the bluer it gets um and so the whole palette is kind of geared towards this this yeah the the the blending effects that you use um when when pixeling data or when you're in pixeling images what we put on top of this on this uh of the 16 um slot palette is a 256 um slot palette called a permutation palette and this also can only um index uh these 16 colors so what you would have necessarily have doubles but what this allows you is to change um the the index during a game and uh do all kind of palette effects like palette rolling um um phasing parts of the image in and out and this was a also a technique that was extensively done in the 80s and 90s um there's awesome videos on on youtube uh where people demonstrate what they could do with a single static image and just modifying modifying the palette after we have that we needed game assets game assets being everything that the developer wants to put in the game apart from code graphics sound and until we had uh our proper tool um well basically we just defined um uh a graphics format which was based on c code so we could immediately feed this to the compiler um and we just took two existing tools this is um a tool called graphics uh graphics two um which is based on deluxe paint uh um famous uh pixling tool no graphics tool hey um and we just yeah they're both open source um and we just took that added our save game so now we already had a had a tool um to to create um tile sheets and just render them out and put them put them in the source tree and uh to make maps this is a tool called tiled and this one is so flexible we didn't even have to change it we could directly um just just load the load the tile maps into it um just create the maps save it out it has a few generic sys uh generic formats and basically you just have to put curly braces at the beginning at the end and you can immediately feed it to compiler but yeah these were just a just a quick hack to to get us going what we really wanted was a was an integrated development environment and um yeah this is the um the screenshot of an early version of the hacker tool um and uh sort of this is sort of the command central for for all the parts of of the creation process in the middle um you have your source code window um at the top there's sort of a no not not a full emulator of the system but there's um it's a possibility if you have created animation um to to try things out or to try out the maps so it's kind of a simulator of parts of the game engine um and on the left is music tracking on on the right you can pixel tiles and sprites and also do animations and see how those work yeah um this is where we are where we currently are here you also can see why I didn't show you that much footage of the of the console itself um this is just a camera artifact so sorry for the flickering um but uh yeah after the talk if you like you can can see it on the on the system directly um but yeah the tile engine is working the sprite engine is working for the tiles we currently support uh one layer of tiles um the map can be any size like a lot bigger than the screen um and it will smoothly scroll and in the few next few months we want to want to add multi-layer tiles um with the zooming so you can have a sort of a depth the depth effect like it's often used in in jump and run games that's called parallax scrolling um we want animated tiles so maybe the grass and your on your map is automatically moving or there's a waterfall in the back um yeah this will be this will be the state of the of the tile engine when it's well not completed but this is what we're aiming for for the first prototype um yeah the sprite engine is also moving again at the moment you can display any number of sprites so it's not really restricted um we still have to add collision and animation um for the sprites so for the for the second prototype for the next revision of the hardware what do we want to add um like I said we really like the idea of having cartridges and uh yeah this will definitely be part of the of the second prototype again um it's not really needed because memories are cheap you can really just put everything on one flash but we really like the experience of having one game uh per cartridge and picking it up putting it in and uh you immediately can start the game and you don't have to scroll through lists and lists the lists of rom and uh look uh at rom 3825 so this is kind of a you know player experience thing that we wanted and and again it turns out that modern microcontrollers you can just attach flash and it will it will show up in main memory um for this controller even I think up to six different flash images or flash ic's um so we could just put that bus on the on the cartridge connector and we would uh really have a have a behavior uh that's very similar to what what the old systems did in the 80s um we also put an extension bus on there um based on i a square c and spi um and and for the microcontroller world if you have these two protocols you can basically put anything there these are these are extremely versatile protocols um so again um earlier cartridges it was not uncommon for a cartridge not to only supply game code but also to maybe extend ram um add a add a co-processor sometimes even if really replace the cpu and do all kinds of of crazy extensions because the the cartridge slot usually was just the the system bus and the cartridge could do whatever i held it wanted next um that we want to add is uh networking right wireless networking and we want for this we want some kind of um broadcast medium similar to ethernet basic basically um but no routing um and no point to point coupling no linking or anything like this what we are what we're aiming for is simply um all the all the huckleboy systems that are in within radio distance of each other um immediately and automatically see each other and well this will show up in in in memory in in menus and you say okay i i want to join a game and this is yeah sort of like uh think of it like LAN party type network um of the 90s and we will probably um use bluetooth 5 for this um mainly because it's well new and interesting um but it also has a extended radio range um and it comes with uh bluetooth mesh so you can connect even more systems together um and what you get for free with bluetooth is connecting connection to um to mobile phones so you can have a companion app and download download new games and yeah what have you um maybe you've noticed what's currently missing is sound um and yes we want to add sound to the next prototype but this is one of the um the aspects that we're still kind of unsure about um for the for the c64 for example sound the the sound chip like the glorious as said um the instruments were roughly modeled um after um analog synthesizers and we don't didn't really directly want to clone this we wanted to take it a step further but we haven't really figured out what this what this step would be um what we would really like to do is uh explore aspects of of generative sound generating instruments generating generating music tracks um because generative programming was also big in the in the early games um simply because there was not much memory and um yeah this was again a technique to to save memory um for for the for the interface for the for the player um we want to add uh bluetooth audio so you can use your use your existing headphones if you have one and well since we're not apple you're also getting a headphone jack um simply yeah because we really really really uh want to try out and do this uh games over audio in a in a youtube video soundtrack um kind of thing yeah the the second prototype with with these uh subs systems added um this will not no longer be based on the deaf board but but be one big pcb with with uh all the ic's on it um it'll come with a it'll be um the first um prototype with a with a proper enclosure and uh the mechanics for a for a d-pad um yeah like i said bluetooth um we'll probably want to add all the sensors that we can find um mobile gaming has introduced a lots of sensors to um to games simply because smartphones usually um yeah have a lot of sensors and i i'm still looking for a game idea where i can add the temperature or the air pressure to the to the way the game behaves um so yeah this is kind of a um a thing for me and um we hope to have this this done to for the next uh congress uh the ccc congress but we don't really have a have a fixed roadmap at the moment so how do we get this design this console out out to you out to people and yeah like i like i mentioned it'll be open hardware and um it we wanted it to be maker spaceable um but we often get asked like okay when when's the crowdfunding campaign when can i buy this um so this we usually say we're not really in or out um yeah we we're not focusing on on on manufacturing on serial manufacturing at the moment um simply because these requirements would um sort of restrict the game design extremely and and either you can focus at least for a diy project either you can focus on manufacturability and keep the price down which means that you're going to use all kinds of cheap chinese bad mechanics and it'll not really be a fun console to to work with um or the or you could just do the design and then afterwards see how how much uh how much you can boil the design down um to make it manufacturable and affordable and this the second way uh really could work simply because uh once you're looking at at thousands or tens of thousands of units you get access to all other development platforms and suddenly a microcontroller doesn't cost like 10 or 15 euros anymore but two or three or something so um while we're not aiming for this a goal of going to maybe 30 40 euros for components plus pcb at least doesn't seem out of the question yeah well what's next um there's there's no really no real conclusion to this talk basically because we we just we're just getting started we just have to have the first prototype we wanted to to do a few um iteration with the with the os and the and the hardware and see where this is going and we're also trying to take it slow because this is really a lot of work halfway through the through the here we realized okay we're actually building a game console and the DIYing a game console is in no way less work so we we don't want to burn out um and yeah really just just keep on going as we as we feel like it and um maybe this will take another year or two or three we don't know but we are hugely enjoying building this and we hope other others will join and yeah work with us on this platform together so um yeah this this was mainly what i wanted to show you how far we've got um we invite you to keep up um we'll post things on on twitter quite often you're and welcome to follow us um we have a website this will be relaunched currently it contains mainly a few pictures from the from the development but we'll relaunch the the website um and put lots of articles there and release all the design files and then yeah well see where this can go okay i hope we have some time for questions um thank you very much thanks axel uh it's always interesting to see uh when an idea that took place in gathering like this comes back as a prototype and um it makes me really happy also especially to see the retro game console um any questions yeah we have seem to have some questions i do a statement and a question thank you for this awesome presentation the graphics were fabulous thank you very much but this this is all goes out to christoph like if it were me you would have got latte slides so but yeah i'm really having myself how many hours did he put into that presentation all of them how many i haven't i haven't left my chair at the at the village much this year but yeah we really enjoyed that uh you're using lua as a programming language yeah what about basic um actually the the design is is open enough so that you could like like i said remix it this this is what we want if for everybody who's coming you say why not i'm saying yeah yeah come come on do it the interface is there so um yeah another option would be micro python i guess um basic there's a few other languages we we kept the interface intentionally clean and easy to work with so if you're if your scripting engine is sort of modular and can run on a micro controller that you can just plug it on top of it so yeah we'll go open to all kinds of new languages amazing project and amazing presentation i'm wondering you you were talking about constraints what are you aiming in terms of memory and in terms of cpu right now it seems like a super overpowered system yes um one of the next things will be to to put a real-time os underneath it so we can really enforce this um we haven't really figured this out we maybe something like 32 or 64 kilobytes of of game code like compiled game code um plus game assets um we we we at the moment we just have sort of a thumb value and then we'll just try what you can do with that what what kinds of games you can actually develop at different levels also also what we want to do is have the thing remixable ourselves meaning all the modules should be recombinable in what we call personas of games so you could you could recombine them to something um early 80s at harry 2600 style or something theoretical even even less powerful or go early 90s um have multiple scrolling scrolling layers and and uh yeah so we will probably develop one or two of those personas of of our own and then invite everybody else to well remix the console in the way that they want it okay thank you um if you want to see the prototype you will be welcome to come up front after the talk and we'll be at the attactor village tonight and probably for the whole day tomorrow so you're welcome and and try this out and um yeah thank you for coming again