Category Archives: Apprenticeship

Change of Work Order

Ok, since I’m running a bit over a week late on my schedule, I’m going to change my work order a bit to save all the heavy thinking to the back of the schedule. I’m going to leave the ‘Game Algorithms and Game Objects’ sub-chapters last. Instead I’ll just focus on getting the ‘Free Form Explanation’s and ‘Description of game mechanics and elements’ done.

Nothing to Report -Entry

I have been updating the documentation. My intention is not to mention every little update here, instead I try and maintain that information on the documentation itself.

So far so good, I haven’t ran into what-now’s or dead ends. My intention is to underdesign the game concerning elements that can be added later e.g. different enemy ships. Of course I have to address this need in the design and subsequently in the technical realization.

On Documentation, Pt. 3

Ok, I promise that this is the last post for today on this subject, I saw the need to revise my document one way still. See if you can spot the difference. Spotting the looney is much too easy around here…

0. Structure, Purpose and Scope of This Document

1. Abstract

2. a.) Free form Explanation of Nokkapokka
b.) Free form Explanation of Kärhämät
c.) Free form Explanation of Vihollisuudet

3. a.) Description of game mechanics and elements in Nokkapokka
b.) Description of game mechanics and elements in Kärhämät
c.) Description of game mechanics and elements in Vihollisuudet

4. a.) Game algorithms and game objects in Nokkapokka
b.) Game algorithms and game objects in Kärhämät
c.) Game algorithms and game objects in Vihollisuudet

5. Audiovisual Overview
a.) Suggestions for the look, sound and feel of the game
b.) User interface

6. Metastuff, some reflection on the process, open problems, other notes

Appendices
-Licences
-Analysis of the gameplay
-Feedback and history

On Documentation, Pt.2

I revised the form of my design document, taking in consideration what has been said earlier. And I notice I will have trouble swallowing. The index should look something like the following:

0. Structure, Purpose and Scope of This Document
1. Abstract
2. a.) Free form Explanation of Nokkapokka
b.) Description of game mechanics and elements in Nokkapokka
c.) Game algorithms and game objects in Nokkapokka

3. a.) Free form Explanation of Kärhämät
b.) Description of game mechanics and elements in Kärhämät
c.) Game algorithms and game objects in Kärhämät

4. a.) Free form Explanation of Vihollisuudet
b.) Description of game mechanics and elements in Vihollisuudet
c.) Game algorithms and game objects in Vihollisuudet

5. Audiovisual Overview
a.) Suggestions for the look, sound and feel of the game
b.) User interface

6. Metastuff, some reflection on the process, open problems, other notes

Appendices
-Licences
-Analysis of the gameplay
-Feedback and history

On Documentation

The whole idea of game design is to outsource the content of your mind so that other people can understand and follow what is it that you want to present. As with any kind of human interaction this poses a mountain of problems but I wont get to them here.

This beforementioned practical aim dictates in part the scope, shape and the content of the game design document. Not having got any look at professional design document templates I have one idea to guide me in shaping the design document for The Apprentice. My document will progress in increasing order of abstraction. The document begins with what is most apparent for the player and progresses toward the technical execution of the game. From quite a freeform explanation of the player sees, hears and interacts with to pseudo-code and descriptions and lists of the game objects. So, the index might look something like the following:

1. (Metastuff)

2. a.) Free form explanation of Nokkapokka (in the order of a thorough game review)

b.) Description of game mechanics and elements

c.) Game algorithms and game objects

3-4. (same  for Kärhämät and Vihollisuudet)

5.-n.) (more metastuff, some reflection on the process, open problems, other notes)

+ possible Appendices

Timetabling

A good way to get things started is to slice it up in smaller pieces and making yourself more manageable (let alone understandable) workload.

As described earlier I have divided my game design project (The Apprentice) in to three parts, each being a subset of that before it. These slices are codenamed: “Nokkapokka”, “Kärhämät” and “Vihollisuudet”. Starting next Monday 13. August I will begin a two week stint to flesh out the design for Nokkapokka. Another two weeks from that will be allocated for Kärhämät. Perhaps surprisingly the next two weeks are allocated for Vihollisuudet. After this six weeks another two week period will be allowed for outside comments (none are expected). After this 8 weeks Nokkapokka goes code.

So the timetable so far will look something like this:

  1. Nokkapokka Design document: 13. August – 26. August.
  2. Kärhämät Design document:  27. August – 9. September.
  3. Vihollisuudet Design document:  10. September – 23. September.
  4. The Apprentice (worktitle) Design document open for outside comments. Possible comments might lead to rewriting of the Design document or parts therein. 24. September – 7. October.

Success of this plan is not expected. Failure, however, will be met with resolve. Note also that the 4. stage is actually redundant, the document and the whole project are open for any comments at any time. Any comments? You know what to do!

It Will Be a Shoot’em Up

I think it’s customary for apprentices to produce something according or set to a traditional mould before you’re allowed to come up with more original stuff. For this reason as well as because I’m stripped for original ideas, my apprenticeship project is to design a traditinional vertical scrolling shoot’em up. With a number of twists of course.

Skeleton of a design document

Technical Decisions

I have been thinking about more practical issues concerning my apprentice-project. I have always thought that something like this should be made in Java to allow as wide an availability as possible. I also think that something like this should be made as easy as possible to produce, even at the cost of efficiency. Especially since this project isn’t primarily meant to display my mad coding skillz. And there are plenty of computational resources on todays computers to squander.

Being as easy on me as possible means that I want to make use of existing components as far as possible. This means they have to be fitting licence-wise. Fortunately this doesn’t seem to be an issue for me, since most these components are released as Free software or at least Open source. I have been looking for a physics and a 3d-engine.

ODE (Open Dynamics Engine) sounds suitable for my needs, only it isn’t in Java. Versions of it do exist for the 3 major platforms, so I don’t consider this a major problem. It’s usability with Java is an issue, however. There exists a wrapper (ODEJava) for Java that provides a bridge to allow it’s use in Java. As this is a work-in-progress the price is unstability.

For the 3d-engine I’ve been considering jMonkeyEngine which seems more than capable for my needs and is Open source as well. And seems to have a interface for ODE as well. I’ll have to set-up these things and get experimenting.

Project Outline

I have added a short description of the Apprentice on the project page. My intention is to have a separate page for the project itself. At this point I take it given that unless I don’t post exact timetables, I don’t have to point out that “it’s coming soon” or use other temporal designates. My aim is to release to something on the 2nd of June this year. Whether it will be a subset of Nokkapokka or something else, I make no claims just yet.

Announcing My Apprenticeship

I have been thinking about this for awhile. In order to get oneself lodged into the Game Industry one needs work experience, at least here in Finland. Master’s degree means dick. In order to crack this slight of circle of doom I am launching a project with the intent of:

  1. Producing a Game design document and
  2. Producing a Game in accordance with the said Game design document.

Since my aspirations are on Game design the quality and practical usefulness of the Game design document is of outmost importance to me. Furthermore, the adherence of the Game with the document (as opposed to content of my mind) is important. Whatever is in the game should also appear in the document. I will open a separate page for this project, which will house the design document and general information. I will also document in detail all the problems, misgivings, misunderstandings and failures in this blog under the tag “Apprenticeship”.

Make no mistake, this is something I have to do, whatever the outcome. Can you dig it, bitches?