Showing posts with label Design & Production. Show all posts
Showing posts with label Design & Production. Show all posts

Thursday, June 1, 2017

Using Slack in a very small team.

In preparation for the master we, Sarah and I, have been using slack as our main communications platform. This, as it turns out, has been incredibly helpful, due to the app integration.

Also I didn't want to use facebook chat. Not for "official" business.



Basically, I've set it up so that Trello, BitBucket and Google Calendar are all linked to Slack, and send activity logs to different channels. This makes sure that both of us know exactly what is going on at all times, and that makes communication a lot easier. No need to ask someone to do something, or when a deadline is due, just go to the appropriate channel and see if it's there. Whenever something happens I get a notification.

For example: Sarah pushes an update to BitBucket and moves a task from "To Do" to "In Progress" on Trello. I get immediate notifications from slack that these things are happening, and, without exchanging a word, I know Sarah has finished something and started work on another.

However, it's not just about real-time updates, but also keeping a log of things. This is so that we, in a years time, can look back and show exactly what we did at which point in time, what we discussed during meetings, which builds were shared,... pretty much everting. This can be used during presentations or to show people who would be interested in our creative process.


Using twine for text based games.


 
Complete passage structure.

PLAY THE GAME HERE


The cool thing about twine, that I've noticed, is that it's got plenty of coding potential. This was mostly to explore these possibilities. Below you can see some of the structure involved.

A randomly generated passage.




Adapted from the story written for the storytelling cource, which you can find here:

Go to the full story.

Wednesday, November 23, 2016

Wednesday, October 5, 2016

JamToday 2016 | C-Mine Crib

my second GameJam, I think this one worked out way better than the first one. That meaning that we actually managed to make a game. Always a plus.

Our game was called Gravity Assist and, trying to keep in with the theme of maths, was about using gravity and command-line style controls. This gives the 'space-sim' a very challenging edge.






We had a good team.

Thursday, September 22, 2016

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.

Monday, September 19, 2016

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.

Monday, August 29, 2016

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.



Monday, August 22, 2016

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:

Tuesday, August 9, 2016

Nothing but exploration.

NOTHING ELSE begun as a game idea from my friend: a computer program has to go around and survive. Things like finding a power source, code to eat, data to consume, and output to place. That kinda thing. From that idea and making a quick prototype I started to think about exploration games; Why do they have maps, or a preset world at all? Randomly generated terrains work, but they stay the same, you can return to the same old, already discovered place.

So NOTHING ELSE is only about exploring new places. The world that exists is the screen, anything outside of your vision and intractable area gets deleted, and if you move the world gets generated around you. You could move down a hallway, turn around, and have an open area to move around, or be stopped by a dead end. Go in circles and keep seeing new terrain.

Download here: https://drive.google.com/open?id=0B0OMXC3OytI5VXlHS3NQY0pSajg

Tuesday, August 2, 2016