Jeremy Davis
Sitecore, C# and web development
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:
Having been in development for a long time I've come across a lot of headscratching odd behaviour in code. Those issus have lead to a fair few conversations where people have looked at the odd behaviour and asked "is it a compiler/runtime bug?". And in all these years it never has been that sort of bug. But for the first time I have recently found a situation where some odd behaviour is C#'s fault...
So here's some info about the issue I saw this time, and what Microsoft are fixing as a result:
