I try to do casual games. I hate that game developers expect you to spend 40 hours on a game and pay for it. You shouldn't dilute content and brag about it being addictive. I don't think games like Civ really need to take as much time or as many turns as they do.

People should be able to enjoy a game in an hour or less a day. Personally, I hate most casual games as well, because they take very little content and try to dilute it even further to stretch it out in small bites. I'm all for compressing a lot of fun into as little time as possible, without cutting out the good stuff.

Honestly, I think polish is the difference between a good game and an epic game. Games aren't really that fun when they're "done", around 30% of the time it would take to make a really epic game is in the polish.

I don't really know how to describe it, but like.. spending an extra 15% of your time on the unnecessary bits would probably double sales.

Like if you finished the game mechanics + art in 6 months, spend around a month on the polish and you'll find a significant increase in reviews, downloads, sales, etc. Not at all a hard rule. I think Blizzard actually allocates a significant amount of development time into polish, and it shows.

My company does some apps for other companies. The stuff that people really love is not that the apps connect to sites and show all the content. But people love things like page-changing animations, custom buttons, and those little optimizations that make it 20% faster. Flipboard is crap. It lacks content. But it's got a LOT of polish and thus a million downloads. It just feels fun to mess around with.

Something like a platformer is even more dependent on 'feel' than a news app.

But if you're spending a ludicrous amount of time on it, make sure you've actually organized it properly. You shouldn't be doing trivial stuff like "a little to the left, no, no, to the right, tilt it 8.2 degrees..."

And if it's a 2 day game, don't even really have to bother.

It depends on how deep you're willing to go.

I don't really think you can just pick up a language and 'understand' how it all works. I know a bunch of programming languages, and I still have difficulty communicating to someone who uses Objective-C.

If you want to do really light scripting things and have 'a feel' for writing code, pick Python or Ruby. Or HTML then PHP if you want something useful.

If you plan to only learn one language in your entire life, go for C# or Java. Great balance of power and ease of use.

If you want to learn it like learning Latin.. to expand your mind and never actually use it, learn C, especially pointers. One of the more influential programmers out there even goes so far as to interview all his applicants in C, because he says that C pointers are the best way to judge programming aptitude.

If you want to go for the middle ground, go for C++.

If you want to learn all of them, go from the lowest level and then work your way up. Learn enough to actually make stuff (a chat room is a nice project). That way, you'll be able to work under harsh conditions, and appreciate options like threading and memory management in higher level languages.

I'd recommend Assembly -> C -> C++ -> Java. You can skip Assembly if you want, though.. if you could actually code a chat room in Assembly, I'd suggest getting a full career as a programmer lol.


Here's a nice source to start off with: http://wibit.net/

I'd recommend just watching the Introduction to Programming and to Object Oriented Programming if you just want to learn terms and stuff without actually doing anything.

I don't recall if this is supported by default. You'd probably have to make a custom movement engine. But in general, you have to make custom movement engines for anything decent in MMF anyway.

just dropbox

If you're writing code on the same file simultaneously, this can be hilarious.

Just version control; it takes only an hour to set up at worst. Get tortoiseSVN, a place to store it: all set.

It's quite covered in the documentation, though the documentation kinda sucks.
http://developer.android.com/guide/components/processes-and-threads.html

The main idea is that UI is single threaded, so all processes should be in other threads.

Or did you have something specific in mind that it doesn't cover?

Also might take a look at your layouts.. there's quite a lot of overhead on each view and viewgroup, so if you've got nested views, it might slow down drastically.

I don't use the NDK, though, so I have no idea how relevant this is  

[IT BEGINS]

IT BEGINS

Bit slow there, should have been 255

Ha, I found a bug that crashes the whole thing the second last day of every month. This was because I'd do a "today+2" to book reservations. Since 32nd Aug doesn't exist, it crashes the system.

I never would've found it if I didn't test that page today, because there are no more last days of the month right before the deadline. People would be pissed at some software that doesn't run for an entire day.

An online multiplayer version of the Sims games

From experience, I find that stuff like this often turn into wargames.

So I think what this topic taught me is that good boss design is completely subjective and hard to nail down.

I liked this thread more:
http://forums.tigsource.com/index.php?topic=27670.0

But I guess this one is more about the mechanics themselves instead of the boss character.

This has had such a big negative impact on my work to the point that I'm wondering is there anything I can do other than making games... Which I have done for the past 25 years.

Make software? It pays more for less work. Such a difference that it'll immediately boost your confidence again. And the software industry can't get enough people.

If you don't want to do it for a few months, just freelance. Freelancing may not pay a lot (depends where you live), but do it as some kind of charity.

[another Chrysalis comes out of the corpse]

IMO, the Chrysalid was the scariest monster ever because it would one hit kill. Well, that's not really so bad. Most of the X-Com aliens didn't just one hit kill, they were tougher and they could kill groups of your guys at much further range. Some could even mind control before you could see them. On paper, a one hit melee kill was nothing.

No, the Chrysalid wouldn't kill your troops. It changed them. They became zombies.. which is really freaky. You can save your troops from mind control and insanity in X-Com. But a Chrysalis zombie could not be saved.

But once you killed them... another Chrysalis comes out of the corpse. This was really fucking scary the first time you encounter it. A Chrysalis zombie could only kill you.. a Chrysalis itself could breed more zombies (and kill them faster than the zombie). You could send the biggest, baddest weapon in the game, launch it on the zombie, and you'd make things worse.

Of course, you'll later adapt your tactics around this and the Chrysalis aren't even as bad as typical enemy grunts late game, but finding out that your solutions made things worse was really scary.


I'd say the key to fear is lack of control. Cigarettes and cars kill more than sharks and suicide bombers. But which is more scary?

A staple of every horror movie is lack of control. Darkness is scary because you can't see what's going on. Freddy Krueger was mediocre by serial killer standards, but you couldn't kill him and you couldn't hide - he goes where you always have to go, and that's where you were powerless. Jason Voorhees was even more direct about it - the only thing about his character design was that he's unstoppable.

Don't think Flash is that good anymore, especially for something with as much work as a MMO. It's getting phased out. Would recommend going for HTML5 since you're already starting from scratch - it's more platform independent, works on mobile, Windows, Linux, etc. Flash is buggy on Ubuntu's default settings, and it's slow on some platforms.

But I don't even know where to begin programming on HTML5 games. Flash has a lot of resources, but you have to deal with the fact that it's going out of fashion.

Spent yesterday evening/night on a bug. Gave up. Worked on another bug this morning. Then I go back to yesterday's bug and it's not there. Which is really annoying because I don't know where it came from or how it disappeared or even if I fixed it yesterday. If I did fix it, I sure didn't tick it off my list. I just get this sinking feeling that it's hiding in some dark corner waiting to surprise buttsecks me...

I've always thought the terms were quite consistent.

Strategy is planning out things on a larger scale, resource management, etc.
Tactics is using available resources, battlefield layout, maneuvers to win.
Execution is following the plans laid out in the tactical phase. Like a pilot trying to bomb a given target, soldiers trying to actually hit targets.


X-Com battles: Tactical
X-Com base building: Strategic
Winning the battle: Tactical
Losing a few battles in order to win the war: Strategic
Jagged Alliance: Before the map, strategic. During the map, tactical.
Total War games: On world map, strategic. Battles are tactical.
Europa Universalis: Mostly strategic, slightly tactical.
Chess: Fully tactical
Battle for Wesnoth: Mostly tactical, slightly strategic.

I'd say a good litmus test is seeing how whether you can lose battles. If losing a battle mean that you lose the game, it's heavily tactically inclined. If you've already won the game before the battle starts, it's heavily strategic.

Total War games have a balance between the two... numbers and troop quality (strategic) matters, but you can win against the odds.

EU3, Paradox games can often be judged by the odds. If you have an army of 30000 men vs 4000 (taking into account their allies), you can calculate victory by the odds. No amount of brilliant maneuvering will really change this. Once war is declared and allies start chaining in, as soon as you get all the information, you know whether you're going to win.


Starcraft or several RTSes of that form has a little of all of it. Most newbies trip at the execution stage, and at that point, it's like an action game, trying to see who can click the fastest and most accurately. 400 hours of practice is a ridiculous learning curve to get used to it, though. So I can see why 95% of people think the entire game is in the execution.

It's strategic in that you have limited resources and have to allocate it. Like what kind of units do you make? What units does the enemy make? Once you're down with a resource/unit disadvantage, how do you effectively manage your resources for a comeback?

It's tactical when you get to things like chokepoints, feints, harassment, unit powers.

Lol, those are the worst. Usually you can't even run them in a debugger, they pop up when you don't expect anything. That's kinda why I make sure all bugs are fixed before moving on... the longer you wait, the harder it is to go back and find out what you just changed that caused a bunch of bugs to pop up. But probably wouldn't really help in this case.

1. Don’t finish your current task at the end of the day, or make sure the next “task” to do is something you feel will be fun or easy. This makes it very natural to get the ball rolling again and pick up where you left off.. your mind wont make excuses.

This seems kind of like a bad idea.

It takes about 15 minutes to get into the flow of things - figuring out where you left off, what to do next. Maybe 30 mins if you've left it over the weekend. So, it's immediate discouragement if you're feeling lazy, or simply unproductive if you're in the mood.

And people are more efficient after some full rest, in the morning. So, I wouldn't really recommend starting with an easy task. Take the hardest you can, cut it down so it's manageable over 3-4 hours. Chip at those hard tasks bit by bit every morning, and do the easier ones late in the day when you're fatigued.

What I do suggest you do to 'warm up' in the morning is set down 15-30 minutes actually planning out what to do the whole day. To do lists do require a little bit of bureaucracy (half an hour isn't that much). Write out your daily plan, how much time you expect to spend on it, and leave around 2-3 hours at the end of the day for when you underestimate the size of those tasks (which you will if you're a programmer).

If you've still got that extra time, spend about 10-30 minutes contemplating what you did right/wrong, and then do some easy, tedious stuff, like cleaning up your folders or washing all the coffee mugs on your table. Don't "reward" yourself by ending the day early; it'll encourage you to cut corners or "punish" you for taking hard tasks.

Heh, spent an hour debugging something, turns out I didn't initialize it. I wonder how many times people get hit by stuff like that before they finally figure it out. At least the advantage of moving on to different languages is that while the syntax is different, the little things that blow up the whole thing are still the same.

I hate it when I have a big list of todo items and I can't find anything to do and find out that I've been aimlessly wandering around internet for 4 hours.

I don't really see how you can have a big to do list and not find anything to do.

An interesting article on design, also with nice statistics.

Generally, the idea to create an optimum design is as such:
1. You brainstorm a bunch of parallel designs, or ask someone to think of one that suits what you're going for.
2. You compare it to your competitors designs, like similar genres. Find out what people really like about them.
3. You decide the good points of all these parallel/competitive designs, then merge them together into one ideal design.
4. You create lots of iterations on top of your merged design - the more, the better.

While it's meant for UI, I think it applies just as well to games, if not better. Especially for things like level design, which aren't so easy to copy off others.

With games, it's hard to predict exactly how your players are going to play it. You'd have to watch them play and realize "oh, there's a design flaw here", then develop a new design out of it.

It's interesting, because I find that a lot of game designers/programmers insist on having a game design document, when a GDD simply cannot predict how the player will act, not without railroading them. It looks like iterative design isn't simply an easier alternative, it's one that would produce better results. (Of course, not saying that you shouldn't write a GDD - you do need your specs, but it shouldn't be intended as the final design)

A remake of Simfarm, but with the cute modern indie graphics/music and better control. Needs to be at least partially based on actual agriculture stuff like Simfarm was. No good agriculture games today