C#/VB.net 与本菜鸡一起摸索用图像引擎做游戏

随着硬件整体处理能力的提升，.net平台上的这些托管语言的运行效率问题逐渐变得几乎……额开玩笑的233，但是开发一个2D的一般规模的游戏还是很没问题的。JIT的优化做得还是不错的，在我看过CLR
via C#之后甚至有点觉得比起生成本机代码的非托管语言，更了解当前运行环境的托管语言在某些方面某些场合反而具有……一点优势。虽然比起那些直接编译的语言，可能运行效率还是差很多，但是开发效率很多情况下高于它，微软提供的IDE的好用程度可不是吹的。这让Native C++还没学多少的我也能过一把写(zao)游(lun)戏(zi)的瘾，于是我用VB.net开心地做起了游戏来。虽然VB.net和C#都是编译时先经过各个语言的编译器转换成MSIL再通过JIT变成本机CPU代码，但是还是有着一些编译器带来的差异，VB.net没有C#里的out修饰符以及能直接使用的指针。C#里好像没有My命名空间以及一些VB.net从VB6里“继承”（字面意思）过来的……又好又不好的一些特性。
 

以上均为废话。相信很多人会问我为什么要用图像引擎而不是用GDI+，GDI+只是个轻量级的图像接口，而DX、OpenGL等等的图像引擎可以使用硬件加速并硬件渲染，效率差异在绘图量不小的时候极为明显。这里我原本选择的是Managed
DX，但是DX SDK安装失败了……万不得已我使用了还活着的SharpDX，是一个基于DX的封装很浅的开源封装库，不过除了官网上给的几个范例根本找不到资料，而且有些地方令我很不爽，大家还可以使用XNA、SlimDX或者Managed DX。  

选好了图像引擎，接下来就可以兴致勃勃地区开发游戏了吗？很大程度上不能。得掌握一些重要的编程思想以及拥有一定的敲代码基础。自研引擎的话需要一个完整的一系列的复杂逻辑链条，过程中总免不了出现恼人的十分难找的逻辑Bug，在初期的阶段超级难熬，我差点就放弃了自研垃圾引擎的计划。那么具体需要掌握什么呢？面向对象的编程思想、并行执行、委托、回调函数、多态的概念以及一些.net底层和系统底层的运作方式，比如GC垃圾回收机制、装箱拆箱的概念、位逻辑运算和Windows中的消息泵等等。
 

顺便在这里安利CLR via C#，看完我觉得我是受益匪浅。
 

另外你问我网络游戏？这方面我非常没有发言权，只能说胡话所以还是以下的话都很可能是胡说八道。我还没有做过联网的游戏，试着让我做的话，我会把各个玩家的按键发到服务器，运算都交给服务器。
 

我目前是一名准高二的学生党，水平很可能还是非常不够，有什么错误也请各位路过的大大指正，在错误中学习哈。


所有的资源（图片资源和背景音乐资源）都是工作室里的小伙伴们制作的。虽然很渣但也不希望被提取呢。