A Shift in Scheduling

Hello everyone,

I've been reviewing a few of the posts as well as the type of content I am able to put out - and have decided to shift the scheduling to every two weeks rather than every week. This is due to two reasons primarily. 

Firstly - having starting on my Dissertation, I have been spending far more time reading through books and research papers. This might give a lot of topics to potentially write about - however, often times a single post can hardly do it justice. That being said - a post every two weeks does potentially allow for a better quality post on these topics, and it also gives me more time to research the topic before writing about it. 

Secondly - connected to the Dissertation, I have been forced to lower the amount of work I dedicate to game-development related projects. As I am spending most of my mental resources and time on the dissertation; it makes it allows less time, and more importantly less highly focused time, to work on projects such as Foundation of Civilisation. I will still be working on the project - however it will have to take the sidelines for a while as the primary focus is on the dissertation.

Something I have been planning and thinking about for a while was to potentially create a website which can host assets, games and potentially these posts of mine. This has been my plan for a long while - however, I chose to start with this blog to help essentially 'practice' and figure out how to actually make it be of a certain standard and quality. Having a post every two weeks does help contribute to this point - as it allows me to hopefully give more time to each post, and raise the quality itself. I will be continuing to look into this in my free time the coming weeks.

Until next time,

Dylan

Open Development

Hello everyone,

Recently - I listened to a talk by the developers behind Desktop Dungeons discussing their approach to developing Desktop Dungeons, what they called Open Game Development. The approach involves bringing in the general public and those interested in the game - as early as possible. 

This is not to be confused with Early Access - the point here is to have your prototypes available to be played, and feedback to be given to you as the developer to use to guide your decision-making. The benefit here is that since payment for the prototype would not have been issued - there are less issues with you changing direction with your project completely - since no one has paid for the product; and at the same time, as the developer - you are more free to discuss potentially very different ideas with the player base, try ideas, and keep them or remove them should you so choose.

The speakers spoke of a number of benefits of taking the approach in terms of marketing and gathering interest. Stating that the prototypes can act as a type of demo later on - when you choose to release the final version for purchase. They also mentioned that one needs to be ready to both say 'no' and also try to understand exactly what issues are; rather than treating symptoms - you figure out the cause of a problem that seems to be continuously coming up from feedback. 

I highly recommend the talk itself - especially if you are considering taking this type of approach in one of your projects. I might consider attempting this approach later on - it definitely seems to be both an interesting and useful way to approach developing a project.

Until next time,

Dylan

The User Interface

Hello everyone,

Recently - during my research for my Masters Dissertation - I have read through Game World Interfaces by Kristine Jorgensen. It's quite an interesting read - and whilst it's mostly applicable to someone studying to understand games - it also has practical applications and explorations that for developers could prove useful. It is definitely a book I recommend picking up to read.

It's on these practical applications that I wish to bring forward to discuss. Jorgensen spoke of a number of ways to understand the User Interface [UI] within games - I won't be going into Jorgensen's theory of the Game World Interface - I simply want to touch on a few thoughts that came to mind whilst reading. UI could, in a very broad categorical sense - be seen as being a combination of or a single one of the following: Ludic, Fictional and Emphatic. 

Ludic refers to UI elements that clearly do not exist within the game world itself. This means that the avatar, characters in the game world, and so on - do not actually perceive the element itself. This common in MMORPGs - where much of the UI consists of action bars, and menus, together with sub-menus that go into great detail on the statistics of the player character. 

Fictional refers to UI elements that can be perceived by characters within the game world. These UI elements exist to both serve the player - but also as part of the game world itself. A common instance here is when playing a third-person game, and the avatar begins to limp as they move. This could be a clear indication that the player's avatar is injured. Other characters within the game world can see this - but so can the player - and it gives the player a clear indication on the state of their avatar.

Emphatic elements can be seen as Ludic elements that are explained fictionally. A common instance here would be first-person shooters where the player character is wearing a helmet with it's own interface that the game suggests is the same UI that you, as the player, use. 

Each different form of UI element has it's own issues and benefits - depending on the genre in question, some UI elements may be preferred over others. In an MMORPG for instance - it can be difficult to provide all the information a player might need to go through it's relatively complex content in a fictionally coherent manner. On the other hand - a horror game might have a better time using fictionally coherent UI elements to put the player in a position where they feel that they themselves are more within the game world itself. 

As Jorgensen points out however - the key points to consider as you work on your UI is to ensure that the information is clearly communicated to the player, and also that the information you provide is context-sensitive. Ensuring the player has the right information in the right situation, and ensuring that they know how to access it and actually are able to notice it, is critical. 

The User Interface is a highly important aspect of digital games as they assist the player in being able to both navigate and experience the game itself. As such - it can be highly beneficial to approach UI in a serious manner to ensure that it is both done correctly, both functionally, and aesthetically. 

Until next time,

Dylan

Game Maker Progress 52: New Graphical Assets Sizes

Hello everyone,

The last week has been fairly production in relation to my dissertation. This has meant that I had to shift focus away from Foundation of Civilisation for a while, however.

After up-scaling the sizes of the tiles - which means that UI elements, for instance, would need to be larger and thus allow for a greater amount of detail to be drawn onto them, it became necessary to figure out exactly how much larger the new images will be. I will be going through and standardising the various UI elements - as well as organising, and where possible, using and manipulating a single image to achieve multiple purposes further down the line, however this has given me a small insight on the new sizes of the UI images, and what to expect later on.

The new graphical sizes [Those listed in the coloured columns] are, at default zoom level, 6 times larger than what was originally used. Needless to say - jumping from 78 x 40 pixels to 468 x 240 pixels opens up a large amount of room for detail and improving the aesthetic aspect of the project. However, this is not the only aspect of the new UI I will be touching on to.

As perviously mentioned - I will be going through the UI to standardise the various UI elements - which will make it far easier to both code, implement, and change as progress is made. This means splitting the various images into something akin to Small, Medium, Large buttons; then modifying those images to create distinguishable buttons as needed; including adding text to the button itself. This is most relevant for the Build Icons and certain backgrounds used for menus such as the Build Menu. Build Icons are each a unique sprite - and for the sake of keeping the resource tree of the project clean - I will be looking into gathering those images into a single sprite, and using Frames to pick which icon to use.

The plan for this overhaul of the UI is make it easier to add, remove and modify menus later on. As I will be working on updating the graphical quality of the UI - it seemed appropriate to schedule the overhaul now - to better see which UI elements need an improvement, and which will likely be modified later on down the line.

Until next time,

Dylan