Show Posts
|
|
Pages: 1 ... 3 4 [5] 6 7 ... 11
|
|
81
|
Developer / Technical / Re: Small, cheap hardware (RasPi?) for displaying/exhibiting games?
|
on: February 08, 2014, 06:34:22 PM
|
|
If your AS3 games can be compiled into AIR apps, I'd recommend an android tablet with HDMI out.
We've demo'd our 1849 game a bunch of times from a tablet (Nexus 10) hooked up to a TV. It was actually really cool - one screen in the hands of the player, and identical copy on the big screen for others to see as well...
(One caveat: if you really need a keyboard support, I imagine there are bluetooth keyboards that would work, but I haven't tried them.)
|
|
|
|
|
83
|
Developer / Business / Re: Need some perspective re: early marketing and open development
|
on: January 16, 2014, 08:43:27 AM
|
I've privately showed gameplay footage to a (very) small handful of people, and they seem to get (and like) what I'm going for despite the prototype-y appearance, which is encouraging. But they all have game dev backgrounds and know how to read a game in development; I worry that a more public/gamer-centric audience will mistake the current aesthetic for the intended one, meaning I could lose a bunch of potential future players who might have liked what I'm ultimately going for but are turned off by what I have right now. Your intuition here is right on. It's one thing to show a game with prototype art to gamedev/designer types, who can see the game behind temporary art. But it's a completely different thing to show it to a wider audience, even if they're gamers. People will latch on to graphical style and quality, instinctively, even if you tell them not to. (TBH even experienced gamedevs have difficulty with it sometimes  ). My approach has been to not release any screenshots with my programmer art, and instead wait until I had first-pass real art in place, in the actual style we're going for. Though I've kept some programmer art screenshots for a blooper reel, some day...
|
|
|
|
|
84
|
Developer / Business / Re: What degrees do employers look for?
|
on: January 11, 2014, 05:23:09 PM
|
This depends almost entirely on what kind of a position you're applying for. For entry-level positions: - Programming: a BS in Computer Science specifically is pretty much a standard requirement. Portfolio on top of that will make you stand out. People do get hired into programming without a CS degree, but then the portfolio has to be amazing (and they have to have equivalent programming knowledge too).
- Design: portfolio / projects are very important. BS degrees are common, not necessarily in programming or design as such. Different studios differ on how they value game design schools - it's still a very recent phenomenon.
- Art: portfolio is the most important thing.
|
|
|
|
|
90
|
Developer / Business / Re: Social media for dummies
|
on: December 11, 2013, 04:51:19 PM
|
This thread reminded me of something I saw on techmeme the other day. Facebook is apparently clamping down on displaying business pages to users for free - they suggest businesses buy ads instead. It’s going to get harder and harder for many businesses to reach fans on Facebook without paying for ads — that’s the message of sales material that the company sent to partners, as revealed in an Ad Age report.
... In the sales deck, Facebook first says it expects “organic distribution of an individual Page’s posts to gradually decline over time,” then it suggests, “to maximize delivery of your message in News Feed, your brand should consider using paid distribution.” Comments at the bottom of the article suggest that, as of recently, people have been seeing massive drop in organic post reach, ie. how many posts get displayed to followers for free, just because they liked the page.
|
|
|
|
|
91
|
Developer / Technical / Re: Crowd pathfinding
|
on: December 10, 2013, 08:23:48 PM
|
Does anyone has experience of programming crowd pathfinding? I think it's a nice and easy way to make game characters to find their path in a natural looking way, but I'm still missing some ideas how to improve it....
I uploaded a small crowd pathfinding demo of my new RTS game project. ... Units don't use pathfinding algorithm like A-star, but instead try to walk straight to the target, and start wandering around obstacles when they meet them. Oh man, there are so many interesting ways to do this stuff, some of which I've done, others I'm looking for an excuse to do...  Off the top of my head: - Potential fields + edge following. As you mention above (go towards goal until you hit an obstacle, then follow the obstacle edge until you get a clear line of sight). It's so simple, and works surprisingly well in many cases! I do like solutions based on potential fields, like this one, a lot. But it can get into weird failure cases, like going around a column without ever getting a clear line of sight to the goal...
- Flood-fill + density. This one is for the case when there's one destination that everyone's going to as a crowd. First, do a flood fill, so you know the base cost from each cell to the destination. Then start moving agents, following standard gradient descent. But as they occupy each cell, they should bump up its cost, and when they leave, bump it back down (and maybe update neighbors as well). This way other agents will notice high-density cells, because they suddenly have higher cost, and avoid them. But this can also lead to local minima (which might be okay).
- Steering that incorporates A*. Make an A* path to the goal, and a "leash" that follows the path at a constant rate, pulling the agent with - but the agent also gets repelled by other agents nearby, and pulled in by the centroid of the group. As long as the leash is elastic, it can lead to pretty nice behavior.
On top of that, there's a question of formations. If you want to maintain a formation (e.g. 3x3 squad of soldiers), do A* for the centroid of the formation, and have each agent follow the path + offset for their position in the formation - eg. using the steering + path following technique above. I don't think I have any papers ready as reference, but maybe I can dig up some...
|
|
|
|
|
93
|
Developer / Art / Re: GIF's of games being worked on
|
on: December 07, 2013, 10:25:27 PM
|
Iron production loop: mine that produces iron ore (in the middle), smelter that converts it into iron bars, and blacksmith that turns those into pickaxes. And then you can use pickaxes to mine more iron ore, or silver, or gold.  
|
|
|
|
|
94
|
Community / DevLogs / Re: 1849: a city management game set in the California gold rush
|
on: December 05, 2013, 06:23:40 PM
|
We have many resource conversion chains in the game (there are about 50 different resources). This chain is probably the hardest: iron ore smelted into iron bars, then a blacksmith makes them into pickaxes, which then get used to mine up more iron ore. It's tricky because it's a feedback loop, it takes a lot of workers, and pickaxes are needed for all types of mining: gold, silver, and iron ore. Fortunately many towns make them, so it's often possible to just buy them already made, at a premium. 
|
|
|
|
|
98
|
Community / DevLogs / Re: 1849: a city management game set in the California gold rush
|
on: November 15, 2013, 09:12:20 PM
|
Hey, thanks for both comments!  Re shadows: actually, we're looking at that kind of stuff right now! Not sure where we're going to go with that just yet - there are so many things we want to do.  And regarding early concept art: I agree, those sketches are very cool! But we were blown away by how crisp the rendered art looks on tablets - especially the high res ones. So we decided to go with that...
|
|
|
|
|
99
|
Developer / Technical / Re: Should I roll my own 2D engine? What would you do?
|
on: November 14, 2013, 12:03:27 PM
|
Cross platform support is a must at this point. Traditionally, I'm an AS3 developer. I've been working with AIR for quite a while ... There are more choices as well, but I'm curious about other people's experiences.
If you were starting a large 2D tile-based game project today, what would you do? Our game "1849" is a fairly large-ish city sim/management game, and it's written entirely in AS3. The main goal was cross-platform compatibility - this way we can ship the same code on tablets (iOS and Android), and PC downloadable, and the web in a browser. The graphics are 2d sprites, but under the hood it's all 3d billboards, since the Stage3D hardware-accelerated api is so much faster than the old school flash drawing libraries. We typically run at 60fps on tablets, even when showing large cities with a lot of peeps roaming around.  To get back to your main question - how much of your tech to roll out yourself, vs reuse existing libraries. I'd say figure out what's the most important part of your game, and then spend a lot of time innovating on that - and make use of existing frameworks or libraries for everything else. For us, the core of the game is the simulation, so I built our own sim engine and authoring tools around that. But when it came to graphics and rendering, I just used Starling, because it works very well, I'll benefit from other peoples' bug fixes, and I don't need graphics to set this game apart from others. Now, if I was making a graphics-heavy game with a unique visual style, my priorities would probably be the exact opposite.  TLDR: My approach: focus on what's unique about your game. Make custom, innovative tech for those core elements. Outsource everything else to third-party libraries. 
|
|
|
|
|
100
|
Community / DevLogs / Re: 1849: a city management game set in the California gold rush
|
on: November 14, 2013, 11:25:45 AM
|
Last night we had the first public showing of 1849, at the Good Game Club in San Francisco. It was an event put together by local indies - about 20 different teams showing their games in an art gallery. It was pretty awesome.  Anyway, here's our table, right before the opening. The game is actually running on a tablet, with HDMI out hooked up to a TV. 
|
|
|
|
|