Posted on October 9, 2016
screens
Yesterday I finished laying the groundwork for the core systems in my new game project!
I have a state machine that manages basic application flow, spawns the environment, the player, and the camera into the scene, then resets if it detects that the player fell off the world. The state machine is also the provider of Update/FixedUpdate/LateUpdate hooks for any entity in the game that needs an update loop (see my other post about keeping the Unity API at arm’s length from your game systems).
The environment is procedurally generated, if you couldn’t tell 😉
There is a resource manager for instantiating prefabs from the Resources folder.
There is an input manager for handling input from Unity and mapping it to user-defined key bindings, including 8-way joystick (aka. D-pad) controls.
The camera is a simple isometric follow cam, just pass it a transform and it will follow the transform around at a specific angle and offset. You can also zoom in and out with the mouse wheel.
The player is just the guts from my old Grenade Guy demo ported into this new framework, so it’s a CharacterController with velocity, acceleration, gravity and ground-snapping. It bumps and slides around the environment nicely, but I’m still suspicious of CharacterController generally as I’ve had major problems with scalability (e.g. many characters on screen simultaneously), although that was years ago. It also drives basic headlook for a character mesh; currently it just tries to look at the spot in the world where the cursor is hovering.
(There’s a minimal worldspace UI framework too, which nicely fits itself to a camera’s far plane and works independent of screen resolution or camera settings, but it’s not being used for anything yet.)
Combine all of these elements and you can run around a simple little world with a few obstacles. Not bad for what my work log claims to be ~40 hours of work, which includes writing these blog posts. Progress!
Posted on October 5, 2016
grep ‐‐week 40
Simple mechanics, complex puzzle creation
@gamasutra.com
A nice technical overview for creating a procedural puzzle generator.
The Daggerfall Paradox
@slate.com
“Call it the paradox of procedural gaming: The less personality a game has, the more personal our own time with it can become.”
Sea of Thieves Will Not Have A Procedurally Generated World
@gamingbolt.com
This has now become the standard procedural generation quote of the week — “No Man’s Sky probably poisoned the well for a very long time to come, as far as procedural generation in major games goes.”
Posted on October 3, 2016
interface
I did some coding this weekend on the core framework to Refuge/0 and was faced with the always interesting problem of how to interface your game systems with Unity.
I’ve worked with Unity professionally for the last 6 years. In that time, on almost every team I’ve been a part of, my responsibility has been building the core gameplay systems (input, controls, movement, combat…) and on many projects I’ve built the core system framework as well. The best part about having that responsibility is I’ve been able to try out many different patterns, and I’ve been able to see what works and what doesn’t in the Unity environment.
In my experience, your best option is to keep your game code as isolated from Unity as you can. I’m not trying to insult Unity here. In general your best gameplay system designs will follow some sort of MVC pattern, and in this case Unity is the ‘view’. Of course Unity is your entire engine, so your ‘model’ and your ‘controller’ are also dependent on Unity. So what’s the point?
The biggest problem I see with Unity projects is relying too much on components or GameObject hierarchies to drive your game logic. When you have hundreds (or thousands) of objects in a scene, with scripts attached all over the place, debugging becomes a nightmare. But if you treat GameObjects as tools for visualizing your game logic, and keep your game logic encapsulated with minimal dependencies on the Unity API, then something like an MVC is possible.
There isn’t any strict formalism to this. As a guiding philosophy it will help you cut down on whole classes of bugs, help improve iteration speed, and make it easier to extend your systems and add new features down the line. Here’s a simple example using the new framework I started building last week:
MyAwesomeGame.unity3d
`-> GameObject
`-> Bootstrap script
`-> Awake() <=== this is your Main()
`-> Update() <=== this is your update loop
So far so good. I have a Unity scene, with a GameObject that has my Bootstrap script attached. Bootstrap is the entry point to your application, so you will want to go to your Script Execution Order settings and make sure it is first on the list. The boostrap script will maybe initialize some other core systems (anything static, like a logger) and then finally will hand over execution to a state machine, which will control the execution of the rest of your game.
Notice the other major Unity dependency here: Update(). I like to use Update() (or FixedUpdate or LateUpdate) to call my own update method with Time.deltaTime as a parameter. Again, this is probably just a matter of philosophy, but helps keep the mindset that whenever possible you should decouple your game code from the Unity API.
Ok, so I’ve created a state machine and it updates once per frame. I still need to spawn prefabs into my scene and use them to actually make a game somehow. But, I need to eat dinner and then hopefully make some progress actually writing code, so this will have to be a cliffhanger until the next post! duhn duhn duuuuuhn.
Posted on September 28, 2016
grep ‐‐week 39
This week’s headlines in procedural generation and design:
Jotun creators unveil eldritch-horror adventure Sundered
@destructoid.com
This game was just announced, describing itself as ‘replayable Metroidvania’, which is another way of saying ‘I want everyone to click on my link’. They also reference procedural level creation ala Diablo and a dynamic AI system ala Left 4 Dead.
Chris Roberts on Star Citizen’s Procedural Planets, Alpha 3.0, & CitizenCon
@gamersnexus.net
I suppose I’ll link to this, since it’s y’know topical and all, but it’s a pretty terrible interview with ultra poor quality audio. Sounds like Chris Roberts is in a closet underwater. I didn’t really get any takeaways from this, except that Star Citizen might have a little bit of procgen in creating planets.
Could ‘Astroneer’ Be The ‘No Man’s Sky’ Killer We’ve Been Waiting For?
@techtimes.com
“Astroneer, like No Man’s Sky, is procedural generated, but only to a degree. Many parts of the game have been handcrafted by the developers, and that’s a good thing because in theory, it should make the world more fun.” — More fallout from No Man’s Sky. Is ‘procedurally generated’ a dirty word now?
Mass Effect Andromeda: Curated Story Content vs. Procedural Generation
@gamingbolt.com
“Procedural generation isn’t bad in and of itself.” — I’ll take that as a yes.
Hearthstone pro says randomness isn’t really the game’s biggest problem
@polygon.com
Here’s an interesting take on the use of RNG and player perception of randomness. This sort of ties back to last week’s article about how developers communicate about procgen with their audience. This is something I’ve debated at length with colleagues ever since playing Tharsis earlier this year. This is great fodder for future posts.
Take a close look at the level design of some exceptional Zelda games
@BossKeys
This seems a bit off-topic but the MVP of my new game can lightly be described as ‘procedural Legend of Zelda’ (moar clickbait ftw), and so I love these Zelda level design breakdowns. This video introduces a very nice graph notation for describing Zelda dungeons that will make a great reference when I start building my own puzzle generator.
Posted on September 27, 2016
where to begin?
Over the weekend I started hacking up the framework to my new Unity project, which is always a fun place to be. I’ve built the core to many game systems, and the early days are full of possibilities. You get to test out new patterns, research the latest tech, and finally make some decisions that will inevitably cause endless pain to your future self.
Of course, since the whole impetus to starting this project was the desire to jump off the procedural deep end, that’s where I wanted to start. My initial plan was to start prototyping level generators, and once I had something that could provide the world’s terrain I would use it as the basis for everything else that will live in that world — environments, characters, narrative, etc.
It didn’t take long to realize this was an awful plan.
What are the rules that define my world? What are the constraints? Without knowing this (in extreme detail), my generator could create literally anything and I would have no way of evaluating the output.
There’s really just one question I had to ask myself: WWND? (What would Nintendo do?)
Developers at Nintendo often talk about their process of grey-boxing a small environment and prototyping character and camera controls until they are perfect. *PERFECT* They will spend months and months doing this sort of R&D until they get it to the point where they can hand someone a controller, step back, and watch them squeal with delight just from moving around this little virtual room, with no instructions needed.
Once all of that hard stuff is out of the way, the rest is easy. Slap some Mario skins on that shit and send it over to design. Done and done.
An interview from 1996 recently surfaced with Shigeru Miyamoto and his team discussing the development of Mario 64, where they describe this process plus all sorts of other great dev insights. After reading that, plus watching some Extra Credits design videos, then reading Kotaku’s exposé on the failures in Star Citizen’s development for some lessons on what NOT to do, it became clear that I had to start with the basics.
This means all of the fun procedural stuff will have to wait, probably for quite a long time. Once I have clearly defined the rules of my world, and the role of the player in that world, then I can open up the sandbox.
