Leaderboard

Hello! I'm back with a quick tutorial on how to make lowpoly trees taking advantage of Blender's 3D add-on "sapling tree generator" in less than 10 minutes! Here's a video tutorial from BlenderGuru with more in-depth information about how sapling add-on works: http://www.blenderguru.com/tutorials/how-to-make-a-christmas-tree/#

Legal I'm not owner by this content, but I share this public content with our community understanding the legal consequences. http://waywardstrategist.com/about/ And We Share the vision from the Owner of this Site, I share this only by educational context or point of view. source: http://waywardstrategist.com/2015/05/04/lets-talk-rts-user-interface-part-1-interview-with-dave-pottinger/ Introduction One of the most crucial aspects of the design of any game is its user interface. This is an incredibly broad topic, ranging from the game’s menu system to its in game graphical user interface or HUD (heads-up display) to its interaction model – keyboard and mouse, joystick, game pad, or what have you. A game’s HUD is one of the most basic and most heavily utilized sources of information to the player in a real-time strategy game – many an RTS has been accused of forcing its players to ‘play the UI’ instead of being more free, as in genres like shooters, to interact mostly with the game’s world and environment. The HUD combined with the game’s control scheme (or mouse and keyboard interactions model) encompass the vast majority of a player’s knowledge of and control over the game space, and it behooves game designers to get these systems just right for players, to reach that age old Platonic goal of allowing the player’s intentions to translate directly into action in-game. Respected RTS game designer Dave Pottinger, now president of indie studio BonusXP, who has worked on storied RTS titles such as all of the Age of Empires games, and Halo Wars, has graciously lent me his ear (metaphorically speaking) and generously lent me his time to answer a couple of questions I had regarding his thoughts as a game designer on this critical facet of the real-time strategy genre. Wayward: It is my opinion, and tell me if you agree (this’d be a great place to throw in a comment if you were so inclined) that by and large the RTS genre is sticking with known quantities: for the most part, RTS interfaces are comparable to those developed at least 10 or 15 years ago Dave Pottinger: I think that’s true. 3 reasons: Part of that is just that there are less RTS games. Less games means less chance to innovate and see new stuff.RTS UI is hard. Improvements for the hardcore are almost always in opposition to improvements for the casual. Just today I decried how we allow you to scroll the camera while drag selecting because it’s terrible for noobs. 3 poeple instantly said “Well, you can’t change that!”. Every genre has those types of tried-and-true assumptions, but few have as much UI as an RTS game. Connecting back to your question, I think it’s harder to innovate when you have so much UI that is established and expected.I think RTS UI is something of a solved beast. Back when I started, there was still a debate about one or two mouse buttons. Thankfully, that’s out of the way. But, by and large, the RTS UIs of old were pretty good.I do fully expect other UI paradigms to come up in RTS games. Absolutely. I can’t wait (and hope to help introduce a few of them). But, I think those need to be accompanied with some game changes. If you have a game that plays like SC or Age, I think you’re going to end up with a UI like SC or Age because that UI works pretty darn well for controlling that type of game. Wayward: At their core, what are your goals regarding real-time strategy interaction models (both with ingame graphical UI and with keyboard/mouse interaction systems) Dave: At the simplest level, we need players to feel like the UI is allowing them to control the game. Well, maybe that’s not the simplest way of looking at it; whether or not they have fun with the game is probably the simplest metric. Nevertheless, IMO, people get most frustrated with UIs when they are unpredictable and/or they don’t know how to make it do what they want. If I have to answer the “How do I do XYZ? question too often during a playtest, then I know that one’s in the crapper. So, at the base level, I want a functional UI. Once you learn something, it should be easy to remember how to do it. I personally want a very consistent UI. The UI should also be responsive. That’s not a hard concept, but it can be hard to execute. Many RTS games run a lockstep, synchronous simulation (to push the unit counts so high). That can create difficult situations because the units may not start moving right away when you command them. That means we need to solve the responsiveness issue some other way. At a higher level, I think an RTS game has a harder-than-average presentation issue… We need to deliver critical info via a split second glance. That’s hard. No one wants to study the gait of a the unit to see if he’s limping when they’re really playing competitively. They need a way to see how much health the unit has at a glance. Hence hitpoint bars. Bumping up even more, if we can solve the functional and presentation issues, then we can start to think about how it does that. Does it look good? Does it fit the mood of the game? Is it fun to navigate? Where can we put the little dashes of love that make someone enjoy a UI? I do know some folks who start with the UI and then work backwards. I don’t think that way, so I have to do it this way Keyboard is similar, but there’s less room/need for excitement and pizzaz. Do I get some response when I hit a hotkey? Does your keymapper work? Great. Move on. Wayward:What do you think are the primary strengths and failings of RTS user interaction design as a whole? If this is too broad, can you comment on the strengths and failings of a representative game (perhaps one you’ve worked on) + comment on what you would’ve liked to see done differently? Dave: Broadly… I’m not sure I’d consider any RTS game to have a great UI. I say that because I think there’s simply too much information that you have to present. I do think there are plenty of RTS and RTS-like games that have good UIs given the gameplay they must serve. SC2 and LOL come to mind. But, I still don’t think either of those games is a good UI. Too much info, too geared towards the hardcore. I also humbly say those things expecting the same critiques to be lobbed at our past work (Age, AOM, Halo Wars) and our current game, Servo. We have a lot of information to show you so that you can make the best informed decision possible. Strategy folks tend to like that. Our job is to present all those things in the best UI possible. I’ll mention two specific fails… The “giant” Age of Empires 3 UI. It wasn’t really *that* big, but once the game was out, it was instantly lampooned. It surprised us. We had spent so much time arguing/debating/redoing that UI; we just never really noticed that it had gained too much size. We burned all of our energy and time trying to make everyone happy; I don’t think we were ever able to step back and evaluate it from a fresh perspective. So, when that reaction hit, the AD for the game (Dave Kubalak) and I sat down and just did the mini version that night without asking anyone’s opinion. Went out shortly after. The SelectAll button from Halo Wars. I hated it then and still hate it now. It was such a cave against the fact that we just couldn’t make the UI work well enough. We couldn’t get control groups to work the way we wanted and we were out of time (being that the studio was getting closed and all). We added it to make the game “as playable as possible”. It instantly had the expected effect. It was so easy to use that it became all anyone ever used. It really un-did a lot of the fine work that went into unit differentiation and special abilities. But, without it, the game wouldn’t have been playable. Wayward:What is the cardinal sin a designer can commit when establishing an interaction model for a strategy game? Dave: I think there are plenty:) A few that come to mind… Assuming everyone will want to “play like you play”. With RTS games having more UI than your typical game, there’s a bigger chance for failure here. You need a UI that can appeal to people who don’t play the same way that you do. In some cases, you may be on the losing end of preference, too. For example, I don’t personally love the QWERTY-style hotkeys that are the rage today. I understand them, though. I can accept that lots of people like them, too. So, we’ll just have an option.Assuming that everyone *wants* to play the way you play. Similar, but importantly different than the previous one. Just because you know the right answer, don’t expect everyone to want the same goal. Everyone has their “limit” in terms of how much energy and effort they will expend in a given game. It’s a huge mistake to assume that everyone will have more fun if they play better. Some folks are okay playing a slower paced game. Let them. Yeah, they won’t win a tournament, but they likely don’t care.Assuming that you are actually any good at the game you are making. You are not. Don’t think you are. Find someone who is and watch them play. That will change everything.Thanks again for your time, Dave! http://waywardstrategist.com/2015/05/04/lets-talk-rts-user-interface-part-1-interview-with-dave-pottinger/

@ wowgetoffyourcellphone and flashing target: Yes, we will have to improve feedback to the player, both visual and audible. For any command there should be a feedback and it should not be annoying (e.g. soft sounds, brief flashing target unit/circle on ground).

V9. Blendfile attached. Should fix the looping glitch. If you bake till the end (0:47) there is the same keyframe so should be okay for the looping bug. ZebuV9.zip

On\per niektb's request I looked at the fir (incorrectly called pine in the game)'s texture. I made some improvements to it, and generated a normal map. XCF and textures included in the zip file. I'd suggest removing pine_w.dds as it looks bad, and same for pine_snow.dds. pine_w2.7z

now you talk about that, we are forget the sound, we need differentiate Gaia animal attack from standard player alert attack.The siege units need sounds when buildings receiving their damage. Even capture needs own alert and sound( my opinion) An different alert when you lost a CC.( this may need an artist to make specifics sound)

Nice, looking good. Now we need death animation, and some idles.

When the fundraiser took place I didn't have the possibility to participate nor did I have the money to get one T-Shirt. So a few weeks ago I used a website called Shirtnator to make one.

Hello, as some of you probably know I am living in England until January, and took advantage of this to go see the celtic exhibition in there. It was really worth the money we had to spend around £13, and here are the photos we managed to take before they asked us to not take any other photos.

Any attempt to make things clearer by dragging the explanation further away from how the game's ruleset actually is will not work well. Selected unit's basic stats should be directly shown in a manner that fits the games ruleset as well as being easy to grasp. A tooltip can be used for more details like derivated values (e.g. damage reduction in 1/100th - also known as percentage - derived by the armor rating - likely just 1 to 9 - for each damage type and the formula which is of little importance within a game - besides of cause a short but descriptive name for that stat like "Health" or "Armor"). For stats anhanced by upgrades the tooltip could show the calculation rather than the final value (that's shown in the info GUI allready) like: GUI (The icon could actually be behind the value if made simple, clean andclear enough): [Armor Icon]: 3/4/2 Tooltip of the armor area: Armor: Pierce: 2+1 (27% damage reduction) Slash: 3+1 (34% damage reduction) Hack: 1+1 (19% damage reduction) Hovering above a units icon should show a table of all the unit's stats to get an overview. For the production queue icons a tooltip should state the units more general capabilities (e.g. "fast" for cavalery and or it's general purpose like it's role) in a wordy manner. The detailed information about units including historical descriptions and their ingame stats as well as the game's ruleset should go to a "enceclopedia" or something that can be accessed from the main menu as well as from the matchsetup screen and ingame (similar to Age of Empires II). There the purpose of the units should also be described thoroughly including what stats makes the unit fit for this role.

Thanks for sharing this, Lion.Kanzen! Since this interview is from another webpage please add a link to that page (hopefully the original one), the title of the original post and the user that posted it (and if known the name of the person making the interview) at the top of your post (above it's content to make clear that the following is a copy/citation). Yes, you have the link at the bottom of your post but IMO the original page and it's creators including the interviewer should get the credits for their work.

New week, new release (even if it may not be regular). This version just changes the capture values, with empty buildings being easy to pick while not that much when someone is inside. There's no real concept behind this, just a experimentation. On the way I started to think about how resources could be categorized for a simple usage and smooth progression. sibyllae vox 20151115.zip

- Edited and added some new Blender features as well as pyrogenesis annotations: - Blender collada export now works better and there's no need to bake the animations even if using IK setups. This reduces considerably the size of the animation collada file. - In order to get clean loops in pyrogenesis, you have to export including the first and last keyframe of the loop. In theory, it is the same keyframe and should be avoided, but the engine needs this duplicated keyframe. In resume: export the first and last keyframe in the animation loop to get a clean looping animation. - Blender now supports "clean channels" option when selecting keyframe channels and deletes the keyframes that do not add anything new to the animation. This reduces the size of the animation file without altering the animation at all. Just select all keyframes in the action editor, hit "X" and select "clean channels"

There is a ticket for this. Two actually one is object damage and the other is falling anims. Those are planned features.

The list is now up-to-date with respect to SVN contributions (pfiouu!)

I think there major problem is that you have to hover over a tooltip before actually knowing the stats. I think we should display it directly on the unit panel, rather than hiding it in a tooltip.

I've tried some things with palisades and walls, without regards for other stuff. Some metagame comments first: -It may very well be too easy to defend in the early game but that is not because palisades are too cheap or anything. It's imo because CCs have too big a range and too many arrows when garrisoned, and garrisoning is too quick since units move too fast to do real damage when raiding, as villagers are too strong. Women really ought to be a glass cannon for resources. -Palisades should be quick to set up, relatively dirt cheap, and relatively easy to destroy with a good enough force. Their aim is to stop raids in some parts of the map in the early game, not turtle. -Walls should imo be slow to build and very resilient except against siege units. Cost seems mostly good right now: they're expensive, but not insanely so. They should be useful to completely wall yourself in, or to completely block a pass or something, particularly when they are well defended (towers garrisoned and units on wall). But since walls don't block arrows, nor defense tower arrows, this makes them slightly OP right now. That being said, I've changed palisades to be slightly cheaper and faster to build, while making them less resilient, particularly to hack attacks. This means you can set them up quickly but 10 spearmen or 5 swordsmen will do a quick job of opening a wall. However it should stop archers pretty well (except for the range thing, again) Stone walls I've made slower to build, but slightly cheaper. I've made them basically impervious to pierce attacks, and quite strong against hack attacks. This means a defended wall should mostly hold its own against melee units, even buffed champion swordsmen (it would probably take 30 at least to go through). However crush weapons such as rams make a quick job of those walls, even the Carthaginian ones. I'll probably commit that change after A19.

Penalty? Walls in 0 A.D. take far too long to construct in most situations, and compared to most walls such as in Age of Kings in which they cost 2 wood for palisades and 5 stone for a stone wall. Compared to these rates coupled with the fact that there are very few chokepoints in 0 A.D. games means that walls are impractical. Age of Mythology priced them at 3 gold. Surely the walls could be more inexpensive in 0 A.D.

I think cavalry archers should be more expensive, they are too efficient in the early game as they are very hard to counter except with more cavalry archers. Perhaps a tech to reduce their range until the town phase? Another thing is walls and palisades, which are imo waaay too expensive, given their limitations: cannot stop LOS, cannot stop arrows, need to be built in territory. Since we also cannot build towers close to each other, it is very difficult to efficiently protect a dropsite or close an area off in the early game. And building a small palisade wall costs a TON of wood. Actual walls are probably too expensive too, but I never tried them. Another possibility would be to allow placing wall foundations out of territory, but only allow building if they are in territory, and make walls expand territory. So you could actually build a wall beyond your territory, but it would rightfully be somewhat expensive (though walls are imo still too expensive).