1. 废话环节（可以不看）

其实我们公司不是游戏游戏，但确实有一块功能需要用类似游戏的表现形式，但都是一些比较简单的游戏，类似黑魂、血源、只狼啊什么的，不是！其实就是一些小游戏，像抢答题、拼接树形结构的数据之类的。

原本我们是用Unity3D来做的，毕竟公司里就我一个会写游戏，只能按照我的技术栈走了。

确实我也开发好了，游戏也能玩玩了，但毕竟我们是做管理系统的，始终绕不开Web这玩意。在推产品的过程中，客户自然会问：你们这玩意，可以在手机上运行吗？

开玩笑，当然可以，只不过，人家要的是在浏览器上运行，当初Unity的WebGL版本体验也不太行，很多手机浏览器都跑不起来。至于后来的Tiny Project，我刚开始是很期待的，然后我期待了1个月、半年、1年、2年，啊，正式版仍然遥遥无期。

而我，作为公司里的万金油，并不能经常去写游戏的功能，慢慢的，我对Unity3D也越来越生疏了。

是的，我放弃了，我等不来Tiny Project，我也没精力去研究它。

于是，我给老板提议，游戏这块要做Web版的话，就用Blazor吧，未来我们的管理系统也全部移植到Blazor吧。这样的话，我们就能把所有的技术都统一为C#了，我也不会花那么多的精力去跟进React这些前端技术，我只需要掌握C#的技术栈就够了。

老板同意了，那是半年多以前的事情了，一直到现在，我们都没时间去移植Blazor版本的管理系统。

但，游戏这块是必定要用Blazor来写的，于是，在空余时间，我就先研究一下怎么用Blazor来写游戏。

2.为什么要拒绝用Canvas？（还是废话，可以不看）

用Blazor开发游戏，其实已经不是什么奇怪的事情了，大家网上都能搜到很多开源的小游戏例子。

但，大部分用Blazor开发游戏，都绕不开Canvas，毕竟渲染游戏对象，确实用Canvas比较舒服。

Canvas确实应该是首选，正经写游戏的话，还是得用它。

但我们公司不一样，我们穷，开发团队都是同时兼顾多种领域的开发工作，所以，我的策略很简单——尽量用现成的东西。

用Canvas绘制游戏对象什么的，会更符合游戏开发者的习惯，涉及到坐标、碰撞这些功能，实现起来会更加轻松。然而，它有个很大的缺点——很难和Html元素混合在一起。

举个例子，比如一个战斗角色，要在头顶渲染一个血量条，用Canvas的话，这个血量条只能自己再封装一个组件。但如果能用Html元素，那就直接用AntDesignBlazor这个库的Progress组件。

更多的，游戏的UI界面，如果UI里要展示一些由Canvas绘制的内容，那又得做一些特殊的处理才能实现。

总而言之，Canvas本身和Html元素是隔离开的，要混合在一起，必定要做特殊处理。

而我们的游戏，逻辑本身不复杂，但必须要有一些UI实现游戏玩法，如果不能方便地使用现成的UI库，对我们来说是致命的，我们没有精力去重新封装这些UI。

所以，我只能做出这个奇怪的决定——不使用Canvas。

经过一段时间的研究，我成功地用Html元素（利用现成的Blazor UI库）来展示游戏角色、处理游戏角色逻辑，将角色的渲染和UI方便地融合。

一方面我参考了Unity3D的Transform、Component、GameObject等实现方式（只是粗略参考，我并没有研究透Unity3D），另一方面也参考了上面提到的使用Canvas的项目：mizrael/BlazorCanvas: Simple 2D gamedev examples using Blazor and .NET 5 (github.com)，主要是参考它对于游戏逻辑的控制。