Back to "Work"

I know my previous post was only yesterday, but I thought I would show you what I managed to do in the couple of hours I've been awake. I mentioned earlier I had planned on paper the 'AutoTile' feature I wanted for my map editor and it really helped with the amount of time it took to code this:



As you can see, just by placing Water\Ground tiles the editor automatically fills in the edges for me so I don't have to. I know there is no pretty UI at the moment. But because I rewrote the engine, I haven't implemented it fully yet. Well enough to be of any use for this.

The way this works is pretty simple. The map consists of 4 layers, which only 2 of are used in the video. Layer 0 represents ground data. In this case only grass and water. Layer 1 contains edge data, which my "auto edge" function works out based on the ground tiles in use. To save memory, only Layer 0 is required to have valid 'Cells' loaded at all times. So when you see no edge, that means that the cell on the Edge Layer doesn't exist. In other words == NULL.

You might have noticed some choppieness when I started to tile. This is because at the moment, my resource manager is loading images on demand. Just as before, if the image has already been loaded, it is found and a pointer to it is returned instead of loading the image again. I can fix this by having the map load all the images it will need before hand, but I will get to that later when I reimplement my map loading feature.

Well this was just a quick update to let you know I'm still working!

Living up to the blog title...

I don't have a very good reason for why updates are lacking. In fact the only reason was the arrival of my birthday and then a couple of dats later Final Fantasy 13!
So, after managing to put 80 hours of last week into the game, I've almost 100% cleared it. I don't usually play games like that, only the ones that deem worthy to steal my life.
I really enjoyed the game, despite how linear it was. The story was good, not the best, but enough to make me feel something for the characters. Althoguh the ending I had to watch twice to get my head around what exactly happened.
The new battle system is nice as well, although a little easy once you get the hang of it. But it's fast paced and flows well, unlike most RPGs that don't have real time combat,

Anyway enough of that game, and more about mine I think. I really wanted to have another video ready for this post but alas I have been lazy and only now decided to open up Code::Blocks and pick up from where I left off.
How ever after my last post, I decided to re-write the whole 'engine' and am still in the process of doing so, so if I showed you a video now, the best I could probably do is something like my first post.
The reason I decided to re-write it is 2-fold. One because I didn't like the coding style I was using. As the project grew I was confusing myself a little bit. Secondly because I was programming elements that just wouldn't be needed. Mainly the GUI... Yes the window things were nice, but I will never use them in my game. From now on I will spend less time on gimmicks that are cool, or I think "That might be useful later" when in fact it wont and code only what's needed. I have a very good idea of what the game entales now, as I have spent a lot of time jotting down notes, and drawing up charts while at work (yes it's boring and empty in the bar I work in).

My next post will have something nice to look at I promise. I actually hand wrote the code for the map editor "auto-tile" feature which I will get working asap (if you remember I was going on about this in a previous post - it's something like the Advance Wars editor when you place grass\water etc...). I have also spent some time on drawing up some sprites that I'm quite pleased with :P So until next time, thanks for read. Ciao.

It speaks... Well, writes...

For detailed changes click here.

After all my work on the GUI, I got a little bored of it and decided to work on something with a little bit more meat and could actually be finished quickly. So I chose to work on my RPG-esque (actually it's near enough a complete copy) TextBox class. It was only after a few hours of head ache I realised this was just another form of GUI and wouldn't be as easy to implement as I thought. If you don't know what I'm talking about, check out the example pic below from Zelda Ocarina of Time to get an idea.

I wanted to implement a flexible TextBox class that very easy to get going when I wanted to display it. It needed to do the following:

• Adjust it's height based on the amount of lines I wanted to display (and shrink if the text was smaller than that amount)
• Take the whole text as one single string (not line by line) and be able to calculate how many lines there would be based on font width
• Have support to colour characters\words\sentences through html like tag system within the text string
• Have support to change the font of characters\words\sentences through html like tag system within the text string
• Have support to force a new line when needed
• Image support, either right\left aligned
• Text alignment - left \ centre (I did right as well but it looked crap and I will never use it so it's removed)
• Display text character by character based on delay time
• Speed up the character by character delay by holding down a button
• Display a whole line in one go without the effect of character by character

So yes, I wasn't asking to much... Especially since I haven't really worked with strings before to this extent. In fact the only thing I've done with strings in the past is assign them and display them (and maybe check their width). So it was quite a nice little learning curve. Check out the latest vid below to see how it turned out.



As you can see I've got everything I wanted apart from the image support (which is coming!) and I'm pretty happy with the results. At the moment it really does feel a little un-optimised though. For instance to prints this text string with the word "RPG" being red and in a different font and adding a new line before it I would type:

"/n<red><f>RPG<-> Text Boxes are more hassle than they look..."

When the string is parsed, new line symbols (/n - not \n) are removed and the text width is calculated by stripping the tags and then re-adding them after. Only during the drawing section of this text are the tags evaluated. Which seems wrong, because during that drawing, the logic is also reading the string character by character. I tried to find a smart way of doing this only during the logic cycle but couldn't come up with anything other than creating another array the same size as the string and keeping information about the tags on a per character basis, and that really did seem like more hassle than it was worth.

It works though which is the main thing, and with clever use of the:

int al_color_name_to_rgb(char const *name, float *r, float *g, float *b)

command in Allegro 4.9 my textbox now supports all these colours with just one simple routine. Yes I am really grateful for the hard work the Allegro Devs do, because it's introducing commands like those that make life a lot easier. I hope one day I will be good enough to contribute something back.

I think that's enough of me going on for one post, so I will leave it here. My next major task is going to be cleaning up my existing code, and completing the Map Editor to 100% or near enough. College finished early today and I thought I would spend the time in the library fleshing out my game design, so now I'm pretty certain what I will and won't need which can only be a good thing. I would like to talk about the game more, but I really would like to have something to show about it first.

Thanks for reading =)

Getting there now...

For detailed changes click here.

I am pleased to say, my map editor is almost 100% complete. I’d judge it at about 85% considering I can’t add the actual “Game Entities” yet until I’ve actually programmed them. But I’m also happy because when it does come to implementing them it should be a piece of cake, I am really starting love my GUI system now for ease of use. It’s basically a onetime set up and it handles itself! The only thing that is a bit annoying is all the call-back functions, even though they normally 1 – 3 lines of code, they are many. One for every element anyway. I don’t like them because they are a pain to name nicely, and they seem messy. But I guess that is just how it has to be. (I just watched the video and found some more bugs, you will probably see them, guess that is what I get for opening my mouth :P).

Since my last post where I listed the changes I had made within the GUI I thought it would be a good idea to keep a sort of “change log.txt” for every post. I won’t fill out every post with it, instead I have made a quick post before this one which I will keep updating with every new post I make. The log will indicate what I have gotten done from one post to the next. For some reason it also helps me come up with what I should be doing next which is only a good thing! There is a link on the right to the change log, but I will also put it at the top of every post just so I don’t have to point it out all the time.
I’m not going to go into any great detail in this post because my last lot have been way to long, but take a look at the video below and you can see how far it has come in just a day, or two, I can’t remember if I posted yesterday or the day before now... Anyway, to the eye candy!



Because I haven’t talked much, if at all about what type of game I’m making you might wonder why I only have 6 different cell sprites. Eventually, probably by the end of next week, each sprite will hold a lot of different types of the same sprite that the editor will choose randomly. Obviously I’m not going to keep them one colour, but they represent what they are meant to be, grass, mountain, water, tree etc... I’m going to use the editor to do the work for me when it comes to mapping as I’m too lazy to fill in all the corners of a forest, or make the mountain flow... Hope you get what I mean, I can’t really explain it without a picture or a video of it, but imagine Advance Wars map editor, when you lay down grass there it automatically fills in the edges for water, sand, trees etc...

Another thing I need to add is the selection of different size of maps. Earlier today I had 2 text boxes which let you set them yourself, but since my game won’t need that attention to detail, I’m going to add buttons for a small\medium\large map when creating a new one which will suffice.

God this is getting long again, well until next time, if you can’t be good, don’t be.

Change Log

Log is kept in sync with my posting and indicates all the work  I have done. I try to put most of it anyway. The boring things I leave out.

v0.0.06 - Post: 02-03-10
````````````````````````````````````````````````````````````````````````````````````````````````````
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.
    - Supports any dimensions (height generated from text, and number of lines required. Box will
        scale down if the num lines required is less than it needs to display)
    - Supports <html tag> like symbols within the text string itself to denote certain colours and
        fonts for different characters witihn the string
    - Text cannot be skipped until the required number of lines has been shown, however it can be
        sped up a lot by holding down choosen button
    - If no title is supplied it is assumed the "per character drawing" is not needed as speech and
        prints whole line straight away.
* Added TextBox to GameState class, it is assumed most\if not all will need to display one


v0.0.05 - Post: 27-01-10
````````````````````````````````````````````````````````````````````````````````````````````````````
* Added GuiObj support via vector in GameState class (moved from just the MapEditor as it is deemed
    all classes will need some sort of GUI).
    - GameState clean_up() also responsible for removing any memory inside this vector during
        derived class's clean_up()
    - Add individual functions for calls to the GuiObj input, logc, draw routines. Due to the fact
        all the code will be identical for each derived game state. (The extra code, other than
        calling those GuiObj functions is just so we can keep track of the active menu and make
        sure it's drawn last, it's input is taken first (even when it's above another menu).
* Added font support inside the GameState class through an array. Named at the moment Main Font,
    Header Font, Gui Font. Can always add more support later. Clean up of fonts done in GameState.
    - Also added load_font(int font_id, std::string font_name) for convinience when checking if
        a font loaded, and so I dont have to type the path for the font all the time. If function
        fails, initialisation for that state fails, as font is considered "Primary Resource".
+ Text class created - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
    like colour, transparency etc...
* Replaced header guards with #pragman once since it's sexier.
* Changed filename format from lower_case.cpp to SexyStyle.cpp (49 of them >.<)
* Added transparency support to Sprite class.
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
    input, but rather it's callback function.
* Windows can now be locked in place
* Added "reset position" button inside Window title bars (optional)
* Added GuiObj Menus to MapEditor
* Implemented New\Save\Load map functions - (still need to get those dialog boxes in a new thread)
* Can now "paint" map with selected sprite and type
* Added support for buttons to call their callback function just on one "click\press" or while their
    "held\pressed"


v0.0.04 and below & Complete Class Listing (Anything bulleted with a + is after 0.0.04)
````````````````````````````````````````````````````````````````````````````````````````````````````
* Console class created  - For debug purposes, can be written to and viewed in-game
* Text File class created  - Handles the opening\saving\writing to
* System class created  - Responsible for setting up allegro, installing addons, creating display
* Keyboard class created - Handles all keyboard input through Allegro event system (global)
* Mouse class created - Handles all mouse input through Allegro event system (global)
* Engine class created - Responsible for main game loop, handling game states and events
* GameState class created - Base class for all game states, has all the stuff a typical gamestate
    might need
* BaseObj class created - For all objects to derive from who have an x,y,width,height
* AnimObj class created - For any class who wants animation support (graphical or not)
* Sprite class created [BaseObj, AnimObj] - For any "graphical" obj to derive from. Handles
    rotation\scaling\transparency etc...
* Image class created - Loads an image from disk, stores its name and path
* ImageManager class created - For the GameState class, takes care of making sure we only load one
    image of the same name. Responsible for loading\unloading images. Has a vector of Image class
* MapCell class created [Sprite] - A single cell which as a group makes up a map
* Map class created [BaseObj] - Has a vector of MapCells for dynamic maps, responsible for drawing
    the map, scrolling (built in camera functions)
* GuiElement class created [Sprite] - A single GUI element responsible for its own input, drawing
    (through base sprite class), and logic (Pure Virtual class)
* GuiObj class created [BaseObj] - Stores GUI elements inside a vector. Responsible for group action
    via input logic and drawing for these vector members.
* Button class created [GuiElement] - Simple button element, calls callback function on mouse click
    or keyboard input (1 + Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.key)
* TextField class created [GuiElement] - Takes input from keyboard, returns value in requested
    format
* Window class created [GuiObj] - Adds functionality to the basic GuiObj in that it behaves much
    like any window you've seen before... kind of
* MainMenu class created [GameState] - Main menu for game (empty at the moment), use F keys for
    debug, swap state)
* Game class created [GameState] - State for the main game (empty at the moment)
* MapEditor class created [GameState] - As the name suggests. Used for mainly test purposes at the
    moment.
+ Text class - Wrapper for Allegro equiv draw_text\f functions with some helpful additions
    like colour, transparency etc...
+ Label class create [GuiElement] - Like a text box, but the value inside cannot be updated via
    input, but rather it's callback function.
+ Created TextBox class [BaseObj, AnimObj] - Behaves much like any RPG message box.

GUI Fun

I know my last post was only yesterday, which doesn't mean I don't have a life, although that may be correct... But anyway I believe I have enough of an update on the GUI to show you a little more. I also found some really nice site which lets me highlight my C++ code just using css and html so I am able to share some snippets with you to help explain what I mean. In the future I may even write some tutorials depending on how confident I am the way I do things is something I can pass on to you without feeling a little guilty =p



(Skip to the bottom for a summary of the GUI features so far, I know I ramble on...)
And now you've seen the video let me explain what the heck is going on! I know it would be easier if I was actually talking over it, but (1) My voice is really boring (2) I don't have a mic (3) I probably won't do it anyway cause I'm to shy, or don't want to sound like a retard... maybe that's the same thing, I dunno. Anyway, as you can see I've done away with those horrible icons I was using last time and decided to go for a "default" button kind of feel made using Allegro's primitives. They really are just place holders at the moment until I do get some decent graphical buttons done. The buttons are made from 3 sections, a background rect, a border rect, and 2 highlight lines (ok that’s 4 but whatever), and during this process I had to choose colours for them, so I thought why not add in 3 types of colour every GuiElement can use? That way they can be changed at a later date. The function for changing the colour schemes for all of the objects within a GuiObj looks like the one below. Except the one below is from the derived window class, notice how it doesn't use the same colours as your using for the elements, but changes them slightly.

If you know of a better method to make this process better please let me know, it was just a quick hack to get it in code, I didn't really put any thought into it. The other change you might have noticed me badly demonstrating was Textbox support, or "Textfields" as I like to call them. Now I remember trying to make a similar thing in Allegro 4.2 and it was a pain in the arse, but with the way the event system works in A5 it was a piece of cake! Although I did bump into one issue whereby in the future I want certain elements linked to hot keys on the keyboard. This obviously proves a problem if the user is trying to type and pressing all these keys which might be opening menus, moving the play etc... So I had to work out a way to lock the input when a text field is active, but keep it open to the text field. I managed it by adding a void *pointer inside the keyboard class which I used much like a bool in that if it's NULL the keyboard input is NOT locked. An object wanting to lock the input needs to provide a pointer to itself in way of a form of ID when it comes to checking who wants to unlock it. This was necessary because one text field was fine, but when I added a second, because only one was active at a time the other kept unlocking the input. The other nice thing about the textboxes is that I can choose what input I want to allow, and also the fact you call their call-back functions by pressing enter (which is handy for when to know when to grab what's inside). Well there are a lot of features for my GUI system now, and way to much to go into in detail in a single post. But the summary below should give you an idea.

Gui Element
• Able to customise the colour through (background, border & highlight). Each derived element decides itself how to utilise them.
• Supports a single call-back function. Again the derived element decides when this is triggered, either through it's logic, or input function.
• Tab Index number, used in conjunction with the GuiObj it sits inside. Lets the element know when it is active.
• Can be enabled\disabled
• Has a label (std::string), which has a lot of alignment options (above, below, out-left, out-right, top, middle, bottom, left, right, centre etc..) Again this is optional whether to draw this, per element need.
• Returns a "value" of the derived elements choosing in the correct format, string, int, float etc...

Text Field
• Limits input to what I want it to accept
• Locks all other input while its being used (except for input which ignores the block)
• Has a flashing line to indicate it's active!
• Auto sets it's height for the font in use
• Only accepts as much characters as it's width will allow (might change this, but will eventually add a text box which will be multiline)

Button
• Uses its call-back when either the left mouse button is clicked on it, or the "select" key is pressed on the keyboard (see GuiObj for what that is)
• err... Accepts only single clicks\presses

GuiObj
• Stores Gui Elements inside a vector
• Supports keyboard\mouse input and the changing of how they are used to manipulate it (for example, the "next element" keyboard keys default is TAB, and its default "select" key is "Enter"
• Keeps track of the active element by TabIndex and mouse position
• Elements position relative to the location of the GuiObj
• Has nice "helper" functions for adding elements (see below)

Window
• Has a background, border, title colour attribute which tries to match the colour scheme of its elements
• Can be moved by mouse dragging
• Most of the time stays on top of other windows (need to sort this)
• Need to add “window buttons” (lock back to default position, lock in place, close etc...)

And wow wasn’t that long winded, feels longer for me since that “C++ to HTML” was giving me a headache using the blogger editor, it kept trying to change it! Anyway hope you weren’t bored to much, if you have any questions feel free to ask.

I’m hoping to move on from the GUI pretty soon, I think I have enough to get started with on the editor. Hmm, actually I need to create an element that can store pictures or something and scroll through them for the map tiles. *sigh* Stupid GUI.

GUI & Map Editor - A Match Made In Heaven?

Now I don't no if you have ever tried to make a game using Allegro & C++, but if you have it probably starts something like this:

1. Great idea!
2. Some sort of very rough mental planning
3. Sit down to code
4. Realise you need something to make the levels with because your levels are going cool storing them in a text file just wont cut it
5. Now you realise you need to program some sort of GUI interface because hard coding everything is ugly and a pain in the arse to edit
6. Get bored and realise your game wasn't so great after all

Well, that's my usual pattern any way. If you've been there I feel for you, but luckily for me things are really coming along! I'm not sure if it's the few years break I have in between programming that forces me to relearn a few things, and lose some of my previous bad habits, or if it's just this time things make a little more sense.



The video above shows some of the progress I've made, but doesn't really do it justice. Most of the important things are in the code. As you can see things are very far from being finished let alone polished so forgive the rubbish graphics and let me explain a little bit about how the GUI works, I'll use the moveable GUI Window in the video as an example.

The GUI Window is derived from a GUI Object. The only addition the Window has (you might have guessed), is that it's drawn with a background and title bar and can be moved around. The GUI Object itself has a vector of GUI Elements which it looks after by calling their respective input, logic and drawing routines. When each GUI Element is added to the GUI Object it's given a callback function which is triggered (depending on its own conditions, for example the "Buttons" you see in the video is a mouse click) within either the elements logic or input functions. This keeps everything nice and encapsualted so all the engine has to worry about is calling the GUI Objects input,logic,draw functions. I hope at least some of that made sense, it felt like a right mouthful.

The main aim of the GUI system is so that elements add specialised functionality through the way their callback functions are triggered, and the objects themselves (which handle the elements) can use these to create more complicated GUI Objects. I will have some examples of these in my next update, most likely the scrollbar, which will be made up of 2 GUI Elements, the 2 buttons at either end. I will add functionality for the drawing of the bar and position within the object itself (or atleast that's what I think in my head anyway).

I won't go on about the map just yet, because that's still way to incomplete, but you might have noticed I have the save and load functions working correctly (even if it is only the map name you see changing).

So until the next time, if you can't be good, be careful!

First Footage

Since my last rather strange (looking back now) post, I thought I would share with you something a little more normal. Like what my game is currently looking like. Bare in mind I scrapped what I had of the time of my last post (which is near enough what I have now) and re-wrote all of the code. Since starting again I have actually learnt how to use extern correctly! God knows what I was doing without it before! Things seem a lot tidier now that I don't have to pass pointers through functions all the time. Don't get me wrong I'm not "externing" everything, in fact only my special console class and the keyboard\mouse class's. The console is actually a drop down box which displays text, which any class I feel needs to can write to it. This is mainly for debugging purposes while the game is running. It also saves a nice text file when the program closes in case anyone wishes to see what was happening.

Apart from that amazing discovery, I've managed to get a nice little sprite class going. Below is a brief video of some of the stuff it supports thus far.



To make the game I'm using C++ and Allegro. You can find links on the right if you wish to find out more about both. But as you can see I'm taking full advantage of Allegro's drawing routines to have maximum flexibility with my sprites (it looks jerky because cam studio is only capturing frames every 5ms). So far my sprites support scaling, rotation and flipping as far as image manipulation goes, and also animation.
I'm quite happy with the way the animation is working out so far, but you might have seen it still has a few bugs (the green square!). The way the maximum frames and number of animations is worked out is actually pretty sweet, once the bugs are ironed out I think I will write a tutorial on it.

Also another revelation this time round (I mean me programming again, I usually have around a 2 year gap) is the way my game states are handled. Someone posted a link to a tutorial on A.cc forums, which lead me to this tutorial. I mucked about with the code a bit and shoved it into my "engine" and so far it's working like a dream. I'm a sucker for keeping things organised and I believe this approach is perfect for it.

Well I think that's enough for today, until next time.

Important Questions & First Post Ramblings

Why am I here? No. Not a question I expect you to be asking yourself with regards to this blog, but instead a question I asked myself. I spent what seemed like a life time starring into nothingness. You know the type of nothingness that looks like a wall with a light switch on it and sometimes has a door? No? Well its irrelevant anyway. The point is I wasn't spending my time idly while in this state of “zen", but in fact wondering what I could possibly write that anyone would want to read. To cut a long story short I fell asleep. I don't really remember dreaming, which is unusual for me, since the night time adventures in my mind are usually vivid. I did however awake with an idea for my first post. So here I am at this unsociable hour putting my thoughts to screen because I couldn't risk forgetting it. Well now you know my idea and how it came about (and I believe it's important to know the why of anything), I shall begin.

So, why am I here? First let me define here. I mean the here as in being, as in human being. Why is anyone here? Well I'm not going to go into some philosophical discussion about the ins and outs and the meaning of life, I could go on to explain my theories\facts (depending on how you look at it) but I won’t. In fact I'm going to be totally selfish and talk about me, after all it is my first ever post in my first ever blog*.

So to get to the point of answering that damn question, when I small I had a dream (not the night time type), a dream that would stay with me right up until now, and most likely until the very day I die (assuming before then the dream is not realised, in which case it wouldn't really be a dream anymore). "What is it?" I hear you saying (I almost really do, and for some reason you sound genuinely interested), well, *ahem* well, the dream is simple - I want to make video games! There I said it. No wait! Don't snicker and walk away in disgust. Let me elaborate on the why, remember, it's always important to know the why of anything. I'll try to keep this short, as I understand this post is getting pretty damn long, and if have got this far and you already read the blog description, I apologise for dragging out what that essentially says in little more than 50 words.

 To the why "I want to make video games" then. We're getting close to the heart of the post now, very soon you will be able to witness it beating in all its glory. *Remembers mental note about keeping it short*
I've played games all my life, and like many thousands of others I enjoy them. But to me games are more than just a toy or an object of fun. For me games represent so much more. Games have some sort of magical power much like a film or a book has power. Not all games posses this. In fact to few do, But those that do, can make you weep, cry with laughter, weep again, break something in frustration etc... The point I'm trying to make is games can influence your emotions, much like anything can, but at the same time unlike anything else can. It's that emotional tie to the player games have I am interested in recreating in my own. I still remember waking up in a ruined Hyrule in Zelda: Ocarina of Time and being full or despair at the mess it was in, the immense feeling of revenge I felt when I watched Hazuki Sensei (my fictional father of which the first name escapes me, I think it begins with 'I') be killed right in front of me in Shenmue, or the time I completed Phantasy Star Online with 3 other people around the world which ended in an epic boss battle with music to make your eyes water at the heroicness of it. I could extend the list with endless examples (Aeries dying in Final Fantasy VII for example) but maybe I'll do that another day. But it's moments like that in games that have imprinted a memory inside of me I likely won’t ever forget. This is the why of my dream. The why I want to make games. Not just because I enjoy playing them, but because I want someone to list one of my games in the one I made above, someone to remember, like I have, but about one of my games. If by this time you're thinking I've lost the plot completely, I like to think of it as passion, not madness (and I know your thinking only a mad person would have to say something like that!).

And on a final note, I guess I better include what you can expect to find in this blog in future posts. Actually thinking about it now maybe that should have been my first post, and that alone...

Anyway I'll be using this blog as a place to keep written progress on the game I'm currently working on (as a way to keep myself motivated into finishing the damn thing!), as well as anything else that pops into my mind regarding game development in general. My next post will be shorter I... No I won’t promise, just in case.

I'm in two minds now whether I need to thank you for reading? Thanking you would mean this post isn't actually for the benefit of myself, but of you, the reader, and by that account I would then have to be disappointed if no one ever read it. On the other hand I could not thank you and believe these posts will only ever be for my benefit. Who am I trying to fool? Of course I want this damn post read, I didn't just sit here for an hour writing it! Thanks for reading then!


Someone who thinks too much,
Tomoso

* For the sake of accuracy this is actually my second blog, but I'm ignoring my previous blog for the simple fact I only ever made one post in it.