> [VS Code] proved itself when I wanted to implement my own add-on for Sublime Text. I gave up after three days of chasing the arcane documentation and just tried VS Code where I was able to do custom syntax highlighting and deep game script integration in a breeze.
I feel this. The documentation for Sublime seems to be in a permanent state of chaos. Most of the details of how to write plugins were never documented in the first place, and for what you can find you will never be quite sure if it applies to ST2 or ST3. Even the official website has a bunch of outdated documentation for version 2 that still isn’t labeled with version number. I imagine this will only get more confusing with the upcoming version 4.
I know almost nothing about it, but there’s some kind of early alpha or beta testing going on. I don’t believe there’s much of an official “word” at all, let alone on ETA.
If you're serious about large scale games, you should look into typescript. I'd start away from any other language, like coffee script, Ruby... See my next point.
Use node.js on the back end so you can do client side and server side validation with the same code. Another benefit is that you can also make your game single player much easier. I usually prefer to start the game multiplayer first and then do single player.
Another tool useful for game is pixi.js (or phaser if you need what they provide. Pixi just does the rendering part, phaser does a lot of game related things)
I'd use illustrator instead of Photoshop because you can scale your graphics without losing quality. Vectorial is better than bitmap.
For state management I use redux.
If you're interested here is my game https://bitplanets.com . It's a RTS game, where you need to conquer planets. You can play with your friends and people online. Of course no need to download or register and works on mobile. (60fps if on a decent phone)
It still confuses and unsettles me that Paint.net started as open source and then went closed source. I mean, people already had the source. All because someone tried to fork it? It just doesn't add up.
Someone tried to claim it as their own by repackaging it and packaging up some plugins... He obviously got annoyed and figured he doesn't want to make it so easy to make your own version.
It adds up for me, just kind of unfortunate, I'd like to think it still would've been better off open, but it's his creation and his time and effort so if that's what he wants to do, I'm ok with it.
It's not clear to me if they used Electron's Node backend for much more than it's File API. If that's the case, they might have been better off just using a QT webview (e.g. pywebview) for the sake of performance (which they cite as reason for moving from NW.js/Electron).
I'm not very familiar with Qt or Qt webview but from their documentation it states:
> This version of Qt WebEngine is based on Chromium version 73.0.3683, with additional security fixes from newer versions.
Assuming they both have a full Chromium embed, would there have been better performance? I assume the developers are mostly JavaScript devs so their choice to use Electron/Node makes sense.
Most folks complaint with Electron isn't that it isn't performative, but rather that it is bloated (you ship an entire browser when all you needed was eg the canvas and v8 engine).
In all fairness, are you aware of a tool for web developers that only ships the canvas and v8 engine? Legitimately curious, because I've tried looking in the past for similar reasons (game dev on an engine I already know) and came up empty-handed.
It's not finished yet but you can get close to 20M mem usage + overhead of your libs & assets. Executable size is node.js + 2M (30M total IIRC and it compresses nicely to ~10M *.dmg because node contains a lot of strings)
Please file an issue if you want it to happen so that it can be tracked how many people want it too (I had no idea that this is a thing in gaming community). It's now at the bottom of my priorities (I'm working on raspi support so that it can run as smartmirror) but it's not that hard to add so it could actually happen.
I added a watch to it and starred; I think it'd be a good idea to be more clear with what's being built in the README.md because I wouldn't have thought that this was a stripped-down browser based on the headline. As well, it's difficult to see exactly what you are getting from graffiti (is it just canvas, does it include DOM stuff) at a glance which may turn away those browsing repos.
Agreed that README is very unclear - it's not a browser at all, actually. It's just a GUI library for rust & node.js which happens to have little DOM-like layer.
This pseudo-DOM is really just enough to make web frameworks work. I want to do GUI apps with the same tools & libs which I use for web development but I don't want to include the whole browser and moreover I want it to be enough resource-savvy so that it can run on my raspi attached to the TV.
It's hard to describe what it is good for because there are many use-cases. It's really rather a platform just like Electron or Qt is, but of course it's very limited now. But really, if you or anybode else have better headline, I'd love to hear it.
Just in case you are not being facetious: totally agreed; but in the case of delivering a game on platforms that include Steam, and also for perception reasons, not really an option.
This would be great, if only... Realistically, I just want a canvas with some audio/input stuff in most cases (though being able to put some divs in places may be nice for rendering things like menus).
I looked a bit a few months ago. There are some interesting things out there. But you will probably be a bit on your own (but not uncommon when it comes to game dev though!)
They tend to use ~10x the memory that seems reasonable—generous, even—for what they're doing, and periodically misbehave and decide to eat tons of cycles continuously for no obvious reason, in a way native apps don't, or at least not so frequently and nigh-universally.
Sure, partial counterexample in VSCode, but then there's all the others.
I agree with what you are saying with regards to the tendency of the platform. But, aside from the weight of unnecessary/unused browser features, I think that has more to do with the needs of the developers attracted to the platform more than the platform itself.
"The needs" being a requirement to ship a MVP ASAP using developers that can agree on a lowest common denominator language of js.
Except for then you have to deal with whatever version of embedded Internet Explorer .NET uses. Maybe the UWP solution uses Edge now, but that still isn’t wonderful compared with embedding Chromium.
Usually in .NET you typically get IE, not Edge. People have been using CefSharp as a replacement. A number of software I have contributed to have done this.
In contrast, UWP applications do use the Edge rendering engine, and while it may or may not be possible to use CEF in these applications, you won't be able to get it certified by Microsoft, therefore no one, at least to my research, has bothered doing so.
I wonder what the future brings with Edge now just being chromium based
Most websites don't run well on even high end hardware. There's most certainly a performance tradeoff using a browser, especially for something as performance sensitive as a game.
Just to add a little more... Haxe not only transpiles to C++, but it also transpiles to JavaScript. With a Haxe codebase, can deploy a project as both a native app and on the web. Really nice for games especially.
Kha is really nice and I like using it. It's amazing that the author developed a specialised IDE (granted it's a modified version of vscode) for the framework.
The quality is so very high, much much higher than a typical open source project, because it's not just a bit of code, but an entire toolchain and workflow. So much so that an entire engine is built off this framework! https://armory3d.org/
I am currently using Haxeflixel game engine for a trivial project and I am enjoying the overall experience. Haxe is a great little language a8the engine is fully featured. The basics like scene management, gui, pathfinding etc are bundled in.
I also tried Heaps which on paper looks amazing but could not proceed due to lack of documentation.
I remember steam games were made in Flash a few years ago. Doesn’t it just export to HTML5 these days? Isn’t it used / couldn’t it be used to make a steam game?
HTML/JS is criminally underrated as a game development platform. You get so much from it, like instant deployment, delivery, multiplayer features, and so much more. You can just send a link to your friends and they can join your game with a single click.
The reason why business apps went all to the web still holds for games as well. Games like agar.io use these features, such as no downloads and instant start, and their success speaks for itself.
My current project, Loop Thesis, is completely HTML5/Javascript. It's going to be a downloadable game, but (at least right now) I can bundle it entirely in a web browser, and often do for demos.
It's complicated.
I don't regret writing Loop Thesis in Javascript; there are substantial benefits to the web as a platform. If I went back to rewrite Loop Thesis from scratch, I wouldn't do anything different. But benefits aside, there are also complications and headaches, particularly around timers, audio, controller support, and garbage collection. I think there are concerns that have to be balanced.
There's definitely room for more games on the web, and there are huge benefits to looking at it as a platform, but I don't want to give the impression that it's all rainbows.
I would bet that the reason HTML/JS is "underrated" is because it presents a unique problem: that no two browsers behave the same way when it comes to HTML rendering.
As a quick test I just opened two browsers in my PC (Windows), ran the Acid3 test, and got different results at different speeds. My phone's browser gave me yet a third result. That's a bad start for a multimedia platform that I'll be in charge of supporting.
For all its weaknesses, there was a platform that offered all you mentioned plus good portability and saw the success you speak of: Flash.
When people refer to HTML5 for games (including this post) they usually mean the HTML5 canvas and its associated APIs (canvas/webGL), not using actual HTML elements to render game graphics.
From what I know, canvas rendering is pretty much the same across different browsers. It's a pretty low level API so there's not as much room for interpretation. In any case, the Acid3 test you're running is focused on the specifics of HTML/CSS layout, and don't think it tests the canvas at all.
I think that canvas has done a good job of taking over the use cases that Flash had, and is very portable these days (basic canvas has 98-99% support[0]).
Canvas rendering isn't that consistent, and when it goes weird it's often OS specific instead of merely browser specific. Some things I've run into:
- OSX likes to turn random Unicode symbols into emoji (extends past Canvas)
- Fractional font sizes on Chrome/Linux get bizarrely stretched out (after a transform that makes the font not a fractional size)
- Complex clipping operations freak Chrome out
- All the compositing rendering options are broken somewhere or mis-defined to the point that it's weirdly hard to render anything to an alpha channel
You also need input APIs to make a game, and the input APIs often have strange inconsistencies in function names, returned objects, or event ordering.
Canvas is nice and straightforward if you want a purely sprite-based game with only mouse/keyboard input (but even then you need to jump through hoops if you want pixel art). Anything beyond that is going to need cross-platform debugging.
Canvas has also had some really weird performance issues in the past that are browser specific. Chrome once decided that the number of images used was too many in an animation, so it had to decode some of the images in the animation on the fly. This obviously killed all performance. This bug has been fixed, but I'm sure there are many others like it around.
> ran the Acid3 test, and got different results at different speeds
It's worth checking the Acid Tests homepage [1] here:
> Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers.
Well, the rendering problem can be solved by using an existing game engine. Rendering is done in WebGL, and the engine abstracts away the browser-specific details.
Furthermore, because of Google's dominance, not many browser engines are left in the market. Essentially all you have to do is support WebKit, Gecko, Blink, and you'll cover 99.9% of your userbase.
The HTML part of javascript game engines is generally just enough to get a <canvas> on screen and dive into WebGL.
The thing is, you can target Unity/Unreal/etc at a browser and get most of the benefits listed above, plus the benefit of using more-or-less the same toolkit as everybody else.
Has Unreal improved their HTML5 offering? It used to be rather poor, because of the immense filesize of the engine. Have they got it down to reasonable levels yet?
How is that a unique problem? If you have an iOS native app and you want an Android native app the difference are probably 100x the differences needed to deal with Safari's quirks vs Firefox's vs Chrome's. Same for Mac->Win->Linux.
The context of the discussion is HTML/JS as a game development platform. Considered as a platform, that is rather unique. iOS and Android are generally not considered as a single platform.
Woah, I tend to keep up on the fairly bleeding-edge of web tech and I hadn't heard of Web Bundles before.
It seems pretty neat, my question is what the functional difference between this and running something like wget with recursive and convert-to-local flags?
Let's say I have some contrived portfolio website and it contains links to several sub-page sections, and some static resources (images, JS, fonts, CSS, etc).
I can run this and get an offline copy of the website that I can browse or distribute how I wish:
You don't need to develop for HTML/JS directly to target the browser as a platform. (Not to say it's not an option worth considering, just that you can get the delivery benefits from other stacks.) Many current engines can build for the browser as well as native applications: Unity, Godot, GameMaker, OpenFL come to mind.
Using things like DOM integration, WebRTC multiplayer, URLs as navigation requires you to develop for the web as a first class platform , which you can only do with JS directly.
Yes, you lose many of those capabilities, but you also gain new ones. I bet agar.io would never have been played had it been a Windows executable or a Steam game. The friction in starting the game and playing the game is so low, that it drawfs all other downsides by far.
In fact, this is the exact justification why HTML/JS business apps have thrived, because even though JS has tons of problems, all of them can be overlooked when you gain the capabilities of the web.
Hacking in HTML5 multiplayer games is a difficult issue. There are cheats/hacks for Agar.io, Slither.io, etc utilizing JS injection scripts and extensions.
Fun fact: there is a hacking forum that still have failed to create trainers for Curious Expedition due to "weirdly changing memory addresses". I think if they would have realized that it was just a browser game it would have been much easier for them.
I have been thinking about this problem a lot and I may have a solution. Essentially, every time the user loads the page he gets a different obfuscated version of the base game. In this way, no script or plugin can be made to hook to your code since it's different every time the game loads. In addition, you can also obfuscate the protocol (for multiplayer) so that network sniffing tools can't capture the relevant data when communicating with the server. Finally, you can tie an obfuscated version of the game to a particular user, so you can find hackers or make it harder for them to run the game.
Jokes aside, there are some Korean MMOs that rely on excessively trusting the client as a core part of their business model. If you offload as much state as possible to the client your server costs go way down. Maplestory is an example of this: if a player is alone on a map, essentially all map state, physics, etc. is handled purely on the client. When another player enters the map, half of the NPCs get 'handed over' to that player, and the server syncs state between the two clients.
On the other hand, you have to keep in mind hacks like bots and wallhacks. In the case of bots obfuscation is practically your only defense. In the case of wallhacks you can try to keep clients in the dark as much as possible, but there will always be a period where the client knows more than the player should (unless you want enemy players to 'pop in' once they are fully in view).
>If you offload as much state as possible to the client your server costs go way down.
It also makes the game much more fluid without adding a lot of complexity to hide the latency. I think South Korean games can get away with it because they require an SSN to register. If you get caught cheating then making a new account isn't easy.
Cheating using modified clients is hardly unique to HTML5 games, and the solution is the same everywhere: move game logic decisions on the server and only have the client predict those decisions while it sends its own choices to the server. The problem with Agar.io etc. is maybe that they don't have a sound multiplayer model designed with cheating in mind, or that the cheats concern things that the server can't control, like client decisions (e.g. aimbot) or client presentation (e.g. wallhack).
has been an absolute dream to develop for a 2 person team.
One of the benefits we've found that rarely gets mentioned is that there are minimal fees. Our only outgoings are server costs and Stripe fees: no payments for Unity/Unreal, no App/Play store cuts.
Another is that depending on your game mechanics lots of existing technologies solve problems that big game engines often handle for you. Thanks to Postgres transactions we have never spent a second thinking about client/server synchronisation.
For those who saw the game on HN a few weeks back, we have turbocharged our tutorial and game information and the player base is growing. Jump on and play a round!
If only JS had better multithreading shared memory capabilities it would be perfect for me. But just with fixed length array buffers limited to numbers I can't do much. I tried regular IPC instead but there's too much latency. It is a huge shame.
Funny thing is, it is not supported on purpose. Most browser had support for SharedArrayBuffer but it got disabled when Meltdown/Spectre came to light (as well as high precision timers in the browser) [0].
And as I said, SharedArrayBuffer is a fixed length, number only array. While it may work well for some use cases, it really can't for many others. Or am I missing something?
By the way, browser compatibility is not a concern if you develop for Electron. Just target Chrome and you're done.
Although it's number-only said numbers can be used to represent anything, really. If you can convert your data to number-friendly formats and back there's really no issue.
If you need strings you can use the native TextEncoder/TextDecoder and shuffle things around as UTF-8. If you need JSON-like objects you can look at encoding formats such as Protocol Buffers, Thrift, and the like. This introduces non-zero latency shuffling data between formats but that's largely what normally occurs over IO boundaries anyways.
Although saying that memory in lower level languages is basically treated as an array of numbers and you can treat the array buffers similarly. It’s also how Wasm memory is exposed. So you can serialize JS and other data in and out of them.
I need to check that out! I've been watching WebRTC since 2011, excited to have some equivalent of a TCP socket. It took them SOOOOOOO long to add data channels.
Are you using it for P2P, or making the 'peer' be a central server?
I did not make the game you are asking about, but WebRTC has an even better feature than TCP, which is unreliable datagrams (essentially UDP). Very few people have done anything with it, since server support for WebRTC data channels is very limited. Still, you can use dirty hacks such as leveraging Puppeteer as a WebRTC endpoint and make true lag-free experiences for the web.
Last I checked a few months ago this library was working for WebRTC data channels on node.js. Check it out, but it might not work properly:
What I'm curious about, as somebody who's writing their own game right now which targets HTML5 (among other things), is how you were able to achieve such great performance. I've given your game demo a quick look and it plays incredibly smoothly, do you have any tips on what to avoid for best rendering performance?
- Use `requestAnimationFrame`, don't use timers. JS timers are really bad, and they won't sync with monitor refresh rates.
- If possible, avoid lots of canvas calls. For example, if you want to draw something simple like a bunch of boxes on the screen, grab the pixel array from the canvas and manipulate it directly, don't call `ctx.rect` in a for loop.
I once stuck in a quick dozen-line block of code before a demo that just drew a couple hundred tiny pixel stars in the background and occasionally randomized their position. Went back and profiled later and found out it was taking something like 30% of my render time each frame, and refactoring just that one block of code got rid of a bit of stuttering on old hardware.
- On that note, cache stuff in memory. My game is tile-based. At the start of a level, I iterate over the tiles on an offscreen canvas and generate a single, giant image for the entire map. Then for subsequent frames I can render that with a single sprite call, rather than by iterating over every tile.
Caching visual effects is huge. In general, don't be afraid to stick generated effects in RAM, because every call you make to Canvas has an overhead.
- Also on that note, don't be afraid to use multiple canvases. If you have an overlay or a visual effect on top of your main game, and you can just update that without needing to redraw all of your sprites/tiles, that can sometimes be a big performance benefit.
> If possible, avoid lots of canvas calls. For example, if you want to draw something simple like a bunch of boxes on the screen, grab the pixel array from the canvas and manipulate it directly, don't call `ctx.rect` in a for loop.
I think this is likely what's causing me the most trouble. The problem is that my game needs to draw many hundreds of circles, each of different colors/sizes. Perhaps I need to pre-render these to an off-screen canvas and then do some blitting.
I'm also tempted now to try what someone else suggested and target WebGL instead (likely via Pixi.js).
No, for a project I am working on using three.js with requestAnimationFrame, it is capped at the refresh rate the monitor is running on.
So my gaming monitor running 144hz at 1080p runs the application at 144 FPS according to my FPS counter from stats.js[0]
On my laptop running at 60hz it's capped at 60 FPS.
There is a huge difference in the "smooth-ness" as well as reduced input lag on the 144hz vs 60hz monitors. So much that I currently dislike working on the app on <100hz monitors.
I don't know the answer to that. I imagine different browsers/OSes will have different caps.
However, assuming the cap is an issue, I still strongly doubt that with `setInterval` you'll be able to get the precision you need to target specific monitor refresh rates, even if you can figure out a way to detect what the refresh rate is. Maybe if you're targeting Electron, but even there I kind of doubt it. Even with frame caps, `requestAnimationFrame` is still likely the best bet (opinion me).
The reality of games on the web is that timing in general, whether it be for update logic, rendering, or audio is kind of a massive pain, and you'll always be accepting some compromises. To me, those compromises aren't big enough to outweigh some of the other substantial benefits, but I don't want to pretend those compromises don't exist.
Are you on Linux with an Nvidia GPU? I fixed that bug recently. https://crbug.com/535392 On other platforms requestAnimationFrame has been synced to the monitor for a long time, in Chrome at least.
I don't have any articles specifically about canvas performance, but I'm pretty open about development so I probably will at some point in the future. If I do they'll be posted at https://loop-thesis.com/blog/ (https://loop-thesis.com/rss.xml)
Cool, thanks for your response. Checked out your "reset hard" prototype demo; it looks great! Reminds me a bit of Bret Victor's talk on inventing from first principles, and a game called "Braid" that involves actively playing with time as a 1st-class property of gameplay. You should post a "show hn" on it! :)
Whenever I try to use Canvas caching I run into an issue I don't yet fully understand that causes my images to come out of cache blocky and terrible looking. Something about a max canvas size? I don't quite get it. Happens whenever I use fabric.js caching.
I'm guessing that means you rolled your own canvas API code, rather than using a library like PixiJS. Is that something you'd consider open-sourcing, or is it so tightly integrated with game-specific logic that it wouldn't make sense?
Yes, no helper libraries and I coded quite close to the metal.It's probably even a stretch to call it an engine. It's just built around the specific game mechanics. It wouldn't make sense to open source that part unfortunately.
I don’t know how this wasn’t mentioned yet but 100% use a Webgl framework, even for 2D games. Three.js is my personal favorite. Nowadays most all browsers and devices support it and I’m sure I don’t have to touch on the magnitudes of difference in speed for rendering anything on the GPU vs the CPU?
If you plan on having any amount of medium to large numbers of things (heck I’d say any amount) you’d be doing it wrong to be using the 2D canvas API.
You can use pixi.js for rendering. For example my game https://bitplanets.com can run at 100fps on a mobile device (on phones that support that refresh rate, like one plus 7t)
I got into gamedev and discovered really good .io games only recently, and now I really want to try to make something like that myself.
I was very surprised to learn what's possible with html5 games now, a few days ago I've learned about https://krunker.io/ - absolutely incredible that it's possible to create something like this, especially for a solo developer.
----
What I'm really curious about is the stack that would be optimal for such games. Here's what I learned so far:
- For 2D people seem to use pixi.js(very fast webgl rendering framework), or phaser(2D game framework).
- For 3D the leading frameworks are three.js(some say it's more focused on creating pretty demos, and is suboptimal for games), babylon.js(html5 3D game engine from microsoft), playcanvas(proprietary web-first game engine). Krunker was made in three.js.
- For networking people seem to use socket.io, I'm not sure what else.
- Engines like Godot and Unity can build games for bowser. People call Unity builds "bloated" and keep mentioning something called TinyUnity as a solution to this. Godot is supposed to implement WebRTC soon, which apparently should be great for multiplayer (https://godotengine.org/article/godot-webrtc-report3).
Can anybody add something to this? I'm just starting to figure things out, and any tips/advice on picking the optimal stack, or links to good learning resources would be very useful!
The payment process for our own user authentication system was handled by a simple HumbleStore widget. They support various payment providers and only charge 5% of the revenue.
Five percent seems like quite a lot, given that most payment processors charge less than three percent. What sort of value do they add outside of payment processing?
Digital Content Fulfillment is an underrated feature that ties directly to platform loyalty. Assuming this means the title is added to the Games Library list on humblebundle.com, customers love watching their collection grow and are more inclined to buy something if it will show on their preferred site (whether that's Steam, GOG, Humble, Epic Games, etc.).
Even scrolling through my GOG collection of games I'm somehow too lazy to play instills in me a sense of pride that at least they weren't purchased on Steam.
Though there are also major practical advantages of purchasing things within stores like GOG and Steam instead of a bunch of disparate websites: when you move to a new computer, you don't have to chase down a bunch of websites and license keys and emails to reinstall all of your software. Which is something I hate so much I only got outside of platform shops as a last resort.
Factorio devs mentioned they do a lot on anti fraud (something with charge backs from stolen credit cards iirc). I don't remember the details but they used humblebundle's payment system because of that feature.
Interesting that CoffeeScript was used. I’m not a front end developer, but I’ve always liked its syntax. JavaScript has picked up many (if not more) features of it as of today, but I still find CoffeeScript code more readable.
From somebody who used CoffeeScript extensively: I don't think it's a great choice for bigger production projects. The less "noisy" syntax has some very unfortunate consequences. For one, it has zero error correction. Almost any random sequence of characters is a valid program so any minor mistake looks at first like it's working and may even pass some tests but looking at the compiled code makes it suddenly obvious that the code is doing something utterly unexpected. Examples include:
* Minor spacing mistakes subtly moving code between blocks.
* A variable in a nested scope accidentally reusing a name from another scope and merging the variables.
* Implicit return generating huge collections that are never used because a function happened to end in a loop.
* Random breakages because the value of the last statement in a function sometimes affects the callee even though the author didn't mean to return a meaningful value.
* People not setting strict mode because "it's not needed with CoffeeScript" but then introduce bugs where they try to write to readonly properties which silently "succeeds" (does nothing) in sloppy mode.
CoffeeScript looks nice and readable but in practice it's almost impossible to decipher what the code actually does.
Most of these issues could be said about Python as well, but the environment that you describe is of a very poor code quality culture. This can happen in any language. I'm not saying we should use CoffeeScript in 2019, but that the criticisms seem vague.
I'd say that a lot of the same arguments are valid for Python or yaml. Why both of these are very widely used while coffeescript slowly died is beyond me. I, for one, really dislike any language that uses syntactic whitespaces.
The implicit collection problem can be prevented by making sure that you put explicit return statements at function ends. This goes contrary to the dense syntax argument but at least there is a workaround for performance critical code.
I still use CoffeeScript for every game I make [1]. I know it's very passée but every time I rewrite something from javascript it turns out to be much shorter and more readable. It's true that there is now many improvements available compared to ES5 times but for me CoffeeScript still has a lot to offer. I admit, it's mostly ergonomics, but the cost of compilation is so minuscule that I find it worthwhile.
The biggest problem with CoffeeScript for me is that it's very much not typo-safe. Most typos lead to syntactically correct programs that blow up in unrelated parts of code.
Yes, CoffeeScript was quite hot back then - no pun intended. Even though its not as used anymore I think it pushed the development of JS itself forward.
Curious Expedition is a fantastic Roguelike. I've been playing it forever. I'm not pleased that they are ditching the gorgeous pixel art for coreldraw-style clipart in the sequel.
Regarding their development stack... this game proves that your stack is absolutely inconsequential in determining if a game/app will be good or not. If the team executes well and the game is obviously not flawed, I could care less if the devs used something not considered "pro".
Thanks for the playing Curious Expedition! Sorry you're not feeling the new art style. It is based on Ligne Claire as popularized by Tintin. I hope once you see the whole game, we'll be able to win you over!
I LOVE the Curious Expedition, and my jaw dropped - literally - when I learned it was an HTML5 game.
From the perspective of someone who absolutely adores the mood and style and gameplay, I see the Ligne Claire work you're doing and it's absolutely beautiful. The art in CE2 is beautiful.
If I may offer an entitled little little nugget of feedback: As I experience it, the "breathing" style of animation feels a little jarring. Maybe when coupled with Ligne Claire especially. I'm referring to the "flexing" cutout animation (time-interpolated affine transformation / skeleton deformation of a set of shapes per entity). I'd like to request an in-game option to disable it :) Or actually, ideally to slow entity motion down to subliminal speed while maintaining motion speed of lights. Ligne Claire adventures are a big part of my nostalgia and my unconscious expectation would be of a more frozen, nostalgic, disconnected, dreamlike life on screen.
Mostly I feel shame to be saying this though and feel like there's no way to say this and also deliver the amazing amount of respect and love for your work.
Thanks so much! I appreciate it! The animation style that you suggest has come up in discussions before. We're still figuring out how to exactly deal with different scenarios where the diary text is much more detailed than what we can achieve in animation. That will be an interesting problem to tackle as we add more and more content to the game.
Thanks for the gracious and, well, amazing reply! I still feel somewhat horrible for making such an "instructive" comment and feel like I have crashed into a beautiful thing and put my ignorant and greasy little fingerprints where they have earned no right to be. But it's such an interesting subject :) I hope I have been able to express the deep respect I hold for what you're doing. — I'll certainly be watching and cheering on the game's development! And will be preordering immediately when that's possible.
My criticism is a testament to how good the pixel art is in CE1. My son and I love your game so I'll be buying the sequel, but I feel like you are going more towards the Renowned Explorers visuals which I felt was completely inferior to CE. That said, I looked at the new art and it is pretty awesome, I just have to get over it.
Thank you! We struggled a bit with coming up with a new interesting art style for CE2, but once we stumbled on art by Garen Ewing we knew we had something exciting for us.
Did you see our comparison with Renowned Explorers by the way? :)
Did you do anything around securing the code? I always worried that it would be fairly trivial to reverse engineer any game I tried to charge for and distribute via the web.
Photoshop is not the gold standard for pixel manipulation, but for general manipulation. Aseprite and Cosmigo's Promotion are much better for pushing pixels. I'd say Promotion is the gold standard.
It is meant to be a new version of Cordova, with support for Cordova plugins. At this time the general consensus is that Cordova is still generally the best, unless you specifically need functionality in Capacitor.
These days it's mostly still just "use Cordova/PhoneGap", yeah.
For Flappy Royale (http://flappyroyale.io, https://github.com/flappy-royale/flappy-royale) we built our own native web view wrappers for both iOS and Android, but that's mostly because we already had extensive native iOS/Android dev experience ourselves and wanted more control.
In my experience Cordova/PhoneGap come with a lot of cruft and bloat if all you care about is a canvas and a handful of other hyper-specific native API hooks. At least in the sense of engineering and tooling complexity; I can't speak to runtime performance considerations, except that it should be irrelevant on iOS since everything's using the same WKWebView under the hood.
> I was glad to get away from all the crazy IDE world that I had to deal with in my C++ AAA days and just working with a minimalistic but extremely fast and powerful text editor.
Makes me wonder what do they use for AAA games, could it be Visual Studio?
Yeah, AAA game development is 99% Visual Studio. Usually multiple versions of it depending on the platform. We just upgraded from 2015 to 2017 at our studio, which required a decently large refactor of some core utilities.
> Coming from the perspective of pretty much hating Visual Studio I was pretty sceptical about Visual Studio Code until I read that Erich Gamma was involved in it.
Thanks! I used https://buzz.jaysalvat.com/ and converted all our raw .wavs to mp3 and ogg with python using ffmpeg. I should probably add that the post as well.
My jaw dropped when I learned Curious Expedition was an HTML5 game. Amazing work.
Given that Curious Expedition is an amazing success and proof the power of HTML5, modern Web development toolchains, and modern browsers, I'm super curious if Codecks have a comparative opinion of Jetbrains' IntelliJ platform / Webstorm JS IDE versus VS Code.
I was actually confusing Maschinen-Mensch and Codecks and thought Codecks were the creators of Curious Expedition, but it would all be quite interesting!
Thanks! Daniel here, the developer of Codecks.
While the majority of our customers are game studios, there's no reason why it doesn't work for other teams.
As long as you and your team are happy with a more playful appearance for a project management tool, I'd suggest to give it try :)
Maybe something to add to the website or FAQ? I searched the page for a long time for anything that would indicate it was a general tool, and since I didn't find anything I assumed it had some game-specific features or wording in the product that would make it a bad fit for any other type of development.
About the only big thing I'd probably change would be YAML or TOML for the configurations over hjson.
Seems like some pragmatic tool selection... I am curious how their turn around time was compared to something like MonoGame, Unity or other rapid development options.
Overall, very cool to see this list and the openness.
I tried YAML for another game prototype in the meantime. I like it as well but I feel the whitespace syntax can be very error prone if not all your team members come from a technical background and know about whitespace settings in the editor.
I was deciding what engine to make a hobby game with last week and was looking at ThreeJS. I couldn’t find any projects with good higher end visuals that had acceptable performance however. I settled on Godot, but I’d love to be proven wrong about webGL
I’ve been using canvas and websockets to make Multislay. I’ve got lots of optimization to do, but it has been fun and going well: https://multislay.com/
> Once you start distributing your HTML5 game on PC distribution platforms like Steam or GOG, you need an actual executable that people can download to play the game offline as well.
Can someone elaborate on this? Why is this needed? Is it a market penetration decision? Does steam not allow HTML5 games?
Due to virus issues, etc, I would prefer playing an HTML5 game in the browser. I don't want to install something that could contain viruses or be a vector or increase my attack surface.
I'm missing something, but not sure what it is. I don't use Steam or install games on my computers, but I do play HTML5 games.
When customers of a PC distribution platform spend money on your game they want to be able to own it by downloading it and having it live on their computer and work offline as well. For this you need to deliver them something that is completely packaged and contains everything to run the game.. so even if that means basically shipping a full browser with your HTML5 game.
We also have a web version which can be played online via the regular browser.
Then you'll get a flood of support tickets from people whose default browser doesn't run the game quite right. People downloading a game on Steam couldn't care less if it weighs an extra 100MB because it includes a copy of Chromium.
Once you are charging money for the game on a distribution network, you probably aren't providing the full game on a standalone site anymore. Maybe you have a small demo.
That's already a possibility if you're using Steamworks (which most Steam games - or at least nearly all I've played - are). Granted, the breakages from a Steamworks-related update are likely far less critical (unless your game critically depends on achievements, cloud saves, instant screenshots, or the Steam Overlay, which would be weird), but it ain't like this would be entirely unprecedented.
Breakage is also already a possibility for games with Linux ports that rely on the Steam-provided runtime environment (I don't know if this applies to Windows or macOS, since I haven't used the former with Steam in years, and haven't used the latter with Steam ever).
I feel this. The documentation for Sublime seems to be in a permanent state of chaos. Most of the details of how to write plugins were never documented in the first place, and for what you can find you will never be quite sure if it applies to ST2 or ST3. Even the official website has a bunch of outdated documentation for version 2 that still isn’t labeled with version number. I imagine this will only get more confusing with the upcoming version 4.