Jeremy Davis
Sitecore, C# and web development
I've been working with C# most of my career, but every so often they add bits to the language which for some reason I've never really got to make use of. And "covariance" is one of those things. But I picked up a beta copy of a great new book recently (Eric Lippert's "Fabulous Adventures in Data Structures and Algorithms" from Manning) and it had a simple but fascinating example of a situation where this can work. It taught me something that maybe you might find interesting too...
Following on from the general framework bits in the previous posts about building a text adventure, what needs doing to create an example game? Here's an explanation of the example repo game to show how it all goes together. [ Spoiler warning - if you want the fun of playing the example game, don't read this post before you play, as it explains some of the puzzles.]
Last time up we created the very basics of a text adventure where we could look at rooms in the world, and had a way to provide other commands like movement or picking stuff up. So what can we do to let the world react to the user's actions, and create puzzles and atmosphere for a game? Step forward behaviours...
The world model from the previous post is all well and good, but the player needs to be able to interact with it. What do we need to add to allow that? Well we need an abstraction for the things the game is going to allow the player to do.
As you might guess from someone who's been writing a blog for a decade, text adventures were something I really liked back in the day. I spent a lot of time on classic Infocom games like The Hitchiker's Guide to the Galaxy. But what if you wanted to build your own as a .Net developer? This blog series has some suggestions...
For a long time a small thing in writing Razor code for Sitecore (and in some other places) has irritated me. It's not really very important, but with the new version of C# there is finally a way to round off this rough edge that's been getting to me...
Sometimes it's the simplest things that can trip up development work. A case in point is a bug ticket I got handed recently, which I think shows the need to understand your tools when writing code. Read on to avoid an interesting mistake with code flow in Razor views...
I've been tinkering with some pipeline modules for the Statiq generation engine that I use to render this blog, and I bumped into a fun mistake in my code which confused me for a while. To help me next time I'm doing this sort of modification, this seemed worth documenting - even if it is a bit of a silly mistake...
One of the fun things about defining objects and their APIs in C# is thinking about which bits you want your consumers to see, and which bits need to be there just for you, and consumers should avoid using. Most developers are aware of keywords like
public
/
private
and
internal
for achieving this, but Explicit Interfaces are another approach to this...
I was tinkering with some some code that could post to BlueSky recently, and it took me a couple of goes to make the process of submitting a message with an image work. So in case it's of any use to anyone else, here's one way it can work:
