Monday, 22 September 2014

Salvation - We can make it brighter! We have the technology!

Hey all :D

I have been running around like an idiot over the last few days. I just finished enrolling and I'm heading back to University on a part time basis :D I'm studying for a masters in games programming and I can't wait to get started!

Anyhow,  I was low on time this week but I am still reading and working on my design. I'm pretty happy with how it's coming along. But I don't want to bore you with boring stuff so check this out! :D

I decided to take a break tonight and instead of designing stuff I had some fun with the Unity Cellshaders! I also started replacing all my quads with primitives (cubes), so my game is slowly starting to become 3D! :D I rotated each cube to see how the outlines looked.

Check out the shot above. I left the spaceships and UI as quads for a comparison. I know it looks rough right now. And my programmer placeholder art is still there but the shaders works pretty well!

Super bright and 3D :D

Anyhow I'm going to get back to working on my design a bit. Just wanted to post something up here to let everyone know that I'm still truckin'. And I thought the construction blocks looked cool, even though they are placeholders haha.

Thanks for checking things out,

Thursday, 18 September 2014

Salvation - Design chance vs. skill

As I mentioned before, I am reading the Art of Game Design book and I'm currently reading about game balance. The book divides what it teaches into lenses, and I found lens #34 - The Lens of Skill vs Chance to be pretty interesting.

I had a thought pop into my head after reading this section about how Salvation deals with refugee ships and provides the player with the resources they need (population). Currently as it stands 4 ships are spawned per x amount of time and they can be 1 of any 4 races.

This means that when the level starts - a player will start receiving refugee ships, and they will be random. This is the chance that the book refers to in this chapter. It states that chance is used more in risk like elements and skill is used in more serious game mechanics. With this in mind I thought about how other city builders / strategy games handle similar problems.

For example many grand strategy games have random events that can occur. However these events are not completely out of the players control. A random event of some nature may occur if the player does something of the same nature. Starve your people and a relevant event may occur. Host a certain party or festival event and a random set of events based on the party type could occur. There is still an element of chance, to keep the player on their toes and to make the world seem more immersive. But they are not completely out of the players control. The play still have to initiate them to some degree.

The fact that the player is the one to initiate the events in the above example, allow them to take the risk that random events may occur. It is a good balance between skill (have I prepared myself for the events that could happen in I do this) and chance (what events are going to happen, did I prepare well enough? Will some unforeseen event happen to my town/city/population etc?).

With this in mind I went back to my refugee spawning. I want to give the player as much choice as possible when they build and run their station. For example lets say the player only wants one race to be allowed into their station. Currently there is no way for them to do this without being lucky. As random ships are sent, and if refugees are forced to leave the station could rebel. There are two interesting ways I can solve this problem, keeping the above in mind:

Solution 1: Plan for negative fallout

So the player has his station, it's blank and empty - the perfect canvas. Now they decide they want only Korr refugees, as they are Korr sympathisers and care nothing for the unwarlike and puny other races!

They build Korr living facilities and the game spawns random ships as it currently does. Because only the Korr can live in the station and the others are turned away, the player will need to prepare for the negative publicity that can occur and the fallout in their stat points. Happiness will go down much faster due to the other races being turned away. Additionally, the player will not have access to the other races buildings as there will be nobody to work them. A third factor will be the stations over all population will grow slower than, if they were to accept all other races along with the Korr.

Why would the player do this? What benefit would they gain? Other than making the game more difficult and because the player wants to roleplay - currently there is no reason. I am still working on this, but I like the idea that the player can decide how to scale the difficulty based on their in-game actions.

Solution 2: Communication Facilities

This next solution would add Communication facilities. Let's call them Comm Sats for the example. Each race would have one, just like the current living quarters work. This is nice as there is now another dynamic, another building in the game the user needs to think and plan around.

The refugee ships in this case would no longer spawn by default and they would no longer be random. They would not know the player station was there at all. Once the player builds a Comm Sat for a certain race, lets say the Klein, it'll act as a beacon for that races refugee ships. Once built, the Klein refugee ships would start spawning in and flying towards to player station.

This would give the player complete control over what race will ever find his station. That way, no refugees who are unwanted will be able to find the station. The player has more control on events.

Additionally this building can be worked on, improved in someway, to allow for more and more refugee ships to find the station - thereby increasing population. This would give the player even more control of events.

The benefits of this solution over the other is that is adds more building functionality, and gives the player full control of things. They can set the difficulty in terms of how they build the pace of their station. Fully upgraded Comm Sats for each race would be pretty hectic. Basic ones for 2 races and then 1 fully upgraded one for another would be easier. 

I am uncertain of which method is best and I'm still thinking things through. But I thought it was an interesting design idea and wanted to talk about it :D I'm super happy I got this book at least. I'm already thinking of design in a whole new way. Still can't wait to get back to code though :P

Thanks for reading peeps!


Tuesday, 16 September 2014

Salvation - Focusing on the Design

As I mentioned on my tweetar I'm currently reading through The Art of Game Design a Book of Lenses. I am realising more and more that my design experience is pretty much 100% from a software engineering background. I think of things in a pretty binary way. This needs to do this, then it'll work.

Trying to design fun is a pretty tricky thing to do. I have always been pretty opinionated about designers and how they think but the more I look into it the more I see just how important their way of thinking really is. And how difficult it can be to get right. I often scoffed at having to waste time thinking about stuff like Lore, Backstory, whether a specific mechanic was fun. As long as it worked efficiently and correctly it was fine.

It wasn't until I played through my game a few times that I started to realise it was lacking something. I am still not sure that this something is or if it consists of a bunch of missing elements. As such I am trying to get to grips with game design in a more formal sense. Seeing as how I am stepping back from the GUI stuff for the moment, I am using my current build and applying things I am learning from this design book.

I am already realising a lot of things I have not been keeping in mind. Additionally I have seen a lot of stuff I just did, to actually be a technique in games design. Being able to read up on new things and improve upon what I've been doing bad/well is a great help at the minute. Especially for morale :P

So my current plan is to spend at least this week reading through the book and applying what I learn to my current build. I want to expand the games functionality. I want to add more mechanics and assets to the game and start working on the technical side of the art style. To do this, it's no longer sufficient to just go "a spaceship .. just cause they are awesome!" This is fine in the short term of a basic game or prototype, but a bigger game will require some planning and forethought.

I'm hoping that by doing this, once I start putting in the mechanics they'll make sense and be fun. I'm hoping to start doing this asap so that I can get some people to play test my prototypes. To see what works and what doesn't work so well.

I also hope to have a solid picture of what I want the game to be once it's complete. Right now I have been winging it design wise. As long as I could build buildings and have people live in them I was happy. But now that I have hit a complicated design area I am a bit out of my depth.

The design I'm currently thinking over are the buildings my game will use / currently uses. Many city building games that I have played use many different types of buildings. All these many types of buildings are built, for a reason. This reason is normally to house your inhabitants/feed them/keep them happy/make money/trade etc. 

These elements never seem to be very large when compared to the number of ways to achieve them. Meaning that the player has a multitude of (fun) ways to achieve their goal (of having a trade income of X or entertainment value of Y for example). The goal objectives are limited, as to not make things to complicated and overwhelming. Therefore, from what I have seen, the buildings available to a player in a city building/grand strategy game, will always be more than the end goals the player can achieve with these buildings.

This can become an issue, as in some games there are so many buildings, requiring so much micro management, that the player becomes overwhelmed. Giving the player a lot of choice is not always a smart move. So finding a balance is important.

Not only is a balance important, but having buildings work in a fun way is just as important. Especially for Salvation as buildings are pretty much a core feature. I'll have to achieve this by minimising micromanagement but still have it present. And using my buildings or building space in an interesting way. As I said before, I have to try and model a fun gameplay mechanic. I can model and code a gameplay mechanic that functions well, but what will make it fun and to whom is something I am struggling with. Hence the reading.

Anyhow, lunch is over and it's work time again.
Thanks for reading!

Sunday, 14 September 2014

Unity 4.6 BETA - Adding new GUI features and what it means for Salvation!

I have finally managed to find some time to sit down for a few minutes to check out the new Unity beta stuff I been hearing about. Reading/watching the changes that'll be coming with Unity 4.6 specifically the new GUI stuff is getting me all fired up in different ways.

Part of me let out a giant exited SQEEE sound while the other part was experiencing a cold sinking feeling that I'd have to redo all of my GUI stuff I spent so long on. If I should choose to upgrade, that is. And I am pretty sure I will be, after seeing what I've seen thus far. Granted I've only had 30-40 mins to check things out. First impression is really good.

After looking at my game framework thus far, playing my demo level a few times last night. It dawned on me that the GUI still feels clunky. It functions fine, but it feels like it could be done better. I click on a panel and it opens up, and I know that each element that is now visible is a separate thing entirely. Tied together by a parent gameObject. But making sure all these elements act together in a synchronised way is tricky. And even though it looks fine now I know that adding more UI features is going to be a huge head ache.

Each element is a separate UI object I have to worry about!
For example the way my GUI is structured, I have to worry about each GUI element separately. For example scaling them based on aspect ratio, requires me to run the same script on each and every GUI element that I use. The new Unity UI will implement a new type of transform, called a Rect Transform. This thing is awesome and you can use it, with Anchors to have all UI elements scale themselves based on the parent element, which could be a canvas. Which brings me to the next feature I'm happy about. 

The canvas is a parent element that all UI elements belong too or need to belong too. If no canvas exists for an element when it is created then one will be made. This is awesome since I do this manually currently. I have an empty object called MasterPanel and this panel has all the GUI panels as children, which in turn have all their children. However doing this manually still takes time and makes things look and feel clunky and fiddly. Just because a gameobject is a parent doesn't mean I don't have to worry about each childs separate settings. For each child, which there are many of! Giant head ache. So I'm stoked about the Canvas. At a glance it seems like they'll allow me to change children elements in a more unanimous fashion. I'm hoping this is the case.

Panels panels panels panels panels ALL DAY panels
The workspace UI elements feature, that canvases will allow for, is amazing good news for me. The latest UI feature I added a few nights ago were little message pop ups that appeared for example whenever a ship offloaded new refugees to the station. I wanted this GUIText (string) message to appear where the ship docked. And as the ship is a moving object in world space (3D space), getting the right transform was a little bit tricky. However, what I am finding very difficult to near impossible at the moment is how to convert the GUIText transform to that of the gameobjects transform. For some reason even though they are identical, they appear different in world space. Making things look buggy and miserable. 

Ship Transform

GUIText with same transform
This new feature will allow me to add my code to a worldspace UI element easy and things will work and look right. As the worldspace UI element is not tied to local space it will make things so much easier. And I will not have to be comparing floating points and doing a ton of number tweaking to get transforms looking right.

So is this a huge step back for Salvation? Not huge but some tweaking will be required. As I'm still working on the framework I feel that if I were to make a change like this now would be the best time to do it. As things are still at their most basic level. A little work now will save a lot of work in the future.

Since Unity 4.6 is still in beta, I can't just make the jump right now and I'm not really sure when it's being released. What this most likely means is that my UI stuff will take a backseat for now. I'll instead focus on the other game features, as there's a lot of stats and numbers flying about. I'll also be checking out 4.6 in more detail and learning the new GUI features on offer so I acn hit the ground running.

I am also going to be removing my terrible programmer art and going to add in 3D models. Basic ones for now so that I can mess around with shaders.

There's a lot to do so I am not to nervous about leave the GUI stuff for now. Especially seeing as how fixing the GUI up has taken up all my time thus far.

Unfortunately I need to stop research for now, as I am actually on my way out the door again, this week end has been busy and not in terms of my games development. Additionally I finish my University enrolment next week, so things might be getting busy. But fear not as I am super keen to crack on with things!

Have a great Sunday everyone :)

Tuesday, 9 September 2014

Salvation Update - More GUI bug Fixes

Unfortunately no concept art for the minute as my lady is a perfectionist who doesn't let me post things unless she is happy with them :x They look super awesome though, I am hoping my code skills can do her models justice once we reach that stage.

But I have a boring bug update for everyone! :D

I added/fixed the Room Selection GUI feature. Well I say feature, it's pretty necessary. The ability to see what you have selected in your station is pretty freakin' important. At the minute this is highlighted by a halo. This works in a really neat way, now when you click on a building it'll have a little aura around it so show that it is selected. Doesn't sound complicated or that impressive but I'm super proud of getting this working in the way I wanted.

All room objects are stored in a list. When the user selected a building or room, this list is searched through for the room that's selected. This rooms halo is then set to active. All other rooms in the list have their halos hidden. What I think is pretty nifty is this list will only be as big as the initial rooms, because I recycle the lists elements. In my current level there are 16 elements in the list and that will never grow. Even if I add building upgrades, buildings, rooms etc.

If the user builds a new building, the emptyRoom object gets destroyed, which means that the list now has a null value. So rather than simply append the list with the new building, I now make sure to update it. All null values are now replaced by other buildings.

A mechanic I want to have in my game is building space. I want the player to have to remain conscious about the fact that they only have a set amount of room to build. So I don't really foresee there being a case where I have a greater number of buildings than the initial ones. And if I somehow do end up with that scenario, I'll just add more emptyRoom objects or an object based off of the emptyRoom class.

With this part of the framework in place I can now add building upgrades, building overwrites etc. And the list will never grow larger than the original set of room sizes. This took me two days to implement and fix. Which is a tad long. But now I can move ahead.

That's all for now, I won't bore you with code this time :P

Thanks for reading!

Thursday, 4 September 2014

Salvation Update - Concept Art added to minisite!

Hey all :D

I finished off the Salvation minisite and updated it with some badass concept art! The Maki and Korr races transport ships! :D

Go check it out here!

As it's like, 3 am and im super tired I'm off! HTML man awaaaay!

Wednesday, 3 September 2014

Salvation Update - Minisite in the works

My girlfriend is being amazing and is working hard at the concept art. While she slaves away over a tablet I thought I'd make a start on the minisite. My HTML and Javascript are basic at best but I got most of the basics done.

Now I just have to populate it with the content.

Not had any time to work on the actual game tonight. Pretty lame since I'd rather be focusing on the bug fixes and such but getting word out is just as important :D I also really can't wait to show you guys the concepts that she has been working on. I think they look amazing :) 

We also had a pretty long discussion about the world my game is set in. I thought I knew a lot about sci-fi but compared to my lady I'm an amateur!

I also started fleshing out the story line so that I can start pin pointing how many levels I'll be adding to the games Campaign/Story mode.

As usual you are awesome and thanks for reading,

Monday, 1 September 2014

Salvation Update - Build here, build HERE!

Before I start on the building highlight stuff there was one final GUI bug I had to fix. That was the stats panel. This panel showed all the required information to the player. This was stuff like population, money, happiness etc. It's also going to grow to show other game features once I get them done.

This panel was updated once per frame. Which mean, that if I hid it, the object that was updating the panel would throw out nullpointers because the panel was now suddenly missing. I fixed this by only updating the panel when it was visible. Once line of code fixed this, which was a nice change given all my other bug fixing shenanigans.

Once I had that code in place, I could use my previous toggle fix to get this feature working. This is a minor but important bug fix as the stats panel takes up quite a bit of screen real-estate. Having the player able to toggle this off, allows them to see more of the game. This is helpful even in these early stages as the player can see what refugee ships are incoming and gives them a few seconds to decide on a building plan.

Many awesome people who have played my game, told me that the building mechanic was really unclear. Often buildings would be build in seemingly random areas. This is not true of course but it does look that way! To fix this I had to add some highlighting functionality to each building block. At this moment in time I made a simple Unity Halo component and added it to the emptyRoom prefab. This shows a sexy pink halo around empty building blocks. I then had to get this working so that when a player clicked a building block, this sexy pink halo would pop up, indicating this is the block they have selected.

I thought about the best way to do this, and since I intend on having more than one level, eventually, hardcoding this was out of the question. I had to have any emptyRoom game object have this functionality. So I came up with a solution to add all emptyRooms to a list. This list would populate once a level was loaded. Once this was populated, I could check to see if any of the blocks were selected. If they were and the player clicked another block, the previous selected one would deactivate its halo and the new one would be activated.

In more detail, all blocks deactivate their halos when a player clicks on a block. After all rooms hide their halo, the current selected block activates his one. If the user clicks on another, the list is iterated over again, to hide any active halos, then the new clicked on is highlighted. You get the point.

A bug cropped up with this functionality. I was getting a nullpointer every time I tried to add a building block to the list. I couldn't figure this out and I knew that the cause was a simple one. I just couldn't place my finger on it. I read through my code and everything made sense. So I did something I never do, I asked for help! I posted on the Unity forums and the kind people there gave me a helping hand. It was just as I thought a simple issue, I just didn't see it as I was staring at code for christ knows how many hours. One of the draw backs to being a solo code monkey, the most valuable thing you can have is another set of eyes. Which, apart from my glasses I don't have! 

Anyhow the bug was being caused because the building blocks were being initialized before the list was. Even though I initialized both in their relevant classes in the Start() method, the blocks were still first. To fix  this I added the list initialization into an Awake() method and it worked like a charm. 

I need to read up more on Monobehaviour as when I started using Unity the tutorials said I always had to place my scripts in some kind of game object, even and empty one, for them to fire off. But after what the guys on the forum said yesterday there might be a way to execute things without messing around with the inspector. This would be a great help as I have a few classes that just need to be running constantly (the manager classes). I think this would also give me more control over what is being run and when. I need more control! D:

After fixing that annoying bugs all seems to be working neat but there's a new problem. If you are awesome and read my previous Ludum Dare posts you know that I destroy Building Blocks and instantiate a new building in the same spot. Because of this, the current halo code breaks. This is because the list, which contains a bunch of emptyRoom objects, is tampered with when a player builds a building. 

The previous list entry for a building block will become Null when a player builds a building in that blocks space as it gets destroyed. The list then tries to access a halo component on an object that no longer exists and presto, nullpointer. I'll fix this today as I just have to ensure that null values are ignored. If the player has a building there, I know they won't be able to build a new building in that spot. So there's no need to show a select halo.

That being said, I learnt from my previous mistake and need to think long term. I am toying with the idea of adding building upgrades. If I do this, then I will need to be able to highlight all buildings and not just the emptyRoom building blocks. If I do go ahead with this idea, I need to be careful about how I fix this bug. I'll look into things more today after I get home from work.

So a quick recap of bugs fixed over the week end:
  • Fixed the toggle panel bug (properly this time)
  • Fixed the stats panel update bug
  • Added building block highlights (fixed a bug but still buggy at the moment)
Once I get done with the highlight bug fixes, I'll be able to fix my stat numbers bug. Thank christ this is a numbers bug. Numbers never hide, follow strange Start() logic or lie! Numbers never lie!

Thanks for reading people :D

Salvation Update - Toggle is false, toggle is true, toggle is false, toggle is true...

My weekend consisted of this little boolean in my console output. Me and him became real close friends! In short, in my previous update I said I had fixed the GUI bugs, finally. This was not a smart thing to say, since it turns out that I did not. I had one panel fixed and working sure, the code was even pretty eloquent. However, I foolishly thought I could just apply the fix to all panel toggles the same way and everything would be cool! I should have known better! 

Adding the same fix to multiple panels toggle buttons, which are simple Unity GUITextures, caused utter chaos. This wasn't because they shared data between themselves. In fact this was the problem. Each toggle button tried to talk to other toggle buttons panels on their own. So the GUI could reach a state where a toggle affected another ones panel, which then screwed up the panels primary toggle. 

For example, toggle x has panel x, toggle y has panel y. When these work separately with their panels, all is well. Click a toggle, panel is set accordingly. However, now they talk to each others panels! So toggle y says to panel x, close yourself sir! Panel x does so but now toggle x says close yourself sir! Panel x doesn't know wtf is going on now and just breaks down in tears.

This was bad-news-bears, if I was only worrying about visibility then the worst that could happen was a panel popping up when it shouldn't. But since I have to deactivate a panel completely to hide it, I was running into nullpointers all over the place! So, I had to find a way to apply my toggle fix to all 4 panels and have them play nice with each other. 

So to fix this I did what I normally do, refactoring! Rather than have all the panels talk to each other in an uncontrolled way I made another manager class to coordinate the panels toggle buttons. This class would hold the state of all panels and if a toggle button wanted to know the state of a panel, it would ask the manager class. All the toggle buttons spoke to the manager class rather than each other.

This improved things but didn't fix the bug completely. I was still getting nullpointers on launch for many of the toggles. When the level loads, the toggle buttons all grab each others Panels and stores them for reference later on. The problem was that some toggle buttons do this faster than other buttons, for some reason. Once they grab the other toggles panel information, they then hide themselves. This is so the user doesn't end up with a bunch of panels all up in their grill, yo! 

Unfortunately, if one panel hides itself before a toggle button can grab the info they need, it results in a nullpointer and a broken toggle button. To fix this bug I had to implement a loading feature. It works pretty well and basically it goes like this: A toggle button loads in the required info from the other panel elements. It then tells the GUI manager it's all done loading its data and storing it for the harsh winters ahead. This is done by all toggle buttons that need data from other GUI elements. The manager class waits until it receives the OK from all relevent GUI elements (all the toggle buttons) and then sends out an OK to everyone who needs it. Once the toggle buttons receive the OK from the manager class, they hide all their panels and anything else that they don't want to have on display on level load. 

Finally, after many, many hours of crazy unorganized panels flying around and buttons running around my screen pooping out nullpointers, I have this fixed. I can't help but feel this is a crazy long way to code a GUI with a bunch of panels/toggle buttons. Maybe I did it the right way and just took longer because I didn't plan for it mentally? 

Anyhow, the next post I'll talk all about the Stats panel and how Unity's Start() method trolled me! :P

Thanks for reading and have a great day! :D