• Advertisement

Richard Cesar

  • Content count

  • Joined

  • Last visited

Community Reputation

167 Neutral

About Richard Cesar

  • Rank
  1. I don't see many people pitching this idea, so I figured I will chime in. The problem with DRM is obviously, as everyone pointed out, it fails to stop the hackers in the long run, and inconvinances your paying customers. This, obviously, in and of itself is not a good thing. But that does not mean do not protect against pirates. I'll admit to having pirated a few games in my life. I will also admit to shoveling out the $60 to purchase diablo 3 when it just came out. The reason for that was because of how difficult and degrading to the experience it would take to do other wise. Was it worth it, ABSOLUTELY NOT, but their anti-piracy measures worked for me. (However, I would contest most pirates are NEETs, and your never going to get a sale out of them anyways). But what if you looked at this from another angle, using what we know about the multi-player markets. Instead of requiring your players to go through intensive procedures to play the game, offer your paying many small (perhaps weekly) updates. New level, new dungeon, bug fixes, new quests, etc. In many cases content that could (if the game was built in that direction) pushed out very quickly. But _NO_ DRM required to play. An account would be required to get the update, and have the updates specifically keyed to their computer. Now of course, the hackers will eventually patch the add-on content as well, but it would be behind that of your paying customers. These customers wont HAVE to get the update, but odds are if they have access to an internet connection they are going to want to. The pirates, though they will still pirate, will be behind in the updates. will have to constantly patch and repatch, and eventually the convinance of your distribution method may even convince those pirates that CAN afford your game, to do so, in order to stay up with the free content.
  2. Java or C# career and future of programming

    If you intend to study the best bang-for-your-buck language, that would be JAVASCRIPT (or more specifically , ECMA-Script). At this point in time, it is the one language that is truely cross-platform viable and runs across a variety top-tier technologies. Its an asset in about every playing field. Core reasons: 1. Cross platform. It runs in every web browser, or web view when packaged into an application, and even as mobile applications. and you can build awesome and complex user interfaces easy, interacting with whatever your host container provides (and more). The ui can be defined in such a way that it looks the same, regardless of what system its on. Or, it can use model form elements to represent other things. 2. Even complex 3d games with hardware acceleration are possible in many browsers (and/or by packaging the browser as a view). WebGL and Canvas will take you far on this route. 3. Its derivative languages include the primary language for AS3 (flash), and one of the primarly languges used by Unity3d (which is pretty much the shit) 4. It is a powerful and flexible web server with native websocket support (see nodeJS) 5. Native json (obviously) support means that it readily communicates with most key/object stores used for big things such as MMO's (read: mongo, couch) And as a more obvious note a strong JS background will make you indespensible to the web and marketing sides of the company. EDIT: In short, its a language thats mandatory in almost every programming team. And thus, in my mind, gives you the highest probability of employment should you be really good in it. However, its one of those languages that everyone knows, but few know well, so there is a HUGE disparity in industry pay, but lots of demand.
  3. Hello Wizuriel: There are quite a few ways you could approch this problem, and HTML5 is unnecessary (and unless your planning on going the canvas route, irrelevent). so the direction you choose to take this in is really a matter of preference and target audience (browser support). I am going to make the assumption you are using jquery here, although any method of dom manipulation should port fine. In the ancient days, ala the pyrimids, babalyon, the invention of the pythagoran theorem, and using tables to describe the layout of a page, the W3C oracles gifted us a tag for what they called the "image maps" (http://www.w3schools.com/tags/tag_map.asp). This is what all those "find-em" games were written in back in the 90's and early 2000's. This is probably going to yield the best browser support due to how long support for this has been around, but is riddled with its own pesks, and there are simply better ways to approch the problem provided you are not interested in support for browsers over 10 years old. In more modern days, the approch you suggested is a little more valid, though not nearly as limited to an "image" (in fact, thats hardly your best solution). Using javascript, you can easily bind yourself to the click event of ANY element. The 1st argument to the click event contains a browser-dependent location (I believe pageX/pageY, but this is one of those things that is generally normalized by api's like jquery,mootools,or prototype which you should certainly use). You connect to this event, You can have a div with a background-image representing your star-map, or an img with a src pointing to one, or a blank div with stars as individual html sprites (positioned div's with a transparent background image that looks like a star), etc. If you have the stars as indiviual elements placed on the page, you can simply bind to THEIR click events, and you will instantly know what star they click, changing the src or background-image of the star as needed. If you are using a background image with no individual elements for stars, then you will want to take the mouseX/Y location, offset it by the parent element (the starmap)'s position, in order to get a normalized starmapX/starmapY value. You then can have a bucket with all of your stars x y and radius. Then simply calculate a hit test to see if your normalized vector would be within the circles. Regardless of which the directions you take here, you should now have the "star" that was clicked (or lack thereof). When it comes to visually showing your selection, canvas not-withstanding, one solution would be to CREATE the stars THAT WERE SELECTED by simply adding an absolutely positioned div or image on valid click (just make sure the starmap itself is positioned, hence why using the PAGE may be a bad idea). This could be a background-transparent image that goes ON TOP of the star to show its selected, or any number of tags. Furthermore, bind to the created tags click events (on create) so that you can toggle on and off stars which were selected, which removes the element. You may want to consider using delegated events here, to cut the number of event handles down. Constallations can then be arrays of stars, probably indexed multiple times with an index for each star it spans (allowing you to quickly derive which constallations are currently being clicked). You should also store your selected stars, along with a reference to whatever represents it, to aid in finding/clearing/deleting it later.
  • Advertisement