¡La Comunidad ha dado luz verde a este juego!

La comunidad ha mostrado su interés por este juego. Valve se ha puesto en contacto con este desarrollador para comenzar con los trámites que llevarían a su lanzamiento en Steam

NeonXSZ
Intravenous Software  [desarrollador] 5 de Dic, 2012 a las 14:10
Developer Diary (See inside for links to the new Daily DevLog)
When NeonXSZ was first published here on Greenlight we didn't have a dedicated website and this was the primary Dev-Log for the game.

The Dev-Log has now been transferred to our forums and has been updated on a near daily basis for the last six months. You can view it here: http://www.neonxsz.com/phpbb/viewtopic.php?f=2&t=11

We've left this older Developer Diary alive for those that are interested.

Última edición por Intravenous Software; 21 de Oct, 2013 a las 11:01
Mostrando 1-15 de 34 comentarios
< >
Intravenous Software  [desarrollador] 5 de Dic, 2012 a las 14:32 
New Upgrade Interface


A rework of the upgrade user interface yesterday and continued with it today.

The previous interface listed all the upgrades in a veeeerrrryyy long list. With each upgrade slot having at least 80 upgrades, and only 3 or 4 of them being visible in list at once, it made for a lot of scrolling and was clumbsy to use.

It was decided to scrap that system completely and replace it with a grid of upgrade icon/buttons.

(NB: It is because I keep scrapping things to improve them that Neon looks a bit rough around the edges. Things will get graphically polished once I'm certain they are permanent)


Each of these icon/button shows the Version Number of the upgrade and the percentage that the player has looted of it already.

The grid is 10 wide by 8 deep, and now we can see about 30-40 upgrades at once in the same screen space as before. It's still scrollable to see the other 40.

If the player hovers his mouse over one of the upgrade buttons a window pops up next to the mouse detailing all the information about the upgrade.

Eg. Energy Regeneration Unit, Ver 1.34, Tech Level 4, A description that includes it's effect, it's mass, and finally it's energy requirement each second.

So the player can now scan through all the upgrades much more easily.

Clicking a button will install it, if it is complete, or the ship's computer will tell them why the install failed.

The ships computer says things like "Upgrade installed successfully" or "Incompatible Tech Level" etc. Messages about what has happened are also sent as text to the message log.



New Shop Interface Integration

The shop interface was then incorporated into the same design. If you are docked at a shop and an upgrade is available at the shop, the original button for the upgrade splits into two buttons. The new one is labelled either "Buy" or "Sell".

You can sell completed upgrades if shops are interested in it. Each shop only buys and sells a small selection of upgrades based on the tech level of the area it is in. You can buy a complete upgrade or pay a reduced price to complete one that you have already looted most of the fragments for.



What's next

This is all about finished. I just need to tweak a few things and then I'll be onto the next job.

The next job is to build some 3D models for each upgrade type, so you can see them inside your ship and I'll use a little pic of them on the icon/buttons I was talking about above.

Oh, but before that an update the Hull Interface is needed to use a similar interface to the new upgrade interface described above. It should be much quicker to do that one because chunks of the same code can be reused. The buttons for the hull will be much bigger and have a little pic (maybe a silhouette) of each hull. It also allows me to do a pop out window for each hull (when the mouse hovers over them) with detailed info about the hull. The previous interface was too cluttered to allow that.

Última edición por Intravenous Software; 9 de Dic, 2012 a las 15:29
Intravenous Software  [desarrollador] 6 de Dic, 2012 a las 12:13 
Thursday 6th December 2012:

The first couple of hours today were spent finishing off yesterdays work on the new upgrade user interface layout. I basically just tested it all out, changed tooltips, cleaned things up, altered text colors, button colors, and that type of thing to make it look clean and more user friendly.

Next was implementing the same system for the hull swapping interface. Hulls are also now listed as a grid of button/icons, and the same method for buying and selling hulls has been used that I created for the upgrades yesterday. This took the rest of the afternoon to get fully implemented and tested.

This whole rework was quite a time consuming process because of the sheer ammount of data and systems that are connected into this interface.


Current state of the rework

So you can now once again buy, upgrade, swap, and sell all upgrades and hulls using this new system. It is all functioning and seems solid.

If you hover the mouse over any upgrade or shop button a window pops up next to the mouse with statistics about the upgrade or how much it will cost to buy or sell.

The hover window is fully working for buying and selling hulls but the hull statistics window is still empty. I finished the afternoon planning the layout of information for that window.


Hull Statistics

Hulls have a lot of statistics: their name and ship class, the ammount you have discovered, a worded description, shield radius, mass, number of turrets, missile storage space, missile creation speed, and then up to 12 upgrade slots which each have overclocking values that need to be displayed to the player.

All these systems are fully functional but until now there has not been a clean way to display this data to the player.



What's next

I have been planning to number the miscellaneous upgrade slots for a while so I could both assign hotkeys to them (for non-passive upgrades) and to more predictably swap upgrades between one hull and another.

Due to the need to display the overclocking data about miscellaneous upgrade slots it makes sense to number them now before I do the Hull statistics window.

So tomorrow will be spent setting up the numbering system for those and then creating the Hull Statistics hover pop up window.

Building some 3D models for each upgrade type will hopefully happen at the start of next week.
Última edición por Intravenous Software; 14 de Dic, 2012 a las 12:21
Intravenous Software  [desarrollador] 7 de Dic, 2012 a las 12:03 
Friday 7th December 2012

Today is Neon's Anniversary. It's a year to the day since the project was started

I'd like to say it doesn't feel like it's been a year but it does! Hehe. Anyway, on with today's diary.



Hull Statistics Hover Window

The main job today was to implement the Hull statistics window. This took much longer than expected. A few new systems had to be created to store and feed the large ammounts of data to this window in a performance efficient way.

It's all up and running now though and it's a great addition to the interface. Being able to easily compare all the data about each hull in a clean fast way is a huge improvement.

Extra time was spent polishing and tweaking all the interface work that was done this week to make it as clean and user friendly as possible. The buttons change colour to show at a glance if it's possible to install an upgrade or hull, and plenty of feedback to the player was added in verbal ship computer messages, messages to the log, tooltips, and information panels to help make the whole thing as intuitive as possible.

The remainder of the time today was spent testing it all out and ironing out any last kinks and bugs with it.



What's next

I will spend a few hours on simple cosmetic changes to other areas of the interface and then I want to crack on with building the 3D models for the upgrades themselves. The eventual plan is to have various models of each upgrade so that a visual difference can be seen as upgrades grow in power.

That is one of those graphical polish things that isn't essential right now but will happen in time. However, it will add a great deal to the overall look and useability of the interface to have at least one model built for each upgrade type so it's easy to differentiate them at a glance. Little pics/icons of these will be added to the new button system that was implemented this week.

If you are reading these Diaries, could you leave a message in the 'Chat with the Developer' discussion so that I know that there are a few people out there who like this stuff.

Thanks,

Paul
Última edición por Intravenous Software; 9 de Dic, 2012 a las 15:35
Intravenous Software  [desarrollador] 9 de Dic, 2012 a las 15:06 
Sunday 9th December 2012:


Plans for the next 2-3 months

This weekend a road map for reaching the build needed for both initial alpha testing and a demo was planned.

Here is a list of the things that should be achieveable in the next 2.5months leading up to the end of February.



1. Create around 100 3D models to represent the upgrades inside your ship.
Right now they are all visually just placeholder cubes.

2. Give the whole interface a graphical overhaul.
Currently the entire interface is made up of text labels with text data. It's time to update that to a graphical interface where icons and bars can replace all the text wherever appropriate.

3. Mouse hover tooltip system
A new tooltip system is needed so that the player gets a pop out tooltip next to their mouse whenever they hover over icons or bars or any other objects in the interface. These will explain how everything works and will serve the purpose of both teaching and guiding the player through the game without the need for boring tutorials.

4. A preliminary update to the cockpit.
This will not be a final rework. The flat panel information screens will need to be retained for now until the information needed on them can be finalised, but for the alpha/demo version a higher detail model will be made for the rest of the cockpit. The current cockpit was thrown together in ten minutes and it looks fugly.

5. Improve the current ship designs.
There are some that are really horrible and need serious work or complete replacements. Experimentation with different ways to improve their overall look is needed. Although there are currently thirty three different ship types, ten different models should be fine for alpha. Later more will be added.

6. Seven more room variations need to be made.
This will allow all the malware and virus areas to have their own variants on the existing room designs. Unfortunately, designing completely new rooms is one of the most time consuming processes. They take between 4-8 days each depending on size. Thankfully these seven new rooms are variants on existing rooms and they generally take about a day each.
However, dont expect the alpha/demo to have massive differences between one station and another in architecture. Eventually there will be 50+ different rooms but to achieve that will take a further 20+ weeks of solid work doing nothing but modelling rooms. That will come later. The plan is to have these new rooms unlock as the player levels up and they unlock higher difficulty spacestations.

7. Even more boring stuff
A whole slew of behind the scenes stuff like finalising the save game system, the user interface for rebinding keys and many other boring things that need to be done.


Disclaimer
Invariably in game development many things can take much longer than expected. Although it is theoretically possible to achieve all the above in 2.5 months it's possible some of them may not go smoothly and cause delays. Only time will tell but that is the goal.


Final Thoughts
As there doesn't seem to be significant interest in daily updates I expect to do updates on a weekly basis in future or when significant milestones are met.

If you are following the progress of Neon please stop by for a chat in the 'Chat with the Developer' discussion. The initial buzz of traffic has already calmed down so it will be a quiet time in here for the next couple of months. It's inspiring to get feedback and encouragement from those who are interested in the game.
Última edición por Intravenous Software; 9 de Dic, 2012 a las 15:51
Intravenous Software  [desarrollador] 14 de Dic, 2012 a las 11:55 
Friday 14th December :


Major Interface Overhaul


The interface has gone through a very significant upgrade this week.


New 3D graphics for all the major upgrades
All the core upgrades were modelled in 3D this week. While the player is at the Ship Configuration screen, all these upgrades can now be seen sitting inside the upgrade slots of your ship (replacing the old placeholder cubes seen in the screenshots). Over one hundred individual models now represent the various versions of all the upgrades. This is a major step forward.


New 2D icons for all upgrades
Last week a new upgrade interface was added that presented the player with all of their upgrades in a grid of buttons.

Because 85% of the upgrades now have 3D models, pictures were taken of these and then placed on their corresponding upgrade buttons in the user interface. This is a huge improvement. Now the player can see all his collected upgrades as a grid of buttons with pictures of each upgrade on them.

When the mouse hovers over one of these buttons a window pops out showing a larger picture of the upgrade and all the statistics and information about it. Clicking the button will install the upgrade into the appropriate slot.


New font and design
Along with all graphic improvements listed above, the whole interface has been updated with a new font style that better suits the sci-fi style. Whereas before all the text was white with a generic Arial font size (because it was all placeholder), it has all now been updated with various font sizes, font colors, and highlighting to give it a far more 'designed' look and make reading all the information easier.


What's Next
There is a little more work to be done on the Hull Interface before this stage of the user interface overhaul is complete. The plan is to get this done tomorrow. Like with the upgrades, the Hull window is now a grid of buttons. Images of each hull need to be made and placed on the buttons and the Hull Statistics Hover Window needs updating to include a picture of the Hull and better layout the information around it.

Once that is done new screenshots of it all will be made and should hopefully be uploaded by tomorrow evening or Sunday at the latest.

This diary entry should be updated once that is complete with new information about what is happening next.
Última edición por Intravenous Software; 14 de Dic, 2012 a las 12:08
Intravenous Software  [desarrollador] 21 de Dic, 2012 a las 13:23 
Friday 21st December:

The goal this week was to address the two most common concerns expressed in the comments here and other places Neon has been shown.

1. The colour scheme being too repetitive, too dark, too red, too green etc. :)

2. Difficulty seeing enemy ships.

At the same time I wanted to spruce up the graphics a little. Now that Neon is out in the wild the graphics are obviously far more important than they were while I was simply trying to get everything working and fun.



New Colour Schemes
The week began by experimenting with different colour schemes to see what was possible. It soon became evident that Neon could look and feel very different.

Having done a few examples of what was possible last weekend, it became clear that some players loved some colour schemes that I thought were ugly, and disliked some that I thought were cool. Rather than force a player to endure a colour palette that they didn't like it made sense to create a system that allowed the player to choose whatever colour scheme suited them.

Some feedback suggested colouring different areas based on the controlling faction. I'd considered this too but chose against it because it could be confusing. Imagine I made the Virus controlled areas red, but then the player became friendly with the Virus faction. Having red as friendly and green as hostile seemed counter intuitive.

Therefore, I wrote new systems that automatically changed the colour of the world in realtime based on whether the faction controlling the area was hostile or not. Each colour scheme now has two styles. One style for the friendly areas, and one style for hostile areas. If the player causes a faction to become hostile, their environment will immediately switch to the hostile version of it's colour scheme, and vice versa.



Environmnet Colour Changes on Events
A few people liked the idea of having the world change colour upon different events happening. For example, the world might change colour as the player flew faster, or flash a certain colour when they levelled up, etc.

The only way to test this was to write the code to make it happen. Rather than write a new piece of code for each event, I decided to write a complete system that would allow me to do this type of thing easily.

The result is that with a single line of code I can now change the colour of the environment, it's entire texture, it's lighting colour, how shiny it is, and the brightness of the main lighting of the world and then have it fade back to normal over any given time.

The first use of this was to make the whole world flash red whenever the player took damage. It only lasts for half a second and is surprisingly unintrusive.

The second use of it was to make the world totally black when the player teleported, and have the world slowly fade into colour and brightness over 6 seconds.

Later the plan is to use this new system to signifiy many other events in the game but for now I moved onto other things.



Colour Presets
I then began the process of actually creating and recording various colour presets. 8 distinct colour sets were developed. Each had a different but complimentary version for friendly areas and hostile areas.

Next a 'Customise' button was added to the options menu that made a list of all the presets appear. The player can click on a preset and the world will instantly change to that preset.

This system allows the player to change the colour at will, or simply play the whole game with their favourite colour scheme.

The idea is to later have these colour schemes unlock as the player levels up. The game will maybe start with four variations and a new one could unlock every 5 levels or so. I think this will be a nice added bonus for players as they level up to change the look of the game and keep it fresh.


[b Environment Texture Warping [/b]
This idea had been around for a long time but only got implemented this week. The idea was to have the texture on the environment slide across itself. It creates a very strange but cool effect and was surprisingly quick to add now that similar code existed for controlling the colours of the environment.

This effect was added when the player teleports. So now after a teleport the whole enviroment texture is warping and sliding over itself while fading in from jet black.



Recoloured Ships
Having had many viewers of the video complain that they had a hard time making out the ships against the black background, I started experimenting with different ways to texture the ships to deal with that issue.

After a few hours a solution was found that seemed to work nicely. It was basically to invert the colours on the ship textures. Rather than the ships having red lines on a mainly black surface, it was swapped around to being black lines on a red surface. This made them stand out far more. It was taken a bit further than this and the ship's textures were reworked to have a selection of white, black and red (or white, black and green for friendly ships).

However, I still liked the original design so a new button was added to the 'Customise' menu allowing the player to toggle between the two ship colour schemes. If they prefer the black ships with red/green lines they can have all the ships look that way, or if they prefer the high visibility ships they can have them instead.

Finally code was added to automatically recolour ships based on their hostility to the player. Before all ships were red lines on a black surface. Now friendly ships are green, and enemy ships are red. They all swap automatically if the players reputation changes from positive to negative or vice versa.



New Cockpit
The old cockpit, seen in the trailer video, was fugly and was a placeholder design. During private development I was more concerned with finalising what data needed to be on the cockpit rather than how it looked but it was well passed time to give it a freshen up.

I didn't want to spend a long time on it because the data to be displayed is still going to change a lot over time.

A higher detail, neater version of the cockpit was built for all the data screens to sit on without wasting too much time because it will likely be totally replaced in the future.

I also reworked the font used by all the displays which took a surprisingly long time to get looking right.
Última edición por Intravenous Software; 21 de Dic, 2012 a las 13:29
Intravenous Software  [desarrollador] 4 de Ene, 2013 a las 4:21 
4th January 2013:

If you are reading this you are probably interested in Neon enough to know that development paused for a week over Christmas. Things started again this passed Monday. That was until I caught flu, bleh.


Monday: Odd jobs and optimisation

The week started out with some GUI optimisation work. The new upgrade system and GUI overhaul had added some slow down in the menus so that was sorted out first.

A bunch of little jobs that aren't worth mentioning, but had been on my list for a while, were then cleaned up, implemented, or tweaked.

Ship textures received some minor tweaking along with a couple of the environment colour presets. Most notably the default green friendly design seemed too garish and was toned down.

On Monday evening, after finishing work, I was very suddenly caught with flu. Lots of coughing and a mild fever came out of nowhere.

Nevertheless I pushed on working through the week. I was modelling for the remainder of the week which is a job that requires plenty of time rather than concentration.


New Virus Infected Areas

Each internal room in Neon has different variations depending on which faction controls it. For example, Virus controlled areas have all their textures and lighting out of whack, the environment objects are all knocked over and a mess, and then there is an infection of cubes growing across them. The goal this week was to ensure each unique area design had a virus version.

Previously these Virus variants had taken most of a day each to complete but I was happily suprised to find that even while feeling sick I was able to make three variations for a single area each day. Each variant takes the same base room design (for that area) but the cube growth was replaced for each one which can change the flow of a room quite significantly. The growth could block off certain areas or cause docking ports to be disabled etc.

This work continued through until Thursday but then unfortunately on Thursday evening the fever from the flu reached it's peak and coughing and sneezing kept me awake until 4.30am. So today I feel rough as old boots and plan to rest and hopefully beat this infection before the end of the weekend. I don't imagine any work will be done today.


What's next?

There are 3 more Virus infected room variants to do that should have been done today but will need to wait until Monday.

The same process then needs to happen for the Malware infected areas. Currently only one Malware variation has been made, and they take longer than the Virus ones. It's more likely that only one variation can be made per day, rather than three. I also plan to experiment with some new ideas for the Malware areas before I plow ahead with that work.

I also have a long list of other jobs needed prior to the start of alpha testing so no doubt I will chop and change between those and modelling over the next couple of weeks.
Intravenous Software  [desarrollador] 11 de Ene, 2013 a las 9:55 
Friday 11th January

The week began on Monday by creating two more Virus faction room variations and getting a third one 60% complete. This one was completed on Tuesday morning.

It was then time to move on to creating Malware room variations. These are more complex and time consuming than the Virus variants.

Upon starting this I realised it was time to fix up some bugs in one of the original rooms so I could use it as a base for the Malware version. There were missing polygon bugs, and some of the environmental objects were missing lightmap UV's. (This was because it was the first room ever built for the game)

Once the bugs were fixed I also needed to recreate the lightmaps for this area. Unfortunately during the creation of the lightmaps I ran into a silly idiosyncracy in Unity and lost ninety minutes trying to work out what was going on. In short there was no time left on Tuesday to start the intended Malware variations.

Wednesday saw the creation of the Malware variant of the room that the video starts in. This took the whole day to create and get fully set up and working in the game engine.

Thursday was spent building another Malware room variation for one of the other larger rooms. The final couple of hours were spent experimenting with the texturing of these rooms. The result was an extention to the Colour Controller script to allow for extra colour textures in Malware areas.

Malware variations now take the existing room design but fade out all the texturing to look washed out. The Malware infection then spreads across the room with a different texture, along with extra simplified Malware geometry replacing or deforming some of the existing features (like the infection is taking over control). Some areas of the room are broken/unused by the malware infection so lights, fans, and other systems no longer work. The result is an improved variety to the look and feel of the Malware areas.

It wasn't mentioned last week but a similar thing now happens in Virus infected areas. In Virus areas the original room design is totally messed up and the virus itself is shown as cubes growing across the room. This can be seen in the video and some of the screenshots. However, the cubes are now a different colour to the rest of the room to add some visual variety.

So, both the Virus and Malware areas now have a more varied visual look than is seen either in the video or the existing screenshots.

The week ended with one final Malware variation being made for the biggest existing room in the game.


Conclusion
Each totally unique room design now has two or three Virus variations, one Malware variation, and the original OS version. There still hasn't been time to give the AntiVirus faction a unique look (it still shares the OS room designs) and I expect this to remain true until after the alpha testing has started.

Designing, modelling, texturing, lighting and then setting up the rooms in the game engine is easily the most time consuming single job in the creation of the game. To create a single totally unique room design takes five to eight days - dependant on room size. Malware variations of these then take a further full day each, as do Virus variations, and ultimately I expect each Anti-Virus variation to take a further day each. So on average to create a single new room with a variation for each faction adds up to two weeks of work.

Needless to say, months of this type of work is still needed before the randomly generated station tech really starts to shine, but at least the Malware faction has it's own version of each room and the Virus faction has two or three variations of each room. Therefore, the Virus areas currently show the most randomisation.

What's Next
There are now just six weeks left before the end of February which is the intended date for having the first alpha build ready for some testing. I still have a long list of things that must be sorted out before that happens and quite honestly I haven't decided what order I'm going to tackle that list.

We will just have to wait and see. Check back next week to find out. :)
Intravenous Software  [desarrollador] 19 de Ene, 2013 a las 4:13 
Saturday 19th January - Part I

As expected, it was a very busy week with lots of small jobs, tweaks, and bug fixes, along with an unexpected rather big job forcing itself upon me on Thursday. I'll write it all up on a day by day basis. It will likely be broken up into multiple parts because so much happened.



Monday's Work


Key Binding / Reconfiguring
The first job was to go through the code to ensure all keys could be reconfigured by the player. Some keys were previously hard coded.

Unity has a built in system that lets the player reconfigure keys prior to launching the game but while doing this I realised that this system is very limited. There is no way for me to find out what keys the player has reconfigured. I'd always intended to add an in game key configuration system, but it seems this will have to wait until a later date because it is a big job. For now the player can reconfigure the keys but not in-game. That's not ideal but it's enough for now.


Greyed out cockpit weapon buttons
I then added code to grey out and disable the cockpit weapon buttons if that weapon was not 100% discovered by the player. This was a longer job to get working than expected.


Tweaks
~ Reworked the skull texture used to show utterly lethal enemies on the radar. Previously it was hard to see it was a skull because it was so small.
~ Added code to make enemy ships better utilise their missiles. Each ship hull has a missile storage space and a missile creation speed. The chance for a ship to fire a missile is now based on the missile capabilities of the hull they are using.


Collision Damage
I wanted to add a very small ammount of damage whenever the player collides with another object. The ammount of damage is also relative to the speed of the impact. Impacts below 15m/s cause no damage. An impact with a wall at top speed causes only 5% damage. Two ships hitting each other, head on, at maximum speed causes about 10-15% damage.

The damage is deliberately low. I don't want to overly punish the player for impacts, but I did want to give them a small reward for careful flying.

With the code that calculates collision speed in place, I was able to alter the volume of the impact sound to match the speed of the impact.


New Shield Hit Effect
Whenever the player previously took damage, his shield would flash. It was a very quick and ugly effect and it needed replacing.

I created a much more advanced effect. Now an energy ring will start at the point of impact on the shield and then slide and wrap around the shield before fading out at the opposite side. This ring can also be seen sliding over the shield from inside the cockpit, so it gives the player visual feedback about what direction any damage comes from. This can happen multiple times at once with multiple rings sliding over the shield.

If the player collides with the environment the ring is white. If he takes damage from an enemy the ring is red.

Time was spent improving the shimmer on the shield to go along with the rings. Shield impacts now look considerably cooler and give far more feedback to the player both visually and audibly.


Fan sound effects
Time was spent creating an appropriate sound effect for the many wall mounted fans in the environment. This progressed to extending the script that controlled the fans. They now have randomised speeds with the new sound effect altering to match the speed of the fan.

Hex Screen Hum
I then wanted to add a hum to the Hex Screens like are seen at the very start of the original promo video. I created a sound effect and added it but I didn't really like it. It didn't seem right to have them making a sound, so it was removed.


NB: All the above was done on Monday alone. See below for Part II of this diary.
Intravenous Software  [desarrollador] 19 de Ene, 2013 a las 4:54 
Saturday 19th January - Part II
See above for Part I of this weeks diary.

Tuesday's Work

Brightness Control
I spent a while looking into how to add a brightness slider to the game. I was staggered to find out that it wasn't possible in Unity without writing custom shaders for everything. There is an ambient light level control that I'd used before for this type of thing but now that the game uses lightmapping the ambient light is baked into the world and can't be altered.

The result was that I had to give up on this option. The solution to this problem will be to ensure that there are some bright colour schemes that the player can select.


Field of View (FOV) slider
I then added an FOV slider to the options window. This went in quite quickly but it caused a number of graphical glitches that needed sorting out.

When the player zooms in, the screen highlights around the border. This stopped working correctly with user configurable FOV so I needed to replace the entire system for this effect so it could handle various FOV's.

High FOV's were also causing the camera to clip inside the players ship, allowing him to see ugly artifacts. I had to go through every hull and tweak the position of the players view point to fix this. I tried to alter it dynamically but that caused more problems than it was worth.

FOV settings were then added to the gameConfig.ini file so that they get recorded and loaded between games.

Finally the options window got reorganised to allow enough space for the FOV slider.


Quit or Restart Dialog Boxes
I had to then write code to allow simple dialog boxes to appear in the middle of the screen. You know the type of thing - "Are you sure you want to Quit" with "Yes" and "No" buttons.

You might think that Unity would offer a simple Dialog box feature but it doesn't. I had to code one up from scratch. I used it to check if the player definitely wants to quit or restart his game. It's a simple thing but utterly essential so it needed to be done.


Friendly Fire
When a ship gets shot, it can turn hostile to the attacker, even if that attacker is from it's own faction. It turned out that this was happening a little too often.

To tweak this I first added code that prevented ships from calling for assistance if their target was a ship from their own faction. I then tweaked the code to give each faction a slightly varied chance to fight back if shot by a ship belonging to the same faction.

Malware ships are more free for all in nature. They are now more likely to have infighting than OS ships for example. Virus ships are generally more hostile all around especially towards opposing factions.


GUI refinements
A number of areas on the user interface were tweaked and tidied up. Primarily the options menu at the title screen.



Wednesday's Work

The day started with a few more GUI tweaks. I then fixed a bug caused by the new collision damage code that was making ships turn hostile if they bumped a wall. The damage they took was making them think they were under attack. LOL.

I then added a sound effect to smoke stacks. These are environmental objects with particle smoke. I had to go through the entire game adding them to each one manually.


Advanced Colour Schemes
The previous colour scheme update changed the colour of areas dependant on whether they were hostile or friendly to the player. Each of the game's colour schemes had a friendly design and a hostile design.

I wanted to extend this so that each faction had a slightly different look for both friendly and hostile colour schemes. I added code to allow this and then began work setting them up. It turned out to be a long job. It took about 2 hours per colour scheme to tweak, test and set up the extra colour styles for each faction.

By the end of Wednesday, two out of the eight colour schemes were set up to use this new system. I'll set aside a day or two to rework the others soon because I ran into a more pressing problem.....


Playtesting
During some playtesting on Wednesday evening it became apparent that Unity was having some serious problems with all the new sound effects I'd added. Unity has a component called an AudioSource that is attached to any object that we want to have a sound effect. Think of it like a speaker.

Adding these to all the fans and smoke stacks had obviously pushed Unity passed it's limit. Every ship in the game has an AudioSource for it's engine sounds, and all the new sound effects meant that in total there were over 1000 AudioSources in the game.

The result was that the Unity's sound system was overloaded. Some sounds wouldn't play, others were playing at full volume when I was nowhere near them, some were crackling and popping constantly. This was a serious problem, and needed a serious solution.

See Part III of this diary below for what needed to be done.....
Intravenous Software  [desarrollador] 19 de Ene, 2013 a las 5:49 
Saturday 19th January - Part III
See above for Part I and II of this weeks diary.

Thursday and a new Sound System
Due to the problems discussed at the end of Part II of this diary I needed to set aside the day to fixing these sound problems.

The result was that I needed to take over complete control of how Unity dealt with AudioSources (speakers for sound effects) in the game.

Instead of putting a speaker on every object in the game that needed to play a sound effect (which was totalling over 1000 speakers) I had to create a dynamic system.

The new system is that any object that needs to play a sound effect now has a little script on it called AudioSauce instead of one of Unity's AudioSource speaker components. This script knows what sound needs to be played, at what volume, and with whatever other settings like rolloff, max distance etc.

As the player flies around the game the player's ship 'collides' with objects that have these new AudioSauce scripts. We use imaginary physics collisions for this job. If it finds one it creates a speaker at that location and then plays the required sound. If the player moves away from that object, the speaker is disabled and put back into an imaginary storage box waiting for the next object that needs a speaker.

The result of this is that instead of the game having 1000+ of these speakers it now reuses the same 20-30 speakers continuously. It dynamically moves them around the world to whatever objects are near the player that need to be playing a sound effect.

This was a very complicated job to set up. Imagine we have all these enemy ships flying around passed the player and speakers are jumping around all over the place so that we can hear their engines, or jumping to a nearby fan or docking bay. It all needs to be done without the playing having any idea it's happening.

However, it was worth all the effort. All the sound bugs were solved by this solution, and it is also far more efficient. Having everything set up this way also means that tweaking and altering sound effects can now be done in one place rather than going around altering the settings of every AudioSource in the game one by one.

That was until a new bug appeared due to this change....


Bug: Too many colliders
The new system above worked by having a physics collider on every object that needed to play a sound. These were like imaginary invisible colliders. Basically it is a fast and efficient way for me to know if the player is near one of these objects.

The problem was that now Unity was bugging out because it had too many colliders active at once. Arg. I'd gone from too many AudioSources to too many Colliders. With too many colliders everything in the game was acting eratically. I could be shooting empty space and a nearby ship was taking damage for no apparent reason.

Luckily, every ship already has a collider to know if it bumps into anything or gets shot. The solution was to use these same colliders for the new sound system.

The result of that change was that I was able to massively reduce the number of colliders because ships already had lots of optimisation code to disable their systems and colliders if they were far away from the player.


Playtesting
To ensure that this new complex system was fully working I did a two hour playtest session. It all seemed flawless. All the audio bugginess was gone and everything seemed slick and bug free. Phew. That could have been a game breaker.

However, by the end of this play session I had a list of minor bugs or gameplay tweaks that needed sorting out. So that's what I set aside for Friday's work.




Friday's Work
Friday was a day of minor bug fixing and tweaking. For completist sake I've copied my list below that reads rather like patch notes.



~ Fixed bugs with 'Escape' key usage. To exit the user interface, or show Quit Dialog if in game.
~ Fixed a bug that caused undiscovered upgrade buttons, and hull buttons, to give no verbal warning as to why they wont install.
~ Fixed a rare bug that allowed the Ship's Computer to speak while the player was dead.
~ Fixed a bug that prevented the Hull window scrollbar from appearing under certain conditions.
~ Fixed a bug that caused military/security ships to respawn too quickly.
~ Added random variance to respawn timers for each ship
~ The size of dropped hull fragments from enemy ships was doubled to increase the rate at which the player can unlock new hulls.
~ Fixed a bug causing Hull Statistics windows to be incorrectly sized if the hull was not 100% complete.
~ Updated GUI Front End Menus and in game message system to use the newer font design.
~ Reworked the algorithms that determined which items each shop sold to be more in keeping with what was intended.
~ Fixed a bug preventing upgrade button icon images from appearing if sold at the current shop but were less than 100% complete already.
~ Fixed a bug where upgrade buttons would be green (installable) even if less than 100% discovered, if it was for sale at the current shop.
~ Main Message style converted to new font style and resized.
~ Fixed a weird bug that made upgrades appear in the opposite order in the final build to when testing in the editor.
~ Fixed a rare bug that allowed enemy ships in dock to start firing at a target.
~ Created a new icon for the HUD targetting for when ships are behind the player to make it more obvious. Added code to prevent most target HUD information appearing when the enemy was off screen.

Added a compass marker to the Radar
To allow the player to better orient himself within the game world I had long intended to add a marker to the radar that always pointed 'north'.

This proved to be far more complicated to achieve than imagined. However I won't bore you with details. The result after a couple of hours of testing and tweaking is that the radar now has an arrow pointing north, but it doesn't just rotate around the edge of the radar. It moves through the radar in 3D so the player can even know his vertical rotation compared to world north.


Conclusion
Wow, that was a lot of changes for one week. The game is getting really close to being ready for alpha testing now.

I suspect that next week I will finally get around to fully implementing the save game system. I did preliminary work on this a couple of months ago, but you can probably imagine that recording every piece of relevant data and then reading it all back into the game is not a trivial task. It wouldn't surprise me if I spent an entire week setting this whole thing up to work in a robust and bug free way.

I'm also seriously considering removing the Anti-Virus faction from the game, or merging them with the OS faction so they intermingle. Having to redesign everything for 4 factions obviously takes 33% longer than doing it for 3 factions, and currently there is next to no difference between the OS and AntiVirus factions. There simply hasn't been enough time to differentiate them like I've done for the Virus and Malware factions. I also think the game would be better to have more 'enemies' than 'friendlies'.


Feedback
I know these Diary's only appeal to a select few fans of the game, and most people will not read through them. However I'm happy to keep doing them as long as there is continued interest.

So if you are one of those people who read through all 3 parts of today's Developer Diary, please leave a comment to say so. They take a long time to write up and I'd not do them in such detail if only one or two people are reading them.

Thanks, until next week....

Paul

Intravenous Software  [desarrollador] 25 de Ene, 2013 a las 12:45 
Friday 25th January

If you are reading this you will already know that Neon went up on Twitch.tv last weekend. Since then there have been three live playtesting streams.

Originally I planned to work on the save game tech this week but the playtesting highlighted other issues that needed to be addressed so it was a natural progression to work those out while they were hot.

# Fixed a bug that was causing the lightning gun to occassionally get stuck active on enemy ships even when they weren't using it. It was a rare bug that appeared after two hours of testing. The same bug repeated once later and got another fix. Hopefully it's done now.

# Made lots of alterations to the ammount of upgrades sold at the various shops so that the player can find what he wants more easily.

# Over the course of the week the algorithms for controlling the size of loot drops got tweaked and retweaked many times to ensure upgrades, hulls and weapons can unlock at the desired rate.

# Added extra configurable hotkeys. All actions should now be hotkeyed and configurable.

# The HUD got an upgrade. The graphics were changed to help reduce blocking the view of the targetted enemy. The target reticule now disappears if an enemy is not in the line of sight, and the whole HUD fades down to make it obvious that the target behind a wall.

# Updated the hud to include the radar icon for the selected ship so that the player can tell at a glance if his target is above or below his own level and by how much.

# Having playtested the F2 Fighter, changes were made to missile damage and the damage of some of the weapons. The Inferno gun is now a much higher damage with higher energy cost which suits the single turret of the F2 fighter perfectly but will drain the energy on a dual turreted fighter quickly. This helps balance the F2 and M1 ships.
The F2 also got a boost to it's missile creation speed to help compensate for it's single turret and got an extra boost in speed with an overclock to it's engine slots.

# The algorithm controlling reduced damage against higher level ships was tweaked to allow ships that are 3 levels higher than the player to be killable. It requires a long fight and careful play but it can be done.

# Converted the first Twitch.tv video to YouTube so it could be added to the Greenlight site. This was a long winded process.

# Annotated all the videos. Added Annotations to the main Neon Trailer to better highlight features in the game and directly link it to the playtest video.

# Added a Call For Help feature to the player. The player can now hit a button on the cockpit or use a hotkey to ask all friendlies within radar range for help to kill his target. Ships from each faction will respond differently to these calls and spamming for help will also reduce their chances of helping. This allows the player to more effectively deal with ships above his level. The player has always got loot drops based on the percentage of kill damage he did so he can't abuse this new mechanic to farm above his weight.

# Unified the code and algorithms for the different loot fragments and tweaked them. The player should now be able to unlock the first new weapon within the first 90 mins - 2 hours, and the first new hull within 3-4 hours.
The look of loot drops was also tweaked to better show the 3D model inside them.
The levels at which the different weapons unlock was altered. 4 of the existing weapons now unlock before level 5 to allow the player access to a bigger arsenal earlier in the game. I'll add extra weapons to unlock at later levels.

# Tweaked the uranium fragment algorithms to drop more uranium overall. Reduced the reduction to uranium dropped when fighting lower level ships to make farming low level ships a more balanced and viable gameplay option. Farming low levels can be very fast and fun, rather than the slow considered approach needed fighting higher level enemies.

# Did a complete overhaul of another area of the sound system. To cut a long story short it didn't solve the issue I was having and eventually reverted back to the old code. The old code was then reworked to remove the problem. The sound system is now rock solid again, without the issues found in the latest stream.

# The playtests highlighted a strange bug with radar tags getting stuck at the edge of the radar when ships were no where near the player. It was rare and random, and was a strange bug to track down. A fix for one possible reason was implemented and it's not been seen again in the last few hours of playtesting.

# Removed a tiny clicking in the thruster sound effect when it looped along with similar issues with other sound effects. Lots of minor alterations were made throughout the sound code to better clean up random clicking and popping artifacts.

# Fixed a number of errors in the particle effect positioning in some of the newer areas.

# Created a new colour scheme. This is an even more extreme version of the colour scheme seen in the original video. It's very neon in look against a very black background with a new crisp sharp outlining. More old school and vector like. This is fully functional with variations for both friendly and hostile on all four factions and is the new default colour scheme. The brighter colour scheme used in recent videos was due to complaints about the game being too dark but I didn't like it so much. That scheme is now "Default 2" for those who think the new one is too dark.

# On Friday I began work on a new Front End interface for selecting the games difficulty. This work is not yet complete but already includes the interface for 4 preset difficulties and a custom difficulty. The plan is to have the difficulty setting effect the size of all loot drops.
Playing Neon on Easy will result in 15% smaller loot. Play it on Harcore for 20% more loot. Play it on Elite setting for 50% more loot. This will be finished at the start of next week.

# Fixed dozens of tiny glitches, and bugs that showed up during playtests that are not really worth mentioning. The last offline play session lasted 2 hours and I didn't find a single bug. Don't worry, I'm sure to make some more soon :)

# Did a significant rewrite of the Greenlight description. Please read through it again and let me know if it is an improvement. This came from asking for feedback about it on another forum. The idea was to make it sound more lively and exciting without exaggeration or hyperbole.

# Overall it was a busy week with many late nights. 10 hours of live streaming and a whole slew of bug fixes and tweaks to get the gameplay ready for alpha. Things are looking great for the alpha. Although I still have a few big jobs to do, there is plenty of time and the game is feeling really solid. The alpha shouldn't really be about finding bugs but more about balancing all the different ships and gameplay. So the alpha should feel more like a beta but without the content levels I plan for beta.
Intravenous Software  [desarrollador] 2 de Feb, 2013 a las 6:42 
Saturday February 2nd:

This week began by finishing off the new Difficulty options window. Recruit, Normal, Hardcore, Elite and Custom difficulty settings are now available. Each difficulty setting alters the starting intelligence of enemies (higher level enemies have ever higher intelligence on all difficulties). The difficulty also alters the damage from enemies. A custom difficulty is also available where the player can manually set the enemy's starting intelligence and damage.

An algorithm was written to calculate loot size based on the difficulty of the game. Playing at a higher difficulty results in more loot.


The Save Game System

The majority of the work this week was spent on the save game system though. This was a time consuming job to store all the randomized information from the hundreds of upgrades, dozens of hulls, and all the data on which upgrades the player had previously installed in each ship.

It was even more complex to read back all of that information and put it back into the right place in the game.

To put things into perspective, the code to save and load the game reached nearly 1000 lines of code. That didn't include the user interface for the system.

However, it's fully functional now as far as I can tell.

After getting the code to Save and Load a game complete, it was time to create an interface for that system. I chose to create a 10 slot save system. The player sees a list of the 10 slots and can select one to enable Saving, Loading, or Deletion of the slot. Each save slot records and displays the players Tech Level for that save and the date and time it was saved.

Code was then added to calculate how long the player had been playing a specific game. This was saved to the save file and read back in when loading to keep it up to date. TimePlayed is now also displayed for each save file.

A Quick Save hotkey was also added. When at the save window, the player can select a save slot and then return to his game. Pressing the Quick Save hotkey will overwrite that save file during play. The player can change which save slot is overwritten by the Quick Save at any time.

When the player now starts Neon, it automatically loads up his previous saved game. While the player is at the Main Menu screen, the game is creating the world and setting up all of the enemy ships in the background. This has always happened but now it is doing it with his loaded game.

This means that pressing "Continue Game" takes the player instantly into his previous game.

If the player presses "Start New Game" the game world must restart to flush all the loaded data and rebuild a totally new game. This only causes about a second of delay though.

Autosave slots currently exist but there wasn't time to implement them this week. They will be one of the first jobs on Monday and shouldn't take long.


Rebalance
I'd decided that individual battles were taking a little too long. I felt the game would be more fun with things a little faster.

I tested a number of tweaks to achieve this and finally settled on increasing the damage of all weapons and missiles by about 40%. This is more significant that it at first seems. All ships regenerate their shields so shorter fights means less regeneration.

The result of this change is that a skilled player can target an enemy and charge at them. With accurate aim he can expect to take them down much more quickly. It both speeds up the combat but also rewards getting in close to do maximum damage before the enemy has time to react. (NB: Enemy AI controls their initial reaction time to the player appearing, and how fast they react to being shot).

You might think that this change makes the game easier but far from it. The enemies use the exact same weapons as the player so their damage is now increased also. I died far more after making these changes than previously but it is an improvement.

There is a definite emphasis now on faster closer combat fighting. The reward for getting the jump on an enemy is significantly more pronounced.

The plan is to soon include extra close range, high dps, weapons to encourage the player to get in closer. There is also a plan for a shockwave weapon that is almost like a melee weapon. This would have severely limited range but extreme damage. The idea of that weapon is to encourage the player to charge at an enemy, bringing down it's shields with regular weapons and missiles and then finish it off with a shockwave at super close range.

That's it for this week. The alpha build is still on target for the end of this month.

Intravenous Software  [desarrollador] 8 de Feb, 2013 a las 10:33 
8th February 2013

The start of alpha testing is so close now and it was another successful week of tweaking, tuning, fixing and improving dozens of different systems.

Autosave functionality was the first job of the week, along with a whole slew of tweaks, additions, and player feedback messages for the save system interface.

Access to the save/load system was added to the Front End Main Menu, and finally the ability to rename saved games.

All of the above took until midday on Tuesday and the rest of the afternoon was spent dealing with a long list of little tweaks and minor bugs.


New Sound Effects
Wednesday was set aside to replacing some old sound effects and adding some new ones. A new sound effect was created for the main guns along with the sound effect for picking up loot. It took a surprisingly long time to do the main gun sound effect because I couldn't get something I was really happy with. I'm still not 100% happy but it's better than the 'pew pew pew' that it had before.

It was then finally time to add sound effects to the user interface. Previously it was totally silent. I created some mechanical sounds for the different buttons, and then needed to go through all the code adding them. The mechanical sound really didn't suit the game so I made some different effects that were more electronic like using an ATM machine. These worked much better.

A new humming effect was created for when the player's ship was sucking up loot, and another alert effect for when dialog boxes appear. Dialog boxes are a new addition that was developed last week and I don't think I mentioned them before. They help to give warnings and feedback to the player and were crucial for making a good save game system.


Graphical Updates
Thursday and Friday was all about texture work, and colour schemes. Many of the textures in the game were old (very old). Due to the unusual way Neon works, it is quite easy to replace great chunks of the games textures.

Five of the colour schemes had their textures redone. This included reworks of even the newest ones to add extra variety of colour in the details while removing all of those blurry edges. This took the whole day because each colour scheme actually has six very different designs (eight if we include the AntiVirus faction that is still very similar to the OS faction).

On Friday, attention was turned to reworking the textures on the ships. Just like the environment textures they were rebuilt to be crisp and clean, and remove that old blurriness. This made a dramatic difference to the look of the older red on black, and green on black designs especially. The ships look much crisper and cleaner with the new designs now.

Then unexpectedly I ended up adding a skybox. This wasn't planned but I'm very happy I spent time doing it. The space station now feels like it's somewhere and it adds a nice atmosphere.

I finished off the week adding new icons to the docking port interface so it's easy to see what services are available at all times while docked. I also replaced the old placeholder 'Available Services' splash screen with a row of big icon buttons instead of simple text based buttons.

Conclusion
Everything is shaping up really nicely now. Neon is looking and feeling significantly more polished already.

There is still a list of jobs that need doing before the alpha testing gets underway but they are all minor jobs now. We are still on target for the alpha build to roll out to the first few testers at the end of the month. :)


Intravenous Software  [desarrollador] 22 de Feb, 2013 a las 10:43 
Friday 22nd Feb 2013

It's been two weeks since the last update and so much has happened.

Miscellaneous Upgrades
# Miscellaneous upgrades now suffer from diminishing returns. Use two 'Main Gun Boosters' at the same time and the second will be less powerful than the first.
# The power of Miscellaneous upgrades was increased massively to help create many diverse upgrade setups, hence the reason for adding dimishing returns.
# All ships have had extra Miscellaneous upgrades added. This was to allow the player to create more unique ship designs.
# Added Shield Regeneration Boosters.
# Created models for all existing Miscellaneous upgrades, and icons for each of them for use in the GUI. This included the various available missiles. Every upgrade in the game now has a 3D model and 2D icon.

Interface Upgrades
A range of tweaks and alterations went into the user interface. New icons were created to display on the menu buttons to show what services are available when docked. The docking ports introduction screen was also updated with large icon buttons to access the services.

Missile data including their range, speed, and size was added to the pop out data windows when pointing at missile upgrades. Each ship has a limited missile capacity so the size of missiles plays a factor in that.

Music
Neon now has in game music. A big thanks goes out to Python Blue for his stella work with the music. We went for a brooding ambient sci-fi atmosphere (somewhat reminiscent of Blade Runner). There are currently different tracks for friendly and hostile space. Python then wrote a fantastic faster paced piece for during combat. Code was written to blend between the various music tracks.
A music volume slider was added to the options window, and later a main volume slider.

Playtesting and Tweaking
Countless hours of playtesting and hundreds of tweaks happened over the last two weeks to prepare the game for alpha.

Every ship went through substantial changes, along with weapon damage, missile damage, loot drop sizes, uranium drop sizes, upgrade powers, etc.
The game now plays out at a much higher pace, with unlocks coming thick and fast in the early game, and combat is also much more intense.

The tractor beam for sucking up loot was also tripled in power. Collecting loot is now actually fun as it chases after the ship. There are tricks to collecting it all into a ball for a quick pickup.

Shop prices and stock availability were also tweaked many times over the course of testing.
The level when the various missiles and weapons unlock was reworked for better flow to the game.

Teleporting and Reassembly (after death) costs were increased to make death a more significant event.

Damage reduction against high level enemies was reduced to allow skilled players to hunt stronger enemies.

A new mechanic was introduced that makes upgrades progressively more expensive if they are above the players tech level. This was to add gameplay because the player is also now allowed to install a much higher range of upgrades. The increased pricing was a better solution than limiting the player to upgrades closer to his level. It adds more diversity to the possible ship upgrade choices available to the player.

Graphical changes
There were no huge graphical changes this time. The interface updates were already mentioned, but the loot drops got reworked some more. The brightness of ships was also reduced. It was previously increased to make them more visible at range but they looked horrible close up.

The lightning guns effect was reworked to be more chunky and was swapped to be the second gun that the player will likely unlock - usually within the first hour of play.

Target Nearest - Prioritise Visible - functionality added
The previous 'Target Nearest Enemy' command did just that. It would happily target the nearest enemy even if it was in another room, or behind the player. A new hotkey was added that prioritises ships in the field of view. This key makes a big difference to the flow of the game. Rather than pause to select enemies with the mouse, this new code does a great job of selecting that enemy right infront of you, even if there is a closer one behind, or behind a wall. The older 'Target Nearest' hotkey is also still available.

Teleport to AHL - added to Quantum Teleporter services
During testing, it was apparent that the game would benefit from having the ability to teleport directly into enemy space.

The 'Teleport to AHL' (Appropriate Hostile Location) tech adds this. The Teleporter scans the station for the best location to teleport the player to taking into account the level range of nearby enemies. This addition makes it possible to load up the game and get immediately into a full on battle against many appropriately levelled ships.

The player could then teleport back home again after the battle if they wanted to.


Random Other Additions
Save game files are now encrypted.
A toggle button for 'Autosave on dock' was added to options. Previously saving was almost instantaneous but the encryption causes the game to pause for around one second. This can be annoying every time the player docks so the option to turn it off and rely on manual saving was added. The game already has a 'Quick Save' hotkey that can be used at any time.

Added a EULA to the start of the game ready for the alpha release.

Added 'Show Frames Per Second' toggle to the options screen.

All the messages about loot pickups were reworked and redesigned to be much clearer and easier to see the most important information.

Kill based loot multiplier
The game now has a loot multiplier that is increased by killing enemies. It quickly degrades. This system rewards the player for killing fast and efficiently, and for getting involved in large battles rather than trying to sit back and pick enemies off slowly. The faster the player kills the larger each loot fragment will be.

Conclusion
Countless other changes and tweaks were made, along with catching numerous new bugs that crept up along the way.

The result is that the alpha release is just about ready. As of this moment it could already be ready, but some further playtesting of this final alpha build will occur over the weekend to ensure there are no final issues that need a quick fix/tweak. All being well closed alpha testing should start next week.

The game is also great fun and nicely balanced already. The alpha should offer around 10-30+ hours of gameplay, yet it only allows play up to level 15 (out of 80). The final game is expected to offer hundreds of hours of gameplay.

I look forward to getting some genuine feedback over the coming weeks as Neon is finally ready to be put into gamers hands (if only a select few initially).

Paul







Última edición por Intravenous Software; 22 de Feb, 2013 a las 10:48
Mostrando 1-15 de 34 comentarios
< >
Por página: 15 30 50