Ray Tracer

Objective: write a ray tracing system that generates images from input sources using ray tracing algorithms. Define an input scheme, as well as choosing a mechanim for displaying the ray-traced image. The system must be able to have the following basic primitives defined in the system, as well as implementing a camera position, and (of course) at least a single light source.
Cube
Pyramid
Sphere

Recommendations: Look online for simple to complex ray-tracing algorithms. http://www.ece.eps.hw.ac.uk/~dml/cgonline/hyper00/raytrace/rayalg.html is one particular site. Implement algorithms alongside test cases for input primitives, and don't make any one system too complex. In the end, the system itself should simply compound environmental effects upon the tracing algorithm itself.

Go with AI

Objective: write a go game that allows a user to play a computer, forcing adherence to the rules of go. The only requirements for the AI of the computer is that it can make plays in accordance with the rules. The most advanced AI would react to the human player's moves in accordance with known strategies in go, learn from its mistakes, and retain its intelligence over games.

Recommendations: Implement the frontend first using an existing UI library (curses, qt, gtk), then concentrate on the computer player. There are a number of ways to approach the problem of intelligent responses. Start with a limited forward-thinking engine to contemplate and score possible moves. Graph theory, neural networking, and fuzzy logic could also lend themselves well to strategic solutions.

Demo Show

Objective: Develop a demo in the theme of Future Crew and others to demonstrate 3D/2D programming ability. The demo must run as a standalone application on the Solaris systems. The demo may include music, models, and other resources external to the program itself, but the focus should be on innovative programming to achieve visually impressive results.

Recommendations: This is a project which will require significant work from start to finish. Set up a sceneboard, time the scenes, citing exactly what should take place in them, and develop each scene and the required programming to it in detail. Look into developing small exceptional effects rather than an overall stunning work. See any number of graphics websites (eg: siggraph.com, opengl.org, nehe.gamedev.net) for resources on good graphics programming.

Database Engine

Objective: Create a new SQL database engine, which at a minimum must provide a way to define a table, insert data, remove data, and examine data. This can be done to a variety of degrees. The major decisions to be made are the following.
  • SQL Conformance - the PostgreSQL conformance site lists supported and unsupported features of the SQL99 standard, all topics of which are discussed inthe PostgreSQL documentation.
  • Persistence - in memory only/file based
  • Access - embedded only/socket oriented
  • Security and Authentication - users, passwords, grants, access control lists
  • Internal DB Structures - b-trees, internal tables, indices
  • Extensibility - functions, procedural language support, rules, triggers, views, user-defined data types, etc.

Recommendations: There are several distinct sections to the development of a database. One is the SQL interpreter. This is probably the largest portion of code in a modern database, since it involves translating arbitrarily complex SQL queries into the operations it must perform. I recommend looking at the SQL language subset supported by sqlite to get some idea of the grammars required to make such an parser work. Another section of development is a virtual machine which executes operations generated by the interpreter. Again, I recommend looking at the sqlite virtual machine tutorial for a guide as to how this should ideally work. The individual operations on a dataset should be defined explicitely here, and operations should be executed based on a ruleset. A clearly defined API between the interpreter and virtual machine will make development run smoothly and autonomously. Other distinct sections include code to handle connections if applicable, authentication mechanisms, data structure management, and a rule engine. Obviously, you should provide ways to interface with the database, be they through client librarys for a server-based DB or an API for an embedded database.

C to Whitespace Compiler

Objective: You've been hired by the innovative Macrohard corporation to build a compiler for their newest suite of stack-based processors. Their instruction codes are all coincidentally the whitespace characters in the ascii charset. While you have the engineers to blame for this, the company is offering you compensation in a popular soft drink to aid in your completion of this task as soon as possible. Your objective is to develop a compiler that will take the popular and often taken for granted C programming language and compile it into the machine code of this new processor, whose instruction set and behavior (also completely coincidentally) model that of the programming language 'Whitespace'

Recommendations: Use lex(1) and yacc(1) to make this a much more enjoyable task. Since both C and whitespace are stack-oriented languages, it should make the transition relatively simple. Your types are limited to a default unit size inside of whitespace, which should simplify the language somewhat. Data structures, function definitions and calls, pointers, and arithmetic are basic tenets of C, and should map easily to sets of whitespace instructions. You should include the operation in and out to allow for access to the I/O utilities of whitespace. Split your team up into two groups, one working on the C parser, and another working on the whitespace code generator.

Compression Communication Library

Objective: Write a library which can be used on two ends of a communication socket that compresses data transmitted accross it. The compression scheme should be of unique design to be flexible enough to avoid unnecessary compression but variable and extensible enough to have applications specify a schema or pick the best suited one based on content. It could perform some analysis on the data beforehand or apply a general compression scheme to the transmitted data. The overall goal is to reduce the total amount of traffic sent over the wire. Performance overheads are negligible.

Recommendations: Implementation of compression schemes in such a fashion defines a number of requirements. All compression algorithms used should have benchmarking mechanisms to decide which would be the most effective based on the data provided. The library must make these bench scores as well as the effectiveness of the compression scheme chosen available to applications which utilize it. This objective is meant as a demonstration of compression scheme implementation and data analysis. You may not use existing libraries or applications to accomplish your compression, though you may implement known and published compression schemes.

Internet Key Exchange Client/Server

Objective: Write either a library or application which implements completely the Internet Key Exchange protocol described in RFC2409. This tool must allow for communication of arbitrary length keys, and be well documented either in terms of usage or its API (possibly both). Your implementation must contain detailed descriptions where each section of the RFC is implemented. Your implementation must also provide both sides of communication for the protocol.

Recommendations: Decide whether you will build a standalone application or a library early on. Split the RFC into sections and define interfaces between those sections so that each stage can be independently developed and tested. A good test of the whole thing is to transfer the public keys used in ssh.

Project Design Tool

Objective: Create an GUI OO design tool that supports the following features at a minimum
  • Use Case Diagrams
  • Sequence Diagrams
  • Class Diagrams
Extended features could include code generation, batch testing tools, automatic management of code to reflect design updates, and versioning system hooks and tracking.
Recommendations: Pick a UI toolkit your group will be comfortable creating such a tool in (ie. QT, gtk, Java Swing), and create a unified interface that can contain the features you are looking to implement. Then split the functionality accross the different diagrams and the backend machine to drive it all. The tool should provide a similar interface to other satisfying tools in its genre (Rose, MagicDraw, Thorn, Gaphor). Use these as a reference point and add features that your team would find useful.

Group Oriented IDE

Objective: Make an IDE for a language of your choice which is conducive to group work. The application should handle project management, have an interface to a good versioning system, and provide group collaboration tools (virtual whiteboards, messaging, etc.). Basic features could include intra-project cross referencing, a project module view, a UI editor/generator, documentation interface specific to the language, compile, execute, and debug interface, and help on the IDE itself.

Recommendations: The core of this project should be safe synchronous development of a project among an arbitrarily sized group. This means that the backend, possibly even a daemon, will be responsible for making files appear consistent accross a project view. A scratchboard and commit interface is acceptable in some cases, and even live development of group files could be an option. For the frontend, the team should find a comfortable UI toolkit (QT, gtk, Java Swing) to provide the features developers would need for such development. The baseline UI should be devised first, with groups of features in the frontend delegated to individual team members. Use your experience with existing IDEs and working in teams to determine what needs to be added in order to make group development effective.

Graphical Filebrowser

Objective: Create a filebrowsing application which provides a unique graphical interface for a wide range of users. This interface should allow these basic operations.
  • File listing (ls)
  • File Deletion (rm)
  • Directory Creation/Deletion (mkdir, rmdir)
  • File/Directory Moving (mv)
  • Application Handler Interface
Extended features could include thumbnails, in-browser viewers/editors, multimedia support, an interface which conveys the directory structure, implied information regarding file relative size, permissions, behavior (stat), etc.

Recommendations: Design an interface which will facilitate all the features you are looking to implement. This project is an opportunity to provide a feature and eye-candy rich interface to a system's files, arguably one of the most important parts of any operating system. You are not limited as to the size or scope of the features you wish to implement beyond those listed above as core.