rude mechanicals…

3 mins watch.

STATE OF PLAY

Moved STATE OF PLAY to the top of page, my gift to the cba community.
Postponed design work to complete more nuts n’ bolts code.

Fundamental code changes: Instantiation > Pooling, Arrays > Lists.
Visited Develop:Brighton conference.
Visited Insomnia Gaming Festival.
Unity – developed crafting system and enemy AI.
Maya – started on basic models.

Well that didn’t go as planned. Despite intending to have a sprint on design, being niggled that the main (crafting devices) mechanic , wasn’t developed, I decided to ‘carry on coding’ .

RL:
The last couple of months, dayjob and family life left little time for Fiendish Devices. In spare time I tinkered at peripheral stuff, such as exploring the games-marketing eco-sphere (it’s a jungle out there); in preparation for when I have an Alpha build to show people.
This included a trip to Brighton visiting the ‘Develop’ conference for the first time,  very useful; particularly some talks focussed on Indie Development, funding and marketing, including tax break information.

I also attended Insomnia, the UK’s largest, 4 day, gaming festival with my son. He could try out pre-releases of games he’s interested in, whilst I chatted to devs in the indie booths. The highlight for him was PUBG, the Battle Royale-based game, brilliant in it’s simple premise: Drop 100 people on an island and last one standing is the winner. They can win by using the array of scattered weapons or just hide, clutching a frying pan, while others thin the competition. I once had the idea to use Lord of the Flies as a basis for a game, but I now realise I had over-complicated the idea. PUBG  just lets’ the players get on with it. It’s a great combination of the two of the most popular PVP arenas, co-op shooters like COD or R6 and a Sandbox PVP environment.
Insomnia was very different from Develop with a much wider array of content, but there were a cadre of IndieDevs and I talked quite a bit with them about their experiences and struggles. One booth of Huddersfield students had a slick-looking RPG, yet buggy as all hades. I said that I was amazed they had done so much design, artwork and  marketing, cardboard cutouts, banners etc. before they had established solid, working gameplay.
The student replied that they had done a simple booth previously, but no one came to check out the game, so this time they had put effort into marketing, at least people were coming to try the game. It makes me think that the sprint solution is a good strategy. While focussed on developmen,t I need to ensure I am not ignoring  marketing. Another indieDev agreed with me about #GameplayFirst, but he did also have some really cute designs in his game. Finally there was an underwater, Steampunkesque game called Fathom which looked gorgeous but had a four-year, rocky financial journey, with backers pulling out and unsuccessful Kickstarter, which meant the studio was now pushing more commercial titles; I hope they do get Fathom out of the door eventually.

Although I took a few weeks break from Unity, I did some structuring on paper to try to organise my ideas about how the code for the crafting system would work. It’s good to get away from the screens and lay out ideas with pencil and paper, I wonder if other programmers like to organise their code on paper.

Returning to Unity I have made some changes to the code framework. Initially I used instantiate, Unity’s way of creating new GameObjects at runtime; however, there are drawbacks to this method, firstly it uses processing power in ‘Garbage collection’ ie it has to reallocate memory when items are created and destroyed; not a huge problem with my game as FD1 won’t have lots of objects in any one scene, but still inefficient and not great if I want to push out some of the game to mobile. The second reason was that instantiated objects had a problem with linking to my hierarchies of other GameObjects and scripts . So I now use ‘pooling’, ie having a bank of inactive objects ready in the scene and turn them on when they need to be ‘created’. This makes garbage collection  unnecessary as objects are just turned on and off rather than being created and destroyed, also they are already linked to other objects as required. The downside of this method is that I need to know in advance the number of maximum items to be created in one scene. It’s the kind of limit I am happy to embrace controlling the scope of each scene. The player will have to solve rooms with a limited amount of resources which is good.
I also changed from using Unity’s arrays, which have better performance, to using Lists, which are more flexible. The performance differences are trivial on my framework and I probably need to be less anal about some efficiencies at this stage.

Eventually I made a spurt of progress with the crafting system: traps can be created powered by steam, gas, clockwork, electricity, fire and explosives which all have different effects, bringing life to the game.

Models
Previously all assets were made from primitives in Unity.
I still hold with not spending a lot of time modelling until the gameplay is solid, I have started to work on simple 3D models in Maya.
Aside from cosmetic improvement, I need to establish my pipeline for assets. Unity and Maya have a particular disconnect; the base units for 3D space in Unity is meters, whereas Maya works in centimetres. It would be easy to, for example, change Maya to work in Meters so that I import everything at a 1:1 ratio. However various problems can occur with physics simulations or animations being scaled. In the end I have gone for a scaling 100:1 at import into Unity seems okay. Initial objects were clumps of parented Unity primitives, whereas now they are single objects from Maya so I can add textures and have some more realistic idea of performance as I work.
This spurt has improved the foundation of the game mechanic, I now need to have a design and marketing sprint.

Leave a Reply

Your email address will not be published. Required fields are marked *