Messages

This has been my week so far. Yesterday I located your "switch to high performance" solve for laptops, but is there a specific resolve for Win 7 games freezing up on a desktop machine (for a game that does not have the option to switch between directdraw & direct3d in winsetup).

Sadly, nope! The high performance trick only works about a third of the time with laptops. For desktops, I have no idea. There are lots of possible solutions and some of them might work for a specific customer, but it's a really long and tedious process to troubleshoot each one. As I am sure you are discovering! Like I said, it's much easier in the long run to create a game that doesn't need to run in DirectDraw in the first place. This is why I avoid plugins like the plague!

Re: Downfall, so you've probably had some of these questions over time too Dave?

Downfall was created with an older version of the engine that CAN'T switch to Direct3D. It would have to be recompiled with the latest version of the engine and tested to make sure it works properly in that mode.

It's still pretty important (and a sad fact about AGS IMO) that it's necessary to get everything right before release. If you distribute with game breaking errors, or can't add something on easily enough in the future, you're going to gain some wrinkles soon enough... Something really needs to exist to help patch AGS games, EXE files in particular - because replacing an entire game (re-distributing a large game to many people for example) is just clunky and not great for (small) commercial enterprises. Yet customers expect it because they've seen gigantic VG corporations do it. Mind you I know nothing of the 'patching' world and quite how those things actually work. All I know is that I'm faced with logistical nightmares because there is no known way of patching a game at this point. And when a game needs to be fixed and is available across multiple stores...well, may as well just get the shotgun out now TBH

Patching is a royal PITA, if only because it breaks save games. And if your game is on Steam, it's even a bigger pain. You upload a patch and it automatically updates everybody's game, whether they want it or not. All your players will wake up that morning and discover that their savegames no longer work, and you will spend several days fielding complaints.  You will need to create new savegames for them and give them the link - another royal PITA. So my best advice is to only upload a patch when it's REALLY worth it - e.g., just before a major sale or promotion. Definitely don't do it AFTER!

For me Im a bit worried about the "no sierra-style interface". I really like that interface, and really hate the 2-click one. I find it a lot more satisifying personally to be able to choose different kinds of interactions instead of 1 click for move and one for all interactions.

Is your game freeware or commercial? If it's freeware, who cares? If it's commercial, you might want to think about streamlining it.

The weird thing with patchmakers is that since AGS bundles the whole game into one big EXE, the patch-file is only negligibly smaller than the full game itself! Although if you are using VO files than it's definitely worthwhile.

Huh. Interesting. I've never encountered this myself, and after launching ten commercial AGS games (all in Direct3D mode) I have yet to hear about it happening to anybody else. It is sounding like the objects are set up in a very specific way which is causing this problem, and I am curious to know what it is.

Does this only happen if two objects are in front of each other? And then the player steps on the Y coordinate equal to one of the baselines and then one of the objects gets pushed to the back? What are the actual effects here?

[LOT.]

Regarding the DirectDraw vs Direct3D thing. It's not a matter of what the developer finds easier/better to use, it's what the end user will experience.

The game won't even run on a significant percentage of PCs if it is distributed in DirectDraw mode.  What will happen is the game will launch and freeze on the very first screen. Sound will play and the mouse may-or-may-not move (it varies) and the user won't be able to do anything.  DirectDraw is so antiquated that a number of computers don't bother supporting it properly. It happened most often on laptops running Windows 7, but desktop users reported the issue as well. There are various ways of troubleshooting the problem, but they vary from computer to computer.

This was a huge problem with Gemini Rue, since the game could only run in DirectDraw mode thanks to its use of the snow/rain plugin.  We got several complaints about this, but it wasn't until the game launched on Steam that the complaints turned into a tidal wave. Every day they came, and there was very little I could do about it.  After months and months of wrecking our brains trying to sort out why the game wouldn't run (and logging swaths of complaints in the interim) we eventually just bit the bullet and re-wrote the snow/rain plugin to work with Direct3D.  There have been no complaints since.

While it IS true that the player can just switch to D3D mode, it is difficult to explain that to them in a concise and simple manner (opening up the game's folder and clicking on setup is NOT intuitive). And be prepared to do so several times every day!  Even if you include the info in a readme or a technical FAQ or something, I know from experience that nobody ever reads those. Instead, here's what will happen: they will download the demo, get the freeze, and then go "meh." Then they will either delete it and forget about it, or go onto their favorite game forum complaining that the game doesn't run (and getting agreements from everybody else who had the same problem). I know this will happen, because it happened to Gemini Rue. A LOT.

So believe me when I say that it's not totally arbitrary when I insist that a commercial game be created with Direct3D mode in mind.

So would the same issue happen if an object has a baseline of Y=100, and the player character happens to walk on that same coordinate?

No, because the character's baseline is not set to 100. If the character is at Y coordinate 100, that's just the character location - NOT the baseline. By default, the baseline is 0.

The problem that the character and the objects have a tendency to 'forget' their baseline in D3D9 is something I got a couple of times. It had mostly happened when the y position of the character is the same as the baseline of the object, and I can speculate, since D3D9 mostly uses floats to calculate positions, the rendering messes up because of a rounded float or something like that. It happens too with walk-behinds since they are processed as objects in the D3D9 renderer. It also happens with characters when two are overlaping and have the same y position. Often flip-floping with behind and front of each other.

I managed to find a way for that problem to occur less frequently. I discovered this with scripted disappearing objects, where suddenly the character appeared in front of an object when another one is visible, and appeared behind the same object when that other one wasn't visible.
To avoid that I had to make sure no object and walk-behind have the same baseline value (always have a difference of 1, for example). Doing so, objects forgetting their baseline didn't happen anymore or very rarely.

Huh. That explains a lot. I was well aware of this happening, but didn't know it was a direct3D specific issue. I learned long ago to never give two object walkbehinds the same value as each other, and I do it automatically now. When all the threads about object walkbehinds getting screwed up appeared I was confused because it never happened to me! Now I know why.

Excellent points all around but Direct3D causes nothing but problems in terms of object walk-behinds etc, making it completely unusable.

Really? How so? I use object walk-behinds all the time.

the reviews on the play store say it's pretty short anyway so probably why its a small file.

The lack of voice acting helps! The VO files for my games take up a few hundred megabytes by themselves.

That sounds really annoying Myinah.
But I guess it's to effectively work as a demo but in case you do want to buy it, you already got the whole game downloaded and can continue where you left off right away.

That's fairly common, and worked really well in the age of 50-MB-or-lower downloadables, when you could download the full game very fast. Now in the age of indie games that are over a gig? Not so much.

There was a game that came out a little while ago called Blackwell, but to be fair they do have this disclaimer on their website:

Blackwell is the result of our 6-weeks production at DADIU, the Danish Academy of Digital Interactive Entertainment. We are NOT, in any way affiliated to Wadjet Eye Games (sorry Dave!), nor we plan to develop any Blackwell franchise. What you see is a student project, we hope you'll enjoy it as such.

From what I gather they changed the name to Blackwell's Asylum... so now they're ripping off two popular recent franchise titles in one hit

They are pretty cool guys, actually. I contacted them after a few adventure game websites wrote about their game mistaking it for my own. The game takes place on the real-world Blackwell Island, and there was an asylum there, so it's not like I could force them to change it. Still, they agreed to put up the disclaimer. The game ended up being in the IGF student showcase. I went by their booth to say hi. They had their picture taken with me. It was kind of funny.

Hmm. The position of the GUI does change depending on whether you are accessing the notebook via a conversation, or through the main menu. It could have something to do with that. I'll experiment. Thanks!

Gemini Rue, for example, was a native 16 bit game! That's unheard of in 2013. It caused more technical issues than I can list. The same for 256 color games.

Is that simply a matter for the "Change Color Depth" menu option in AGS, or did you mean something more than that?

Yes, Josh selected 16 bit from the color depth menu. This turned Gemini Rue into a native 16 bit game, which had a lot of conflicting issues with modern hardware.

Didn't Steam remove their non-Greenlight submission page though? It kind of sucks that these "AAA" publishers get their stuff on Steam no questions asked and Valve won't even tell you what's wrong with your game. I guess it's not practical to make an indie game that doesn't win competitions and expect to get a Steam pre-order page before release.

I think they did. Fortunately I have a relationship with one of the dev managers at Steam and I just submit all my games through him. But even still, I have to prove myself each time!

[DESPITE ME PUTTING IT ON THE SUBMISSION APPLICATION THREE TIMES!!]

[WARNING! Long post ahead!]

It would be great if you could talk about getting on Steam without going through Greenlight, but I'm sure you've signed some NDA that prevents you from that.

Nope! No NDA. I'm free talk talk about it and often do.

When we released Gemini Rue, we knew we had a hit on our hands. It was the first game we launched that seemed to have "hardcore" gamer appeal - RPS loved it, as did Giant Bomb, among others. When it became the #5 rated PC game on Metacritic that month, I figured we were a slam dunk for Steam. I got all the information together and sent it to them, only to receive their boilerplate rejection letter in response.

I KNEW something was up. They never tell you their reasons for rejecting a game, so I couldn't ask them why. All evidence seemed to point that this was a game that the Steam audience would love, but for some reason they weren't accepting it. Something wasn't coming across in my pitch to them, so I hired a PR guy named Joe who could walk into their office during Casual Connect and make the pitch for me.

Joe told me an interesting story. During the meeting, the subject came up that Gemini Rue was an IGF nominee. Steam had NO idea that the game was an IGF nominee, DESPITE ME PUTTING IT ON THE SUBMISSION APPLICATION THREE TIMES!! They obviously never read the thing.

As for Blackwell, they also kept rejecting that. It submitted the whole series to them three times and only got their boilerplate rejection. After Gemini Rue got accepted, I tried pitching Blackwell to them again but again it got rejected. In the end it was Indie Royale to the rescue. The games appeared on one of their early bundles, back when Simon Carless was involved. The Blackwells were the only Indie Royale games WITHOUT Steam keys, and that looked bad, so Steam accepted the games purely on those grounds.

With EVERY game we submit to Steam, we have to do a version of this dance:

Puzzle Bots: Submitted to Steam. Steam rejects it. It got into the PAX Prime showcase and had a good showing. Steam accepts it.

Resonance: Submitted to Steam. Steam rejects it. We submit preview copies to every major press site under the sun and beg for preview coverage. The preview coverage is substantial and glowing. Steam accepts it.

Primordia: Submitted to Steam. Steam rejects it. They suggest going to Greenlight. We put the game on Greenlight and the game shoots up to the #47 spot in two weeks. The game becomes one of the prime examples of "What's wrong with Greenlight?" whenever the subject comes up. In the end, Steam accepts it.

As of now, we have eight games on Steam. Nine if you count Emerald City Confidential (which was a work-for-hire thing). I had hoped by this point that they would just whitelist me for any future game we do. About a month ago I asked them if I could have an app ID for our upcoming game so we could incorporate the Steam functionality early instead of at the last minute like we usually do (because, you know, they never accept us until the last minute).

The response? "We will review it and let you know." And so the dance begins again...


TL;DR: We knew the games were Steam-worthy, and it was just a matter of convincing them. That and we are aggressive, stubborn bastards.

[3 - The oldschool Sierra interface]

3 - The oldschool Sierra interface, with different icons for walking, looking, talking and interacting. We all know it. We all love it. Sadly, nobody outside of the narrow niche of old-school Sierra players understands this interface. For everybody else, it's not intuitive at all. It's frustrating, fiddly, and very hard to tutorialize. Plus from a purely practical standpoint, it will be very difficult to port the game to other platforms that don't have a right-click button! So do try and avoid it.

This I find most interesting. So what would you recommend? Since you talk about platforms without a right mouse button, I'm guessing "left click to act, right click to look" is not the best choice either. So what would work best? Single click? Verb coin? Lucasarts verb-buttons-at-the-bottom? Something else?

I was mostly referring to how you can right-click to cycle through the verb icons, which negates most of the frustration many people have with them. If you can't right-click, it becomes twice as annoying. A verb coin with a few actions is the way to go, if you want to plan ahead for a touch-screen interface.

If Direct3D supported 256 color mode and didn't ignore resolution when scaling down characters, maybe I'd be okay with it.

Well to be fair, if you were going to write a commercial game you wouldn't want a native 256 color game anyway. Like with DirectDraw, it can act REALLY unpredictably on modern hardware. Gemini Rue, for example, was a native 16 bit game! That's unheard of in 2013. It caused more technical issues than I can list. The same for 256 color games.

As for scaling characters, yes this can be annoying. For Primordia we had to render out a whole new set of scaled-down walking animations for the characters that needed them. A bit of a pain, but it was either that or lose over 1/3 of our audience. When you're making a commercial game, that takes priority. For freeware it doesn't matter!

[1 - Avoid DirectDraw like the plague.]

Hi all. Over the last few years I have received a number of emails from AGSers inquiring about us publishing their game. I am taking a break from publishing this year (our new baby has a way of sucking up a lot of our time and energy), but I have noticed a number of common issues in the games that are sent our way. These issues aren't mistakes exactly, but rather things you have to consider when you want to bring a game to a commercial standard. When I give feedback to the developers, I've found myself often giving the same bits of advice. So I thought I'd share the most common of these issues with the community. If you're thinking of going commercial, it might be of some use.

Quick disclaimer: I learned these common mistakes the hard way - by making them myself! You'll see examples of these mistakes littered throughout our entire catalog.

1 - Avoid DirectDraw like the plague. Always use Direct3D. DirectDraw isn't supported anymore, and the results are mega unpredictable. On a good chunk of computers (usually modern laptops), the game will freeze at startup. There are various ways of fixing the problem, but the solutions vary from computer to computer and it's impossible to troubleshoot them all. Release a commercial game that uses DirectDraw by default and be prepared for a ton of tech support emails you won't be able to answer. You can tell your players to "Switch to Direct3D" but the steps for doing that are not intuitive. And if your game is on Steam, it's REALLY a pain. So it's best to avoid it altogether. Make sure your game runs smoothly in Direct3D and release it in that mode.

2 - Avoid the 3:4 aspect ratio (320x240, 640x480, 800x600). If it's not too late, go widescreen (320x200, 640x400, etc). I've noticed a LOT of AGS games sent my way are in the 3:4 ratio. It might be a nostalgia thing, or it might be because AGS starts that way by default, but it causes many problems. On many monitors, the image will stretch across the screen and look ugly. And as with DirectDraw, the solutions vary from computer to computer (and monitor to monitor). Even if the game plays fine, your players will still think you are crazy for releasing a game in 2013 using 3:4 aspect ratio, and get annoyed that they have to play with big black bars on the side of their monitor. I know this because Resonance and the earlier Blackwell games were made this way. It's not a major deal-breaker like DirectDraw is, but it's something to consider.

3 - The oldschool Sierra interface, with different icons for walking, looking, talking and interacting. We all know it. We all love it. Sadly, nobody outside of the narrow niche of old-school Sierra players understands this interface. For everybody else, it's not intuitive at all. It's frustrating, fiddly, and very hard to tutorialize. Plus from a purely practical standpoint, it will be very difficult to port the game to other platforms that don't have a right-click button! So do try and avoid it.

4 - Avoid long intros. This is subjective, but it's an issue that I see cropping up many times (and in my earlier games). Let your players discover your world by exploring it. You don't need to tell them everything right at the beginning. The player wants to PLAY. They aren't going to process a major infodump during the first five minutes of the game. Count the pieces of information you are giving the player in the opening cutscene. If it's more than 5, EDIT IT DOWN (my personal rule - your mileage may vary). This isn't dumbing down your game. It's allowing the player to discover these things on their own. Have faith in your world and the player's desire to explore it.

5 - Are you planning an episodic series? Please reconsider. Unless your name is Telltale, the customer faith in episodic games just is not there yet. Nobody wants to get invested in a story that they don't think will be finished. And let's face it, 9 out of 10 times that is exactly what happens. If your game title ends with "chapter 1", "part 1", or (worst of all) "episode 1"; it sends the message: "this is a short game with a cliffhanger ending that will only continue if the first part sells well enough." There are definitely exceptions to this - Cognition being the most recent one - but it's already hard enough to get people to buy an indie adventure game. Why make it harder for yourself?  A stand-alone game with sequels is better, but still difficult (see: Blackwell).

Anyway, that's it! Keep in mind that this is all subjective, based off my own experience in making and selling commercial AGS games. I might change my mind about any of this stuff a year from now!

So in my game I have a GUI that contains a listbox. This GUI acts as a notebook interface, which is used to ask characters about various topics.

Sometimes - not always - when turning on the GUI the game crashes with this error:



Line 473 is the following:

      int noteitem = note_list.GetItemAtLocation(mouse.x, mouse.y);

note_list is the name of the listbox. The command is telling the game to get the index of whatever listbox item you are hovering over, and assigning it to int "noteitem."

This line of code is located within the repeatedly_execute_always() function of the global script. This command is within the IF statement "if (gNotes.Visible==true)" - e.g., it only gets activated if the notes GUI is on the screen.

Here's the chunk of code:

Code: AGS

(from within repeatedly_execute_always() )

if (gNotes.Visible==true)
{

    int noteitem = note_list.GetItemAtLocation(mouse.x, mouse.y); //<-- the line that gives me the illegal exception
    if (noteitem >= 0) 
    {
        note_list.SelectedIndex = noteitem;
        GetNoteInfoText();
        note_info.Text=noteinfotext;
    }
    else
    {
        note_list.SelectedIndex = -1;
        note_info.Text="";
    }      
      Mouse.UseModeGraphic(eModeInteract);
      GUIControl *theControl = GUIControl.GetAtScreenXY(mouse.x, mouse.y);  //get the control
      if (theControl==btn_notesup && btn_notesup.NormalGraphic != 441) 
        btn_notesup.NormalGraphic=441;
   
      if (theControl != btn_notesup && btn_notesup.NormalGraphic!=440)
        btn_notesup.NormalGraphic=440;

      if (theControl==btn_notesdown && btn_notesdown.NormalGraphic != 443) 
        btn_notesdown.NormalGraphic=443;
      
      if (theControl != btn_notesdown && btn_notesdown.NormalGraphic!=442)
        btn_notesdown.NormalGraphic=442;

    }

By happenstance, I had made a savegame right before I got the error message. But when I reloaded, the command executed just fine. Since this bug only happens very occasionally, it's very hard to track. And the error message doesn't give me any useful information.

So... help? Thanks in advance!

-Dave

edit: Oh, and here's the crashdump file.

Funny voices are fine, but it's also good to hear your "normal voice" in order to get a better idea of your range. Most actors have a commercial reel as well as a character reel, which show off both. A good example of this is the VO reel of Sarah Elmaleh (who played Anna in Resonance!). Her character reel is mostly funny voices, but her commercial reel is more natural and you get a much better impression of what she can do.

Being a guy who casts a lot of voice actors, my first reaction to hearing that is "What does his voice actually SOUND like?" All the characters in the reel are cartoonish caricatures, each with their own forced fake accent. Which one is you? It's good that you have variety, but you don't need put on an accent to make the characters different. Emotional ranges (sad, excited, flirty) are all just as important. When I listen to a reel, I want to hear the actor, you know, act.

Rosa's horribly awkward grin is often the best thing about making a Blackwell game.