12 replies to this topic

[slpwnd]

What is Factorio ?

Factorio is a 2d creative game about building factories on alien planet.

What do I do in the game ?

You will be in charge of a character that is building a factory from scratch. You will be mining resources, automating production, managing energy sources, designing the flow of items in your factory, researching technologies and defending from hostile alien creatures.

What is the game inspired by ?

We drew a lot of inspiration from Transport Tycoon-like games, Civilization and Minecraft.

Why should I care ?

This game is made by geeks for geeks. The core of the game is building things. You cam create huge almost self sufficient factories. There are machines crafting other machines. All the stuff is travelling on transport belts. There are simple means of "programming" the robotic arms that move things around. You also have little logistic robots that transport things among designated containers. The ultimate goal of course is to have self replicating factories:)

When & where can I get it ?

Public demo is available at http://www.factorio.com (win, osx, ubuntu linux).
The game is at the moment raising funds for further development. If it succeeds the alpha will be released in March 2013.

I want to know more

You can get more information on the webpage linked above. There is a trailer, screenshots, plot information, etc.


This is how the game looks like at the moment:









We are curious about any feedback, ideas, suggestions you might have.

[Reedbeta]

Hi slpwnd, thanks for posting about your game. To help start a discussion, perhaps you could tell us something interesting about the development process of your game? For example, you could post a short discussion of some technical problem you solved or the art direction / game design choices you made.

[slpwnd]

Hi Reedbeta,

sure that is a good idea.

How it started

We are two programmers, not really an indie game dev team. Just two guys who were writing C++ code for living, having games as a hobby. Last year a hobby project of my friend turned out to something much bigger than we expected and soon we found ourselves working on the game full time. Looking back it feels kind of foolish:)

The process

In the beginning all the art in the game was very conceptual - usually made by us in some simple painting program. Later on we hired freelance 2D artist to work on the game. We do the game design, game development and web development ourselves. The in game 2d graphics, 3d graphics, concept art and sound is all outsourced. This is the biggest mistake I can see we made. Starting a project of this size without having a team with people of versatile capabilities. We are very dependent on work of our freelance artists and the fact that they are working remotely makes the process long and tedious. That is one of the reasons why still half of the graphics in the game is sort of conceptual.

The technical challenges

We face new challenges all the time and this is one of the great things about this kind of job.

The game is written in C++. We haven't used any existing game engine. That could have been a big mistake. On the other hand we had no experiences with any of the them, we were not sure whether they would scale well (basically hitting a framework limits) and making a game from scratch was a fruitful exercise. We use couple of libraries of course, namely: Boost, Allegro for graphics and Agui for UI.


It might be suprising, but we have to keep an eye on performance all the time. Despite the game looking relatively simple and being 2d. There are loads of objects that are moving and require collision checking. The maps might be infinite (and proceduraly generated) so as players explore the map the number of objects to update ever increases. The largest portion of the time is spent in updating the items moving on transport belts. We reiterated functions doing collision checking couple of times and recently even added optimizations for items on the belts.


The AI alien creatures are using relatively standard path finding algorithm. We have implemented couple of custom heuristics for caching paths from similar locations. Another standard trick was to allow only a limited number of steps per single game tick. Player doesn't have any units on his own so we are not facing a problem of sending out units fast without a path simply because they are not (most of the time) visible when that happens. Alien creatures can break structures to make shortcuts on their path.

The game has been written with an eye on modding possibilities. Namely in defining and identifying objects in the game. Already at the moment it is possible to define and modify a lot of game content via json files. It is naturally possible to change animations, sprites, speeds, health of objects, enable recipes, modify technologies, etc. Another way to allow players create game content are scriptable Lua scenarios. Again probably nothing new - we have written a very simple framework and API ourselves. The demo and beta campaigns that are already available are written in Lua.

----

Hmmm I could really go on for a long time, but I am not really sure whether this is interesting for anyone. If you guys have any specific questions I will be happy to answer them. Apart from that we are just 2 guys completely new to game development who are having fun writing game that they enjoy playing.

[Reedbeta]

Cool, thanks!

slpwnd, on 02 February 2013 - 01:40 AM, said:

The in game 2d graphics, 3d graphics, concept art and sound is all outsourced. This is the biggest mistake I can see we made. Starting a project of this size without having a team with people of versatile capabilities.

That's an interesting perspective. Around here we see a lot of people who are trying to put together a team with all the roles that (they think) they need to finish their game, when they haven't even started the actual game yet. I've always figured you have a higher chance of success if you just dive in and start building the game yourself, then contract an artist, sound engineer, etc. when you're farther along, rather than trying to find people willing to throw their hats in the ring when all you have is an idea. As a programmer with not much art skills, I would probably go that route. But you think it was a mistake to do so? Do you have any tips for working with others remotely, finding reliable people, etc.?

[slpwnd]

I personally thing that the best setup is just 2 people. One doing the complete art and the other one doing the programming. I suppose they can take care of business side of the project. At least in our project there is incomparably more work on the graphical side than on the sound and music. Also you can just go and buy some ambient tracks and generic sounds for like 2$ each and if you spent enough time searching you can get stuff that will sort of fit in the game (we did it).

The problem we face is that process with communicating with freelancers, explaining them what we want and then making sure it gets done takes a lot of time. And it isn't really flexible. Like last time our graphic spent like 2 weeks making sprites for the inserters (the robotic arms that move things around and look really funny), but in the end we couldn't have used the result, because we found out, that the new sprites obscure the player's view and there is no easy way around. Maybe it is a problem of our workflow. We try to change it and get some work in progress from our freelancers asap to give us an idea so we can give them tips and hints. But I really believe that if we had a graphic guy sitting with us and being genuinely interested in the project it would be a completely different level.

Haha I just found some picture how the game looked like couple of months ago:


I am a programmer with pretty much zero art skills and so is the other guy. So for us it was only natural to go, do the programming and figure out the graphics on the way. And the result is that we have really interesting game from the gameplay PoV, but I am afraid that a lot of people are put off by funny looking, half finished graphics (which should have been done a long time ago).

So to come back. Maybe it is not necessary to have the complete team from the beginning. It is definitely a big advantage. But what is necessary is to have freelancers you know you can rely on and communicate well with. Have a plan upfront. And also something we totally underestimated: get concept arts for the game. This way you have something to market the game with and also it serves as a guide line for the person doing the graphics.

We learned some lessons the hard way:) I would be happy to hear any opinions / experiences you guys might have regarding this topic.

[rouncer]

looks really good! hope you get some success with it.

[fireside]

Quote

I personally think that the best setup is just 2 people. One doing the complete art and the other one doing the programming.

I agree for smaller games. There are the least amount of arguments that way. I think programmers don't understand the level of difficulty of doing good artwork and tend to use it improperly. For instance, an artist needs a pretty good idea of what the art is supposed to do and that can usually only happen with some placeholder graphics. A lot of programmers don't understand that. They just say, I need so and so and expect artists to read their mind. Artists can be the same way about programming, asking programmers to do things that can take huge amounts of code without understanding what they are asking. Games need to evolve. I've heard all kinds of people give these top down plans for games that fall down immediately because everyone contributes parts that don't link up properly. A simple prototype that expands is the better way. Once you see it, and play it, it's easy to see what is needed and what is not. Artists can give recommendations and do much better work that fits in with the game play. Even on games I do solo, I use that method. It's much easier to get ideas once you start adding artwork even if it's just placeholder.

[Stainless]

I tend to complete the game with programmer graphics, then give the completed game to a GA and basically say "Fix this"

That way they know exactly what the graphics are for and where they are used and they can test without having to bother me.

Finding a GA that draws in a style I like is the problem, several projects have just been dropped when I think the graphics are sh1t.

I lean towards procedural generation now

[slpwnd]

That is actually the way we took. When we add new concepts into the game we do the graphics ourselve. You can totally see it in the game I described above (and even in the official trailer). And slowly the graphics is catching up. Hmmm maybe the problem is not in the overall process after all.

[slpwnd]

We made a simple tutorial video about building a very very basic factory. If you are interested have a look at:

[rouncer]

i love the little dude, the game looks pretty cool, so, you build factories with it, im not quite sure i understand whats going on, but whats the main goal of the game? do you manufacture airplane parts or something? and you get some high score?

[slpwnd]

At the moment the goal is to achieve enough of scientific research to build a rocket defense building and protect it for a specified period of time. The motivation is that there are coming colonizing ships from the Earch and rocket defense will protect their landing from potential attacks by the aliens. Well the game is pretty much about building big factories and this is sort of a side motivation.

[rouncer]

yeh, the game mechanics at work is the important thing.