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

Progress Update 23rd September 2017

Hello everyone,

The reason for the title of this post being what it is - is that sometimes progress is more general, and less specific. Truth be told - it can be an intimidating feeling when you feel as though you haven't really progressed in a specific project, sometimes even when you attempt to objectively look at the progress you've made recent, it can also feel as though you could have done more. Which isn't a bad thing - critically looking at yourself, reflecting and thinking about how you can do better is good - but crediting yourself when it's due and also doing so can be a difficult balance. I digress - the general progress updates will likely be used on days where progress was more general rather than project specific.

My progress with the introduction to digital art course is going fairly well. Much of what's being taught is still fairly basic - however, strengthening basic concepts is definitely key to improving a skill which one feels less proficient at. I am quite anxious to return to work on Foundation of Civilisation, however. I am holding off as I continue work on this digital arts course; and also add more focus towards my Master Dissertation.

My Masters research will be occupying a fair portion of my time the coming 6 months at the very least - this will mean that work on Foundation of Civilisation will be slowed down. That being said - I do plan to continue working on the project throughout the 6 months. I will most likely be dedicating a day or so during the week to working on Foundation of Civilisation, but ensuring that the Dissertation receives priority. 

Until next time,

Dylan

Game Maker Progress 51: Exporting Game Data to Text File

Hello everyone,

As I continue the Udemy Digital Arts course - with not much to show for at the moment as the course does start off fairly basic with concepts such as line work and line weight, I decided to bring forward a system I have implemented into the game to later on help with balancing and gathering game-play data.

The system as it is at the moment simply saves specific data from the game session to an external text file - which can then be imported to a spreadsheet software to help with interpreting the data itself. At the moment - the data gathered is simple, population growth, decline and immigration during a specific turn. However eventually I hope to add other data points that could help with balancing; including resource production, amount of workers at various workposts, and so on.

Needless to say - balancing is not the highest priority for the moment; although having this system in place, together with the insights it could help provide, might help make design decisions later on. Plus due to the simplicity of implementing the system itself [less than to around an hour's work], I decided it would be best to just implement it whilst the idea was fresh in memory, and I had some time to spare. The information is also gather un-intrusively - which will definitely aid in play-tests later on - to help figure out what numbers to adjust during game-play and so on.

Until next time,

Dylan 

Game Maker Progress 50: This Month's Plan

Hello everyone,

As I have mentioned in a previous post - this month will be focusing primarily on improving the project aesthetically - and aiming to improve on this aspect both in relation to making changes, as well as making the graphics more appealing.

Much - if not all - of the game's current graphical assets were always intended to be placeholders. I do have a vision for how the game would aesthetically look at completion - however, between now and then lies a few obstacles. Depending on whether I decide to forgo bringing in digital artists to create assets for the game, or simply create them myself - will have a major impact on the project. Whilst the biggest barrier to bringing in digital artists to create assets is primarily financial, as well as finding the artist with the style that can fit the game itself; the biggest barrier when creating the assets myself is a mixture between my skill-set and the time-investment. 

As such - the first thing I am will be working on this month - is taking a digital arts course; with the aim to improve my drawing abilities, both digitally and non-digitally. This will likely take up a large part of the month, and will also likely take more time even after - however the intention is to begin improving my artistic abilities in digital arts, and keep moving forward from there. 

Following this - there are two aspects of the aesthetic of the game that will require improvement. First of which is not visual per se - but will help with implementing and modifying graphical assets - that is standardising and improving the way graphical assets are handled in the project. This can be as simple as making sure that all icons are the same size, and making sure that each icon defaults to the default zoom level to allow for maximum detail, to improving the way code modifies the graphical elements for effect. The other visual aspect - is simply to improve the graphical assets. 'Improve' being a very general term - however moving towards what I have in mind, whilst also making sure that the graphical assets are both recognisable and appealing are a major part of this aspect.

I may do a few touches to the code itself this month - however, primarily this month I will solely be focusing on the graphical and aesthetic aspect of the project itself.

Until next time,

Dylan

Game Maker Progress 49: Minor Additions

Hello everyone,

I apologise for the slight delay in posting this article. During the last week I have been busy with other work - which has resulted in me not achieving much in terms of Foundation of Civilisation. However, I have been able to find time to replace some placeholder graphical assets with more relevant ones. 

Aside from providing graphics to the Housing and Traveler's Lodge upgrades within the Residential District; I've also given a graphic to the Event notifications to help the user tell what type of notification it is, at a glance. 

I hope to spend the next month focusing more on the graphical side of the project - and begin to change some of the placeholder graphical assets with more fitting ones. Whilst those would more likely not be the final graphical assets, it will help give the project a better appearance during play-testing, and will also help to begin dialling down on the art-style which I have planned. 

Until next time,

Dylan

Game Maker Progress 48: Added Structures, Upgrades and Event Notification System

Hello everyone,

After a few considerations - I decided to delay the Village to Town system for later on - most likely October. The reason for this decision was that implementing the up-scaled graphics, together with a few other related features; much of the game's code has to be modified to ensure it functions with the larger tile size. For this choice - I decided before moving onto another major feature that would require essentially braking down the game's functionality again until implemented - I would like to have another play-test to ensure that most of the game's systems remain functional; and no hidden bugs crop up.

That being said - with the end of the month nearing - I decided to focus on adding more content to the game itself. Based on the feedback from the first play-test - there was a high request for more approaches to deal with issues in-game, be they resources or structures. Whilst the game is early on - and content is a relatively low in importance compared to getting the game's functionality down - with around a week left in this development cycle, I decided it would be worth dedicating some more time to adding this content to begin trying it out and testing it. 

Balancing will definitely be a continuous process - as will be changing around structures until they both fit in a logical manner - and fit with the still-evolving game's functionality. It is - needless to say - imperative to maintain a type of general approach to various game systems, to allow room for changes in the way the game works. Such as making sure that if down the road - structures do need to be placed adjacent to one another - the code to build structures is easily modified to allow for this restriction. 

Another system being added is an Event Notification system. Players during the play-test of the Pre-Alpha 0.1 Build expressed their wishes to be notified of certain events; and this feature had already been planned to be implemented - and it has found it's way into this build. At this stage - the system is very much a place-holder in terms of it's graphical and also in terms of it's ability to convey information. Players receive a weekly report of Growths, Immigration, Decline in the Population, and also the change in season. Aside from this - players are also notified if a Residential District is running low on food - and they also can move the camera to the related district by simply clicking on the notification. For the moment - a small icon falls from the top right of the screen - and the player can hover over the icon to display the related information. It is, needless to say, planned to ensure each icon is distinguishable for various events - and also allow for a cleaner and quicker way to relay the information within the tool-tip.

Until next time,

Dylan

Game Maker Progress 47: Designing the new Village to Town System

Hello everyone,

The last week has not been very productive for a number of reasons - between other obligations and similar reasons; as such I used it to stream-line a few processes to make future work simpler and easier. For example - I organised the sprite and image files I use for the tiles and structures within Krita - the software I am currently trying out to use for graphic creation - in layers in a way that will make it easier to create new structures, export it's relevant images, and import them into Game Maker Studio in as few steps as possible.

I have been thinking a lot about a major change I want to implement in the way that towns are built. Previously - players simply built districts that perform various functionality such as housing the population or refining material into other resources. This was always meant to change - and I have been taking steps into figuring out how to implement the early stages of the player's civilisation building with village, that will eventually lead to the creation of towns, and their subsequent expansion using districts.

As it stands - players will begin by constructing villages which will be a amalgamation of the current existing Residential, Mercantile and Artisan districts. Once a village reaches around 100 population - it can expand into a town. Expanding into a town changes the village tile into a Capital District - and also unlocks the ability to build the various other districts adjacent to it. In a way - this gives towns a more later game feel, and also provide a more authentic way of growing and developing - rather than what is usually done where the player creates the structures when, and where they might fit. This will require more planning by the player - since the districts will need to be built adjacent to one another - and it is a possibility that a bad placement in the early game of a village could mean that the town will be smaller in size, and will require the player to build an extra village to expand instead. On that note - it is worth mentioning that the player will be able to build more villages which themselves will expand into other towns - I have yet to decide how to handle interaction between the various towns that a player might possibly decide to create. 

This will be a fairly major feature of the next test-build, which I hope to have completed before the planned play-test date. 

Until next time,

Dylan

Game Maker Progress 46: Zooming, Tile Up-Scaled and UI Scaling

Hello everyone,

The last week has been focused on something which I've been meaning to do for a while. Previously the sizes of the map tiles were around 200 x 200 pixels. As such - all UI elements were designed with this in mind. This size made it difficult to put certain detail into the art of the game, and as such - I've been meaning to scale it up to a larger amount - a tile is now 800 x 800 pixels. This has meant that the UI needs to also be scaled up in size, to match the new tile sizes as the camera is further zoomed outward. 

Since I was working with the scaling - I decided to put in Zooming once more; since this feature was planned to be in the game - which I decided to put on the backlog for a while. Now re-added - my goal the past week was to ensure that if I decided to scale up the tiles once more - I wouldn't have the issue to re-adjust the size of the UI again. 

After a few days of working out the mathematics of it - it's working quite well! The system essentially increases the scale of the sprite of the UI element, whilst also maintaining it's position on the screen. This was done by using variables containing the distance from the centre of the screen where the camera is centred, and then using percentages to position the elements on the screen. As long as the scale of the image was correct - the element will remain in place whenever you zoom out.

This has - of course - meant that I have a day or two of going through various UI elements and adjusting the code that positions and determines their scale. However once that's done, everything should be in working order and future proofed to deal with this automatically if I decided to upscale the tiles again!

Until next time,

Dylan

Game Maker Progress 45: What's next?

Hello everyone,

The next development cycle is under-way - the next play-test currently planned for the end of August. Due to the shorter cycle this time around - the feature list includes far less time-heavy work; and will instead of focus on fine-tuning the issues with the core game-play loop. 

One of the major changes will be moving towards a new way to build your nation - starting with villages, and expanding into larger cities with districts. This has a two-pronged benefit - the first being it eases the player into the growth, requirements and expansion of larger cities, and it also provides a more believable feel to the way the nation expands and grows. Together with this - new structures will be added, together with new resources, all to help encourage a different approach to solving various problems faced within the game, and also tackle new obstacles.

Warmth and health are both planned to be within this next build. Simplistic versions of the larger systems - but it will help gauge the effect of these systems on the game itself, until slowly expanding them to become more enticing and engaging, in relation to planning and consequence. Nation Traits - one of the features which has been planned from the very start - will also begin to be implemented. Nation Traits can be seen as the nation's general understanding of a particular field. As Farming is done more and more in the nation, your people will learn more about farming - unlocking new benefits, structures and ideas. This will help give both a feeling of progression - as well as an indication that the new budding nation is finding it's footing in it's new land.

That more or less tackles the more in-depth and complicated features that might give rise to unexpected issues. Some are prioritised over others - however, they should all fit within the allotted time-frame. Finally - a number of less work-load intensive, more convenient features are planned - such as the ability to view the composition of the workforce in a menu to know how many people are doing what - to an event tracker which will help inform the player of any issues that might be arising, or any events of note.

Much of what's been decided has been based on the feedback generated from the play-test - it was both a motivating and highly insightful experience, which I plan on hopefully replicating more and more as the game progresses forward. 

Until next time,

Dylan

Game Maker Progress 44: Play-Test Update and Planning the Next Step

Hello everyone,

Yesterday - the first group play-test of Foundation of Civilisation took place. Whilst the game is still heavily in development, the first feedback was both promising and insightful! I was a little bit nervous - as I think many people tend to be when showing of their new work; especially when it is of personal importance. The overall response to the game was positive - the game in it's limited state shows promise to being a fairly enjoyable game to play. 

Before-hand, I'd like to take this opportunity to, again, thank the play-testers for their support and willingness to help try the game at this incomplete state - which I am confident will help make it a far better experience as a game!

A small informal survey at the end of the play-test helps shed some light on how the play-test went. The results will now be used to help plan what needs to improve, what needs to change, what is highly requested to be added next, and where there is interest. Needless to say - this was a small play-test of around 6 individuals, so the size of the sample is limited - but it remains useful none-the-less.

When asked what should be prioritised for the next build of the game - the average responses were as follow;

========================================================================

Higher variety of resources and approaches to fulfilling different needs and tasks: --------------2.16

More structures to build that perform different tasks: -------------------------------------------------2.3

More depth to the population: ----------------------------------------------------------------------------2.83

More depth to the environment [By environment - it is referred to the tiles which structures occupy]: -------3.16

Better reasons to explore the world itself: ---------------------------------------------------------------4.6

Better authentic-feel to tiles: -------------------------------------------------------------------------------4.6

========================================================================

At it's current state - there is also a major need towards giving players a reason to plan ahead, and perhaps even the tools to plan ahead better. When asked how much did you plan ahead when placing your structures, players responses average was as follows;

========================================================================

How much did you plan ahead when placing your structures? [1 not a lot, to 10 a lot]: -------------- 5

========================================================================

When asked about what they'd like to see in the game, the suggestions and ideas were highly varied. Ideas ranging from different types of events to help cause disruptions to the game, which would make planning more critical, to tools that would aid in planning, and controlling the nation itself. Many of these suggestions will likely find themselves in the already planned out systems, to perhaps even being added to the list of features to be added in the future!

The next week will involve planning what to add and test in the next prototype build - which I am hoping to schedule at the end of August. Needless to say, due to the shorter cycle [For the first prototype, it was a 2 month cycle] - less features will be added, and the focus will likely be on both refining what already exists, and adding new features that are planned out for testing.

Thank you for reading through this if you have, and thank you for the play-testers who participated in this play-test!

Until next time,

Dylan

Game Maker Progress 43: Project Update Prior to First Group Play-test

Hello everyone,

Preparations are more or less complete for the group play-test which is scheduled for next Saturday (29th July 2017). I feel both excited, and nervous; as the project makes it's first step towards being tried by players as a game. 

The last few days have been quite the joy when it comes to Foundation of Civilisation. The project has made huge strides since it's planning, concept, and the hours of work that have been put into it until this point. There are still hours, days, if not months of work left before the game can be anywhere near what I believe it could be ready for public release - however progress is being made. The most exciting feeling from play-testing the game came from it actually feeling like a game - like a game I would play. 

With so many ideas still left to be tried and tested, both exciting ones, and ones focused on making the project just that little bit better of an experience; in terms of optimisation, and in terms of game-play. 

Until next time,

Dylan

Game Maker Progress 42: Preparations for Play-Test and Next Step

Hello everyone,

As I begin preparations to have some play-testers try out the project - I started working more towards usability by fixing the tool-tips and working on the interface. The play-test will help offer a few insights on what's already been done and what can be improved, and changed. Aside from a few parameters being tuned, and fixing a few basic bugs - the game for the initial play-test. At the moment - most of the parameters have been set with testing in-mind; as such they need to be adjusted to what they could be for game-play purposes.

I have a number of ideas on what to change, add and remove that could help the game's experience. Thinking on how to go from the early-game to the late-game and ensuring the game remains compelling was one of the more important considerations as I continued thinking on could be added next, after the play-test.

Two ideas that came to mind is to have an underground-map which the player can dig-out to create underground structures. The second idea is to allow the player to have certain decisions and choices that will influence their nation. These can range from trade deals, to large immigration, to dealing with issues and so on. Following the play-tests - I will begin planning out the next build, plan out what features to implement, fix issues, and adjust elements based on feedback!

Until next time,

Dylan

Game Maker Progress 41: District and Workpost Upgrade Plots and the Production Menu

Hello everyone,

This week I worked on two fairly work-load heavy elements. Both still have work that need to be done beyond simply tuning - however, since one depended on the other; it meant that I could not focus on one to completion before moving onto the other. The most work-load heavy is the new Upgrade System for the various Districts and Work-posts. 

Plots represent a space in which a structure that has a certain functionality can be built within a district or work-post. Previously - the Artisan District was the only structure that would have had these types of structures - the sawmill for instance, refined logs into timber. However, moving forward each structure will have plots where upgrade structures can be built with functionality ranging from increased efficiency and productive, to different resource production and a number of other ideas. The idea of 'Plots' came as I intend to make the menu as shown above, a small map of the area - with plots of land along roads being available for structures. This helps give a more tangible feel to the districts and work-posts as being actual places within your civilisation. 

The production menu - the more incomplete of the two systems listed here - will be able to show the amount of resources being produced 'per game tick' so to speak. Each tick - represented by the temporary clock-like indicator above the season and weather indicator - represents around a week for instance within the game world. So based on the production rate - we can see that 9 logs are being cut per week for instance. The production limit listed here will be adjustable by the player to limit production of resources. This is mostly important based on feedback of previous play-testers about artisan structures using so much raw material to produce refined resources, that it became difficult to have enough raw resources to do other actions. 

I have also replaced a few of the UI backdrops - in particular the ones used for both menus - the plan in this account is to have these menus appear on paper-like material; that you as the leader of these people are looking at whilst making your decisions on a day-to-day basis so to speak.

Until next time,

Dylan 

Game Maker Progress 40: Workers and Real-Time Game-Play

Hello everyone,

This week - two more critical components of the project have been implemented. These being the ability to add and remove workers to and from work-posts, together with the relevant code to ensure that if a population loses a member who contributing as a worker - the working population reduces; and the second component is that of real-time game-play. 

The ability to add and remove workers has been a major element of the project which has now been taken care of. Ensuring that the player does not somehow end up with a large amount of workers, when residential districts only have a few workers, as well as ensuring all the correct figures are shown, was a small head-ache. Thankfully - much of the work to ensure the system works was done with the concept build, which now only meant I needed to refine it and re-implement a new version. 

There does need to be a lot of adjustments to parameters based on the fact that game now operates in real-time. The real-time element in essence functions by having an 'Alarm' on-going during game-play which triggers a set of functions and resets the alarm; to signify time passing by. The way this has been implemented allows for a fairly simple way of allowing the player to choose speed - be it slow, normal and fast - which will be implemented along the line. This is a major change from the concept build - but a necessary one based on the type of game-play I am offering. Some of the feedback on the concept build described the game-play to be too slow; this might be the solution for this, this remains to be seen with play-testing however. 

There remains a few other tasks before I can begin refining the current build to a form to allow play-testers to test the game. More specifically is adding the Artisan District's functionality, possibly add the ability to save and load, and add the Production Menu to allow for better management of resources. Following this - I will be focusing my attention on the User Interface and the place-holder graphic elements. I will be keeping most of my efforts on the UI and the place-holder graphics in a more general form - for instance - attempt to have a single button graphic that can be modified using code and scaling to perform multiple tasks. 

Until next time,

Dylan

Game Maker Progress 39: Weather and Seasons

Hello everyone,

Two key systems were implemented in the last week; weather and seasons, together with a resolution manager. 

The weather and seasons are two of the most basic or fundamental obstacles that players will need to contend with and plan for. They do not necessarily pose negative effects - for instance, farms produce far more during rainy weather - they do however, suffer a production hit during winter time. 

For the moment - the only way the player can tell what season and weather it is currently is by looking at the indicators at the bottom left of the screen - with the left showing season and right showing current weather. This is, for the most part, temporary as I wish to reflect the changing weather on the tiles themselves - as well as provide a better indicator to show the current season and weather. I also have plans to have area-specific weather events, for instance rain in the north, and clear skies in the south, these are however in the back-log; as the priority is to have a playable prototype using these new systems.

The resolution manager is an addition which I find to be quite enjoyable and pleasing. The resolution manager calculates the optimal resolution based on the width and height of the display that the game runs on. The game's resolution will then adjust based on this figure - allowing it to be played on various screen sizes fairly well. That being said - I hope to implement a way for players to choose the resolution and aspect ratio they wish later on. For the moment, this does aid in providing play-testers with a build that can adjust as required based on the display they utilise.

Everything is progressing nicely - the game's systems are nearing a stage where the game can be played, however there are still a lot of systems, code and elements that require attention before I can begin to play-test the game, and begin thinking of more advanced systems to put into place.

Until next time,

Dylan

Game Maker Progress 38: Continuing Foundation of Civilisation Project

Hello everyone,

After a fair amount of time focusing on other work; it's time to continue on Foundation of Civilisation. One of the first steps after the fair amount of time being not working on the project was to re-adjust back into the work I had already done - and seeing how to adjust to the new schedule now that University work is for the moment complete. 

I have chosen to move the project onto Game Maker Studio 2. The new work-flow and features have already proven to be extremely valuable - the most key of which being the new layering systems within the room editor. This has made layers the interface, various instances of objects and so on - far simpler and intuitive. 

Whilst Game Maker Studio 2 did allow for a very simple import of a GM1 project - I have slowly been adjusting the project to not use any of the compatibility elements that come with importing the project. Eventually, I aim to make sure that the project is a GM2 project rather than a GM1 project. Now moving forward what are the priorities? 

The first priority will be getting the project to a playable position and to begin testing in that way. As I have previously spoken about - getting the core of the game-play working is urgent. As such - the first milestone will be that - having the project to a state where the core game-play is functional. After this is done, other game-play elements will be added to add depth, and ensure the user interface is intuitive and convenient. 

Much of what I've achieved in the past week has been hidden system components - such as getting the population code working, the work-posts code working, and changing old systems to fit into GM2 in a way I can work with GM2's workflow easier moving forward. I have begun working on adding the UI elements needed to play the game.

One of the key pieces of the UI elements was the selection of structures. I had a few ideas on how to achieve this in a way that does not take over most of the screen, but also relay the information needed in a manner that both clear and readily available. The above image shows one of the structures available to be built, the Artisan district; by selecting it, you open a few interface elements that will fit as shown on the right image. 

I will also be adding At-A-Glance [AAG] elements that give the player information on specific tiles that they can access during game-play quickly. Depending on what type of structure, the AAG elements will differ - for work-posts, the players will be able to quickly see the workers set and maximum amounts, the efficiency and the current production of that work-post.

It's good to finally be working on this project once again - I plan on getting the playable version ready as soon as I can so that I can begin getting feedback on the new way the game plays - and work with this new feedback to improve the project.

Until next time,

Dylan

Types of Resources in Games

Hello everyone,

Things have begun to settle down and I can begin thinking on continuing the blog and progressing on my personal projects. Something that during my research has come to mind, as well as when I continued reflecting on how to better design and develop Foundation of Civilisation was regarding Resources. Something which I will be discussing today.

As I researched certain concepts of Economics, and began to reflect on their application when talking about digital game economies, I began to think that it may be worth distinguishing between different types of resources. A possible way to distinguish these is based on their ability to impact game-play;

Short Term [Here we talk of Execution]

E.g. Consumables

Ability to affect game-play now. Whether it is by affecting specific parameters such as Health and Mana, or by apply certain effects such as Invisibility or curing conditions.

Medium Term [Here we talk of Tactics]

E.g. Currency

Ability to affect game-play outside of now. Such as the ability to purchase items like potions to prepare for combat.

Long Term [Here we talk of Strategy]

E.g. Attribute Points

Ability to affect game-play after a long period of time. Such as the ability to specialise the player character in specific ways.

One does need to look at the game in question - for instance, a sword in a game where upgrading equipment takes a very long time - might be considered a Medium or Long term resource; if a game however uses durability, and the sword needs to be replaced regularly, one might consider it to be a Short term resource. Why would making such distinctions be useful one may ask? Simply put - it can allow you to make better informed decisions on design choices and what players will likely be thinking about when they are planning their characters. This can help you guide new players, or offer better choices and alternatives to existing players. 

Another reflection was the idea of how do resources behave in game economies? Resources can be consumed, they can be Exchanged or Traded, or they can be Refined into other resources. This is nothing special per se - it's pretty straight forward. However, when dealing with resources is such a prime activity within Foundation of Civilisation - this will likely allow me to better optimise my code, and think along the lines of what players could potentially do with resources - opening up opportunities to use the resources in a variety of different ways, and ultimately providing players with a more interesting experience whilst playing the game!

Until next time,

Dylan

Providing Information with Embedded Narrative Elements

Hello everyone,

Recently - during my research in Deus Ex and it's repeated area of New York Hell's Kitchen - I've noticed a technique or approach towards embedded narrative beyond simply providing text information. 

Often times - when we talk about embedded narrative we look at either the Environment itself - or things like diary entries or audio logs for instance. Whilst Deus Ex definitely makes use of objects that convey text information - such as Newspapers, Books, Data-pads and E-Mails - there is further insight in the way this information is portrayed. 

When you find something written in a newspaper, you might assume that the information you are reading is wide-spread. At least more wide-spread than if the information you've read was found in an e-mail. This is something that is worth thinking about and reflecting on when you are creating your own embedded narrative elements - as it offers more depth and gives the player a better sense of the story world itself. 

Having multiple embedded elements pointing and reinforcing one another could serve to be an effective and often interesting means to allow players to form a narrative. Providing them with not only multiple perspectives on the same information - but also different mediums [Newspapers for instance being public, whilst an e-mail is private] can help players form a narrative more effectively, and possibly an even more interesting narrative!

Until next time,

Dylan

A Small Update

Hello everyone!

If you've been following my previous posts - I talked about how things have been quite busy the last few weeks - and they still are. Right now, there is a lot of work I have to do with regards to the Masters programme I am doing - so unfortunately that means a lot of personal projects have been put on hold.

I will be most likely continuing on Foundation of Civilisation later on - once things have settled down. I will also be continuing on pixel art practice once things have settled down. I may also decide to do more analysis type posts - perhaps going further than Embedded Narrative or simply broad analysis of concepts of other areas [such as economics] and their application to games. These would hopefully be both helpful and insightful to help guide design choices and even get ideas among other things! 

Until next time,

Dylan

Embedded Narrative Techniques within Deus Ex

Hello everyone!

Recently I have conducting research on Embedded Narrative and the repeating aspect of the New York Hell's Kitchen area within Deus Ex, released in 2000 by Ion Storm. It has been proving to be an insightful look into rewarding players willing to explore and read the material left around by explaining events in the world through multiple 'channels'.

For instance - when you first arrive in Hell's Kitchen from the subway, you are able to access a Public Access terminal that has a few articles and announcements about what's happening in the game world. The first entry talks about a chlorine leak poisoning the Hudson river and causing problems in one of the water purification plants.

Further on through the level - you may choose to investigate the sewer areas - after being provided a key and asked by a smuggler to go rescue a friend of his. If you choose to do so - you will discover a group of what appear to be private military individuals. One of the data pads simply state that they are there to covertly observe a warehouse in the area.

However once you do some more investigating - you discover that they set up base in one of the water purification plants - and have been administering chlorine into the water supply from the plant. 

Here we have simply one story that a player can discover and learn about. All these different approaches and channels funnel into delivering the information and story for the player to piece together as they explore the environment. The game also mentions places that the player will be going to later on [Brooklyn Shipyards] and also lays the foundation as to what, why and how what will happen was able to take place.

An insight that can be taken from Deus Ex's approach to relaying information about events is to take different approaches. What a player can learn about in a news paper article, you can then reinforce and provide further information in a e-mail. Piecing these specific pieces together provides both an interesting way for you to provide information about the game world, and what the player is seeing and experiencing!

Until next time,

Dylan

Tile-Thursday 8: 32 x 32 Volcanic/Barren Tile Set Progress 4

Hello everyone,

The last week has been very busy with University work - and it seems that the next few weeks will likely be the same. I may have to pause on pixel art for a small while - whilst I work on University work. 

I have been playing around with layers in Pyxel Edit and trying out different ways of making the same tile / object re-usable in a way that it appears to be different. This can be seen with a number of the objects in the below image - such as in the background, the cave rocks and the shrub on the small elevated piece of terrain.

Until next time,

Dylan

Reflecting on Economic Ideas to Understand Games

Hello everyone,

The last few weeks I have been reflecting more and more about the usage of economic concepts and ideas in understanding games. Among the benefits of using economics within game development - we can use it to help guide design decisions - should we add a new quest to the game that will reward player a sizeable amount of currency? Should we instead give the player an item reward? These may sound as questions linked to balancing - however economic ideas help with other design decisions such as how many types of currencies do we have? 

When talking about a MMORPG [I will be speaking of MMORPGs primarily but realistically - this counts for most games that have a persistent world / economy with large numbers of players] - the concepts of economics seem to be more apparent and clear. Whilst developers often are able to control an economy of a non-MMORPG - the same is more difficult and intricate within an MMORPG setting. For the sake of ease when discussing contrasts - I will also be thinking of single player RPG games when I refer to single-player games.

I decided to reflect broadly on these ideas within this post - I may decide later on to explore more specific ideas and situations - however I have yet to decide on this. I will also be speaking in more simplified definitions and terminology - and should I choose to explore the topic more, might delve into the more specific definitions and terminologies. These are simply reflections so of course, do not take these to be facts or necessarily true, they are simply a few thoughts that came to mind when reflecting on economics and game economies. So look at this post as a simple sharing of thoughts so to speak.

Demand and Supply

As one of the fundamental concepts in economics - Demand and Supply are elements we can likely envision the most in a game setting. If a player demands an item - health potions, equipment, cosmetic items and so on - then they may be willing to attempt to acquire it. In a single player game - these often involve finding them in the world - or simply purchasing it from a Trader using the in-game currency. In an MMORPG - the situation becomes more a bit more interesting - at least in my point of view. 

Demand in an MMORPG - especially where a Trading Post, Auction House or similar is available that allow players to place purchase orders and so on - is often influenced by a lot of factors beyond the usage of the item. In games such as Guild Wars 2 - players purchase skins, mini pets and tonics that have little functional purpose in the game outside of aesthetics. The same can be said in single player games - however in a single player setting - the developer can balance out items to attempt to ensure different types of players have what they want. Which brings us to the concept of supply.

Supply refers to the amount of a particular item available within a market. In a Trading Post - these are offered up by other players - who choose how much to charge for the item itself. This shift from developers having control of prices within single player games to often having to alleviate at least a little control to players begins to show us a better picture as to why economics is useful to game developers. 

Influencing Price or Introducing New Content

As a developer in an MMORPG who is about to introduce new content to the game - it is worth noting at least what the effects of the new content will be on the game itself in terms of it's economy. Player demand and supply will shift and change as the game goes on - and a lot of new content is often a major driver towards this change. If one were to look at a number of items in games such as Runescape before and after the introduction of Raids - one can see how players would demand more of a specific item they believe will be valuable - often driving up the price of the item. Another consideration is when you add too many quest and rewards - but not enough ways for players to spend their rewards if it is currency. 

When there is too much currency within a game economy - what is likely to occur is that the general price level of goods will rise - in a general way of speaking, each gold coin is worth less in terms of purchasing power. The implications here mean that older quests become meaningless in terms of currency rewards unless adjusted to the inflation. This means that in the early game - we can't count on players to interact as much in the player economy - and may have to settle for NPC traders; or as it sometimes may be the case - the players may decide to skip the quest and content entirely. 

Conclusion

Realistically - it is difficult to keep in mind all the concepts and effects a particular decision of piece of content may have. Sometimes - players will simply surprise you or act in ways you didn't even consider. Regardless - Economics is something I believe could be beneficial to look into for developing games - perhaps more so for games with persistent economies rather than others. Understanding a few of the fundamental concepts so to speak could be enough to prove beneficial; then perhaps looking into other concepts if you feel like they may be more useful or insightful or simply interesting!

Until next time,

Dylan

Tile-Thursday 7: 32 x 32 Volcanic/Barren Tile Set Progress 3

Hello everyone,

During the last week I've been experimenting and trying out a few ideas on the background. Usually I would try to use a slightly opaque or light colour to make distant objects. This time around - I decided to try out a new approach by adding a layer that darkens background objects to seperate them from the foreground. I definitely like the result!

Until next time,

Dylan

Embedded Narrative within the First Chapter of Dead Space

Hello everyone,

This week I decided to bring forward a small analysis I did for the first 10 to 30 minutes of Dead Space (Visceral Games, 2008) - approximately the first chapter. The analysis was in regards to Embedded Narrative - for those of you who are unaware of what this implies - think of it as methods through which a develop can tell a story through the environment and objects within the environment. A few examples of these include codex entries, notes, environment objects, audio logs and markings. 

When conducting my analysis I tried to take on the role of a new player who has yet to play the game itself. Using the environment - I attempted to interpret and imagine what possible could have taken place. We will be interpreting what we see based on the environment - assuming that we have next to no knowledge on what the state of the story is within Dead Space. The analysis will be done sequentially - from when the game gives us control of the avatar to around the end of Chapter 1.

The Analysis 

Docking Area 

From the start - as we depart from our crashed maintenance ship - we walk onto the docking bay area bridge which seems to be filled with luggage bags. Whatever happened - we can possibly assume that it was sudden - and people seemed to be just arriving or just departing from the ship just before or during what was happening. 

Lounge / Waiting Area

As we make our way into the ship - the amount of luggage left around the waiting area, coupled with coffee cups and what appear to be stains (stains of what exactly is debatable - is it just coffee or blood?). This seems to reinforce what we already assume - that whatever happened - it was sudden.

Security Desk

As we walk around the security desk in the lounge we are presented with a large quantity of blood stains. Arguably the first signs that whatever happened - people got hurt. However - what was it? Were people rioting because they were kept out of the ship? Were they being forcibly kicked out? Were they being quarantined? Also if conflict did occur - where are the bodies? Was it settled without casualties and people were taken to an infirmary? 

At this stage we are introduced to the 'Aliens' who answer the question we have on what might have happened - but raise so much more... 

Some initial thoughts would be how did they get on the ship? Who or what are they? What lead to this? Where are the crew and where are the bodies if they are not alive? Do these aliens take the bodies of the crew members?

Maintenance Room

As we escape one of the aliens chasing us through the back areas from the security desk - we arise to this. Perhaps the most significant feature in this room aside is the dead crew member and the writings in blood. This tells us two key elements - the crew did survive the initial attack by the aliens - and they are fighting back. As we collect the plasma cutter from the desk we can assume what that the instructions written in blood are instructions towards killing the aliens. Presumably - the crew member was dying - injured by one of the aliens - and wanted to leave a message for any other person to find so they do not suffer the same fate. 

Audio Logs 

As we move forward from the maintenance room we locate an audio log - which follows a crew member named Bensen and a group of survivors. From the audio logs we can't be sure how long ago they left these here - but it is a possibility that the crew member found dead - was part of Bensen's group. Leading us to believe that Bensen and his group could be alive. 

Tram Tunnels 

As we continue moving forward we find this scene. At this point - we have no idea how ago this had taken place - and who these individuals were. However as we make our way forward it becomes more clear. An audio log within the Tram Maintenance room tells us that Bensen and his group were attempting to repair the Trams to try to reach a different area of the ship - but they needed a stasis module. Presumably - these individuals might have been the ones bringing the stasis  module to Bensen and his group - however we can only speculate on this point.

End of Chapter 1

By the end of chapter 1 - we know that aliens were clearly what caused the USG Ishimura to require assistance. We know that there was a group of survival alive - but we have no clue as to what happened to them. We also know that the alien attack was sudden and unexpected - and that the body count seemed low relative to the size of the ship up to this point. Whether this means the ship had a small crew - or the aliens are taking the bodies somewhere - is unclear. 

Concluding Remarks

This analysis highlights the potential use that a number of techniques using simply the environment could have for relaying information and story. Embedded Narrative is often used to tell a story of past events - encouraging players to piece together an idea of what took place before they arrived. However it can also be used to teach the player in a diegetic [Diegetic meaning that it lies within the story world - think of it as the player character is aware and can see/manipulate/hear it etc...] manner. 

Through simply embedded narrative elements - we were able to piece together a large amount of information with regards to Dead Space. [Spoiler Alert] Those of you who have played Dead Space would know that the 'Aliens' were Necromorphs as they are known within the game world - brought onto the ship - which answers two of our questions as to where the bodies were - and how the attack happened and how sudden it likely was. 

Hopefully this has been a useful analysis that might have given you ideas on how to use Embedded Narrative elements within your projects - or simply as an entertaining read if that is what you're looking for!

Until next time,

Dylan

Tile-Thursday 6: 32 x 32 Volcanic/Barren Tile Set Progress 2

Hello everyone,

A small update for this week! Progress on the Volcanic / Barren tile-set is being made. I am enjoying working on this tile-set a fair bit up to this point! I worked on the tiles themselves for some variation and added a few decorative objects. 

Until next time,

Dylan

Game Maker Progress 37: Next Step - Production Menu

Hello everyone,

Before moving onto the next set of tasks - I fixed a couple of issues that were left with the resource sets and resource tracking slots. This is not final - I will be changing the icons themselves - however for the moment these will suffice for testing purposes.

The next major element I will be moving onto next is the Production Menu. The production menu will be an important tool for the player to manage their nation. It will allow the player to assess what is being produced, how much and also set a production limit to prevent structures that generate a particular resource to overflow the storage or consume needed resources. 

Until next time,

Dylan