EPTThe Big Programming Thread - Page 122
| Forum Index > General Forum |
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. | ||
tofucake
Hyrule19269 Posts
| ||
|
Fryght
Netherlands254 Posts
Due to the fact that the threshold for Flash is very low, there are a lot of noobs, trying to get Flash to do what they want, so it's easy to look up a lot of info, instead of having to dig through documentation for hours on end. Also, in the end, when I want to do some game development by myself or with a really small team, I tend to look more at the practical side of things. That also includes getting content (such as graphics/sounds/etc) into the game and how much time I need to spend on 're-inventing the wheel'. Unity3D already makes it so that all my GameObjects have an Update function that is automatically called. If I really want, I can even get my hands dirty and muck about with the drawcalls and whatnot. Getting content into the game is a breeze. The IDE is your manager program, which also serves as a level editor. All of the programming is most easily taken care of in Visual Studio (which now also offers a free version). Unity3D also offers organization in 'scenes', which greatly facilitates state/level management. The IDE allows you to mess about with a lot of the content during run-time. Those are a lot of handy practical features, imo. I am also very skeptical towards Unity3D, as their documentation/tutorials in regards to C# is pretty meager. I guess they kind of assume that anyone that knows C# should not require too much instruction any more. Luckily, there is a very active community. Open source development can also be pretty volatile. If they decide to experiment or change the implementation of certain features, there is no-one that they owe an explanation. If a proprietary toolchain tries to pull that kind of jazz, they'll get a lot of shit for it. Once people pay for something, they expect a certain quality from the product and they WILL hold the company making the product responsible if it does not meet their expectations. Several good examples of proprietary vs open source: - Apple (app store is controlled, derp friendly devices) vs Android (open market, loads of low quality stuff polluting the market, requires some tech affinity) - Windows (still the most used OS, most support from games/drivers etc) vs Linux (a lot of builds to choose from, requires tech affinity (console/shell), highly customizable IF you know what you're doing) - Flash (one company decides standard) vs HTML5 (will take a long time to reach full implementation in browsers/standard, just look at CSS2/CSS3 ._. ) I did start looking into HTML5 (which is why I mentioned Construct 2 - which, by the way, does suffer from your mentioned restrictions and the need to hack in my own stuff), but when I looked at some available game dev frameworks, they were very meager and not particularly well structured. What's out there so far pales in comparison to the framework that Flash offers, imo. Not to mention that all browsers like to implement (or NOT implement) the HTML5 guidelines in their own way. Furthermore, compared to Flash, it's a hell of a lot easier to steal HTML5/JS games and their content. I don't really feel like sticking a lot of hard work into a game, just to have it show up on some random other site, with ads slapped all over it. Other than that, I wouldn't mind switching from Flash to HTML5, as I work as a web developer, so I'm already quite familiar with JS (and jQuery). As I see it, HTML5 will be really nice for delivering media through the browser, but I don't really see it as an established platform for games yet, other than WebGL, perhaps. But then again, if I look at stuff like Quake Live vs Google's Quake WebGL Quake port, I find plug-in stuff such as Quake Live the more impressive of the two. Principles and code standards are nice, but I don't think anyone writes flawless code and you'll improve plenty as you clock in more time. To strive for perfection right off the bat is very noble, but can also cost you a lot of time. If you don't have a deadline ticking away at you, by all means, go ahead. Not everyone is as fortunate, however :p tl;dr/Back on topic - My question: Any way of properly protecting an HTML5 game from being jacked? Code obfuscation is a possibility, as is minimizing, but that still doesn't do much to actually make code unavailable to the user. Any way to protect it decently enough so that it's not worthwhile to try and steal it? | ||
|
Zinroc
Canada73 Posts
| ||
|
Fryght
Netherlands254 Posts
One way would be through a cron job. Windows guide here You can also tie the .php extension to PHP's command-line interface, which can then be set as a scheduled task (guide). | ||
|
tofucake
Hyrule19269 Posts
| ||
|
bc4m
United States17 Posts
On March 06 2012 10:59 Fryght wrote: tl;dr/Back on topic - My question: Any way of properly protecting an HTML5 game from being jacked? Code obfuscation is a possibility, as is minimizing, but that still doesn't do much to actually make code unavailable to the user. Any way to protect it decently enough so that it's not worthwhile to try and steal it? Besides obfuscation there's nothing you can do. You could do something crazy like transferring everything encrypted and decrypting it on the client-side but in the end the browser needs code to interpret. If the browser can get it, anyone can. If you need to protect your code open platforms like HTML5/Javascript are not for you.  | ||
|
supereddie
Netherlands151 Posts
On March 06 2012 10:59 Fryght wrote: My question: Any way of properly protecting an HTML5 game from being jacked? Code obfuscation is a possibility, as is minimizing, but that still doesn't do much to actually make code unavailable to the user. Any way to protect it decently enough so that it's not worthwhile to try and steal it? The only way to do this is have all the game logic server side and use html for display/interaction only (=no logic in html/javascript) | ||
|
Fryght
Netherlands254 Posts
| ||
|
supereddie
Netherlands151 Posts
| ||
|
Fryght
Netherlands254 Posts
Of course it is possible to have the server handle all game logic, but then you have to deal with networking and stuff won't be as snappy as it is running locally. Not to mention that this tech is not really built for real time client/server communication. Having a game rely on AJAX/long polling is not really an option for stuff like platformers etc. It is fine for MMORPG-ish stuff, I guess. Basically, I feel that HTML5 won't replace Flash any time soon in the game portal sites. It will replace most (static) video and mp3 flash players. As for streams, does anyone know if HTML5 has anything for that? | ||
|
supereddie
Netherlands151 Posts
I think streaming is possible, as long a you have a suitable protocol (like rtp, rtsp, mms) and the browser supports the codec. | ||
|
freelander
Hungary4707 Posts
| ||
|
kingcoyote
United States546 Posts
On March 06 2012 22:56 Fryght wrote: Yeah, so then my assumptions that HTML5 is not really viable for publishing games you want to monetize seems confirmed. It's a shame, really, as it seemed to have good potential to replace Flash for publishing browser games. Seems like HTML5 will only 'liberate' media delivery then. I think you can monetize an HTML game fairly easily. It won't be through the traditional "buy us for access" model, but that is not the only business model available these days. I'm actually working on an HTML game right now that I hope to monetize once it gets a little bit more complete, and my partner on the project and I are working out our plan for what sources of revenue are possible. | ||
|
tec27
United States3727 Posts
On March 07 2012 01:13 supereddie wrote: I never said anything about AJAX (or polling) - using this with a game is not a good idea. server-sent events however, are viable in my opinion (and part of the html5 'standard'). I think streaming is possible, as long a you have a suitable protocol (like rtp, rtsp, mms) and the browser supports the codec. WebSockets tend to be better for games, since it allows for bi-directional communicatiton, although its less well supported and a tad harder to set up on certain platforms. Still, http://socket.io/ is a really nice library that makes utilizing WebSockets pretty painless (and has server components for a bunch of languages). | ||
|
pphp
Brazil24 Posts
| ||
|
Fryght
Netherlands254 Posts
On March 07 2012 10:38 tec27 wrote: WebSockets tend to be better for games, since it allows for bi-directional communicatiton, although its less well supported and a tad harder to set up on certain platforms. Still, http://socket.io/ is a really nice library that makes utilizing WebSockets pretty painless (and has server components for a bunch of languages). Yeah, I've looked into WebSockets, but a while back there was little to no support across the browser boards. Really hope they would get everyone in line. But CSS3 makes very skeptical. I mean, CSS3 is not exactly rocket science and has been around quite long already, yet there is no standard still and we have browser specific implementations *shudder* | ||
|
bc4m
United States17 Posts
On March 07 2012 20:17 Fryght wrote: Yeah, I've looked into WebSockets, but a while back there was little to no support across the browser boards. Really hope they would get everyone in line. But CSS3 makes very skeptical. I mean, CSS3 is not exactly rocket science and has been around quite long already, yet there is no standard still and we have browser specific implementations *shudder* Web development will always be like this, unfortunately it's par for the course. I feel like native games are the way to go but then again I have hardly any game-dev experience. | ||
|
billy5000
United States865 Posts
can anybody explain to me the differences (pros and cons) of these two in laymen's terms? maybe an example too | ||
|
MisterD
Germany1338 Posts
There are of course also static methods that are just "hey i don't know what i'm doing so i just make a static method that doesn't even really have anything to do with what's in this class". Those cases are either badly design or should be kept to "work in progress" until you properly understood what fits where and can then move or integrate it somewhere it fits. and well, instance methods are just that. Methods that can only be used when you have an instance of a class and inside the methods, all the classes instance members can be accessed. Also, instance methods are required for making use of polymorphism. You can't make interfaces for static methods. And instance methods save you passing the "target" object as an additional parameter every time. Imagine, you'd have to always call LinkedList.add(list, item) or ArrayList.add(list, item) instead of just list.add(item) regardless of the kind of list you have. That'd be rather ugly and painful.additionally. That's why you should generally prefer to put stuff into instance methods behind a proper interface, because then you can exchange the implementation without having to change any code that uses the interface. That just doesn't work with statics. A general good guideline: Small, closed off pieces of code (helper methods, pure functions, singleton accessors etc): make them static. Anything else, make instance methods, and if it's used by other code and there might be different implementations in the future, additionally put it behind proper interfaces. In several cases, it might be an option, to actually use both: An instance method that doesn't really do anything but invoke a static helper. For instance, if you were to write your own List interface, for example if you need a "list" that only offers get(int) and sort(), and not add(item), then you could have one implementation that does funny things like return the n-th line from a file and when you call sort(), it sorts the lines in the file on the disc, and you could have another implementation that internally uses an ArrayList, and if you call sort() on that it just forwards the call to the static helper Collections.sort(this.arrayList). This way you have both easily reusable sort-code, AND made that code exchangable through an interface. | ||
|
Sandrosuperstar
Sweden525 Posts
| ||
| ||
