(This column is posted at www.StevenSavage.com, www.SeventhSanctum.com, and Steve’s Tumblr)
One of the concerns I see expressed about No Man’s Sky is that a small team of indie developers like Hello Games just couldn’t do this. I disagree, and in fact think it’s quite likely’ll they’ll succeed.
So you know i’m not wasting your time, I base this theory on:
- My experience in IT (20+ years).
- My work as a software project manager (12+ years).
- My interest in development processes (12+ years).
- My work in procedural generation (most of my life).
- My experience as a gamer (most of my life).
So let’s look at the reason I think Hello Games is going to pull this off.
A Focused Game
First of all, no matter how “big” No Man’s Sky seems, if you look at it, it’s an extremely focused piece of development:
- Exploring large procedural spaces – mostly planets.
- These spaces have procedural features, including life.
- Mining and finding resources.
- Dealing with hostile and non-hostile life.
- Crafting by combining various resources to change equipment.
- A focused set of equipment for the characters
- Interaction with species via various actions, trees, and simple fight/aid mechanics.
- Space travel.
- Exchanging of good via trade games.
- Cataloging findings.
- All of this is done with a chosen aesthetic.
No Man’s Sky, when you look at it, is somewhere between evolutionary and revolutionary. All the parts have been seen before, its the combination of them that stands out to create a universe.
The game design is very focused – Sean Murray and company have deliberately restrained adding new features. This means that Murray and Team can pay attention to what they want to deliver exactly. Well-defined features allow for focused development, focused testing, and good delivery. If you know what you want to do, you can deliver it a lot easier.
No Man’s Sky is delivering a very focused experience, which allows for focused development. Speaking of . . .
Focused Initial Development
The first developer on No Man’s Sky was Sean Murray himself, who built the core engine, which he eventually expanded to 4 then 13. This is the way you do core initial development.
Small, tight teams – sometimes an individual – are a great way to start a project. One or a few people, working together (often unmanaged) can deliver a prototype with surprising speed because theyre focusing on getting everything together. They’re not trying to market. They’re not trying to make it run on every machine. They’re not even making the most efficient code. They’re ot havign people constantly try and change things. They don’t have to write patches.
They’re making a start. As one guy I worked with called it – “stick smart guys in a room and feed them pizza.”
This is the kind of arrangement that I’d expect would deliver a decent prototype. It may not be perfect – it may only be a prototype that’s eventually discarded. But it lets you get the basics down.
This is exactly how I’d expect a project like this to start – and be successful. It’s a good core foundation.
Agile Development
So you have a focused plan and a core prototype. How do you polish something like this into a game? It’s procedural, it’s going to have a lot of complexities, and it’s not something you plan easily.
The not-so secret is Agile Development. Basically, tight, integrated development where teams have a large list of goals, but focus on small deliverables that are high priority, deliver quick, and focus on interaction and iteration.
Sean Murray’s team uses classic agile processes. They have a morning meeting, set goals, and do a master build in the evening. This is all happening in roughly the same space from what I’ve seen in videos, increasing interaction.
Really, what Agile does is acknowledge that planning everything out often fails as you find the flaws to your giant plan as soon as you start. So you set goals and meet them in increments, researching them as needed, and cooperating tightly with your co-workers. Even if you don’t deliver everything, Agile’s focus on “delivering stuff that works” means you usually get enough – or more than enough – done to meet your goals.
In short, the team at Hello Games is using the exact kind of software processes that would lead to success.
Plenty Of Resources
A team of 13 or so people may seem small, but gaming (and indeed any software development) has a number of resources to call upon.
- There are services out there to do development or provide code. You can outsource pretty easily if needed. Not sure if the team does it, but it’s an option. There’s a lot of games made by a “team” that really involve many outsourced teams.
- There are a huge amount of libraries, graphic tools, code engines, and more for development teams to use. You can bet that these have been used by the No Man’s Sky team – just like any other development project. Few pieces of software are created from scratch in their entirely – and you can bet a lot of media resources aren’t.
- There’s already lots of procedural games and algorithms and theories, from past Roguelikes to the Superformula. There’s a lot of examples to be used or to at least show what is possible.
- People network. You can bet the folks behind NMS were asking friends, fellow coders, and other connections for advice.
In short, there’s all the resources out there the team may need to make NMS a reality – resources other games have leveraged. In fact . . .
Public Accountability
The NMS team, despite the game’s hype, is remarkably modest. Sean Murray seems affable and humble. The game is getting played up, but Hello Games isn’t bragging or strutting around. It’s refreshing.
At the same time, the NMS team has been very clear about the game and game goals and what it does. Though there’s occasional assumptions by gamers about the game, it’s easy to find the team being very clear on what they’re doing.
They’re being publicly accountable. They’re saying what the game is – and if they screw up, it’ll be very obvious.
Frankly, I don’t think anyone does something like this and delivers anything less.
The Conclusion
NMS has focused goals, started right, uses the right management techniques, has resource to call on, and Hello Games has been clear on what they’re doing in a way that holds them accountable.
Me, despite some concerns about the game that I’ve stated, I think Hello Games is going to deliver.
– Steve
(This column is posted at www.StevenSavage.com, www.SeventhSanctum.com, and Steve’s Tumblr)
As I wait for No Man’s Sky (if I disappear for a week in June, you know why), I’ve been analyzing the game, what it means, and what it tells us about procedural entertainment. Today I’d like to focus on crafting.
I love crafting. I enjoyed the Atelier series of games, finding new alchemical potions. I love Starbound‘s crafting (OK, maybe I’ll vanish in July too). You can guess that Minecraft was a revelation. This all goes back to Demon’s Winter, a vastly underrated DOS game that let you build magic items.
With No Man’s Sky, the huge emphasis on crafting has me intrigued. The thrill of finding elements, the joy of a discovered blueprint, the fun of creating the right components. I love the challenge of building the ideal loadout, and NMS is going to give me that and all of the exploration and resource collecting. I’m looking forward to it.
I will be the guy staying on one crap planet for hours because of a wealth of ruins filled with schematics. Trust me.
No Man’s Sky provides a mixture of real and made-up elements, a nice nod to both recognizability and to the proper sci-fi feel. But as I’ve watched the game, I’ve come to realize there’s another, missed opportunity that other games should take up.
Procedural elements.
Imagine a game like NMS (or NMS II, which again I feel is possible) that has procedural elements. The joy of discovery is not just felt on finding a new world or a new blueprint, a strange crystal or interesting rock formation could hold an element no one else has seen. There could be elements even the creators hadn’t foreseen, out there, lurking.
Sci-Fi and fantasy is often about strange and unusual materials. Let’s see more of that in games.
Of course to make them useful and understandable, procedural elements would need to be handled in certain ways. here’s my thoughts on it:
Where They Fit
Procedural elements would have to work into an existing crafting structure. The elements have to have some recognizable use despite their procedural nature. This would likely mean:
- The crafting structure recognizes general classes of elements (builds weapons, catalyst, etc) and procedural elements fit a general class but have unique cases. “Iron” is the same all over, but that procedural deposit of “Dekelite” has unique traits, thought both can be used to build weapons.
- Thecrafting structure recognizes specific elements, and procedural elements can “substitute” for regular ones and bring certain benefits. Thus “Chromatic Polytanium” may substitute for “Copper,” but any scanning device built with it has extra bonuses.
- Items that are used to power/supply other items may provide unique bonuses. A unique element that provides energy may, perhaps, deliver double the fuel value of a common one.
Unique Traits
It’d be pretty easy to make procedural elements that seem very samey, so work would have to be done to vary them. The need for variance would depend on how often they’d be encountered, of course (more on that later). But traits may vary along such areas as:
- Specific use.
- Elements they substitute/are used for.
- Bonuses and combinations of bonuses.
- Disadvantages and tradeoffs.
- Additional effects (perhaps if you make a potion with this element it always confers invisibility)
- Physical traits (even different colors or weights).
A game that uses procedural elements should have enough variances that they’re actually interesting, unique, ad surprising. Otherwise it might not be worth implementing.
But done right it could be amazing. Imagine traipsing through a fantasy forest to discover a rare gem deposit whose naturally holy traits repel demons and confer charisma. Imagine exploring a distant world to find a fuel source that boosts your hyperdrive beyond capacity – but will wear down your spaceship. Each finding is something unique, wondrous.
When You Can, Add Story
I’ve written about the need for procedural games to have pproceduralhistory. Same goes for procedural elements – I can’t say it’s required, but having “more” to the elements than a name and trait may be neat.
Maybe a procedural element in a fantasy game exists because a certain area is irradiated with magic. A procedural element in a SF game may have unusual energy properties because it was formed on a planet near the sun. Add something tomake the elements meaningful.
Or at least give us some flavor text for fun. Something to help us build our own story.
Oh and make sure the names are appropriate. I’d much rather find Chromatic Steel with it’s ability to make swords tht dazzle with rainbow light than a similar element called Furbonanium. Only use nonsense if it fits.
Don’t Overdo it
Finally, unless procedural elements are a theme of the game (and it may be), don’t overdo them. If you want these elements to stand out, then they have to stand out.
In any game of reasonable gameplay (20-40 hours) odds should be that only 1 or 2 procedural elements are found unless that’s a core part of the game. An element like this should be fascinating, amazng, perhaps game-changing – and overdoing it reduces the wonder.
That moment you find that rare deposit should be one you remember for the rest of the game.
So that’s my take on where NMS’ offspring should go – and a lesson we can learn from the current development of NMS. If a game focuses on the wonder of discovery and crafting, why not surprise your audience with procedural elements. Give people that unique experience that is personal – and perhaps theirs and theirs alone.
– Steve
