未加星标

JavaScript: Do you like games? (part 1)

字体大小 | |
[前端(javascript) 所属分类 前端(javascript) | 发布者 店小二03 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏
javascript: Do you like games? (part1)

Maybe I should ask if you’ve ever thought about how games work, perhaps even about building a game from scratch? If not, turn away now; I see lots of math in your future!

In my childhood I was fascinated by Mario and other games like it. They were very simplistic and yet extremely fun to play. Mario is making a comeback with Super Mario Maker on Wii U which actually didn’t surprise me one bit.

After years of programming I tried to make a few games of my own and I quickly realized that the methodologies, working environments, strategies, planning, testing and ways of thinking were totally different.

I still wanted to learn… and using a framework wasn’t enough; I wanted to know enough to build one from the ground up. Pure foolishness right? I prefer to think about it like Witold Gombrowicz did :

Foolishness is a twin sister of wisdom .

There’s no code in this part (sorry); we need to get some things out of the way first…

So how does one start building a game? Here’s the thing, a game is not usually something one does without a team. You need a few things: a story/idea, a game genre, the game platform (web, desktop, mobile, console), a programmer and a designer at the very least. Currently the team consists of: me, myself and I…well see how that works out.

I wanted to make a mini-engine/framework/library/bundle that would enable me to build games. It needed to have some of the basic functionalities like:

the game loop generic screen drawing and refreshing logic multiple screen containers (like you would see in a 2 player split-screen game) screen container clipping screen layering input event handling (from a keyboard and/or mouse) custom event dispatching asset loading (for in-game media files like sounds and sprite sheets) displaying and animating sprites (blitting a.k.a. bit blit ) animation frame rate control path finding (this might be nice to have) a 2D physics engine (2D to keep things “simple” as it should have collision detection support and other features)

You might be thinking that’s a hefty list but the ideal engine should not be opinionated on the game types you can build; besides, the list is actually pretty small and I wanted to get out of my comfort zone a bit.

I wanted to write everything in ES6 so I prepared a babel-gulp-webpack-sass boilerplate. It works with the live reload extension to facilitate development so make sure you install it in your browser. Follow the instructions to get it running.

I’ll do all the coding in another GIT repository , to keep the boilerplate intact.

For rendering I decided I’m going to use the Canvas element. It’s not interactive (I’ll go into more details about this later) so it might add more coding challenges, which is perfect. It’s generally the preferred choice for web games so it fits the bill.

The approach will be simple, we’ll have a dual purpose code base:

one part will be the engine and the other will be games using that engine.

Creating mini games with an immature engine will quickly let us know what it’s lacking and how to improve it.

Let’s start with the first thing:

The game loop. What is it? Why do we need it?

I consider the game loop as the heartbeat of a game. It keeps everything updated and rendered correctly. Everything drawn on the screen needs to work with a single game loop if we want deterministic behavior.

You don’t want to create a shooter game and have bullets pass through players without damage, or have the players fall through the map because the player, bullet and map updates were in different loops.

In older browsers the setInterval() method was the way to go, as you could call it once every n milliseconds. Nowadays that’s a bad practice and only used as a fallback if requestAnimationFrame() is not available. The requestAnimationFrame() method will trigger ~60 fps. It’s an approximation because it will generally match the refresh rate; more here .

I usually like to have a small class diagram before I start coding to at least highlight the main class containers. Something along these lines should suffice for now:


JavaScript: Do you like games? (part 1)
game engine diagramv.1.0

This diagram is incomplete and that’s perfectly fine, we just need something to get started, but first some explanations:

at the core of everything we have an EventDispatcher which we can use to listen for and emit (trigger) events; this should probably be a singleton and it will act like a global publish and subscribe. the Keyboard will help us determine when keys are pressed and released. Now while it does extend EventDispatcher , we should not use its features to implement the Keyboard logic as we don’t want to propagate events back and forward, we simply want to have that option if we need it. the Canvas has only tow jobs: to create and store a reference to the canvas tag and its context, to update its properties on screen resize. Everything will be drawn on a Canvas instance. the Scene extends the Canvas and you can think about it as a viewport/camera/screen. We can have multiple Scene instances for when we want to do things like split-screen. Its job will also include calling the update() and possibly render() methods of all elements within it. the DisplayObject is what holds any items that we want to render. Other classes will extend it and add more properties; for instance we might want to set things like isSolid , hasGravity and others to be consumed by the physics engine. the Game class will hold the main game loop, all the scenes as well as some game play and pause functionalities. the AssetLoader is self explanatory.

The structure might not be perfect but it’s good for our needs as any class directly or indirectly related to Canvas will be able to: dispatch events, listen for keyboard inputs and draw to the screen which is nice.

You might be asking yourself if we really need the event dispatcher; I’m actually planning on using that later to facilitate unidirectional data flow.

Next we’ll start working on all of these classes and maybe implement the basis of a mini-game to see some actual progre

本文前端(javascript)相关术语:javascript是什么意思 javascript下载 javascript权威指南 javascript基础教程 javascript 正则表达式 javascript设计模式 javascript高级程序设计 精通javascript javascript教程

主题: JavaScriptJava
分页:12
转载请注明
本文标题:JavaScript: Do you like games? (part 1)
本站链接:http://www.codesec.net/view/483835.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 前端(javascript) | 评论(0) | 阅读(27)