permith

Members
  • Content Count

    49
  • Joined

  • Last visited

About permith

  • Rank
    Advanced Member

Recent Profile Visitors

1081 profile views
  1. this comes up pretty often http://www.html5gamedevs.com/search/?q= GameDistribution
  2. Heavily modified ImpactJS. To allow them to have multiple levels being the biggest feature, and probably some things for their AI. They have a few blog articles that talk about their tech.
  3. There's a point of investment for an HTML5 game where you say screw it and just go to a market front like Steam. For instance https://store.steampowered.com/app/368340/CrossCode/ Has reached Steam's monthly top sellers a couple of times. And there are quite a few other games on Steam that are actually HTML5 but don't bother to tell anyone. ____________ Which kind of leaves web portals with games that have much lower investment levels, attempts at gimicks, and similar. Basically it's hard to stay relevant, when it's hard to get games that are competitive/relevant. Also have you tried to use a portal recently, they're well terrible, slow, ad filled, full of distractions, clogged with login flyovers, and an all around nightmare to use.
  4. So many red "blippy" things, and "roll over" things.
  5. CrossCode has a demo out that's web based. Curious expedition as well.
  6. Cross Code hit Steam's top sellers page briefly a few times. You can track this down by their kickstarter campaign, when Steam Spy worked, and the boxleiter method. Other games like Titan Souls on have started as an HTML5 game in a "One Shot" game jam. Not sure if still HTML5. Going smaller there's The Next Penelope, isotrode, and The Curious Expetition. There's also a nice mix mash of games that I've heard are HTML5 on steam. Though I'm not going to rip them apart to verify and/or haven't heard their devs say anything in developer circles. Outside of steam the developers of Slither.IO are on the record in a Washington Post interview of exceeding $100,000USD a day. Though I can't search that site well anymore, and don't want to fight the pay wall. ______________________________ Personally from my own experience, you can develop projects really fast in JavaScript. Even in my two unfinished projects (a 2D platformer, and playing with the math of orbital dynamics), it's nice how much you can have to show after 40 hours compared to other platforms. _______________________________ LINKS: https://store.steampowered.com/app/368340/CrossCode/ https://store.steampowered.com/app/297130/Titan_Souls/ https://store.steampowered.com/app/332250/The_Next_Penelope/ https://store.steampowered.com/app/449140/Istrolid/ https://store.steampowered.com/app/358130/The_Curious_Expedition/
  7. While it satisfies your OP, but these do less for your "Looking for people to license from". Though the developers here will probably love seeing these. https://www.radicalfishgames.com/ (Their game cross code has hit the Steam top sellers list, and They're over a few hundred thousand in unit sales) http://maschinen-mensch.com/
  8. @mattstyles I think my original intention would have been better stated like this: In any programming paradigm that you follow, as long as you follow it well you'll be able to get work done easily. But you'll have to break out of your paradigm at some point to eventually interact with other software and that is where it will get messy and frustrating. (Annoyingly enough my original post did need some bashing though, though I hope my post didn't praise OOP though). The game I showed also did a good job of all the bad that will happen when you badly try to mix different programming paradigms, even if you will get a nice advantage out of it here and there (I imagine badly since it does get pretty close to just being entity component pattern) .
  9. There is no such thing as truly functional programming that actually does something. At some point you're going to need to take in some form of a messy state, then at another point you're going to need output some form of a messy state. Whether it's in and out from a database, in from the previous step and out to the next step, or similar. Even taking input from the keyboard is a very stateful action in the sense that over many many cycles of whatever type of process/threading/event manager where you're remember the state and where previous state affects the current state. That isn't to say functional is pointless, it's actually really nice to do things that you can truly pin down to an in and out problem. _____________________________ Though the platformer I'm currently working on does mess with functional and entity based programming a bit, though with the dumber JS objects (Though I've given few cares about purity, one person touches that code). Basically each entity has an X, Y, a communication queue, preprocessing queue, and a processing queue. first the objects preprocessing queue runs, followed by the processing queue. To actually get stuff done the preprocessing and processing queue can access the communication queue and change X, Y location. For instance if my player touches something it sends something to that objects communication queue (which gives it a chance to send a kill message back, or a forced movement request back). Player physics are ran every tick in it's processing queue with some state stored in that semi-functional function. If an object wants to be drawn it communicates to itself, then the part of the game loop that draws everything can see that communication. There are some things that I like. Each object is the same object just with different processing orders shoved inside them (If I cared a bit more at keeping at my style it would be pretty easy to allow the player control process to jump between entities and make stuff just work, and even in it's current state I could see myself making the game multi player without an insane amount of work). Likewise I have never found it so easy to write unit tests for a game, especially for the core entity protocol (even the messy stateful physics wouldn't be too bad). Lastly all the actual gameplay logic, and core logic are pretty separate (I've only needed to change the core logic that I made before I started on the actual game with only a small handful of lines of code). I'm not particularly happy with some of the end results since I can get some pretty deep stack traces for even simple logic, you can also see a lot of areas where I'm struggling with not knowing JavaScript very well, and I'm generating way too much garbage at the moment. though these issues haven't been such a bad effort that I'm keeping them till my next game. You can see my earliest showable build http://lostlocus.com/ (arrows/WASD, Spacebar, F/J) Though be warned there are plenty of dragons in there(old code). Though everything is still separated out into different files for easier readability, all the ugliness of being an early build is still there, and the parts that actually make it more than a tech demo just aren't there (actual map loading, real assets, AD hooks, and similar). Which is also why I'm not too concerned about it walking off (that and there are some polish issues that would embarrass even a thief like the GC stutter that that version has). Though considering that it's only about 1000 useful lines of code for a usable start to a platformer I'm still happy with it. EDIT: If your intention is to make a game, I don't think you're being pragmatic enough. Though you're making great strides to teach yourself it seems.
  10. There are some companies that won't want to talk to you, There are others that will use it as an advantage for themselves(lower pay, or legal leverage), and there are quite a few that just don't care. The companies you're dealing with aren't in the business of dealing with businesses, they're in the business of selling games at the lowest margin possible.
  11. You contact them. Normal business rules apply for writing letters and sales pitches. If you have no idea at all, or want some reviews of a good amount of companies True Valhalla's book works. After a certain number of posts(unclear supposedly 10 posts, but I got access sooner), a Sponsors and Portals forum opens up. A few larger portals have ways to automatically add your games for a percentage of ad revenue, though this will almost always end up in underselling yourself by a long shot.
  12. Start here: https://developer.mozilla.org/en-US/docs/Games/Tutorials/2D_Breakout_game_pure_JavaScript and https://www.youtube.com/watch?v=XgK4YaMqQFg and here https://www.google.com/ This is also a horrible way to go about asking that question. It's like asking an artist "How do I art?". The answer for such a question is going to be draw lines on a piece of paper.
  13. The above is very apt. I've seen some of my old code where I had horrible math skills, compared to some of my new code there is a world of difference(where I'm still bad, but less horrible). The difference was measured in pages, 20-30 pages compared to 12 for a missile command game(both were in Java and the 12 page one had a few more features like a menu screen. They were coded about a decade apart just as an FYI). Math will open some nice doors to short cuts/efficiency/sanity but it won't necessarily keep you from getting the job done.
  14. http://venturebeat.com/2015/04/30/it-costs-more-than-3-to-acquire-a-mobile-user-now-fiksu-finds/ http://www.mobyaffiliates.com/blog/average-cost-per-install-apps/ If you're looking to get on a portal/have a sponsor, you don't need to care about the most expensive part of a game(marketing to users). You just need to focus on making a good game, that looks good in your elevator pitch to a sponser. You'll get paid by focusing on a few dozen points of contact, rather than the scary world of marketing to random people who are trying to ignore you. Users almost never pay anyways, and the web is far better at passive income generation(with ads and data tracking) than what you can normally put on an APP anyways.
  15. I'll deal with opinion here. But to me it seems like you're more likely to make some amount of money off your game with HTML5/Flash distribution than you are with native/phone. For steam the typical barrier of entry seems to be years of man hours invested into your game before people will look at it, on App stores user acquisition can reach up to $3.90 per user for some of the major games. In HTML 5/Flash you have a good number of publishers that are competing enough to keep cash/man hour requirements for a game actually reasonable(App/Phone has essentially 2 App stores that everything is funnelled through, PC has Steam mostly), Likewise when you do find a publisher the developer can get some amount of risk off loaded since they typically pay some up front before it ends up on their site, If you're self publishing you're on the web usually which means you have access to normal advertising which the web has become good at. That being said with it being easier to come ahead, most people don't seem to win as big as they're able to on App stores/steam when they do win. But you won't see angry grumbling about making a good game and getting nothing for your efforts like you do on other Dev sites.