Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Dave Gilbert

#481
Speaking as an employer/producer of indie adventure games, original work is ALWAYS more impressive. Even if it's shorter. ESPECIALLY if it's shorter. If I am going through a list of potential candidates, I am not going to spend an hour playing through someone's sample piece. So shorter & snappier is better.
#482
AGS Games in Production / Re: Unavowed
Fri 17/02/2017 17:19:00
\o/ Thank you! The GIF compression does it no favors. I'm hoping to put together a nice teaser trailer soon.
#483
While the subject of copy-write is murky when it comes to freeware projects (it's really up to the IP holder to decide whether or not to shut you down. LucasArts has been pretty cool about it, generally) I would be wary of using your fangame as a "resume piece." Speaking only for myself, if someone sent me an Indiana Jones fangame to demonstrate what they could do, I would probably not even bother to check it out. When I hire someone, I want to know what they are capable of doing on their own. A fangame just says to me "this person can't come up with an original idea." Again, I am speaking ONLY for myself. Your mileage may vary, of course. But that said, if your long-term plan is to use your fangame as a springboard to something more substantial, you are better off making an original product.
#484
Davy Jones: creepy uncle edition.
#485
AGS Games in Production / Re: Unavowed
Wed 15/02/2017 14:34:35
Been while since I uploaded a screenshot. Here's a bunch of animation to tide you over!

#486
Valve is no longer interested in being a curator/gatekeeper. And honestly, that was never a position they wanted in the first place. Greenlight was their attempt at fixing that. The theory was sound - put your game on Greenlight for $100 and have the community vote. This was a great way for unknown developers to get on Steam without having to jump through hoops (like I had to do!). For awhile, it kind of worked. Steam would accept the top 10 rated Greenlight games per month. This later was broadened to 100 per month. Now it's expanded even further. It's around 100 per week (and sometimes per DAY)! There are too many games being made! I'm not sure why Valve opened up the floodgates like this, but since they did there's no point in keeping Greenlight at all. Might as well create Steam Direct and have devs bypass it entirely.

Course, this all depends on the fee they will charge for the service. It will NOT be $5000 as some reporters have claimed. I'm pretty sure at most, it will be $1000. At minimum, it will have to be higher than the $100 Greenlight fee to deter all the shovelware peddlers. So... a few hundred bucks probably? Just guessing.

As a developer who is already on Steam, my concern has always been the marketplace getting flooded. Back in ye olde times of 2012, finding one of our games on Steam was easy. You'd find it just by casually browsing through the store. Now, there's SO many games (and most of them are awful) that discover-ability is next to impossible. It's easy to get angry about it, but this happens in ANY industry that has proven to be popular/profitable. Indie games have shown to be good money-makers, so here we are.

I suppose it's the flip side of an old problem. Before 2012, the challenge was to GET on Steam. Now, the challenge is to get NOTICED on Steam. You actually have to do marketing and promotion these days. And that's, like, work.
#487
Quote from: Crimson Wizard on Thu 09/02/2017 12:32:16
Quote from: Dave Gilbert on Thu 09/02/2017 10:50:50
Sure. Sorry to sound dense, but how do we go about doing that? Is that something I do on my end or yours?

Ideally, I could test your game on my PC with debugger and/or profiler (the tool that calculates process speeds).

Other than that, I could make a special version that writes times of operations to the log file, and let you run it.

If it's not too much trouble, the latter solution would be the better idea, just in case the problem has to do with a setting on my computer.
#488
Quote from: Crimson Wizard on Thu 09/02/2017 00:38:13
I cannot think of anything in particular... except in the past many objects were not properly deleted before exit and memory just cleaned up by operating system.
But 5-10 seconds? I cannot remember any game exiting so long. If that really takes so much, I would like to try doing profiling when running your game under debugger, to see which operations take most of the time.

Sure. Sorry to sound dense, but how do we go about doing that? Is that something I do on my end or yours?

edit: I tested quitting the game in windowed mode and it was instant. It only takes a long time in fullscreen mode.
#489
One very minor niggle. While in full-screen mode, booting up and quitting the game both seem to take several seconds longer then they used to. Around 5-10 seconds. I remember encountering this when I tested out your alt-enter version of the engine, so that may be related.
#490
Quote from: Snarky on Wed 08/02/2017 14:36:24
Particularly since switching to another set of sprites is tough when you're supposed to smoothly scale with distance.

This is true. If you're scaling with distance that is a problem. Fixing the issue in-engine is definitely the best solution. So thanks, CW. :)
#491
Quote from: Crimson Wizard on Wed 08/02/2017 14:32:38
Quote from: Screen 7 on Wed 08/02/2017 14:23:42
So how does one avoid what is happening in the Aeronuts screens in this thread: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54413.msg636552825#new

Fixing it in the engine!

That would be a much better solution than mine. :D
#492
If I need to scale a character that small, I'll generate a new set of sprites to be displayed at the smaller size. A bit overkill, but it's worth it if I can avoid DirectDraw. :)

(Dualnames might remember we did something similar for Primordia! We did it for Shardlight as well, during the prison escape sequence)
#493
That's what I figure too, but the print screen button does the same thing. Doesn't it?

edit: aaand I figured it out. I fixed the problem but remapping the "take a screenshot" command to CONTROL-P. Apparently with the control button held down, it doesn't advance the dialog window and the screenshot is taken properly. For some reason, I hadn't tried this before.

Anyway, I'll marked this as solved. If someone in the future has the same problem and reads this post, you are welcome.
#494
So lately I've switched to using FRAPS for screenshots. It's quicker and more flexible. However, it does one weird thing.


As you can see, the portrait is displayed but the text is not. I've tried it numerous times and the problem remains.

When I take the screenshot using the standard print-screen button, it works fine:


Does anybody know how FRAPS works and why this could be happening?

Thanks! :)

-Dave

edit: I am using the F10 button to take screenshots with. I have tried tying it to other keyboard keys but I still have the problem.
#495
If you design your game specifically to work in DirectDraw, then there's a good chance you won't be able to run the game in Direct3D. But, switching from Direct3D to DirectDraw is relatively painless. There might be some issues with slowdown and scaling, but the game will at least WORK. So the point stands - don't design with only DirectDraw in mind.

This has ceased to be an issue as more people make the switch to Win7 and higher, but that's been my experience.
#496
Sweet! A new version!

Will download soon and see what's what. Thanks again.
#497
Hurrah! Thanks to all who nominated Shardlight!
#498
AWESOME! Will update soonish and test it out.

One small request for a future update. Something I've always meant to bring up before now:

Quote
Exposed Clickable property for room Objects in the Editor.
Can the same be done for hotspots?

Thanks again, Mr. Wizard!

-Dave
#499
I never said it was a Win7 specific issue. DirectDraw caused no end of problems on a different number of systems. There didn't seem to be any rhyme or reason to what caused it. In the end, I avoided needing to think about it entirely by switching everything to Direct3D. I've had no problems since.

Edit: In seeing old posts, I did mention Win7. This was because it was the most recent OS at the time. The point still stands though. DD is antiquated and can cause unpredictable problems on modern systems. If I had issues in 2011, I can only imagine what issues One could have now. Why put yourself through that? For one rain effect? 
#500
DirectDraw should be avoided at all costs. It's not supported anymore and causes no end of problems. An AGS game in DirectDraw mode won't run on a large number of computers, specifically laptops. What usually happens is the game freezes completely upon startup. When I first encountered this problem and called up a tech support line, the first suggestion they gave was to "try using DOSbox!" This was back in 2011, and DirectDraw was outdated even THEN.

So, yeah. Don't use DirectDraw. I personally think it should be removed from AGS entirely, but I know I'm in a minority.  :D
SMF spam blocked by CleanTalk