1赞
做过一大片子弹的 没注意多少，后期就一直在优化渲染，不过有合批，drawcall也不会很离谱
https://docs.cocos.com/creator/2.4/manual/zh/advanced-topics/ui-auto-batch.html
1赞
渲染不用担心的，因为人物很小，大概就20个像素左右，1024x1024的合图能容纳50个左右的人物图片，将僵尸和人类的合图在一起渲染问题不大的，关键是人类和僵尸的行为逻辑，看图差不多有1000个单位在动，就算每个单位的行为才是消耗最大的地方
以前用别的做过类似的，还要放大缩小，后来卡爆了。要对图片做处理，类似谷歌百度地图那样
专业术语叫Lod吧
还好，你这个元素比较简单，几乎可以全部合批，渲染上压力不大，消耗主要是cpu计算上
如果是需要可以整体放大，那么每张图片的分辨率要有一个限度，不然可能图片数据缓存要爆
如果只是需要单个图片的放大而不需要整体放大，可以分两套图，一套是icon显示小图，一套是大图。
这个渲染应该没问题 背景图用纯色加一些树之类得填充 人物和僵尸都能合批。没有打断合批得话，dc会很小 主要是1500个单位都能随意移动就代表要给这1500个节点都绑定一个脚本 每次update都要判断当前得位移目标并进行位移。这样子gamelogic耗时可能就炸了
遇事不决30帧
老板有眼光，有胆识有想法，不随大流
用c++写套ecs
感谢各位回复。
合批 LOD 看来是一定要用的。
AI肯定也要分帧处理，像人是5帧思考一次，僵尸7帧一次这样。
待我来年慢慢搞吧，看下creator性能到底如何。
反正项目经理说了“年后只要你和游戏有一个能跑就行” 
1赞
才1500个简单sprite的渲染你瞧不起cocos呢，不要太轻松，不过1500个同时寻路，走好不送，web还可以一试，源生的优化够你吃一壶的
我表示最新版的cc项目没几个逻辑，最基础的打开弹窗都好卡
如果为自己好，还是推荐unity
1赞
看这个设计图，渲染我感觉没啥问题，分层合批用好了完全没压力。
业务层面，首先，可以考虑用 bitECS 做核心逻辑解耦，这个ECS框架比较优秀的一点是使用TypedArray做存储，使用位运算做筛选，性能相当优秀；
其次，参考米哈游的技术分享（Genshin Impact: Building a Scalable AI System
），AI也可以有LOD的概念，一些决策树等复杂逻辑可以做到10Hz以下，其实也不会影响表现；
再者，如果是web平台或者微信小游戏等支持的平台，可以考虑用wasm承载部分重度逻辑，只要把关好IO的频次与数据量，使用wasm应该是正收益的；
另外，场景内物体的全局调度上，使用高性能的四叉树（少闭包+位运算+对象池）做场景划分，应该也可以大大减少一波性能开销；
最后，要是这些逻辑能放到服务器上，那就让服务器去扣性能吧，做个渲染仔拼UI多舒服。
4赞
上四叉树 
这么多单位要同屏出现吗？在手机上能看得清吗？
还是不决就PPT