Yesterday I “Making Games Talents” finally was held in my area (at least near enough to attend it) and the company set that was presenting itself contained all the company’s I ever wanted to work for: Related Designs, Crytek and Spellbound. First of all I’d like to thank Game Star (and IDG) and especially Heiko Klinge for making this event possible. It means a lot to us crazy devs, designers and artists to have the possibility to actually shake some hands instead of just writing one application after another and get ignored. This way we can show the company’s why we matter and why we stick out of the crowd. It was a quite rainy day yesterday and the first hard thing was to find the place ;o). Honestly guys.. next time a better description would be nice (or was this the first test?). However during my search I met some people who where also looking for the right place and so we made a team effort out of it. We sticked together for a while and met again later on. What will become out of this group is uncertain, but we exchanged e-mail addresses and you might here from us again (On this blog or maybe even on a bigger scale) ;o). I first attended some lectures. After that I tried to get started with shaking hands. Getting to someone wasn’t really the easy part. Because the company’s like Crytek, Related Designs and Spellbound where all but overrun. I took my place in the line and finally had the chance to shake the hand of the CEO from Related Designs (if that isn’t already something ;o) ). Sadly though they don’t have a position open for a junior programmer at the moment. He took my portfolio and wrote some infos down. To bad. I’d really enjoyed working for them! The Crytek booth was badly crowded, but I tried my luck. When I was finally in front of the booth I met Cortney. He’s talent manager at Crytek. He took the time to look at the game I developed together with the GDIG at FH-Trier and listen to my explanations. I found him to be quite patient and friendly (considering what he had to all day). Last but not least I went to the Spellbound booth to present my case. They also where very patient (considering my notebook crashed before I could start the game and they had to wait on it for quite some time) and especially very friendly. All in all my hopes have somewhat risen (concerning GamesCom they have rocketed). Now comes the hardest part: wait and see. In the meantime I’ll look for more opportunities to get into the gaming industry. Keep your thumbs crossed!
October, 2010Archive for
Making Games Talents and beyond
Sunday, October 17th, 2010KWatchman – An Idea given Birth
Tuesday, October 12th, 2010First of all: Thank you everyone for you comments and suggestions. They really got me on the road and showed my that there indeed is interest enough to do some more serious work. So I sat down and made myself a little planing and even some (small) coding today. Here’s what I got so far:
The project will consist of mainly 3 Parts:
- Part one being the kwatchman-service (in what manner I’ll realize this I’m not sure yet). Its basically just an empty rack to manage and run part 2 (maybe this will even be a daemon so it can run under higher privileges).
- Part two being Plug-ins that can be loaded by kwatchman-service. There will be (for now) 4 kinds of Plug-ins:
- Sensor Plug-ins (they collect the data from a specific source e.g. libsensors-plugin, hddtemp-plugin, nvclock-plugin, etc.. )
- Interface Plug-ins (they provide interfaces for all apps that like to access the collected data e.g. dbus-plugin, network-plugin, nagios-plugin?, etc… )
- Database Plug-ins (they provide storage for long term data collection e.g. mysql-plugin, postgresql-plugin, nepomuk-plugin?, etc… )
- Alert Plug-ins (they do something in case an alert is issued by crossing some threshold e.g. knotify-plugin, phonon-lugin, log-plugin, shell-plugin, etc… )
Apart from the database Plug-ins all Plug-ins can be used or not used at will. So the user can ultimately decide what gets refresh and which alert is being send if a threshold is crossed. Concerning the Database Plug-ins I guess its much easier if only one is allowed at a time. All other use cases can be handled by Interface Plug-ins (e.g. if you want nepomuk as your db but want to access the data via php on a webserver a php friendly interface Plug-in would be the solution).
- The last part are GUI’s that access the data and configure the Plug-ins via the interface Plug-ins. Those can be a very wide variety of apps and applets ( e.g. native KDE4 apps, plasmoids, KCModules etc.). Im not completely sure how the initial configuration of the service should be made so that at least the correct interface Plug-in for your favorite App is activated.
The first implementation will (most likely) contain:
- The kwatchman-service (whatever it will be)
- A lm_sensors sensor Plug-in
- A nepomuk or MySQL database Plug-in (not sure yet)
- A native (ksensors like) KDE4 app
- A interface Plug-in for the native app (maybe via dbus?)
- A knotify Alert Plug-in
As soon as I’ve got those components in working order I’ll concentrate on more sensors and Alert Plug-ins. After I that database Plug-ins will be my attention and finally I’ll write some more apps and Interface Plug-ins.
As for now I’ve got a (very rudimentary) cmake concept for detecting libs and deciding what gets compiled, a (also rudimentary) file structure for the code and some template for the KDE4 App.
So.. now to it: What do you think about THAT concept? Crazy? To big? Super? If you have any supplementary suggestions to the concept don’t hesitate to comment!
The King is dead, long live the king!
Monday, October 11th, 2010Have you ever wondered what became out of KSensors? I did. Many times. Well the sad but inevitable fact is: its dead :-(. And as far as I can tell there are no real successors standing in the doorstep. All the sensor apps available for KDE4 are hardly replacements. Most of them are plasmoids and I’d rather consider them toys then the real deal. Because of this I decided to bring in KWatchman (hope the name isn’t taken. Couldn’t find anything though). Essentially KWatchman aims to be a full replacement for KSensors. Showing sensor data on a dashboard, in KDE4 sys tray and ringing “the bell” if something is wrong. As of now the only thing that exists for this project is the idea, an (empty) git repository (http://gitorious.org/watchman) and an (mostly empty) IRC channel (#kwatchman @ freenode ). Before I begin on writing any code however I’d like to ask YOU about this ;-). So: What do you think about this idea and more important what do you think should be changed / made better as with KSensors? As this will not be a fork of KSensors but a complete rewrite I’d like to hear any Idea about this. Just drop me an E-Mail, write me in IRC or post a comment to this blog entry. I’m happy about any comment. Thx.
Social Networking
Weather
9°C
