Game Kit

Many Ideas

Posted Sat, 2007-06-16 15:16 by morthozz

First of all, apologize me for my English, I know it not quite good but Im improving. I have posted before but they have been deleted (I dont know why).

Quality / Stability, Kernel

I wish that Haiku before have been or sooner if possible BeOS clone. Have some security and quality features, i propose that this OS have a memory execution protection, just to make the life easier and secure, just to enforce to make best programming practices. The thing is like this:

*proteccion to dont allow execution of code if its in a "not code" memory section/page. So to prevent STACK and HEAP/DATA execution. So the application could fail, but OS remain stable.

*proteccion agaist stack underflow and data/buffer/heap overflow. So bad programmed applications could not damage the Operating system in that way and compromise it.

*independant memory position aplication execution.

with all this open techonlogies (even could be implemented by software) not only could make the user life easier but the developer life too, becouse it could be much more easier too detect some common bugs without crash our system. I guess some BeOS application are not too good programmed so they used that bad techniques, so at first place we could use a COMPATIBILITY user allowed method (or even a listed application allowment for compatibility mode with old and bad BeOS bad programmed apps).

at last
*portable devices compatibility and support, like those that could be plugued inot usb port, ex: Mp3 players, video players, memory cards/sticks, IRDa, WiFi, Routers/Hub/..., external storage.

Network Interface

I wish a well firewall, powerful but yet easy to configure, with an advanced mode for experimented users. Preconfigurated with the common and best settings to do every day work.

*Here we could add, a good network interoperability with all Unix open standards royalty free (SCO, BSD, Linux), to make a good neighborhood this OS in a network.

User Inteface, Game Kit

In this part I really wish a powerful GUI with a simple interface, capable to do good 2D/3D work. With advanced features to made easy programming great games using that GUI-API. I must be easy to extend, but the User Interface must keep standard, with the option if you wish to make it customizable with something like skins disigned by users, but with out let it modify the kernel/drivers of the OS. I made enphasis on standard because it hard work to bring support when the GUI its so different, and even the final user (common user) dont even know it at all its features and diferent options positions.

What its important too bring success to this OS its make powerful and yet simple, but with some easy advanced features for that know how to use it. To bring applications for: word proccesing, calc sheet, slide presentation, a good photo processing ex.linux:GIMP, a good vector drwaing ex.linux:InkScape, good Developing tools, like IDEs, .NET power and simplicity; and not less important a good 2D/3D engine (integrated API) so they (open and close developers) could bring great games. With all this we could attract much more users and industry.

-Morthozz

Feature Wishlist

Posted Sun, 2006-08-13 15:25 by admin

This article was started by myself, but it was extended by our users when it was placed on our wiki. The development team will have to review and discuss all suggestions.

Multi-User

  • something similar to what Win2k does, where you try to do something and it says "you don't have permission to do that. If you are an admin, click here to enter the admin password for permission."
  • multiple users - One or many at a time? Security for many at a time?

New Kits

  • vector math library to use MMX/SSE/SSE2/3/4/5
  • What about having a synthesized speech kit. Applications would send text (possibly with special marks) to the kit. Particular languages could be available as plug-ins.
  • Voice recognition
  • Should we have help system? Pocket PC has very handy one, it's HTML-based. There's a folder somewhere, where your help files are (for example, StyledEdit.htm). When you have StyledEdit opened and you open help, it goes directly to the StyledEdit.htm file. When there's just an empty desktop and you open help, it goes to index (automatically updated links to files in help folder). So, whenever you install a program, the install script or package manager copies just one HTML file to the help folder. It's so easy to use, that OBOS should have it too. And there could be a simple search capability within the help files
  • synchronization kit - some sort of way to notify and automatically update subscribers when data changes
  • im kit
  • XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit
  • Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)
  • Database Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better. Look at SQLAlchemy for inspiration.
  • Fax support (kit?)
  • RPC (SOAP, XML, Web services etc.)
  • SpellCheckAPI
  • Reference kit (dictionaries, thesaurus)

Media/MIDI

Printing

  • Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

Device Kit

  • Why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your Haiku machine should have a class to access it.

Game Kit

  • Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more.
  • Translation Kit
  • How about 3D objects? Or vectors (structured drawing)? HTML read/write?

Mail Kit

  • public/private key encryption for email

UI

  • ditch menu bars for context menus only
  • we should go vector. And we should adopt SVG as our standard.
  • Dictionary of translated words, so that untranslated apps can be automatically (if imperfectly) translated.

How about being able to have a several applications using the same window, each one having its own tab? I believe there are UNIX window managers that do this though I've not tried them so I'm not sure how good it is in practice. I imagine there would be pros and cons.

Some GUI description language (XUL?) is a really nice thing to have in R2.

include a standard widget for toolbars, Some thinks I like about some toolbars:

  • drop-down buttons.
  • animated icons.
  • separators
  • options per toolbar - small icons, text under icon.
  • !!! configuration tool - add/remove button on the fly !!!
  • ability to collapse the menubar into a clickable icon for more screen space (maybe even into the tab?)

 

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

  • BHTMLView - include JavaScript? External players? Use some existing framework?
  • How about an Outlook bar? Or a grid widget? Many new controls possible, look at other OSs. Graphs and charts
  • How about a BImageFilePanel? One that queries the device system for image yielding devices and has neat features like thumbnails, etc? Or a BSoundFilePanel that lets you play snippets before loading the whole file? Still-Image Acquisition & Moving-Image Acquisition
  • RAD / easy graphical GUI-creation toolkit
  • Color Management
  • Multiple monitor support
  • LayoutManager (already in the works for R1)
  • workspace sharing via network
  • investigate ZUI concepts
    • access embedded data (e.g.: email attachments) in-place
    • spatial data organization
  • look at Morphic/Tweak, Chalk (Slate's CLIM+Morphic combination)
  • replicant may run as separate process?
  • OpenBinder
  • scalable UI
  • gamma correction?

Localisation

This would be fantastic it would allow easy language localization of any part of OBOS (OS included) to a specific language and it would allow for users to have several languages available in is system in just one installation.

All higher layers of system should use some kind of localisation. This covers:

  • Language translation files for applications
  • Time and Date writing order/conventions
  • Currencies
  • Number spacing
  • Keyboards
  • Fonts ( BeOS default fonts are lacking some Latin European glyphs )
  • API/GUI should be able to fit different font sizes and string lengths (Example: Chinese has very big chars)
  • system–wide Unicode/UTF-8 is a must

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar, number widgets, phone number, address that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right. Layout management, too, so that resized widgets can flow properly.

Note: Axel Dörfler is already working on this in the OpenTracker repos.

Kernel & Drivers

  • ability to move processes from one machine to another (load balancing)
  • Anyway, a good thing to add is device feedback. This way drivers would be able to implement force-feedback for mice, for example.
  • A method for drivers to publish functionality in a standard way. It could be only metadata. It would allow querying to discover if certain functionality exists in the driver and/or the hardware
  • Power Management and other "special" laptop support
  • Bluetooth
  • FireWire
  • CardBus/PC Card
  • PCI Express
  • 64-bit processors
  • Debugging via the kernel
  • RAID (hardware and software)
  • Hardware–accelerated OpenGL
  • EFI (UEFI 2.1)
  • Enhanced SpeedStep
  • WiFi (2200BG, 2915ABG, 3945ABG, PRISM?, USB adapters, ...)
  • Firewire
  • Intel graphics drivers
  • more file systems (NTFS r/w, UDF2.6+attrs r/w, ZFS, XFS?, EXT2/3FS?, ReiserFS?)
  • FS-independent indexing service (e.g.: Beagle), but might use FS index (if available) for faster queries
  • userland FS API
    • LDAP address book
    • IMAP
    • IMAP address book + calendar + notes [plug-in based backend]
    • WebDAV?
    • FTP
    • P2P with queries [BeShare?]
  • transactional VFS (see Windows Vista)
  • versioning VFS
  • FS ACLs
  • extend node monitoring to monitor all VFS calls
    • not only specific directories
    • allow for filters that can intercept and deny access (e.g.: virus scanners)

Network

  • ZeroConf / Rendezvous / uPnP
    • with support for add-ons: e.g., instant messengers could use ZeroConf to expert services to your friends
  • event-driven API (new device, configuration changed, (dis-)connected, etc.)
  • mobility-oriented
    • access important functions and profiles via Deskbar replicant
    • auto-recognition of profiles
    • update default printer and PPP connection
    • update timezone?
  • IPv6
  • WiFi with full encryption support (WEP, WPA, WPA2)
  • RADIUS client authentication
  • anonymizer modules (Tor, DNS translation, etc.)
  • NDIS wrapper
  • networked file system

BeMail

  • show all drafts in a list on the left
  • closing will auto-save your email. no need to save your work
  • unlimited undo history is stored for all drafts, so you can undo something even after having closed BeMail

Tracker

  • Not only does it offer a more efficient space, it enhances the usefulness of the OS by offering a place to stash information vital to the user. Some examples of replicants that could be of use would be a pulse like CPU histogram, a virtual workspace manager, a clock and calendar, controller for audio players, applications/script/folder shortcuts and a drive space monitor, to name a few. I'm sure others can come up with more. It would be left up to the user to decide what they want to display as a deskbar replicant, in what order they want them displayed and how they want it displayed.
  • what if "My Computer" opened into a mime type directory. You could either look at a type's subtypes OR look at the files with that mime type.
  • In the Tracker with an icon(or icons) highlighted, you decide to copy them to another directory. You simply right click, move the cursor over Copy To and you then proceed to find the directory you wish to copy them to. Now you find a few more files(we will use mp3s as an example) that you wish to copy to the same directory. You simply right click, move the cursor down to Copy To, but this time when the next menu forms their is an option at the top that says Most Recent or Recent. Moving to the right on this item shows you the last 5 or 10 directories that you have copied to. This functionality would be available from the Create Link, Copy To, and Move To pop–up menus.
  • integrate xcv ([1])
  • This could be implemented like this: when the appropriate file is highlighted, make Tracker extend its viewable area, like a drawer, and this drawer should work like R4's Container; attach a new replicant that can handle this file type. BeMail could be made a replicant, NetPositive already is (could be the handler for graphic files), SoundPlay also...
  • Folder backgrounds are stored as an attribute of the folder. Why can't we preview images by clicking once on them and have Tracker send them into the open folder's background attribute? For that matter, any type of data/media could be handled the same way. Video, audio - all that stuff. We can even have tracker do cool things like make a split pane to preview emails and text documents (any kind of document that we have a "tool" reader for - Gobe, Word, Abiword, etc.).
  • What about allowing "rules" for file management on the desktop, i.e. when files are dropped there.
  • rework queries and UI (categorization, time-slider/scroll-to field)

BFS

I think it would be useful to have attributes with both a name and an index: you could get the 6th attribute named "foo", for instance. This is useful because it lets you associate more than one value with a single attribute in a system-defined way. If we had an installer that tracked what libs an app depended on, it could place those in attributes and query for them, without worrying about separating the lib names with some kind of token. MP3s could have multiple authors. We could also give translators an attribute for what they translate, which would make this obvious to the user, *and* obviate the roster: the system would know where it was going. Currently, we have only one value for attributes which is very annoying with a Contact's email addresses: we use tricks like "Person:Email"="first@mail.com, second@othermail.com". This has to be changed. Think of BMessage: "Person.Email" gets an array of values: "Person.Email"[0] = first@mail.com "Person.Email"[1] = second@mail.com How this is handled with indices: the "Person.Email" index may simply contain multiple entries pointing to the same file.

  • Full text indexing.
  • versioning
  • maybe replace BFS with a DB (DR8, but much better)

Components

The micro solution consists of reverting to the computing roots of the D+F concept (data and functions, no programs). That is, the killer app for GE is that there is NO app. Your system consists of functions which the user invokes in which ever order they choose, and vendors ONLY provide functions. They no longer provide programs. The entire User Interface has to be changed to allow for an entire different concept of work flow. Let me repeat that one more time - a new work flow requires a change in the user interface (think fundamental change like the change from CLI to WIMP).

I connect the Cron component to the MediaPlayer object and boom - alarm clock. This is what OO was supposed to bring to coders. We are talking about bringing it to end users. Of course, just like, say, themes, there will be builders and there will be users. But what we are really talking about is making coding message based and more modularised. The idea of wrapping complex structures in one binary file & using special dev/apps tools to poke inside seems to be giving way to keeping 1 simple type in each file, & letting a folder keep it all together. Advantage is any suitable app can edit specific components. Apple used to use resource forks with ResEdit, now they want all to use the hidden folder approach. Much much easier on tool developers since you reuse what is already out there.

[ Note that the enlightenment foundation libraries ( http://www.enlightenment.org ) goes some way toward making this possible. Combinations of Embryo, Eet and Edje allows this level of customization through "themes" for a single application. ]

Lets make it cooler, you get your components, link them up Cortex style and save them as new processes. Imagine browsing through your Video directory and previewing the video using the folder's background as a screen. The icons maybe will become slightly transparent so that you can see the video a little clearer, but not much because it is - after all - just a preview to see if it's the right document.

Input Kit

  • fix the InputServerMethod issues.
  • I also have been thinking of moving Joysticks to the input_server.
  • allow users to determine the order in which input is passed to the InputServerFilters.
  • allow for system wide key bindings
  • MIME/Roster
  • File types are more human-readable: Document, Image, Video, etc. In our local database we store the MIME translations for those types. Multiple-inheritance is supported, too (Ogg would inherit from audio/ and video/, for example). Instead of specifying attributes for each format individually (MP3 has its own attribute set) the attributes are inherited from the supertype (Audio). Internally, the file types are stored as MIME. This allows for better OS-interoperability, backwards-compatibility, and more flexibility (we can change the inheritance structure of the whole type database and it will continue to work). But there is a problem with this model: global queries (Audio/*) would have to look for multiple MIME-types (application/ogg, audio/*, etc.). Nevertheless, it should be a step forward, usability-wise.
  • BClipBoard - ability to have multiple items on the clipboard

Translation Kit

  • meta-data (also for file attributes)
  • 2D/3D vector graphics
  • documents (OpenDocument-based API?)
  • spreadsheets
  • databases?
  • viewers + editors API (like replicants)

Support Kit

  • Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

Other

  • User preferences USB stick (flash storage) - on boot/disk insertion, check to see if there is a removable volume mounted that has a home directory on it. If so, boot using this as home; allows visiting users to bring their preferences/apps/data with them. Basically a Haiku install minus the system on a flash drive/CD/whatever.
  • bundles
  • read-only base system (separate partition), read-write overlay system for additional apps, and mobile user profiles (see BSD-HALO)
  • collaboration services (multiple persons working on one document over the network )
  • download_server + API (does this make sense, at all???)
  • input profiles?? (mouse, keyboard, joystick?)
  • energy profiles

Some vague ideas...

Posted Wed, 2002-10-16 05:00 by admin

Late at night, beating my brains for yet another newsletter article, my eyes were drawn to a notebook nearby my desk. This notebook contains my ideas that I brainstorm for future versions of OBOS. One of the complaints that people have is that R1 as we have defined it has no "future". It doesn't do anything beyond recreate what Be did and that we should aim higher for our first release. Interestingly enough, there is another, equal sized crowd of people who say that we are trying to do the impossible. In either case, R1 will be what it will be.

R2 and beyond are wide open, though. The following are some bullet items, some thoughts and ideas. Nothing solid, nothing developed, nothing thought through all the way, and certainly nothing promised. But some ideas, none the less...

XML - possibly methods for BMessage to transform to and from XML, possibly a whole different kit

Encryption - a plug in architecture for encryption/decryption. Probably public/private key. With a key manager of some sort, so that it is easy for users. Also with a tie-in to the Mail Kit of some sort so that mail programs can quickly and easily encrypt and decrypt messages. Also a cache of public keys with methods to refresh them (via Networking Kit)

Additions to BBitmap - this class is really in need of a lot more "stuff". Think LeadTools for Windows - the ability to choose some area of the bitmap and apply transforms (plug ins). This has been done a dozen times for a dozen different art programs. Let's do it once more, possibly leveraging someone else's work and make it part of the OS.

In a similar vein, how about a BSound class that adds effects? Mute, slide, reverb, echo, etc. All, again, as plug ins.

Vastly improved printing is needed. Color management is huge, now, with digital photography. Additionally, more functionality is needed. Watermarks, more margin control, etc. All of those "extras" that you have on Windows and use once a year.

BHTMLView - I am not sure how this one should be done, but it is just obvious to everyone that we need one.

Localization - this is probably the single most requested feature. And one of the biggest. Because this ties into so many other things. At minimum, we need to add currency, calendar and number widgets that tie in to the locale. Plus automatic translation support (i.e. translate phrases into current locale's language), resizeable, font independent widgets, right to left and top to bottom text, etc. There is a *huge* amount of work in doing this right.

Game Kit - this kit needs a massive overhaul. Be never really took it seriously, but I do. Sprites, Backgrounds, collision handling, parallax, 3d, scrolling, tiling, AI, controllers (joysticks, etc) and more. This kit could almost be a career for someone.

IM Kit - I have heard rumours that this is being worked on. Possibly leverage that into our work. This kit could be useful in a dozen different apps. Tech support in your office suite? Inter-player chatting in games? More and more, we are all connected...

Device Kit - if there is any less cared for kit out there, I don't know what it is. Only BJoystick (which belongs in Input Kit) and BSerialPort remain. But why does serial port deserve a class but not BParallel? Or BAudioCD? Or BVideoCD? Or Scanners, Cameras, PDAs, etc? Every "thing" that you plug into your BeOS machine should have a class to access it. Banish ioctl()'s forever!

Tracker - A lot of code clean up to happen here. After that, I would like to experiment with different, alternate Trackers. The desktop metaphor doesn't work for everyone. I don't think that anything works for everyone. Let's make a couple or more different Trackers and see if they suit someone's needs.

BClipBoard - ability to have multiple items on the clipboard

Interface Kit - there are dozens of widgets missing from here. Not to mention all of the stuff we mentioned for internationalization. How about an Outlook bar? Or a grid widget? Lots of honest work to be had, here.

Storage Kit - I think that this is a little hard to use. Lots of times, I have found myself taking the long way around on some simple things. Maybe some better methods...

Support Kit - Lots of new classes for here, too. There are numbers of useful little helper classes that we could all use... How about a pool allocator, as an example.

DataBase Kit - access for SQL databases will be a large sticking point to getting on the corporate desktop. The sooner the better.

Translation Kit - Good kit, as far as it goes. How about 3D objects? Or vectors (structured drawing)? HTML read/write? Tons of good work to be done here, too.

A CD Writer application is a critical piece that we lack. And a scanning app. Simple stuff that come with other OS's.

Power Management and other "special" laptop support

A dock - every OS should have one of these.

As you can see, there are a ton of ideas. And I know that every one of you has some, too. These are just mine. R1 is a stepping stone. A place to start. Not a place to end up. I certainly don't intend to rest on my laurels when R1 is done. I intend to step it up another notch and build what Be didn't have time to finish.


Design goals for the Game Kit

Posted Sat, 2001-10-20 05:00 by admin

The Framework

If one is to believe the books and magazine articles, websites, and game developers one talks to these days, there seems to be a general consensus that the bare-metal, code-it-from-scratch mentality just doesn't cut it any longer when developing games. Software engineering practices long appreciated elsewhere in the software development world are finally making an appearance in the last bastion of the garage-hacking, caffeine-swilling coder.

This is for a lot of reasons. For instance, game publishing schedules ("If it doesn't ship in time for Christmas, we're gonna lose our shirts!"), lack of in-house expertise ("Sure I can write that, just let me brush up on my number theory first."), egg-on-the-face from having shipped buggy products (let's not name names), improved tools and the general enlightenment of the coding community, amongst many other factors, are all changing the way games are made.

So what does this mean from a practical perspective? It means that libraries that provide a framework in which to build a game are increasingly de rigeur. Adopting a clean API (GPI?), preferably portable, frees developers from having to deal with all the minutiae of writing a game. They're then able to focus on creating novel technology to differentiate their game (not that this happens often enough, but that's another rant - see the Scratchware Manifesto), spend more time on design, make the architecture more flexible, squash bugs, etc.

It turns out that there are a lot of these libraries out there, from the completely closed and de facto standard DirectX, to the various completely open ones infrequently used for commercial projects (most of the Unix-based APIs). They are written with different goals in mind, and often from one person's perspective as to what would constitute the ideal game development platform -- hence the proliferation.

The Design

The fun part, and the challenge, of working on the Game Kit for Haiku, is that the Game Kit is currently sparse. Be was presumably working on correcting that, what with OpenGL being re-written and the necessary changes to the Game Kit that would entail, but if we don't get any of that code, perhaps that's just as well. We get to spend some time thinking about how best to build an amazing Game Kit almost from the ground up, and do it in a way that meshes nicely with the existing API that we've come to know and love as BeOS developers.

Which isn't to say that we won't be source compatible with programs that use the existing Game Kit, but there really isn't all that much code to be compatible with, relatively speaking. The small size of the Kit means that, although it'll be tricky to implement because of how tightly knit it is with other parts of the OS, it still shouldn't be all that much work (at least, not for the people working on the game kit). A lot of other stuff has to be in place, e.g. graphics support, before it makes sense to worry about getting a BDirectWindow happening.

In the interim my approach has been to peruse the other libraries available, particularly those with source available, and try to determine what's good and worth keeping, and where we can improve on existing designs. Some examples you might want to look at are SDL, Clanlib, PTC, Allegro, CrystalSpace, and DirectX - the list goes on.

Another pair of technologies we'd be well off having are OpenGL and OpenAL, because they're standard or becoming so, well-known and supported, and having them automatically lends us a certain air of legitimacy. There is also an increasing body of knowledge accruing on the net, at places like gamedev.net, gamasutra.com, and flipcode.com pertaining to what was once one of the more secretive branches of the software industry. Go ahead and have a look. You'll thank me you did.

The Implementation

As far as the actual classes, systems, and whatnot that will compose the Game Kit, here are some ideas:

  • display surfaces.
  • n-Buffered display, i.e. back-buffering.
  • resource compression, (en|de)cryption, loading and translation.
  • network game support, including game finding, negotiation, etc.
  • BMessage transport across networks.
  • OpenGL support. Perhaps a native 3D engine that wraps OpenGL.
  • OpenAL support. Perhaps a native 3D audio system that wraps OpenAL.
  • multichannel and positional audio, including audio convolution.
  • generic implementations of commonly used game algorithms, e.g. A*.
  • a logical game framework based on an extension of BApplication.
  • a decoupled, multithreaded graphics and game state framework, i.e. game state and "drawing" happen independently; a drawing thread can take a "snapshot" of the current game state for rendering while game logic proceeds.
  • a generic save game framework, usable by all games.
  • hardware queries that determine the capabilities of the current machine. Some standard benchmarks might be useful to scale game features according to the capability of the hardware.
  • force feedback, general haptic support.
  • classes for uniquitous game elements like menus, consoles, splash screens, scrolling credits, bitmap fonts, etc.
  • support for playback of multimedia (courtesy of the Media Kit).
  • automated music generation
  • multilingual support (good 'ol UTF8, multiple resource files, etc.)
  • serial debugging, message console debugging, etc.
  • math stuff, e.g. vectors, matrices, quaternions, splines, compression, etc.
  • low-level stuff, e.g. bit-fields.
  • insert your favourite feature here.

If half of the code you need to write for your game is written before you first sit down with a design document in hand, chances are you'll be a happy developer. Our mission with the game kit is to spread such joy throughout the land.

The Future

Since it's you (yes, you!) that we expect will one day be writing the video games we intend to be playing on Haiku, the Game Kit people would love to get some feedback from you: feature requests, design suggestions, recipes, whatever. Send it to Robert Medeiros or Vitaliy Mikitchenko.

Of course, nothing I've said here is set in stone - at least not yet. My personal milestones are to have an unoptimized alpha version of the new Game Kit released with the first alphas of Haiku, profiled and somewhat optimized betas accompanying the beta OS versions, and massively tweaked cycle-squeezing code shipping with the 1.0 release, whenever that might be.

Chances are the Kit will be available and usable long before then (I've already written, and re-written, moderate sized chunks of the library in an effort to grok the design), but I don't want to promise that the API won't change, or that things won't break horribly up until that magical moment when my sweaty hands are cradling our collective love child -- a golden master of Haiku v1.0.

Syndicate content