Materials everyone's never done.

A collection of 'materials', such as 'instant noodles', 'half-filled wine bottle' and 'mug'. Mug's my favourite, good times making the glaze reflect properly.

Old grayscale bust from last year.

An exercise for the Game Art Course from last year. A bit narrower jaw then the example I copied. Liked doing the ears, enjoyed those. Call me weird, I don't care.

Emergent Game Interfaces: Day One

Right, so for this course we are a 4 man team. Myself, Brecht, Philip and Arthur. Today we had an introduction and started discussing ideas for what we would be making.

Personally the most interesting were a game where player's phones would act as battleships in a game, and a game where people would walk around and listen to audio, trying to find a 'place' that matches a certain description.

Here's a list of all the ideas, in case you were curious:

1. Digitised Ball Maze.
2. Diving Experience
3. Phone battleships 
4. Lazetag
5. Makey makey, make an environment using sounds (+ crazy lightling?). VR make environment out of sounds.
6. Walk around and find soundscapes, emotion.
7. Drawing by walking around, collaborative drawing by placing dots.
8. Awkward makey makey touching.

I'll be discussing some ideas in later posts, as the research continues.

CommandLine v4.0 | Getting into it.

After messing with different systems for commands and asking help where I can, I've found that the best solution is to assess my own ability and keep things real. Keep it understandable. All the systems we (My friend and I) have come up with are essentially more complicated versions of checking if a word that was input by the user matches the next word of a command.

As such I started work on v4.0 with the intention of making it a understandable, rigid system, and start work on the rest of the game to see how it plays. Surprisingly it's the most promising command system so far, partly because I can understand it in it's entirety.

The work continues.

CommandLine | Day 9

Time flies. 

So since the pitch I wrote over a week ago I've been working on making a quick proof of concept.

First was my own attempt, which I quickly realised was very inefficient. I was satisfied with my UI and interface, and the concept was slowly taking shape: a battleship game that was more of a crew simulator, with the player issues commands and talks to his/her crew by typing them into a command prompt, much like ye olde computers. However, the scale of the project I envisioned became quite daunting, and I quickly asked my friend Nicolas, who is a way better programmer than me, for help.

CommandLine v1.0

It's in this version that most experimentation happened, like keyword-based commands vs rigid strings, something which I may still want to implement;

The impressive thing here is that it would get the actual names of functions from a 'commands' script, and it would check the string entered in the InputField to those. the code itself became the list of commands.

After a few days of work I started anew, fresh and with the knowledge I gained from v1.0, I started work on v2.0 with a focus on getting the commands read through lists and the unity inspector. A completely different approach to v1.0.

 

By making a class 'words' and it having a list of itself I could simply make branches of words, making a sentence. Dialogue or command could then be checked and (this is where I realised the difficulty of what I was trying to do) run a function with some variables.

This worked very nicely, but at this point I just asked Nicolas to go ahead and write me some code, which he did almost instantly.

That brings us to the current v3.0, which is based on Nicolas' code and that I will be building upon to get the command and dialogue system up and running. Something about tress and delegates and stuff. SuperTree.

Here's to collaborations.

KDR Sunday Scrim | Desinging Advertisement Poster

Our HAWKEN clan is going trough some changes, and because I want to attract new people to join our open training I need to advertise. That's the purpose of this poster.

Using in-game screenshots and google image-search explosions (if you know good royalty-free alternatives, please let me know), Image edited in Photoshop and text in Illustrator.

Original screenshots:

Pitch: Text-Based submarine battle

You're the commander of a sub fighting an under-water war. You must use commands to, well, command your ship, and communicate with your crew to take out the enemy ship. This to make information gathering and the giving of commands integral part of the game.

Modern games where you are supposed to fly large aircraft or warships with a crew it's played as if you're all alone, with hotkeys and your mouse to aim and fire all weapons. This game gives you a crew to manage and give orders to.

2 player, competitive.

Screen is nothing but a text prompt and a 'sonar' radar screen that you can 'pulse' to get the locations of objects around you.

Example Game:

List commands
- accelerate/decelerate
- rotate (degrees*)
- scout
- locate
- fire (weapon)

Accelerate 10
- accelerating from 40 to 50 knots.

Scout
- Enemy ship 30*, 200m

 Rotate +60
- rotated +60*

Scout
- Enemy ship  90*, 210m

Locate Engine
- Engine located

Locate firing bay
- Failed to locate firing bay
- Enemy Fired 3 Torpedoes, 205m, 6 sec to impact

Commands
- accelerate/decelerate
- rotate (degrees*)
- scout
- locate
- fire (weapon)

Decelerate 20
- Decelerating from 50 to 30 knots

Rotate -90
- Rotating -90*

- 1 Enemy torpedo hit, 2 missed
- -20 health to hull

Scout
- Enemy ship 180*, 250m

Rotate+90
- Rotating +90*

Scout
- Enemy Ship 90*, 260m

Locate Hull
- Enemy Hull Located

Fire Torpedoes 3, Hull
- Firing 3 Torpedoes at enemy hull, 255m, 6.5 sec to impact

Accelerate 20
- Accelerating from 30 to 50 knots

Scout
- Enemy Ship 100*, 250m
- 2 torpedoes hit Enemy hull, 1 miss

and so on and on