I've posted this on another forum already, but I'd like to get some opinions from you guys here as well
Just like I believe many indies with a game at a relatively early stage of development, I'm experiencing all the pleasures and ordeals of trying to get as much exposure as possible. Being present at events, social media (best traction thus far!), forums, indiedbs, reddits - you name it. As I'm working towards a first polished demo - press releases and contacting twitchers, youtubers, bloggers, websites and press crop up on the horizon. And let's not forget trying some IGF, Indiecade and the likes. There's loads of info and advice of various kind about all mentioned above all over the Internet.
There's one thing I'm quite curious about though, and I'd love to hear from more experienced colleagues here who got their games published on Steam / GOG. That is, did you use any paid advertising to boost sales of your game? Did it work and where did you advertise? Adwords / Bing Ads? Reddit ads? BuyAds? Other?
Also, any success stories with some experimental / guerilla marketing? Anyone ran through city centre naked shouting his / her game's title to increase sales?
Positive Bells - well, as the name suggests, a cheerful, soft instrumental (kids puzzle game anyone?) Epic Story - one of my personal favourites, this tune is full of emotions (even goes up a tone at the end for a more dramatic effect;)
Looking forward to your opinions, also if you like some of my stuff please click the green 'thumbs up'. Thanks
If you haven't done so already, try validating your markup - always start with creating the best markup you possibly can, for example you may have an unclosed div which would screw up the rendering of a page. In most cases IE would be the misbehaving one (if you follow standards and good practice rather than building it for IE)
Chrome tools and Firebug are already mentioned, for "easy CSS" you may try the likes of Stylizer - you can download the trial and see if it's good for you. ***[[[And basically, educate yourself for a start - you'll then notice that markup is more than 'copy'n'pasta of some template' - each element has it's purpose, you'll learn about doctypes, microdata, semantics, why it's good for you to have an alt tag even if you're not bothered about accessibility (or why by creating an all-flash website you're hurting yourself). You'd eventually get to know CSS better, the browsers and what to expect out of them, etc etc. Google around, you can check those 2 for some reading: htmldog , A list apart . If you get to streamlining your work have a look at 960gs and HTML5 boilerplate. Avoid w3schools and THIS is why;)]]]
*** - 99.99999% not relevant as you seem to just want to 'get your site sorted quickly & easily' rather than becoming a top-notch frontend dev.
When I read '7-Day-Roguelike' I was expecting some ASCII-style, not quite big but 'yet to be awesome' thing but this is excellent. Tried the web player version - no problems.
I like the graphics style & the way it reveals new locations -> instantly reminded me of some long forgotten, ancient (Amiga?) tomb-exploring game. I laughed while during a rather lenghty fight my character became 'a bit hungry'
Work on some animations, polish the gameplay and you'll have a chance to make one of those 'repetitive, but so damn addictive' games. Just don't make it any more statsy, focus on the action, exploration, etc.
Well, I hope that's the right forum for my little announcement.
You know what they say - everybody needs a hobby. And I've got one - music that is;). Whenever I have time (not much of this thing), I like to play the guitar, record, compose, mix, tweak synth knobs and get involved with the whole production process.
Please have a look at some of my work and tell me what you think:
Dark Fire - for the fans of devilish, haunted guitars & eternal darkness (NOT death metal, etc.) Acid Journey - a bit of a psychodelic, trancey-guitary mixture Cold Fusion - energetic, punchy, fresh & with some nice riffs / melodies Mass Bass - well, the title says a lot here
And there's more, slowly, but surely coming in. Now, back to code!
Yep, there was a bit of a discussion going on here;) Cygnus_X, me and jolid made some valid points which should hopefully be useful to other people.
Flash is a bit of a game changer I suppose (not as risky as js in terms of moving some 'heavier lifting' to ther frontend?). Unity or similar may possibly be a good idea (since you've decided to require a plugin anyways), it's not something everyone will have installed cause it's needed for YT, but if the game justifies the requirement with it's looks, etc. (accelerated graphics) you should be fine - haven't used it, but it's said to be really easy to use.
Just an idea which came to my mind - back to js - it may be worth to have a look at some web based, ajax chat clients (gmail messenger, meebo and stuff), the way they operate - they do not require you to download anything, yet they provide a neat real-time chat facility.
I bet you're right with what's popular, the viability of 'real-time', etc., but: Virtually every page and refresh in this scenario would require a call to your update function.
The above statement is false.
You have to be careful & clever there. Done wrong, this could be a potential bad practice / security threat - allowing me to easily skip the timer and call the update() when I please ('Why would I wait 20 mins to have it built / done if I can have it now')
Let's start over. Some assumptions to make first: we have a browser based rts game - database driven, markup + js on the frontend of course. Let's assume 1000 players for the numbers sake. The game has the usual - displays money + some stats at the top, allows to purchase buildings, army, view & attack other players' kingdoms (takes time until your army reaches enemy). And we try to achieve the 'real-time' gameplay feel.
I'll try to reword the 'build a building' example:
Scenario 1 - The User buys a building: DB pseudo-structure 1) You have a 'buildings' table in your db 2) Let's not get into the details of what params (table columns) can the buildings have (also skip the obvious columns like ids, etc.). For this 'real-time' example all the columns we should care about are like: building_name, price, status, time_it_takes_to_build, created_at, updated_at The action 1) User clicks 'Buy Building Blah' 2) You create a new building for this user in the db; you take off the price from the amount of money the user has; you set the status to 'under_construction'; both created_at and updated_at you populate with current server time at this stage. Knowing current server time is a given, it's there for you all the time, no performance probs - it's also a big player in the further part of the story;) And voila! - you're done, it's pretty much the same thing you would do always - regardless of whether you use Cron or not, so no performance talks here.
Scenario 2 - the infamous page refresh (The User decides to have a look at his buildings, etc.) 1) 'Click' 2) You GET user's building from db - there's a good chance that's gonna be the only db hit (and no updating) 3.1) The building has status of 'under_construction'. Well, right there you already have when the buildings was purchased (created_at), how much time needs to pass for the construction to complete (time_it_takes_to_build) and something you always have, no matter what - current server time. Now it's easy;)
3.1.1) If enough time passed since the created_at till now, only then you update: status => 'complete'; updated_at => current server time. On a page the user sees 'This building was built format_time_nicely(updated_at)'.
3.1.2) If not enough time passed, you echo 'building will be ready in time_remaining' - on the user's machine (after page is loaded) you can grab the number easily and have a nice js countdown (no talking to server there)
3.2) The building has status of 'complete' - no need to explain further, no extra db hits, checking - just display the data you already have
Well, there you go;) Hope you do not see 'updating everywhere' now, but updating ONLY when you actually should be updating. And most important - it's a 'real-time' game, players always see uptaded stuff - there is a feel of 'constant flow', etc.
With 'cron-way' (the way it was put) you would: 1) skip checking times - not really a performance boost there. 2) not have occasional update statement - hmmm.. mild performance boost, especially with all the js / ajax goodness which make 'waiting time' much less obvious and painful for the user
Plus, what seems to be the reason of why I am even talking against Cron here: 1) How do you achieve this 'real-time' effect with Cron, without stupidly low interval (seconds) - big performance issue 2) Imagine this: 1000 players online, 300 refreshes the 'view my buildings' page - the rest stares at the screen doing nothing:
Without Cron - could be lightweight / slightly heavier requests (depends if any updates necessary or not). But all the happy players would have the correct, up-to-date info constantly
With Cron - lightweight requests, info displayed to users most likely out of date until next Cron job. Then when it happens - you would have to run a giant loop through all the players, checking / updating every single detail - buildings, money, army, fights, etc. Even if most players had nothing to update, you'd still have to go through every single detail.