Factorio Forums

Hello,

Automated testing
We decided to start working on the automated testing of Factorio, we are not sure whether call it unit testing or integration testing as it will be something inbetween, but we know that we need to start with it soon,
yes there are few simple unit test from the ancient days of Factorio, but that is it.

The main reasons for that are:

• The 0.8.5 and 0.7.5 took quite a long time to stabilise and we are quite sure there are problems that are just waiting to be found.
• The automated testing pays off in the long time, but until now we were very uncertain if the long run will even occur ...
• The game is getting more and more complex, almost every new concept interacts with every other concept already there.
• We want to refactor and optimise a lot, and tests allows us to do it with much more confidence.
• We learned, that some bugs are hard to notice for a long time, this was especially true for the crucial logistics system bugs that were there for the whole 0.6.4 and 0.7.5 versions.

Considering, that we spent 3 weeks in the bug fixing phase of 0.8 already, it seems like spending at least week on extending the automated tests every release would pay off quickly.

Pipe/Oil industry
Tomas is now preparing the engine for more complex pipe related machines. Some of the new pipe-integratable machines will have much more freedom in the settings of the pipe connections, this will be also useful for mods that would like to have different pipe mechanics. His 2X2 storage tank entity with is already working and using the new system.

There are still many steps that needs to be done for the basics of the oil industry:

• Add input/output liquid connections to Assembling machines
• Different liquid types
• Different pipe categories (we plan 2 pipe types that will not connect with each other, to allow player have two distinct pipes next to each other, aka the buildcraft style)
• Liquid requirements/result specification in recipes
• Destilation tower
• Oil platforms and resources.
• Burning towers
• pumps (Not like the offshore one, this would work in the factory to speed up resources/specify direction)

Blueprints
I made already some small preparations of the blueprints functionality, we made some more specific specifiation how will the blueprint stored.
The player takes the empty blueprint item to cursor, and select rectangle (by holding the build button), the selected area will be stored into the blueprint item.
Once the blueprint item is filled, player can build it by right clicking same as it was normal item, it will just build more items (in the ghost state, to be built by construction robots) at the same time.
The blueprints will not be stackable, and it will show overview of the blueprint in the tooltip, the question still is, how should the item icon look like, if they are all the same it would be messy, but the icon is too small to put the overview there, one of the options is to just put letters A,B,C there, or/and numbers, but this still seems confusing.

Happy new year
I believe, that this year we made a lot of improvements of Factorio and we hope to keep our dedication for the next year. There is lot of we are looking forward: Oil industry, automated construction, more diverse factory, different and variable energy sources, biomes and more diverse enviroment, extended enemies, doomsday like weapons and mainly multiplayer.
We have small improvised party here in our Factorio headquarters, we hope you enjoy the new years the way you like the most, happy new year.

This is nice to hear.

Before I go to the party I want to mention - and I'm sure you already thought to it, but if not - then please don't forget to cover all this new testing functionality with unit tests! The testing code coverage must be 100%. Otherwise this is a good shoot into the foot! it's really hard to add tests into an existing program (should be done only, when you change something), and the first rule is even harder: first write the test, then program. I mention this, because in my company we had two teams which made that wrong and nearly had lost the customer because with rising complexity they couldn't keep the performance; and even me does it sometimes wrong... and it is always bad. always!

So I think my best wishes for you in 2014 is: Hold Out!

And Happy New Year to you and the whole team and the rest of this fine community.

Happy New Year!

Very excited about all the upcoming stuff

 the question still is, how should the item icon look like, if they are all the same it would be messy, but the icon is too small to put the overview there, one of the options is to just put letters A,B,C there, or/and numbers,

maybe if we could name the blueprint? And the name will be like Blueprint: Solar farm, and when you right click the blueprint, like the modular armor, an screen with a little preview shows (maybe with something like a blueprint photo filter (google? ), the entity picture or the item icon)
And the icon of the blueprint I think that should have numers instead of leters ( 01, 02 etc)
And happy new year

I think that better than numbers or letters, let player choose the graphical symbol on the blueprint. I can imagine that normal buildings and items icons could be used to pick from, like solar panel in blue color+border means "blueprint for solar farm".

That way player can find what he wants fast, all blueprints are blue, solar farms have solar panel icon on them, and if he has more types he can distinguish them by onmouseover names.

Graphical symbol: I've an app called "sun vox" and there you can paint graphical symbols for a musical pattern.
At first I thought WTF, but now I think is cool, because unknown symbols are much better to remembered, than chars or digits. The editor for the icon is super simple, just a grid and two colors.
If the user doesn't paint an icon, the program uses random graphics, simple symmetric patterns.

Complicated to explain, maybe better to view:
http://www.warmplace.ru/soft/sunvox/sunvox18.png
http://www.warmplace.ru/soft/sunvox/sunvox20.png
http://www.warmplace.ru/soft/sunvox/sunvox21.png
http://www.warmplace.ru/soft/sunvox/sunvox22.png

The icons are at the top right, some black and white stuff. All icons in the examples looks like generated by computer (symmetric). You see also on the low of the pics some more symbols. That are tracks and the sequencer plays this pattern at that position.

While Automated testing is good for finding bugs and posibly finding code botlenecks don't expect that making this would make your further development much easier.

I might seem haers but I think the biggest problem you currently have is poor organization. No I don't mean your team organization. I mean your approach to codding. As I have read a commeent some time ago you still folow the "first thing that works" approach when implementing new features. While this approach is prefered when developing prototypes it is not best when developing final more complex products. Why? By implementing "first thing that works" for certain feature you might limit yourself from implementing some further features due to limitation of your current code.
So what I suggest is for your to stop for a while, write down what you want features you plan to implement in the future and then go look at your existing code and think hard "is this code suitable for being extended with future planned features". Finally go and reafactor your existing code so that it would alow you to implement all these planned features in most easy way.
I understand that you probably are not much entuziastic of doing this right now (code refactoring is not fun). But the thing is that now when Factorio code is still small this could be done easier than in some near future when Factorio code would already be to enormus.
And if you are afraid that you might start loosing players unless you keep bringing new features with every new version. Let me tell you this that sooner or later you will have to do this. Doing this would probably take your less time since Factorio code is still not so big but in the future this could take much more time. And that would mean that many more pepole would be disapointed for much more time in the future.

And another thing. Do start commenting your code. Nicely commented code means that even a person who didn't write certain part of code can know what it is for.
And yes sometimes even you as an author of a cerain piece of code won't be able to initially remember what that part of code is for. And that would mean you will spend some time figureing what that code is used for instead of working on some new code.
As a programmer myself I have lots of code examples (trivial applications) which represents me trying different codding paroaches. And since many of them are poorly commented or not commented at all I have not much use of them untill I study them and figure out how they work.
Yes I could just copy that code into my finall aplication and hope it would work. But by doing so I could make so much problems, so much new bugs, that I wouldn't have idea where to start looking for them. It is always imperative that you absolutely understand your code.

So in short make full refactoring of your code and when you do it make sure that all teams programmers are present. This shouldn't be a problem since you actually all work together at same place. Why? Each programmer has its own way of programming which means that ones code might not be as understandable for another. So when you all work together you actually use approach which is common for you all.

Hm. Not so nice to hear such things at new year morning.
I wanted to wait with it some days. no just kidding.

Poor organization: hm, I think they make already a good mix.
An example: In my team we sit together, programming and suddenly we discuss, how to do stuff. Most important. I'm sure they make it the same way. Or when we get the user-stories from our customer. Most times we need only some minutes, because the stuff is relatively easy. But currently we have a task, where we first implemented a prototype and yet in January we reimplement it and it takes us about half a day to organize that work, and another to implement a prototype.

What I want to say: no, it depends. And I mean they know that. Perhaps better planing? Yes, but the team is a bit too small for that. 5-6 in a team would be a good number, where we have enough opinions and more time to experiment.
But the problem still remains: the code becomes extremely complex because interacting code of complex problems and of extreme optimizing.

Optimizing is another example: we don't optimize our code in the first implementation (ok, some cases, when we really know that it will be too slow). We measure, if it's needed and optimize only then. This helps a lot to keep complexity low. Ok, for a website this is easier, but when I think to the IDE we use for programming: it logs also every step. Might be an idea that factorio does the same: "Do you want to send anonymous statistics?" Yes, why not? We currently write for our project some code to see daily statistics, what parts are slow and if needed, we optimize it.

But generally I think the biggest problem is the code complexity and the interaction of the code parts. And this is in my eyes a proven way, that tests help to find this. The problem is in most cases, that they write code, which works, but not all other parts can be tested, because it might be hidden. Think for the simple bug, that logistic bots don't take out items from limited stacks. When you create systematic tests before implementing - test-driven-development - this would not happen.

It just really hard to keep the discipline. For that case I recommend pair-programming. Sit together, two keyboards, one writes, the other says what to do. Write a test. Make it fail. Then write the change to make the test green. Then make a new test. And so on. Really hard in the first days. But suddenly you see, that this works as fast as two programmers, we have teams, where we measured that it is faster! Just because you don't make big failures. And then it makes suddenly fun.
And no, this approach is not always the best. Try it out, keep what works.

Commenting code: hehe. In my opinion good code doesn't need inline comments.
I saw code, which had longer comments than the code. Or code even without any meta docs. Or code, which had every line commented. Code, where the comment says much different, than the code. Comments lie. Good code should be documentation enough. The problem is in my eyes, that you cannot comment the interaction. Good style is to separate the interacting parts, but in most cases, this is not possible.
But therefore are the tests! Interacting code can be "commented" with tests.

Nothing is better documenting, than running code!

Thanks for the input guys. I will try to keep it short:)

SilverWarior wrote:As I have read a comment some time ago you still folow the "first thing that works" approach when implementing new features.

This was meant from the gameplay perspective not the internal perspective. It is quite difficult to "design" something that will be fun without actually trying it out.

SilverWarior wrote:So what I suggest is for your to stop for a while, write down what you want features you plan to implement in the future and then go look at your existing code and think hard "is this code suitable for being extended with future planned features".

We actually do this continuously all the time. When making new feature we keep asking (usually each other) "and what if in the future we want to add X, will it still be possible?".

SilverWarior wrote:I understand that you probably are not much entuziastic of doing this right now (code refactoring is not fun).

Actually code refactoring is fun and rewarding because it simplifies things and that gives one good feeling. We do it continuously, though maybe we could spend more time doing that, that is true.

ssilk wrote:But the problem still remains: the code becomes extremely complex because interacting code of complex problems and of extreme optimizing.

This is the main source of the problem in my opinion. The codebase is not small already and there are many concepts that interact with each other. So when doing a change one must think hard what could this change influence. Also often we have to sacrifice some good design for the speed. That doesn't make things easier.

ssilk wrote:The problem is in most cases, that they write code, which works, but not all other parts can be tested, because it might be hidden.

Yes. And often similar kind of bugs keep reappearing. That is why I believe having a set of tests for frequent scenarios will help a lot. It will also make refactoring easier because having tests will provide a certain degree of certainty that nothing was broken.

ssilk wrote: For that case I recommend pair-programming.

We actually tried pair programming on some occasions already but it didn't work at all. I think some people are just not suited for that, I personally can't really write any code with someone looking over my shoulder.

ssilk wrote:Commenting code: hehe. In my opinion good code doesn't need inline comments.

Again pragmatism is the right way to go imho. Now and then I am like "hmm logic is not really obvious and it should be written in the comment". On the other if the code can be written in such a way that it is clear and doesn't need comments, that is always better.

One key observation is also following: It is easier to make one release and fix all the bugs at once then to make continuous releases and keep adding features. This is because the bugs are nasty creatures and they are coming back:) That is why for the continuous release model (ours) the tests have more meaning than for the build-test-release-leave model.

slpwnd wrote:

ssilk wrote: For that case I recommend pair-programming.

We actually tried pair programming on some occasions already but it didn't work at all. I think some people are just not suited for that, I personally can't really write any code with someone looking over my shoulder.

Well, in my team are such candidates, which hates that, too. Nonetheless I keep recommending to do it as often as possible. We didn't force anybody to make pp, but meanwhile some who said half a year ago, they don't like it, say now "Sometimes pair-programming is really a good thing, I would never found the bug this fast."

One key observation is also following: It is easier to make one release and fix all the bugs at once then to make continuous releases and keep adding features. This is because the bugs are nasty creatures and they are coming back:) That is why for the continuous release model (ours) the tests have more meaning than for the build-test-release-leave model.

Hm. Continuous releases. We try to release once a week. We use feature flags for adding new features. The whole new feature is capsuled with a flag, and can be turned on in runtime. This enables in most cases to turn a new feature off, if it has bugs or work on two new features without feature branches. For example, we switched from memcache to redis. We tested it quite well and at some day we released it. But then we found a bug in production, because in very rare cases we forgot to clean the cache and we switched just back to memcache, everything worked as before.
Not alway that easy. But what I mean is, that integrating the code soon is in most cases good, because you find the bugs earlier and have the option to say "ok, if we have a bug we can switch it off without new release".

slpwnd wrote:This was meant from the gameplay perspective not the internal perspective. It is quite difficult to "design" something that will be fun without actually trying it out.

Pardon me but I got impression that this is also true for internal perspective especially by observing how certain thing are implemented. I would have implemented certain things in a bit different way to alow me more freedom in the future.

slpwnd wrote:Actually code refactoring is fun and rewarding because it simplifies things and that gives one good feeling. We do it continuously, though maybe we could spend more time doing that, that is true.

You know you are actually one of verry few programmers of the ones I know who says that?
Most of them still thinks that code refactorion is "necessary evil". And no these are not just newbie programmers. Some of them have over 20 years of programming expirience in many programming languages.

slpwnd wrote:This is the main source of the problem in my opinion. The codebase is not small already and there are many concepts that interact with each other. So when doing a change one must think hard what could this change influence.

I usually try to avoid interdependant concepts whenever posible. Why?
Becouse these kinda concepts are "bug spawners". If you have these conepts written in a way that small change in one could wreak havoc in other you will quickly end up fixing bug in one and by doing so creating a new bug in another. And then by fixing the bug in another you could creat a new bug in first one. So in short you could cycle yourself up in continous creating new bugs which are results of fixing old bugs.
When this happens it is best to simply go and redesign the whole thing in a different way that to simply continue in your neverending bug hunt.
But as I sad before sometimes this is not posible. So in such times you should make sure that you design such concepts in a way that change in one won't have too much change in other or even wrap up the two concepts into a whole new one which kinda works as bug prevention system. This one is hard to explain as it is also hard to implement.

slpwnd wrote:Also often we have to sacrifice some good design for the speed. That doesn't make things easier.

Based on my expirience with enough determination you can implement basically any design without loosing too much speed. But the hard part is that quite often for doing this you need to redesign large parts of your existing code.

slpwnd wrote:Yes. And often similar kind of bugs keep reappearing. That is why I believe having a set of tests for frequent scenarios will help a lot. It will also make refactoring easier because having tests will provide a certain degree of certainty that nothing was broken.

Based on my expirience when similar bugs start reapiring this means that base code from which buggy features are extended for is written in poor way and thus makes implementing of new features to difficult.
I usually end up reqruting this whole base code and subsequently all the already implemented features which extend from this base code.
I realize that this hurts productivity big time but in the end it does provide much better results.
In a poject of mine I have part of code which I have compleetly rewritten for so many times that I even stopped counting. In the beggining that part of code caused me a lot of trouble when extending it to implement new features and provided me with good performance. But now after so many rewrites it is verry easy for me to extend that code to implement new features and it provides much better performance. The code is now almost three times fastar that it was in the start.

slpwnd wrote:On the other if the code can be written in such a way that it is clear and doesn't need comments, that is always better.

What seems clear and understandable to you might not be clear and understandable by other team members. You see your own code would always seems more understandable to you.
Another reaon why I recomended code commenting is that since you decided to actually share the code insight wtih some of us forum members having inline comments in code could help us understand the code much easier.
I must admit that I have spent quite some time looking at Factorio code and there are still some areas where I have no clue how that code even works. Now it is true that my knowledge of C++ is not as good as my knowledge of Objective Pascal but I usually don't have so much problems in understanding some C++ code.

slpwnd wrote:One key observation is also following: It is easier to make one release and fix all the bugs at once then to make continuous releases and keep adding features. This is because the bugs are nasty creatures and they are coming back:) That is why for the continuous release model (ours) the tests have more meaning than for the build-test-release-leave model.

That is completly true.
If you wanna continuosly work on certain project you need to properly design your project right from the start. You need not only to organize your code to be able to implement planned features but actually organize your code to alow yourself to implement even unplanned features. And that is the most dificult part.

EDIT: I also apologize if I may have ofended you in any whay but sometimes I'm know to be blunt. Sometimes even to blunt I'm afraid.

2cents: really don't like the buildcraft approach to make pipe work independently.

you already have an engine at hand to allow pipes not intersecting if the player doesn't want to: the logistic belt directional system.

that would work perfectly to avoid unwanted pipes crossing and would only need to have transportation direction set by pressure and not fixed.

LoSboccacc wrote:you already have an engine at hand to allow pipes not intersecting if the player doesn't want to: the logistic belt directional system.

Placing pipes the same way like transport belts seems really to be a very neat idea.

BurnHard wrote:Placing pipes the same way like transport belts seems really to be a very neat idea.

Problem is the current pipe handling system, which connects adjacent pipes no matter what, which makes for easy splitting and fusing of lines.

The belt system is rather more complicated and requires specialised equipment.

What if there is only one type of pype, but that pipe can be placed in three ways?
The first way connects to everything.
The second way connects to the first way pipes and to the second way pipes.
Aand the third, that connects to the first and to the thirds

Well placing the pipes as transport belts is an option. But one of our motivations for the pipe system is to not make "belts for liquids". What I mean is that we want to make it work differently so it provides another layer in the game. We will test it with the 2 sets of pipes and see how it goes.

@ficolas Congratulations to reaching the smart inserter;)

SilverWarior wrote:

slpwnd wrote:Actually code refactoring is fun and rewarding because it simplifies things and that gives one good feeling. We do it continuously, though maybe we could spend more time doing that, that is true.

You know you are actually one of verry few programmers of the ones I know who says that?
Most of them still thinks that code refactorion is "necessary evil". And no these are not just newbie programmers. Some of them have over 20 years of programming expirience in many programming languages.

Well, you can add one to your list, I also like refactoring my code to make it better !
and can't imagine people with 20 years of experience not enjoying this ...

@ the dev team,
for the blueprints, wouldn't it be better to put the picture of the building in ghost mode with a little logo showing it is a blueprint ?
-> you would be thinking the wrong way, trying to put the picture inside the blueprint instead of fitting the blueprint picture into the original image.

I also think you should think of all the possibilities you might want (or the modders might want) when you set up a new feature, as I read somewhere on the forum, for the tool belt! you hardcodded the two tool belts in the player code -> if you had though 'what could be added to this we do not think of right now' you would have made your game more flexible

I will also talk about something I don't know much but guess a lot : I think you codded the character into the game in a way that does not allow you to implement multiplayer easily I think, by not thinking from the start : "what if we want to allow several players on the same map"
see my point ?
if you had though of that from the start, you would have spend more time but made it more flexible to allow the multiplayer and therefor speed up the process !

Of course, I don't say it is easy, I would not know where to begin to make such a game myself so ...

oh, and I see you showed your code to some of the forum members ? if you want someone else to take a look at it, don't hesitate (i'd love to see how you did it so far ^^)
(of course I'm still a newbie on this forum and the code sharing might has been in a tier of the indiegogo campaign, so I will understand if you don't want me to take a look , but ... a fresh eye might be good for the game ?)

Anyway, nice to see you have plans for the game !(and nice ones)

StanFear wrote:I think you codded the character into the game in a way that does not allow you to implement multiplayer easily I think, by not thinking from the start : "what if we want to allow several players on the same map"
see my point ?

In the initial version the character was implemented in such way to prevent implementing multiplayer.
But some time ago developrs did change this so current implementation of ingame character supports multiplayer. Even more, the game can now use multiple forces where each force ddefines one group of entities/characters.
Currently game uses three force groups:
- neutral force which contains trees, fish etc.
- player force which contains player characters, player buildings, etc.
- enemy force which contains biter spawners, biter worms (turrets), and biters themself.
So all they need is just add aditional groups to extend the current game mode either for implementing multiplayer or maybe even implementing a new group of aliens if they decide to.

So yes developers already made a few steps closer to multiplayer but due to limited funds at that time they decided to postpone the implementation of multiplayer to future time and focus more on single player content first.

SilverWarior wrote:

StanFear wrote:I think you codded the character into the game in a way that does not allow you to implement multiplayer easily I think, by not thinking from the start : "what if we want to allow several players on the same map"
see my point ?

In the initial version the character was implemented in such way to prevent implementing multiplayer.
But some time ago developrs did change this so current implementation of ingame character supports multiplayer. Even more, the game can now use multiple forces where each force ddefines one group of entities/characters.
Currently game uses three force groups:
- neutral force which contains trees, fish etc.
- player force which contains player characters, player buildings, etc.
- enemy force which contains biter spawners, biter worms (turrets), and biters themself.
So all they need is just add aditional groups to extend the current game mode either for implementing multiplayer or maybe even implementing a new group of aliens if they decide to.

So yes developers already made a few steps closer to multiplayer but due to limited funds at that time they decided to postpone the implementation of multiplayer to future time and focus more on single player content first.

well as I said, I was just guessing, but it is cool to know about that ! this seems to be a good way of doing things to me ...

slpwnd wrote:Well placing the pipes as transport belts is an option. But one of our motivations for the pipe system is to not make "belts for liquids". What I mean is that we want to make it work differently so it provides another layer in the game. We will test it with the 2 sets of pipes and see how it goes.

@ficolas Congratulations to reaching the smart inserter;)

What about "filled barrels" as items. That way we have an option that consume metal resources and more time but allows us to transport liquids using belts if that option suit best our factory

We can have a building (A) that converts liquid to "filled barrels" items either out of thin air or using "empty barrels" crafted with a new recipe in a factory (C) or crafting a limited ammount by hand, depending on the size of our complex.
And then another building (B) than do the opposite process, making the barrels dissappear or giving back the "empty barrels" in the second version. Building A and B could be the same building and configurable with a setting on it's GUI