A study of systems implementation languages for the POCCNET system

The results are presented of a study of systems implementation languages for the Payload Operations Control Center Network (POCCNET). Criteria are developed for evaluating the languages, and fifteen existing languages are evaluated on the basis of these criteria

GED - a generalised syntax editor : a thesis presented in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University

This thesis traces the development of a full-screen syntax-directed editor - a type of editor that operates on a program in terms of its syntactic tree structure instead of its sequential character representation. The editor is table-driven, reading as input an extended BNF syntax of the target language. It can therefore be used for any language whose syntax can be defined in EBNF. Print formatting information can be included with the syntactic definition to enable programs to be pretty-printed when they are displayed. The user is presented with a pretty-printed skeletal outline of a program with the currently selected construct highlighted and all required syntactic items provided by the editor. Any constructs with alternatives, such as "", which occurs in many languages, are initially denoted by a placeholder in the form of a non-terminal name (i.e. "") which is expanded when the user indicates which alternative is wanted. All symbols entered by the user are parsed immediately and any erroneous symbols rejected, making it impossible to create a syntactically incorrect program. The editor cannot detect semantic errors as no semantic information is available from the EBNF syntax. However the first use of all identifiers is flagged by the editor as an aid to the detection of undeclared identifiers. A "help" area at the bottom of the screen continuously displays a list of the correct next symbols and the syntactic definition of the currently selected program construct. This display, together with a multi-level "undo" command and the provision of a skeletal program by the editor, provides a way of exploring the various constructs in a programming language, while ensuring the syntactic correctness of the resultant program

A NPC Behaviour Definition System for Use by Programmers and Designers

In this paper we describe ZBL/0, a scripting system for defining NPC (Non Player Character) behaviour in FPS (First Person Shooter) games. ZBL/0 has been used to illustrate the use of scripting systems in computer games in general and the scripting of NPC behaviour in particular in the context of a book on game development. Many novice game designers have clear ideas about how the computer game they imagine should work but have little knowledge – if any – about how their ideas can be implemented. This is why books on game creation (design, programming etc.), as well as all-in-one game creation systems – especially designed for ease of use and intended for an amateur audience – enjoy great popularity. A large proportion of these books however merely present solutions in the form of descriptions and explanations of specific implementations with inadequate explanations of principles. While this may benefit rapid application development it often does not lead to a deeper understanding of the underlying concepts. The understanding of rule-based behaviour definition through simple scripting in computer games and the development of such scripts by programmers and designers is what we aim to address with the ZBL/0 system

I/O Considered Harmful (At least for the first few weeks)

One of the major difficulties with teaching the first programming course is input/output. It is desirable to show students how to input data and output results early in the course in order to motivate the students and so that they can see the results of their programs. Output is also a useful tool for testing programs. However, in most programming languages input and output are esoteric and the techniques for performing input and output must be learnt by the students at an early stage, precisely when they are trying to understand the basics of programming. We argue that input/output operations need not be taught in the early stages of a course if the language environment provides appropriate tools for testing programs. This assertion is demonstrated by reference to the Blue objectoriented language and environment