Lostcast 145: Function Bump
@geoffb it sounds like you’re using multiple singletons?
Do you find that more helpful than a less targeted, more encompassing singleton?
I’ve been opting for a game singleton, and using it in much the same way as you’d use a world object in a scene-graph, that is, my game object spins up what it needs, and keeps references to it all internally (PokerKingdoms.instance.table, PokerKingdoms.instance.deck, etc…). Recently I implemented a multi-player interface, and rather than rewriting my player object from a singleton, I could change the player variable to an array, and write a few handlers in the game class to be able to address the various players. It was one of those instances where everything was structured so well, that I moved from 1 player, to N player support with about half an hour’s code.
I’ve always seen singleton as a way to define something that there could only ever be one of - and in game-dev, I’ve only ever seen the game itself as sitting in that basket.
I’ve probably taken this structure too far in the current PK rewrite; the game itself was developed from scratch completely detached from unity, and my scenegraph is now just a view, and interface into the game itself (too much time doing WebDev)
@salmonmoose Yeah, we’re currently using a few different singletons in various places. The idea of a single singleton for the game instance is interesting. I’ll have to let that percolate and see how I feel about it.
As for separation of game and view, I’m trending in the opposite direction. Our current HTML5 game engine has that going on and I’ve come to loathe it. I find that there’s much more code involved with keeping the view in sync with the model. After using Unity for a while, I really appreciate that the view and model can exist on the same entity. Webdev has definitely trained us to keep things separate. A big downside, in HTML5 at least, is that we end up traversing the model’s entities and the scene graph’s node in separate passes, which is bad for performance.
I get around that by providing soft links.
For instance, PK is built around a table, deck, cards, and hands. I have classes for all of these, and GameObject classes for each of these.
The base class can spawn a GameObject, and both objects can talk to each other.
However, the base class can exist without a GameObject, I use this for when I’m dealing with an object in an abstract sense, for instance, my AI routine generates literally thousands of hand combinations, (a hand is a collection of 5 cards), and spinning up, and throwing out GameObjects would be terribly costly, and without severe optimization, would also likely make the GC rage.
So the logic part of the game operates completely without the aid of unity.
Keeping the GameObjects in sync with the base classes is simple, animation is queued on the GameObject, which generates it based on the base class state (ie: change of state since last frame), and Animations can lock GameObjects, if a base-class has a GameObject, and it’s locked, it does not change state.
At any time, a GameObject can determine its real, and perceptive state, depending on which object it queries.
This gives me blocking, and non-blocking animations, and, in theory, I could slot any interface in front of the game logic (like a network).
Pulling Unity away from the Logic means unit tests are significantly easier to build (I’m closing in on 150 of them).
It’s all falling into place - however, it is currently designed around something with very discreet states, rolling it onto my more realtime projects may expose some flaws, although they tend to have far simpler logic behind them.
Loved the cast. I got this to say, when I backed AWL2 on Kickstarter I wanted to back it because you guys were developing it. I mostly wanted to support you guys, but now, after listening to this lostcast, I want to PLAY AWL2 because it sounds ‘coin noise’'ing awesome. Mana slotted weapons just sounds different enough to be cool and interesting, but understandable enough where I will likely have 0-.1 “Wtf is this, and how do I do it?” moments trying to figure it out. Great stuff guys, I look forward to seeing this very cool sounding game unfold.
I really enjoyed this podcast. I’m dealing with some burn out still myself, I have a self imposed ban on not working on any games or anything after I leave work. It’s been very tough to switch my brain off, it’s always whirring away.
In relation to @geoffb and the variations game engines you’ve worked on / tinkered with, I often wonder what game development is like for people who don’t come from a software background. It was the curse of my beginning game development years when the only way into the industry was as an coder so I’d write and re-write things all the time…and never get closer to finishing a game - but I did have a pretty tight A* with some heuristics for a while :P
Yeah that’s interesting I’d imagine that when anybody’s first working on games, they “retreat” to what they’re most comfortable with. So for us as engineers, it was over-engineering and making too vast of an engine. For artists, it’s probably making a ton of graphics, then later realizing they’re not the right assets for what they want to build.
It’s tough because when game-making there are so many important disciplines to pursue. Fun tho :D
@salmonmoose That’s definitely the way to go for games like PK. Since we’re working on real-time arcade games that tends to slant my opinion. When we make turn-based games, I tend to follow a similar setup: The game simulation exists in isolation and simply throws event which the rendering code listens for.
I’ve never been a testing fan, but I having a rock solid, self-contained simulation sounds great.
@Vox Thanks! We’re moving much faster, which is great. We’ll have a playable demo for Indie Cup in December. I’m thinking that we should do a limited alpha test after that as well.
@anthony I wonder that, too. In my head, those people can focus on game design and building good products without worrying too much about tech. However, the lower-level stuff does genuinely get me excited so it’s tough to stop tinkering.
@richtaur ugh i know. I kept wanting to not launch a new app of mine. Trying to think of things to add, wanting to add a first time user experience, etc. But in the end, i just had to ship it. I fixed some animation lag this morning, and pushed it up :). It’s so easy to want to go back and refactor, or add one more little thing. We sometimes just have to think about what is the goal. While making stuff is important to practice, so is actually shipping it. Speaking of which, i have yet to practice any marketing :(
I think Unit testing would be a poor fit for real-time arcade stuff anyhow - where it would do you some good would be in your generation code. Starting with a simple test like “can I get from the start to the end” would cut down your iteration time dramatically, and allow you to build more complex sets of rules - and in turn, tests, (like, “are my bonus rooms off the main path”).
I’m curious if you run any other tests in your game - it was a bit futile, but PK collects analytics, how often a certain hand is drawn, how long the player takes to make a hand, that sort of thing. It was mostly useless, although the hand frequency was useful, flushes are by far the most common hand drawn, because the match-3 genre teaches us to match by color, not other patterns. But a flush is a stronger hand, than it is hard to make, so I had to pull back the points, without changing it’s rank.
I think you’d get some interesting numbers out of AWL(2), even if you tracked which weapon killed which enemy, you’d be able to balance weapon/enemy distribution for difficulty (giving players optimal weapons in the early game, and less optimal weapons later in the game).
I just used Google Analytics, and fired off events (so I can also see which countries make which hands most) - but I’m certain there are game-centric analytics providers.
@salmonmoose Unit testing would be good for generation, I agree. With AWL1 (and 2), the dungeon generation code is unable to build a “broken” dungeon (at least I’ve tried very hard to make that so). It works like this:
- Place start room on the map
- Place a path of rooms from the start of some length, culminating at the end room. This is the “critical path”. (Room choice uses heuristics to prefer rooms with fewer existing room near them to avoid a dungeon that circles back onto itself or into a corner.)
- Create a pool of valid rooms from which to create off-shoots. Create N more rooms, where N is the max size of the dungeon.
- Randomly connect N rooms to each other excluding the start and end rooms.
- Choose room types and locations.
With regards to analytics, we’ve collected them before using GA and mixpanel, but never actually used the data for anything smart. It’s something I’d love to dive back into because, as you point out, it’s great for understanding game balance. My quick 'n dirty method is to look at Steam achievement % to see how far people make it in the game, heh.