Refinement and Elaboration

One of the main problems I find is my ideas sound falsely amazing, simply for the fact they are so sketchy; the mind simply fits in the impossible blanks with enthusiasm and delusions. This post is me trying to refine or deepen my understanding of my own idea.

Let's start simple;

It shall have a background.
The background will be as tall as the screen, and as wide as the level needs to be ('X'); If X is wider than the screen you will be able to move your mouse over buttons to the sides to scroll along to the extents either way.

It shall have an 'Inventory'

The inventory will most likely be at the bottom of the screen - It will contain an icon (or something similar) of a selection of items available at the beginning of each level. These inventory items can be placed on the background and interact with other placed inventory items and objects already placed on the background at the start of the level items can be removed from the background again and put in inventory. Items already placed on the background will be locked in place, whereas inventory items can be dragged about/rotated and such. (basically the only difference between the two)

It shall have 'Function Box' items

A large majority of the pre-placed items and inventory items will be objects which act as function boxes; they will have input(s) and output (s). As a general rule, In order for the outputs to be functional, all of the inputs must be filled/met. for example; if a function box has two inputs, and one output; both inputs would have to be connected to something in order for the output to work. There will be different types of function boxes which will have different functions; there might be a splitter, which allows two outputs from one input, and a joiner which allows the opposite. from there it depends what you could have function boxes doing; for instance, you could use colours; which would allow function boxes to change colours of inputs/outputs, or you could use input strengths. colours I foresee being more straight forward for players.

It shall have 'Wires'

Wires will act much like electrical wires; connecting different inputs/outputs of function boxes and transmitting information. Wires will be included (unconnected) on the function boxes; this will allow players to simply join/disconnect the end which isn't connected to somewhere it is needed. Wires will have set lengths (whether it is per function box, or just one global set length); creating an extra constraint needed to be overcome by players. wires will automatically snap back if not connected to anything.

It shall have a 'start hub(s)'.

The starting hubs will provide the 'power' in each level, they will have one or more powered outputs (possibly of different colours/types if needed) and will be a static already placed item.

It shall have a 'end hub(s)'

The end hubs will be how the game is won - they will have one or more inputs, which once all are activated/connected correctly, the level will be complete. As with the starting hubs, the inputs can be of different colour/type requirements if needed.

Other possible funky things

• Different energy transferral; e.g. from 'electricity' to lasers to 'electricity' again
• Obstacles - means you would have to position function boxes better to allow wires to reach.
• More stuff here.

So yeah, I'm quite happy with the plan so far... What d' you think?

Try not to become a man of success, but rather try to become a man of value.

- Albert Einstein

This dissertation project is all about learning and becoming more valuable. I thought I'd list some things I will need to learn or overcome with my current plan (such as it is).

• Javascript/C#;
• Using Unity as a 3D game engine (or for a high percentage of the time);
• How to create a base class or script which everything else runs on;
• Loading/cycling levels;
• Creating all (or most) objects dynamically (opposed to having them already placed in the editor);
• Adding objects inside other objects dynamically; complete with positioning, rotation and other such goodies
• Dynamically creating physics based rope with length constraints (Using Physics hinges, maths and such);
• Subclasses (objects take on some properties of others);
• Object dragging/dropping/snapping(mouse);
• Transferral of variables/information through connected of objects (and termination);
• Removal of infinite loops;
• Coding UI/menus;
• Scrolling;
• Control of lighting/objects through code (position/brightness/colour);
• Pre-loaders (possibly in terms of sub-loading);
• Designing my own mechanics (that work);

As of yet that's as much as I can think of, but I do not yet fully know the extents of what this project might entail for me.

Time to Rework. AGAIN

I talked with Chris yesterday, and we decided that instead of doing a project which mostly revolves around art, and code, and lots of other stuff (and basically over-scoping drastically... Have a project which is mainly code (or has a large, hard to do code part) as its base instead, and fit in other stuff around it.

I've got to admit, I'm quite disappointed, simply because very close to this discussion I had found possibly the most interesting and applicable reading(s) I've found to date:

Carson, D. (2000) Gamasutra, Environmental Storytelling: Creating Immersive 3D Worlds Using Lessons Learned from the Theme Park Industry. [Online] Available at: http://www.gamasutra.com/view/feature/3186/environmental_storytelling_.php [Accessed: 23 October 2012].

Carson, D. (2000) Gamasutra, Environmental Storytelling, Part II: Bringing Theme Park Environment Design Techniques to the Virtual World. [Online] Available at: http://www.gamasutra.com/view/feature/131593/environmental_storytelling_part_.php [Accessed: 23 October 2012].

I literally want to be this guy.
He talks about practically everything I was trying to convey in my last post, and more - but never mind: rethinking is for the best. Perhaps The readings will come in useful at some point.

---

Anyway; the new direction of my project is still in the direction of a Unity game - but instead of focusing on mainly theme, it will be on code.. for this reason; most (but not all) of my readings have changed;

===

Goldstone,W., 2009. Unity Game Development Essentials. Packt Publishing.

(Previous Readings)
This book looks very useful as it covers all aspects of Unity in good detail.  HUD creation and object collection in chapter 5, particle systems in chapter seven... Actually, Yeah; I am definitely going to read through large parts of this book as I believe it provides a good groundwork of some of the main aspects of unity I may not know so much about.
Additionally, while Googling for the picture on the left, I found an Ebook called "Unity 3.x Game Development Essentials" by the same person. From what I've read, it seems to be an updated and expanded version of the book for the newer versions of unity.

Goldstone,W., 2011. Unity 3.x Game Development Essentials. Packt Publishing.
===


Mernard, M., 2011. Game Development with Unity. Course Technology PTR.


(Previous Reading)
I borrowed this book from Ross temporarily (he needed it more than me and there was only one copy) this book is very good as it covers making games in unity as a whole; this means it goes from concept, to working around unity, scripting, UI, particles, music and more. I may not need some early chapters in the book, but I have a feeling I will need most of the later ones.

===

Gerasimov, V., Kraczla, D, 2012. Unity 3.x Scripting. Packt Publishing.

This book is by the same publisher as the ones by Goldstone, so I'm hoping it's going to be just as good. From what I've read, it seems to require some previous understanding of unity scripting (or at least how to start-up with unity scripting) so it may benefit me to read some of the more basic books I have found before reading this one. Chapter four, depending on exactly what I want to do may prove very helpful as it covers inventorys in unity. Other areas of interest are GUI, and AI. How much I can use may be limited form this book as it seems it makes a fps shooter, which is very far from what I'm planning to make.
===


Brownlow, M., 2004.Game Programming Golden Rules.Charles River Media.

I picked up this book instantly as it seemed just what I needed. This book is full of tips for coding. unfortunately  most of it is not for the languages I use and/or it is for far more complex things such as projects you code from scratch (instead of using a unity engine or other such things) I'm kind of disappointed but I'm pretty sure I can find something which will benefit me in this book.

===

Castillo,T., Novak,J., 2008.Game Development Essentials: Game Level Design. Delmar Cengage Learning.


I got this book for my old project idea, but it covers all aspects of level design and the thought and concept progress, so although it may not be as applicable as it used to be, the early chapters (1-3) for concepting and designing should be of use.




===


Moore, M., Novak,J., 2008.Game Development Essentials: Game Industry Career Guide. Delmar Cengage Learning.

I got this book because I was on about how I had not much of an idea of what i wanted to do when I'd finished uni and the good thing is it should be useful for whatever I decide to do for my dissertation - and perhaps improve it in the areas I need to in order to get a job.




===


This seems like a fantastic read which would go well, or help vastly with almost any game design project; This book as some great insight into how to make a game fun to play and how to polish a game very well. chapter 14 may also be very useful for our group project this year. Most of the book interests be including but not limited to inputs, responses, mechanics and polishing.
I think it may actually help improve my games, rather than just expand my knowledge; which I think is probably a good thing.






===

Adams, E. (2011) Gamasutra,The Designer's Notebook: Eight Ways To Make a Bad Tutorial [Online] Available at: http://www.gamasutra.com/view/feature/134774/the_designers_notebook_eight_.php? [Accessed: 31 October 2012].

I plan to do a game which gently eases players into several retentively new mechanics, progressing in difficulty; people always seem deluded that a good tutorial is an easy thing to do, but it clearly isn't judging by all the flash games I've played in the past. This reading should be a good guide for doing a good tutorial; or at least what not to put in a tutorial; which is a good start.

===

Possibly More readings to come (actually, its probably vital I get more).

Anyway; My new dissertation proposal is a 2D rendered puzzle game in unity - The basics of the concept is to transfer "energy" (whatever it may be) from one side of the screen to the other using wires. There will be several things stopping you from doing this; the first will be the lengths of wires given to you. This means you will have to go through several "stations" along the way in order to reach your goal. the second thing stopping you will probably be "station" size or capacity; this means you'd have to split your "energy" through different stations and regroup it at the other side. Although the mechanics are a little sketchy at the moment, they are a lot more solid than what I had before. other related mechanics might be colour coded wires/stations, "energy" transformers/reducers, and other ways of transferring "energy" from one place to another.

What sets aside this idea from the other is that it is highly code based; it gives me the chance to deepen my knowledge in code while making an interesting concept and/or a game.

This concept derived from a simplification of a few mechanics that I found elsewhere;
the first was from a game called crazy machines: crazy machines is a puzzle based Rube Goldberg game; you can use pretty much anything to solve an incomplete Rube-Goldberg machine. my focus was the electrical components,as you simply drag and drop plug sockets from one place to another in order to link them. It's an interesting concept but it's a minor part of the game which hasn't been explored to its maximum potential.

Crazy Machines: Wire component of the game.

The second spurt of inspiration was from programs that use Node editors; primarily UDK texture editor and FilterForge editor;

Example of UDK node texture editor

Stylised version of the filter forge node editor.

These examples are simply node editors; but I've spent a while using them through my time making textures and you find (unless you know exactly what you're doing) that using them becomes a puzzle - you know what you want, you know roughly how to do it; but finding the right boxes and connections which give the result can be a real thoughtful/addictive experience.

The third and final inspiration for a node game is from the flash game "tentacle wars"; the aim of tentacle wars is to manage the size of your tentacles by connecting them and fight off the opponent; the fighting is irrelevant to me, but the mechanic of dragging connections and transferring a form of energy is.

Tentacle Wars

Anyway, this post is far bigger than I originally planned, So I'll stop otherwise nobody will read it.

Fear is only as deep as the mind allows.

I've been thinking long and hard about what I want to do for my dissertation; and I think I've honed in quite a bit from where I was before;

-----

• I want to make a Unity game (as my chosen readings may convey) this is for several reasons;

             A. Unity is becoming increasingly popular on-line in terms of gaming, and Unity allows creation of game on other devices such as Phones; this is a very nice gateway to expand into for the future. (more information on Adobe vs Unity is available here)

             B. Unity allows creation of 3D games; I have done a lot of modelling for mods and other projects through the years (both for university and in spare time) but I don't think I've actually made a proper game.

             C. Unity needs code like any other program; But I've spent most of my University life mashing buttons in Actionscript 3.0 - it would be good to expand to other languages (which unity allows for)

             D. Despite my moaning, and the extra parts of the pipeline needed for 3D projects... I enjoy it considerably; I just need to know it better and get faster at doing it.

-----

• I want to make a heavily spooky themed game;

             A. Spooky is fun. AND it's nearly Halloween.

             B. I'd like to think I can do spooky; my pride an joy was a short Gothic-Horror story I wrote in high school - I've never been any good at putting things on paper, so when poor borderline C/D-grade Sean hands in a high-B-grade Gothic horror story; he gets pulled in for possible plagiarizing (Falsely, obviously).

             C. I spent a lot of time in Themeparks when I was smaller (lol); Usually (but not always) the spooky themed rides/areas were done the best. This wasn't because random things jumped at you though - It was because of small details; The fibreglass crypts that were ajar and pouring smoke, Or finger scratches on a wall. The sudden appearance of a monster with flashing eyes was only the tiny punchline in the huge work-up before it. I believe there is a certain type of enchantment in an excellent themed work-up like that.

             D. additionally to C; The best fear is the ones created by the player themselves; Michael Thomsen briefly touches on this in his article "Revival Horror: New Ideas in Fear-Making"; "The things they begin to fear most aren't the resuscitated burn victims with scissor fingers lurking in the next room, but rather some vague agglomeration of their own worst imagination. To have touched a player on the terms of their most intimate insecurities and fears, rather than forcing them into the whirligig of an auteur's invented phantoms, is one of the most delicate and rewarding achievements in game design." Thomsen(2010,p2).

-----

• I want to make a first-person game which isn't a shooter.

             A. There are too many Unity Shooters out there; 50% of first page here when I checked  and I'm sure other places have similar stats.

             B. Most horror games are shooters, and even though I want my game to be spooky and not horror, I feel the same still applies.

             C. If I am carrying a highly effective killing weapon... What is there to fear?

-----

Anyway; I made a couple of test assets, testing out my skills and Unity's;

This is what it actually looks like on the other side of the wardrobe. (hilarious lamppost reference)

I was thinking about different mechanics I could have; there was typical mystery/clue finding mechanics, then there was lock and key exploration... and THEN I thought that I could do an 3D avoider game.

Okay, that may need some explanation.

Basically, I was thinking about doing spooky exploration, then you suddenly (reason yet decided) start hallucinating and get taken to a strange area themed on the place you were. the area would be a simple "get from point A to B" game, but you would have to avoid hallucinations of objects in the area you were in (e.g. giant swinging grandfather clock pendulums) I'll be perfectly honest, that seems like a massive, not entirely thought out, over-scope. BUT it does sound a little further away from first person horror exploration which is basically Ross' "exploration of immersion in games" dissertation idea (found here) (which I am proud to have helped give birth to, yet don't wish to stomp on.)

Think I might need help and advice from wise people such as Rob for direction; I could spend a whole year deliberating, when all I really want to do is start making horrible, regrettable mistakes.

Thomsen, M. 2010. Gamsutra, Revival Horror: New Ideas in Fear-Making. [Online] Available at: http://www.gamasutra.com/view/feature/134160/revival_horror_new_ideas_in_.php [Accessed: 19 October 2012].

Books Glorious Books!

Goldstone,W., 2009. Unity Game Development Essentials. Packt Publishing.

This book looks very useful as it covers all aspects of Unity in good detail. Chapters of interest include terrain creation in chapter two (and height/light maps), HUD creation and object collection in chapter 5, particle systems in chapter seven... Actually, Yeah; I am definitely going to read through large parts of this book as I believe it provides a good groundwork of some of the main aspects of unity I may not know so much about.
Additionally, while Googling for the picture on the left, I found an Ebook called "Unity 3.x Game Development Essentials" by the same person. From what I've read, it seems to be an updated and expanded version of the book for the newer versions of unity.

Franson, D., 2002. 2D Artwork and 3D Modelling for game artists . Premier Press.

For some reason on my trip to the library I managed to pick up the thickest book they had. Despite it's size, the book is full of step by step tutorials of the pipeline of several areas of creating assets for games. Part three of the book is of great interest to me as it covers making textures for both organic and inorganic models in small steps. unfortunately, despite it's size, the book seems to cover easy things (which I'm likely to already know) in insane detail, and the more complicated things are either small "tips" or about programs or steps I would never use. After sifting through everything I'm sure I can find many interesting things I didn't know before.


Ahearn, L., 2008. 3D Game Environments. Focal Press.

This book is very interesting; I'm a bit concerned about it's layout (it starts with optimizations to work, with complex vocabulary) and then goes into introductions. Saying that, the optimizations may come in very handy further through my project.Chapter 3 is interesting as it covers shaders and materials in good detail, and chapter 8 and 9 cover natural environments which I may touch on quite a bit in my project. the book doesn't have as much in terms of tutorials, but it focuses more on tips to make what you have look professional.

Mernard, M., 2011. Game Development with Unity. Course Technology PTR.

I borrowed this book from Ross temporarily (he needed it more than me and there was only one copy) this book is very good as it covers making games in unity as a whole; this means it goes from concept, to working around unity, scripting, UI, particles, music and more. I may not need some early chapters in the book, but I have a feeling I will need most of the later ones.

The Journey Begins

Welcome to my new blog covering everything there is to know about my dissertation for my third year on my computer games design course.

I have been thinking about which areas of the course I wish to explore in greater detail or embark into for this year of work. It seems stupid that for a project I can practically do anything about (within reason) is the most difficult to decide what to do, simply because of the sheer amount of choice available, and the breadth of the skill-set I seem to have acquired over the past two years.

The obvious choice to make would be to do a code-based dissertation project, as this is one of the areas I have expanded upon the most throughout the course. I have spent  considerable time improving my skills at Actionscript 3.0, to a point where I am quite proficient in using it; Doing a project in Actionscript 3.0 for the third year would be turning over the same stones yet again, and wouldn't really be utilising or expanding my knowledge as much as I could (although I haven't ruled out re-thinking my complex/broken node/number based game I came up with a while back).

Anyway, the simple fact is, that although I enjoy the accomplishment of some working code after a few hours of working on it, I really don't want to spend the whole of the third year staring into the matrix; that's just not fun or enjoyable, and possibly quite demoralising.

This is what I see.

I have quite enjoyed modelling throughout the years, and I'd like to think I've gotten quite good at the geometric side of it; unfortunately my texturing and UV mapping skills aren't that great at the moment which is something which I'd like to improve on. I did think about modelling, rigging, UV mapping texturing and animating a character and implementing it into UDK. in short, this task was advised to be too big (I think I'm glad at this point) and that I'd use my time better if I explored a more simple program I already knew of more fully (rather than a tiny bit of a hugely complex program)

Then I came up with an idea of creating a game in Unity - Unity is less complex, relatively new to me, but becoming increasingly popular on-line against flash gaming. Creating a game in Unity requires many skills; which include modelling, texturing and coding, which are the main areas I wanted to broaden/improve/deepen.

As for the distinct direction or focus of my dissertation/unity game... I'm still deciding EXACTLY what that is I have a feeling readings might help.