Platformer speed-mockups to get back into the groove of things...

Really nice!  Reminds me of the old Cinematic Platformer games.

So a tablety version of Professor Layton?

Let's see.  I work for a small indie studio full-time, and I'm really keen on getting better and better as a computer scientist, so I tend to code a lot.  My day usually runs about like this.

I wake up when my girlfriend wakes up, usually around 9-10, and take her to school.  Neither of us are big breakfast eaters, so I usually skip it.  Then I drive about half an hour to get to work.

Nowadays I'm usually the first one there by about 10:30.  Sometimes the other programmer beats me there, but not always.  We tend to get in pretty close to the same time, though.  Our artist shows up a lot later, usually around 12:30.

Usually we get lunch around 1pm or so; ramen is always a favorite (not cup ramen, but a restaurant).

Right now we're crunching, and we're kind of working with a dearth of organization.  We usually talk about what we've gotten done over the night, and whether or not we've found anything new that needs to be changed.  We divvy up tasks based on workload and specialty, but sometimes we'll trade tasks if things get too hairy for one or the other.

I kind of keep track of everything that goes on in the project.  Throughout the day I'm thinking a lot about the art, UI, gameplay balance and coding.  We all work in the same office, so if I think of an art thing, I can just turn around and talk to the artist about it.

Presently my days alternate between fixing bugs (or tweaking some features, usually controls or physics stuff at the moment), and doing game balance work.  I tend to code in bursts of about an hour and a half, then try to take a break.  Walk around, get something to drink, that sort of stuff.

This continues, and I leave around 6:30 or so.  When I get home, I keep working as much as I can.  It depends a lot on how much there is left to get done, but I'm usually up until 2-4 in the morning.  If I have 4 or so really late nights in a row, I start getting really tired and have to sleep early.

I used to cook a lot more, but recently I've been eating out just because I like having an hour out of the day where I don't really have to do anything.  Weekends are pretty much the same, but I don't commute, and try to spend some more time with my girlfriend and catch up on sleep.

All in all, I'm working about 12 hour days.  I try to keep my dicking around on Tig and such to a minimum and stay focused as much as possible.  Playing video games is an absolute no-no, which was VERY hard to do at first but got a lot easier after the first two weeks.

There's a decent spattering of modern era and Scifi RPG's, and people have given reasons as to why the bulk are fantasy that I agree with.

One thing that interests me is how pervasive the supernatural is in RPG's.  Most of them seem to have magic, crazy ultra-technology, psychics, ghosts, time travel, spirits, digital spirits, digital psychic devil spirits wielding magic, etc.  The worlds brim with fantastical powers, usually wielded or harnessed by important characters.

I'm sure there are some totally mundane RPG's out there, but I can't think of many off the top of my head.  Mundane here doesn't mean Heavy Rain-esque "Drink that OJ and play with your kid" mundane, but just lacking obtusely supernatural elements.

Oh boy, I think there might be a fairly critical bug if you're playing on OSX that causes you to fall through the floor after jumping.  Odd that it would only be on OSX; I'd think that the Unity browser plugin would play exactly the same on any platform.

I could've sworn I didn't notice this when playing it on a Windows machine, but we'll see.  I'll fix it when I get home either way.

Valuable lessons in platform testing!

Edit:  Ok, OSX version has been fixed.  While I was in there, some visual improvements were made and the overall robustness of the game increased.  There was on occasional bug wherein you could fall through the floor on Windows as well, but it should be fixed for all versions of the game.

A Plump Helmet Man attacks! I went overboard with the detail in this guy, I'll probably have to remove a few layers to make him fit in with the rest of the characters.

Wow, that looks awesome, Chris!  I love the "head kind of looks like a poison skull" thing you have going on.

"You live in a little house made of guns. You need many guns to fight invaders but you also need to keep a roof on top of your many children."



http://www.whatwouldmolydeux.com/display.php?GameID=279

Here's the game I worked on at the Molyjam!  This makes my third game jam, but the first time I've ever finished a game at one.

There were a lot of things that me and my team wanted to add to it, but didn't have time.  More enemies, a planning and strategy phase, all sorts of cool stuff.  Pretty happy with how it turned out, all things considered.

It is more encapsulated and safer

Citation please.

"Than a raw global."  Not "than a namespace solution."

Come on, dude.

Also, since people are already commenting on that, what would be considered better, making a factory for the sound sources or letting the user construct them himself? I tried both ways and direct construction seems more elegant, but with a factory I am forcing the sources to only be created when the mixer exists, which is handy.

I'm actually pretty curious about these sound sources as well.

What are they to be used for?  (Music, sfx)
Are they very performance intensive, or are they super lightweight?
What needs access to them, and when?
Do you have a limit on the number that can exist?
Are there special considerations, like in order to create one you have to load the audio file, which takes a lot of time, so you need some kind of caching solution?

I'm curious what some of the arguments against singletons are. I use them for all my major engine components. I used to use global objects, but I ran into problems where these objects weren't being constructed in the order I wanted, so I switched them over to singletons to address that. It's a minor inconvenience to have to manually shut them down before the program terminates, but mostly that's abstracted away in engine code and I never have to think about it.

Because in C++ you can use namespaces to accomplish the same thing as Singletons.  Since there is an alternative, and it is possible to make namespaces that perform better than Singletons, people are like "Never use Singletons".

I think Singletons have advantages, though.  They're easy to understand, easy to use, and far more friendly if you're under time constraints and need to hack things out quick.  I use them a lot, and have yet to run into issues caused by my using them.

There are some cases where a Singleton just wouldn't work, but if you're reasonably sure you won't run into a stumbling block using the Singleton, the go for it.

Consider also the scope of your project and how long you expect to use it.  Will it be 6 months, 5 years, 10 years?  Is it something that anyone else will use, or just you?  It's totally legit to make tradeoffs in coding if it buys you development time.  If you're trying to design something that will last for many years, or will be used by tons of people, then you have other goals to think about.

I will also say that while Singletons are "globals in a pretty dress", if you're going to bone an ugly code practice, shouldn't it at least be wearing something fancy?  It DOES have advantages over straight up global data+static functions.  It is more encapsulated and safer, and it is able to be demoted to a standard class easily.

I spent all day doing lots and lots and lots of math to setup my enemy spawning system.  Had to dust off my calculus knowledge, but it works now and it is awesome.  Suuuuper awesome.

Speaking of optimizations, last week I noticed that the game I'd jumped on to help wrap up was running pretty poorly on my 3Gs.  Like, 5-10FPS poorly.

I did some profiling and discovered that something like 70% of CPU time usage was going to calculating movement along splines.  Almost everything in the game was being moved with splines, when really it didn't need to be.  I spent about two days and coded everything to move with physics instead, and it ended up being well worth it.  Game hovers around 30 FPS now, and plays almost exactly the same as it did before.

Although one example of that which was actually really awesome is in Custom Robo. When it comes time to man up and begin the final stretch to defeat the main villain, there's the obligatory "are you sure you're ready for this?" speech and the yes/no option. If you hit "no", the other characters try to convince you to go. You hit "no" again and get different dialogue, and everyone starts getting annoyed. You can keep repeating that until all the other characters get really pissed at you and just leave without you. Then you get a special ending, and the secondary character gives a speech about how you just killed everyone and how bad of a person you are.

Custom Robo also gives each opponent a special win quote and mini-cutscene for when they beat you, something I've never seen any other game do. It makes everything more believable, since the game world goes on even if you failed (or decided to be a jerk) and you get to see the results of that. You never actually lose any progress though, you just have to start that specific section over again.

A couple of the Paper Mario games do stuff like this.  You'll get to the final boss and they'll be like, "Join me!", and you can actually choose to do it.  The party tries to talk you down from it, but if you're really insistent you'll do it and the game ends right there.

Pretty funny.

You should also take into account that friction gets bigger as the velocity increases... Yeah, that's the problem. You use static friction that never changes. When you have friction that increases with velocity, then you can have one ship with high max speed and low accel and a ship with low speed but high accel.

The friction isn't really constant. It's very simplified as I don't use a force to simulate friction and rather operate directly on the velocity, but I multiply velocity by a constant, so the bigger the velocity the bigger the change. This is why I even have the max speed mechanic, it wouldn't be there if the friction would be a constant force.

Having friction change with velocity doesn't help, this actually how it works in reality, and in reality you won't have what I want unless the objects have different aerodynamics (so different 'friction' values per object).

I'm thinking in a car, as you press the gas your rate of acceleration is actually increasing. I assume you are applying a constant force to the ship? I think technically you need to have a "rate of change of force/acceleration" up to some maximum force. So one ship could have higher rate of change of force, but a lower maximum force, and vice versa.

You might not even have to change your friction and other variables... Assuming you just need to get the right feel and not be physically accurate.

I thought about this, but when would the force increase? It would make sense that when you start the engine then the force is gradually increasing until you are on full force.
But the you only experience the difference in acceleration when you start your engine, not for example when you take a turn.

Unless the faster you move the bigger the force. I might try this out but I have a feeling that this would not feel right to the player.

Is modeling friction really the way to go?

Why not set the max velocity for a ship, and a function to describe the decay of its acceleration?

The closer you are to the max velocity, the lower your acceleration gets, until it reaches 0 (when you're at the max velocity).

You could model different acceleration attenuation curves to do things like have a ship that accelerates very quickly at the start, but levels off for a while, a ship that has near constant acceleration, or one that has a surge of acceleration in the middle of its power band.

Game physics is about getting what feels best, not simulating reality.

I definitely need the friction/damping, otherwise everything would just slide around hopelessly.

I never said "Ditch friction entirely", but I'm not sure it's the right tool to use if you want to cap the acceleration of your ship in the manner you're looking for.  You can still have friction for all the other frictiony things in life, if you really want to.

However, in this case friction's merely a force that's acting counter to the direction of your movement.  You can still have a decay force that kicks in when the player is not actively pushing on the gas, which will give the illusion of friction by providing deceleration proportional to your velocity.

In fact, in the case of a vehicle, there are lots of things at work that contribute to your deceleration.  The rolling friction of your tires, air resistance (a very big factor for real vehicles), the momentum of the engine parts, and the friction of the engine parts, and probably more.

Also, the change of acceleration for an ICE is strange and complex, even when you disregard outside forces.  It does not follow an exponential curve, but rather a power band wherein your acceleration increases, levels out, then decreases.

Unless you're aiming for a super accurate simulation game, I'd instead rigging up a physics solution that doesn't follow reality, but achieves the desired effect, rather than trying to balance drag, friction, and acceleration all at once.  In the past, I've had far less luck trying to model reality.

Is modeling friction really the way to go?

Why not set the max velocity for a ship, and a function to describe the decay of its acceleration?

The closer you are to the max velocity, the lower your acceleration gets, until it reaches 0 (when you're at the max velocity).

You could model different acceleration attenuation curves to do things like have a ship that accelerates very quickly at the start, but levels off for a while, a ship that has near constant acceleration, or one that has a surge of acceleration in the middle of its power band.

Game physics is about getting what feels best, not simulating reality.

Looks like this thread came to kick ass and chew bubblegum, and we're all out of bubblegum.

Your animations are rather nice.  Punching's not super easy to make look right.

Just finished implementing the last gameplay feature in the game I'm working on.  It's been a pretty rough month, so I'm super happy it's come to this point!

Hey, something just occurred to me. Is it possible to do a hackintosh build? That way you could just get a cheap, used PC and put a recent OSX on it. That would likely be the cheapest way to work.

Anybody with experience along those lines? Maybe I should try it myself, on dual-boot or something...

I tried a hackintosh once, and it didn't go terribly well.  Getting complete compatibility and stability was tough, and I spent many many hours tinkering with the thing to get it to work right.

It might be easier nowadays, that was a few years ago.

Plus, there's the fact that Apple updates iOS pretty frequently, and thus updates Xcode pretty frequently, which usually requires a pretty recent version of OSX to run.  If you want to be able to build for the latest iOS version over the next few versions, expect to be upgrading your OS a couple times.  When you upgrade, things might break.

If you're comfortable buying second hand, it would be the best deal.

Whatever you get, make absolutely sure it has an Intel based processor.  You cannot build an iOS app unless you're using an Intel based machine.  They started putting Intel processors into Macs in like...2006 or something?  Somewhere around there.

Beyond that, the Mac Mini would be your best bet for a new Mac at the lowest price.  I think they're around $600.

[On Multiple Goals:]

Personally, I've always interpreted "Game Over" to mean "the game is over", meaning some sort of condition has been met to end this current session of play, not necessarily that a win or lose has been secured.

I do agree that in a broader sense, "Game Over" is often used to signify failure.  You'll see it for lose screens, but rarely for victory screens.  Usually they have a "You Win" or "Thanks for Playing" or maybe "The End" or something, probably because that feels a bit better than "Game Over."  This might be one of those things that was subtly driven by psychology, that people don't respond very positively to "Game Over", but it serves as a softer (if objectively nebulous) term for "You Lose".  We often play it a bit fast and lose with English, so that term "Game Over" kind of adapts to fill whatever definition is missing from the game's vernacular.

The whole goals part of the article is the one I find most interesting, though.  Talking about goals is a bit sticky with games for several reasons

1)  Games can have multiple goals.
2)  Beyond explicit goals, there are implicit goals and emergent goals.
3)  Goals do not always reflect the motivation to play a game.


On Multiple Goals:
I would say that many SHMUPS have multi-layered goal structures.  Let's take Ikaruga, for example (because designers fucking LOVE to talk about Ikaruga).

You have levels, there's a progression through them and an ending to the game.  You can beat the final boss and win.  One explicit goal of the game is to work your way through all the levels and win.

You also have high scores.  You can play the game not to complete it (beat all the levels and the final boss), but rather to get a high score.  This involves executing expert level play, which is inherently riskier than playing it safe, but the score rewards are much stronger.  Completing the game is certainly desirable, but merely a consequence of your primary goal (getting a high score).

The player may execute on these goals separately, or simultaneously.  Sometimes goals can be mutually exclusive, but not always.  I very staunchly subscribe to this "there are mutliple ways to play a game" mode of thinking, and believe people should be cautious about too narrowly shoe-horning games into one mode of play over another.

On Implicit/Emergent Goals:
There are some "digital media artifacts" that exist that people are hesitant to define as games, for one reason or another.  Beta-era Minecraft is an oft-discussed example.  It was a big'ol sandbox.  You can wander around, craft stuff, fight enemies, build structures, etc, but there was no way to win the game.

It didn't stop people from making their own goals, however.  Collect a ton of diamonds, build a cathedral, get to the Nether, etc.  The possibility space for the game is quite rich; there are lots of rules to that system, and the various components have relative value.  A creeper is a bigger threat (typically) than a spider, a diamond is (typically) more valuable than stone.

No one tells you, "Hey do this stuff", but players are more than capable of generating their own goals.

A lot of people are like, "Well then that's a toy."

Well...why?  You have goals, the only difference is that you decided what they were, a game designer didn't tell you what they were.  Emergent versus Explicit.

What happens if you play an undisputed video game by your own rules?  Is it now a toy?

Consider Ikaruga again.  It is possible to play the game without using your weapons (bullet eater runs).  You can absorb bullets of the opposite color and bosses will eventually fly away after a certain amount of time.  Now, I don't think this was the first SHMUP to do this, but I think this original mechanic of "bosses will time out after a while" was not meant to support bullet eater runs, but more as a time limit of "Hey beat the boss quickly or you won't get many points".  Originally, I do not believe there was any explicit goal structure for doing this, but players observed that you could play the game this way and made up a "game within a game" because the self-imposed rules made things interesting and different.  I could be wrong because I don't have an Ikaruga cab lying about.

So again, we're left with a similar situation to Minecraft, wherein the player has defined their own goal structure.  However, I feel that the urge to call this method of playing Ikaruga "a toy" is far less potent.

I have no idea if this is a toy or a game, or if Minecraft is a toy or a game.

I do think that implicit/emergent goals are important for games, too, and as valid as their explicit counterparts.  I feel that sometimes people scoff at them, but I think they can really add to an experience.  Of course, the designer shouldn't be lazy, but even providing a really rich possibility space with no explicit goals is quite the design feat.  Trying to torque your design down so hard that emergent play becomes impossible, in my opinion, runs a serious risk of giving you a very stale experience, and renders few tangible benefits to the player.

It's like building a narrow, glassed in tunnel through the rainforest versus giving someone a GPS filled with a couple interesting locations to check out and cutting them loose.

On Motivation For Play:
This one's a big topic, admittedly, but I want to point out that the goals of the game are rarely the true motivation for people to play a game.  I'm never like, "Holy shit imagine all the points I could get!" when I sit down for a session of Tetris.

If I play something like Tetris, I'm doing so to exercise my mastery over a system.  If I'm playing Ico, I do so for the art and emotional experience.  If I'm playing Amnesia: The Dark Descent, it's to creep myself out real bad.

It's important to keep that in mind when stating your goals for the player.  I think goals are really secondary to the overall experience you're trying to give the player, which is what will ultimately fulfill their motivation for play.

This is why many people enter unspoken contracts with the game designer to play by their rules, rather than reality.  If we all played games in the min-maxed way, we'd play like speed-runners, because for many games that's the best way to attain the stated goal (save the Princess, capture the last Metroid, etc).  If I play Symphony of the Night, I don't immediately run to some extremely cheesy area, farm up some sweet as weapon, then do crazy shit to beat Dracula in 10 minutes.  I mean, I could, but I usually find it more fun to progress through the game "normally", to fight the bulk of the enemies along the way, collect a bunch of items, level up, that good stuff.

The exception to this is competitive games.  I struggled really hard with MOBA's until I internalized that I needed to ditch my assumptions about "how the game should be played" based on my previous expectations established by games.  In those, my motivation for play is very much to win, and there I do play them in as heavily a min-maxed way as possible.