ozkriff's devlog

Zemeroth v0.6: Renown, Upgrades, Sprite Frames & Flips, Effect Icons, and Videos

Sat, 21 Sep 2019 00:00:00 +0000

Hi, folks! I'm happy to announce Zemeroth v0.6. Main features of this release are: renown and fighter upgrades, possessions, sprite frames and flips, and status effect icons.

Zemeroth</a> is my hobby turn-based hexagonal tactics game written in Rust</a>. You can download precompiled v0.6 binaries</a> for Windows, Linux, and macOS or play the online version on itch.io</a> (should work on mobile browsers too).

After 0.5 release, I've experimented a little bit with smaller forum updates</a> and short complimentary videos</a>, but I've expectedly failed to make them regularly. Actually, I only managed to publish one such update: drafts for second and third updates were never finished. So, I decided to cancel my attempts at making weeklies and squashed all the "weekly" text drafts together into this larger announcement post.
Video drafts were also squashed into a video version of this post</a>, check it out:
</a>
So, what does this release add to the game?
Renown and Fighter Upgrades</h2>
The biggest additions of this release are the renown system and fighter upgrades.
"Renown" is the currency of the campaign mode that the player receives by winning battles and spends on recruiting and upgrading their fighters between battles. The term is obviously borrowed from Banner Saga</a>.
Updated campaign menu looks like this:

Now it shows not only the last battle casualties and their current fighters but also their current renown and a list of possible actions with their costs (in renown).
The player is now free to choose more then one action if they have enough renown.
One upgrade option is chosen randomly for up to two upgradable fighters in the player's group.
If the player doesn't like provided upgrade options, they can skip straight to the next battle (that will be a little bit harder) and use their renown later.
Recruit candidates (and the amount of received renown after a battle) are still encoded in the award</code> section of campaign's nodes (this is likely to become a little bit more random too in future versions). A sample fromassets/campaign_0.ron</a>:
initial_agents: ["swordsman", "spearman"], nodes: [ // . . . ( scenario: ( objects: [ (owner: None, typename: "boulder", line: None, count: 1), (owner: Some((1)), typename: "imp", line: Some(Front), count: 3), (owner: Some((1)), typename: "imp_bomber", line: Some(Middle), count: 2), ], ), award: ( recruits: ["spearman", "alchemist"], renown: 18, ), ), // . . . </pre> (Note to myself: Employ an "implicit_some</a>" RON extension.) Fighter costs and upgrade options are described in a assets/agent_campaign_info.ron</a> config, that looks like this: { "swordsman": ( cost: 10, upgrades: ["heavy_swordsman", "elite_swordsman"], ), "elite_swordsman": (cost: 15), "heavy_swordsman": (cost: 14), "spearman": ( cost: 11, upgrades: ["heavy_spearman", "elite_spearman"], ), "elite_spearman": (cost: 15), // . . . </pre> Recruitment cost consists of a basic type cost plus a group size penalty (the player's fighters count). The penalty is added because the intended size of the group is four to six fighters. The upgrade cost is just a difference between original and upgraded type costs. Now the campaign has some level of strategy: the player should think if it's better to recruit a new fighter or upgrade the existing ones. The player should never have enough renown to buy everything they want. As for the new fighter types, most of the current upgrades can be split into two "kinds": "Elite" fighters are generally faster, have more abilities and can use them more often. They feel overpowered at this iteration and most likely will be nerfed in next releases. </li> "Heavy" fighters are the opposite: they move slower (two move points instead of three), have fewer attack points, but deal more damage and have more health points. Later I will convert some of their extended health points into armor points, but this doesn't work atm, because there're no enemies, except for Imp Summoners, that can do anything with an armored fighter. </li> </ul> Basic fighter types were nerfed: fewer strength points, accuracy, abilities, etc, but are still useful. The idea is that the player should have fighters from all three kinds in their group: slow heavies are supposed to be used as devastating "iron fist", quick and agile elites are used for vanguard and flanks, and basic fighters are used to fight weak enemies or finish off wounded ones. Here are current "upgrade trees" (they have only one level for now, but I'm planning to add more nodes in future versions): spearman - still has 3 health points, "Jump" ability, and two-tile attack range, but lost one reaction attack, one accuracy, and one dodge point. Only useful for defense. elite spearman - has 4 health, one more accuracy and dodge points, and, most importantly, has an additional attack. The latter allows using him as the first fighter in a series of attacks, because he can move closer to enemies and instantly attack one of them from a safe distance, giving the initiative to the player.</li> heavy spearman - moves slowly, can't jump at all but has 5 health and deals 2 damage (that's a lot, considering his two-tile attack range). Still only useful for defense, but is very effective.</li> </ul> </li> swordsman - has 3 health points (lost one), lost one accuracy and doesn't have "Dash" and "Rage" abilities anymore (only "Jump"). elite swordsman - has the stats of an old swordsman: 4 health, more accurate and all three abilities: "Jump", "Dash", and "Rage".</li> heavy swordsman - slow and has no abilities at all but has 6 health, increased accuracy and greater attack damage (3).</li> </ul> </li> hammerman - has 4 health points and low accuracy. Lost "Heavy Strike" passive ability, but still have "Club" and "Knockback" abilities. heavy hammerman - slow, lost one attack point, but deals up to 5 damage, breaks up to 3 armor, has 6 health, a "Heavy Strike" passive ability and both "Club" and "Knockback" abilities. Can slay even a fully fresh imp summoner in a few strikes.</li> </ul> </li> alchemist - is a special type, because he can't attack directly. He lost all bombs except for the Push Bomb. Also, the cooldown of the "Heal" ability was increased. healer - heals more points with a 2 turns cooldown and can throw only Poison Bomb. Also, can do double moves in one turn for cases when the wounded fighter is on the other side of the map.</li> firer - can't heal anyone, but can do mass destruction by throwing exploding and fire bombs.</li> </ul> </li> </ul> (See objects.ron</a> for exact details.) As you can see, sometimes the upgraded versions lose some of their abilities. These upgrades are more like a specialization, not just an improvement: the fighter focuses on a smaller set of skills. I also try to make fighter's stats match their visuals so the situation described in this itch.io review</a> won't repeat: ... the most mobile unit in the game is the only one wearing heavy armor. Perhaps it'd be more fitting for the Hammerman to be in plate. </blockquote> Agent's Info Screen</h2> A basic fighter info screen was added: It's opened by clicking on a small [i]</code> button on the right from a fighter's type in the campaign menu: This screen allows the player to look up stats and abilities before recruiting or upgrading a fighter. Possession</h2> Another gameplay change is possessions: imp summoners can now possess imps to give them more action points for a few turns. The "Possessed" status is visualized with a yellow lightning status icon (read more about the status icons in the "Status Effect Icons" section below). On the beginning of their turn, possessed imp gets three additional Joker points (reminder: Jokers can be used as attack or move points and aren't removed when the agent receives damage). Possessed imps can run through the whole map, make a lot of attacks, and they won't stop on your reaction attacks until they're dead. So the player must look closely for potentially possessed imps and be ready to reposition fighters to form a lethal defense line: The idea is that the player should never be in a situation like when two possessed imps run towards a lonely and badly positioned fighter. Note: "Possession" looks like to be a bad name for one demon forcing a lesser demon to be more performing, so this ability and effect will likely be renamed in future versions. Visual Improvements</h2> There're many small visual improvements in this release. Current Tile Highlighting</h3> First, a tile under the cursor is highlighted now when using a mouse (it was requested by many playtesters). It makes no sense do this with touch inputs because the user will just constantly see the latest tile they touched, so the feature only works when input event's delta movement isn't zero. ^ Switching between mouse input and touch emulation in the web version Sprites Flipping</h3> Next, agent sprites are now flipped horizontally</a> to match their action's direction. Weapon flashes are also now flipped when needed. ^ A screenshot with both imps and humans faced left and right I've wanted to add this for a long time because previously humans were facing strictly to the right (imps - to the left) and sometimes they were attacking each other backward. To implement this enum Facing { Left, Right }</code>, a Sprite::set_facing</code> method, and a corresponding action::SetFacing</code> scene action were added</a> to the zscene</code> library. The implementation of Sprite:set_facing</code> is a little hacky atm. I was hoping to implement this method using only ggez's ggez::DrawParams</a>' scale</code> and offset</code> fields, but because of this bug</a>, it doesn't really work with custom screen coordinates that I'm using. So the method was implemented on zscene::Sprite</code>'s abstraction level using external offset. Dodge Animations</h3> It's hard to actually miss while attacking a static target with a melee weapon in real life. Most of the misses are caused by the targets dodging moves. So, simple target dodge animations when an attack misses were added to the game</a> to display this. ^ Dodge animations demo Move Interruption Message</h3> If any tile of a movement path is inside the attack range of an enemy agent with attack points, a reaction attack is triggered. If this attack succeeds the movement is interrupted. A move point (or a joker) is spent even if the agent hasn't actually moved anywhere: the starting tile is also considered a part of the path. This prevents agents from exiting a melee too easily ("Jump" and "Dash" abilities exist to counter this). I like this mechanic, but sometimes it wasn't clear to playtesters what just happened: they clicked on a tile, but were attacked and can't move anymore. A helper message is now shown</a> when an agent's move is interrupted. ^ A demo of a heavy swordsman's failed attempt to move away from an imp Frames</h3> From the beginning of the project I decided that I don't want to implement real smooth animations for agents: I don't like how 2D skeletal animations look in general and per frame animations are too hard to make. Quoting from the initial vision</a>: * Simple vector 2d graphics with just 3-5 sprites per unit; </blockquote> So the plan was to have a few situational sprites ("attacking", "taking damage", etc) per unit and use simple procedural animation to make the image more alive. It's a compromise between having real animations and only having totally static pieces. Some procedural animations (like "bumpy" walk</a> or blood splatters and dust</a>) were implemented in previous versions of the game, but all agents still used only one sprite. With this release, agents finally get special sprite frames for (some) abilities</a>! ^ A demo of special ability frames ("Rage", "Heal", and "Summon") For now, special frames are used only for the visualization of abilities. I've tried adding "attack frames", but they conflicted too much with weapon flashes and I decided that the game looks better without these frames. Though, it's likely that spearman will get special directional attack frames in the next versions</a> because he can attack enemies two tiles away from him and it looks weird with a completely static sprite sometimes because the spear is too far away from its target. Sprite sets are configured now with a sprites.ron</a> config that looks like this: { // ... "alchemist": ( paths: { "": "/alchemist.png", "throw": "/alchemist_throw.png", "heal": "/alchemist_heal.png", }, offset_x: 0.05, offset_y: 0.1, shadow_size_coefficient: 1.0, ), "imp_summoner": ( paths: { "": "/imp_summoner.png", "summon": "/imp_summoner_summon.png", }, offset_x: 0.0, offset_y: 0.15, shadow_size_coefficient: 1.3, ), // ... } </pre> The ""</code> (empty string) frame is considered the default frame. As the event visualizers don't know anything about specific agent types, the code usually checks if the sprite has some event-specific frame and only then adds an action node that will switch the sprite to that frame during its execution: let frame = "jump"; if sprite_object.has_frame(frame) { actions.push(action::SetFrame::new(&sprite_object, frame).boxed()); } </pre> Frames are stored inside the zscene::Sprite</code> struct like this: drawable: Option<Box<dyn Drawable>>, drawables: HashMap<String, Option<Box<dyn Drawable>>>, current_frame_name: String, </pre> I didn't want to index a HashMap with a string for every sprite on every frame, so the current frame lives in a special field drawable</code> and everything is stored as options to simplify frame swapping. Explosion Ground Marks</h3> To make the battlefield look more interesting decorative explosion ground marks were added: Same as blood, they're slowly disappearing into transparency in three turns to avoid making the battlefield too noisy and unreadable. It looks boring when there're many similar big explosion mark sprites on the battlefield, so in future versions there should be something like 3-5 randomly chosen versions of this sprite (#531</a>). Status Effect Icons</h3> Icons for lasting effects were added</a> so the player can quickly see a more detailed game state info: There're three lasting effects atm: If there's more than one lasting effect applied to one agent, icons are stacked vertically: The icons are twice the size of brief info dots because they're more detailed. External Contributions</h2> There were a few PRs from external contributors: by @debris</a>: "Bump ggez to version 0.5.0-rc.2"</a>;</li> "Highlight buttons on mouse over"</a>;</li> "Load sprites from sprites.ron file"</a>;</li> </ul> </li> by @ltfschoen</a>: "docs: Fix logic of insert within zcomponents"</a>;</li> "Update readme with instructions to add missing dependencies"</a>.</li> </ul> </li> </ul> Thanks, folks! Other Changes</h2> AIs of the Summoner and Bomber imps were tweaked</a> to keep shorter distances because chasing summoners through the whole map with slow heavy fighters is just boring.</li> The "Explosion Bomb" ability was balanced: explosions now destroy armor</a>. This was done to balance this ability with a "Fire Bomb".</li> The "Club" ability was balanced</a>: its duration was educed and the "Fly Off" effect was removed. This was done to better differentiate it with the "Knockback" ability.</li> A mostly empty rustfmt.toml file was added</a> to the repo (to explicitly document the desired formatting</a>).</li> I added a new "Inspiration" section</a> to the README with a list of games that inspire(d) Zemeroth.</li> </ul> Text Logo</h2> The game now has a (temporary?) text logo: The image was manually re-drawn (in a low-poly style similar to game's angular sprites) from a text written in the "Old London"</a> font. Not sure if it really fits the game - surprisingly many people say that it looks like something related to Death Metal and not just a generic medieval font - but it'll do for now. Spreading the Word</h2> I've got the ozkriff.games</a> domain and moved my devlog to it</a>. This is my first domain and the buying process turned out to be not nearly as scary as I was expecting. I revived my Patreon page: patreon.com/ozkriff</a>. I also created new social pages (in addition to twitter</a>): fb.com/ozkriff.games</a></li> vk.com/ozkriff.games</a> (ru)</li> </ul> ... and a bunch forum threads and database pages (in addition to itch.io</a>): tigsource</a></li> indiedb</a></li> users.rust-lang.org</a></li> gamejolt</a></li> gamedev.ru</a> (ru)</li> </ul> The initial plan was to post weekly updates to Patreon, forums, and catalog pages but as that experiment was canceled (see the preface) I most likely will just post links to new version announces there. Let's hope that this will motivate me to make smaller releases more often. :) About Devlog Videos</h2> As written in the preface, new devlog posts will be complimented with their video versions for folks who prefer consuming information in a more dynamic audio-visual form. I don't have any experience with making of such videos (I've been only making GIFs and short gameplay videos) so I'm learning this stuff as I go along. I see it as a part of game development, so it makes sense to add a few notes about my current routine to the devlog. Ideally, I'd like to do record a live demo without a strict script, but speaking to the camera when you're not used to it is quite stressful and additionally I'm not quite comfortable with English. I've tried a few times to record the whole video "live" in one piece and it totally failed for me. So, I prepare a script (by adapting a text post a little bit) and read it out (usually, one section at a time). I don't have any external mic and just use a simple headset for now (as clearly can be seen from the video). I use Audacity</a> to do the recording and to filter out most noticeable background noises</a>. Then, I record short intro and outro clips using my phone's (its camera isn't perfect, but still much better than my laptop's webcam) to personalize the voiceover a little bit. GIFs from the post can't be reused for the visualization because they're too small, so I go through the script and use SimpleScreenRecorder</a> to record a lot of screen clips. I'm using Kubuntu as my main OS, so the natural choice for a video editor is Kdenlive</a>. Its UI feels a little bit clunky, but docs are fine and it seems to do all the basic stuff that I need: cut/match the video clips to the voiceover and add some background music. Finally, I prepare and add subtitles. There're at least three reasons to do this: accessibility, my terrible English pronunciation, and translation (to Russian). Again, KDE software seems to do the job fine: I just add the script to KDE Subtitle Composer</a> line by line and tweak the timings a little bit. And that's it, the video is done and can be uploaded to YouTube</a>. I'm not completely happy with the quality of the 0.6 announcement video, but I guess it's only a question of practice. That's all for today, thanks for reading! Here's Zemeroth's roadmap</a>, if you want to know on what I'm going to work next. If you're interested in Zemeroth project you can follow @ozkriff on Twitter</a> for fresh news or subscribe to my YouTube channel</a>. Also, if you're interested in Rust game development in general, you may want to check @rust_gamedev on Twitter</a>. Discussions of this post: /r/rust</a>, twitter</a>.

Zemeroth v0.5: ggez, WASM, itch.io, visuals, AI, campaign, tests Mon, 13 May 2019 00:00:00 +0000 Hi, folks! I'm happy to announce Zemeroth v0.5. Main features of this release are: migration to ggez, web version, itch.io page, campaign mode, AI improvements, visual updates, and tests. Zemeroth</a> is a turn-based hexagonal tactical game written in Rust. You can download precompiled v0.5 binaries</a> for Windows, Linux, and macOS. Also, now you can play an online version</a> (read more about it in the "WebAssembly version" section below). </blockquote> The last release happened about a year ago. Since then the development mostly happened in irregular bursts, sometimes it even was completely stalled for weeks. But a year is a big period of time anyway, so there're still lots of changes. Lots of text ahead, feel free to skip sections that you're not interested in particularly. Here's a table of contents: Migration to the ggez</code> Game Engine</a></li> WebAssembly Version</a></li> itch.io</a></li> Visual Improvements</a></li> Campaign Mode</a></li> Hit Chances</a></li> Armor</a></li> AI Updates</a></li> Bombs and Commutative Effects</a></li> Other Game Rules Changes</a></li> Gameplay Video</a></li> SVG Atlas</a></li> Assets Hash</a></li> Tests</a></li> Other Technical Changes</a></li> Indikator</a></li> Migrated This Devlog to Zola</a></li> Roadmap</a></li> </ul> Migration to the ggez</code> Game Engine</h2> An experiment with maintaining my own engine (even a simple and minimalistic 2D one) turned out to be too exhausting in practice: you have to fight a constant stream of reports about small corner case issues and deal with platform-specific tweaks and hacks (stuff like this</a>, for example). It can consume surprisingly large amounts of time. But what's more important for a hobby project, it also sucks too much fun out of the development process. And what made it worse in my case is that Häte2d</a> intentionally wasn't a general-purpose game engine (to reduce the scope of work), so it was sad to know that all this work won't be reused by anyone. But converting Häte into a real general-purpose engine wasn't an option either, because it wouldn't have left any time for Zemeroth's development. So I've surrendered and decided to give away some control over low-level parts of Zemeroth: Häte2d was discontinued</a> and replaced by ggez</a>, the most mature and actively developed Rust 2d game engine at that time. häte</code> had some built-in basic scene management</a> and GUI</a> systems, but ggez is minimalistic by design and has none of this. So, two helper crates were extracted from Häte2d and rebuilt on top of ggez: ggwp-zscene</a> is a simple scene/declarative animation manager that provides: Sprites with shared data;</li> Scene and Actions to manipulate sprites;</li> Simple layers;</li> </ul> </li> ggwp-zgui</a> is a tiny and opinionated UI library: Provides only simple labels, buttons and layouts;</li> Handles only basic click event;</li> No custom styles, only the basic one.</li> </ul> </li> </ul> Since Icefoxen asked not to use ggez-</code> prefix</a>, I used ggwp-</code> ("good game, well played!") to denote that the crate belongs to ggez's ecosystem, but is not official. These helper crates are still tied to Zemeroth, not sure how helpful these libraries can be for a project that is not Zemeroth-like. But maybe someone will manage to extract some benefit from them. These crates are still immature and aren't published on crates.io yet, while the rancor</code> component library was renamed to zcomponents</code> and is published</a>. Initially, I migrated to ggez v0.4 that was SDL2-based. But as soon as the first release candidate of winit</a>-based ggez v0.5 became available I attempted to migrate to it. I've filed a bunch of mostly text-related issues in the process</a> and tried to fix the most critical ones for Zemeroth: "Remove the generic argument from Drawable::draw"</a>, "Drawable::dimensions()"</a> (big one!) and "Fix Text::dimensions height"</a>. These PRs took some time, but then I relatively easy ported Zemeroth to ggez v0.5.0-rc.0</a>. ggez v0.5 isn't released yet, so at the moment Zemeroth uses ggez 0.5.0-rc.1</code>. It's stable enough for me. Before the migration, I was using cgmath</a>, because it's a simple and straightforward library. But ggez's "native" math library is nalgebra and even though ggez v0.5 uses mint</code> types for all its public API, I still migrated to nalgebra, because of this</a>. One downside of the migration to ggez is that debug builds are much slower now because more code is pure Rust. Something like 3-5 FPS on my notebook. But it's ok, I don't need debug builds often, I prefer debugging through logs anyway. And when I really need a debug build to track down something extremely strange, I can use cargo's yet unstable feature "profile-overrides"</a>. cargo-features = ["profile-overrides"] [profile.dev.overrides."*"] opt-level = 2 </pre> Another serious downside of the engine switch, though temporary (?)</a>, is that there's no native Android version of the game for now. But who really needs a native port when you have... WebAssembly Version</h2> After ggez v0.5-rc.0 was published, Icefoxen has posted "The State Of GGEZ 2019"</a>, where among other things he wrote that a web port is unlikely to happen soon because a lot of issues in dependencies need to be fixed first. It could be relatively easy to write a specialized web backend for ggez, but ggez's philosophy is against having multiple backends. And that's where Fedor @not-fl3</a> suddenly comes in with his good-web-game</a> WASM/WebGL game engine. He had been experimenting with 2d web prototypes (like this one</a>) for some time and used a custom 2d web engine for this. The API of this engine was heavily inspired by ggez so he managed to write a partly ggez-compatible wrapper in a weekend. Colors are slightly off and text rendering is a little bit different, but otherwise, it works nicely and smoothly, providing the same experience: </a> Zemeroth uses good-web-game for its web version as a quick-n-dirty immediate solution until a proper WASM support arrives to GGEZ (there're no plans of making good-web-game some kind of official GGEZ backend or anything like this). The currently implemented subset of ggez's API is quite limited and while it may be used for other games, it will probably require a lot of work to do. You can't use crate renaming in Cargo.toml</code> to reuse a name on different platforms, # Cargo.toml with these dependencies wouldn't build: [target.'cfg(not(target_arch = "wasm32"))'.dependencies] ggez = "0.5.0-rc.1" [target.'cfg(target_arch = "wasm32")'.dependencies] ggez = { git = "https://github.com/not-fl3/good-web-game", package = "good-web-game" } </pre> So the crate substitution hack is done in main.rs</code> using extern crate</code> items in main.rs</code>: #[cfg(not(target_arch = "wasm32"))] extern crate ggez; #[cfg(target_arch = "wasm32")] extern crate good_web_game as ggez; </pre> 99.9% of code stays the same, but I had to use a separate main, because good-web-game has a different initialization API: #[cfg(target_arch = "wasm32")] fn main() -> GameResult { ggez::start( conf::Conf { cache: conf::Cache::Index, loading: conf::Loading::Embedded, ..Default::default() }, |mut context| { let state = MainState::new(&mut context).unwrap(); event::run(context, state) }, ) } </pre> Finally, a short helper script utils/wasm/build.sh</code> was added: #!/bin/sh cp -r assets static cp utils/wasm/index.html static ls static > static/index.txt cargo web build </pre> cargo-web</a> only packs a static</code> directory (it's hardcoded), so the script copies the game's assets there;</li> the index.html</code> template page is also copied there;</li> all assets should be listed in index.txt</code> for good-web-game to be able to load them, so this file is created;</li> </ul> You can find a minimal example of good-web-game here</a>. itch.io</h2> The web version needs to be hosted somewhere. itch.io</a> is a nice place for this: ozkriff.itch.io/zemeroth</a> it has a nice and simple UI (for both developers and consumers), it's extremely easy to upload a web game there</a> and it's a relatively known store for indie games that can provide some exposure by itself. </a> (Zone of Control also got an itch.io page</a>) Note an "Enter fullscreen" button in the bottom right corner of the game area: As I've said in the ggez section above, the web version of the game seems to work fine on most mobile devices: With a playable version only a click away I received a lot of fresh feedback: a lot of people that previously were only following the development now actually tried to play the game. The most important things people want to see improved are: Improve the GUI: Replace text buttons with icons, show some tooltips, etc;</li> Add a tutorial or at least a short guide;</li> Randomness is too frustrating: missed attacks should result in some little positive effect, like pushing enemies back or reducing their stamina;</li> The game lacks ranged attack units, like archers or knife throwers.</li> </ul> @Yururu even wrote a giant comment</a> on the itch page! It's inspiring when a stranger from the internet breaks through the crude primitive interface, figures out game mechanics on a quite deep level, and writes a detailed review of their experience and thoughts. I've created an itch.io list of Rust games</a>. When I find a Rust game on itch.io I add it there. Also, I've sent a request to itch.io folks to add Rust as an instrument, so now a more official list is available: itch.io/games/made-with-rust</a> (you can edit a game's instruments here: "edit game" -> "metadata" -> "engines & tools"). Looks like my original list will be deprecated with time but it's still useful for now because only authors of the games can add an instrument to the metadata. Visual Improvements</h2> The initial draft</a> of the new sprites looked like this: Tiles are flattened now. It's less a schematic top-down view as it was before. "Camera" is moved to the side so the tiles and agents are shown using the same projection. There're many gradients in the mockup image above. Later I decided to get rid of all the gradients and curvy lines and stick with "pseudo lowpoly" style. Floating Eye and Insecto-snake agent types from the mockup haven't made it to the master yet. All objects now have a shadow. It makes the image a little bit more tangible. Walk and especially throw animations feel better now. Initially, shadow was an ellipse with gradient. Later it was replaced by two semi-transparent hexagons for style consistency. Added blood splatters and weapon flashes</a> to make attacks more dramatic: The number of drops depends on the attack's damage. Blood slowly disappears into transparency in three turns, otherwise, the battlefield would become a complete and unreadable mess. Every agent now has WeaponType</code>: "smash", "slash", "pierce", and "claw". For now, they are just visual information. They affect only what sprite is used during the attack animation. Same as agent sprites, weapon flash sprites are not yet mirrored horizontally. That is most noticeable with curvy smash sprite. Also, spearman's "pierce" weapon sprite is horizontal and it looks weird during vertical attacks. Either multiple sprites are needed or it should be rotated. Added a Dust effect</a> (for jumps and throws): It is created by a simple function that just emits a bunch of half-transparent sprites and attaches position and color change actions to them. Sprites' size, velocity, and transparency are a little bit randomized. Campaign Mode</h2> A basic campaign mode was added. It's just a linear sequence of battles with predefined scenarios. After each battle, your survived fighters are carried over to the next battle. If you lose a battle - the campaign is over for you. If you win a battle, you're shown a transition screen with a list of your dead fighters, your current squad, and possible recruits: The campaign is defined by a RON</a> config file with this structure: initial_agents: ["swordsman", "alchemist"], nodes: [ ( scenario: ( map_radius: (4), rocky_tiles_count: 8, objects: [ (owner: Some((1)), typename: "imp", line: Front, count: 3), (owner: Some((1)), typename: "imp_bomber", line: Middle, count: 2), ], ), award: ( recruits: ["hammerman", "alchemist"], ), ), ( scenario: ( rocky_tiles_count: 10, objects: [ (owner: None, typename: "boulder", line: Any, count: 3), (owner: None, typename: "spike_trap", line: Any, count: 3), (owner: Some((1)), typename: "imp", line: Front, count: 4), (owner: Some((1)), typename: "imp_toxic", line: Middle, count: 2), (owner: Some((1)), typename: "imp_bomber", line: Back, count: 1), (owner: Some((1)), typename: "imp_summoner", line: Back, count: 2), ], ), award: ( recruits: ["swordsman", "spearman", "hammerman"], ), ), ] </pre> Here's some real campaign scenario: campaign_01.ron</a> There's a known bug that you can exit from a battle that is not going well at any moment to start again. This will be forbidden - permadeath is the only way :) . Hit Chances</h2> In the previous version of Zemeroth the hit chance was always 50%. Now, attack_accuracy</code> and dodge</code> stats were added to the Agent</code> component to implement a basic hit chances math</a>. When you select an agent that can attack (has an attack point and enemies in range) a hit chance is shown over all available targets: During the attack animation, a hit chance is shown near the attacker with a smaller font. This was added in order for the player to see how dangerous enemy attacks are. Also, wounded agents now become less accurate. Each lost strength point results in -10% hit chance penalty (up to -30%). Missing strength points (wounds) are shown by almost transparent green dots: This gameplay change has two game balance consequences: Now it's more important to wound enemies, finishing them off is a lower priority most of the time. Sometimes wounded enemies even can be helpful to the player, because they are not a real threat to player's fighters, but can block the path for other enemies;</li> Alchemist's "heal" ability became important because your agents are less useful when wounded too.</li> </ul> Also, attacks with strength > 1 have additional hit chances - with reduced damage (each attack strength point gives 10% hit chance improvement). This emulates the situation when an attacker barely touches their target but still manages to make some damage to it. Armor</h2> A basic armor system was implemented. Armor points are shown above the agent in one line with strength points using the yellow dots. Each armor point deflects one damage point on each attack. Some weapons can break armor (the attack_break</code> parameter). Fire and poison ignore armor. Here's a little demo: an imp can't break armor so he can't deal any damage to the heavy swordsman;</li> toxic imp can't deal any direct damage but he poisons the swordsman ignoring the armor;</li> insecto-snake destroys the armor with a powerful attack.</li> </ul> In the current version of the game only imp summoners have armor, so be careful with them. AI Updates</h2> Now, enemies always act in order of remoteness from a player's fighters</a>. This way melee imps don't trip over each other too much. </li> AI learned to avoid walking into spikes, fire and poison clouds. </li> AI now moves closer to its targets even if there's no direct path to them (full demo video</a>): </a> </li> Non-melee imps (bombers and summoners) are now trying to keep distance from the player's fighters in range</a>. They need to avoid melee fights but still be able to throw bombs at a player's fighters or summon new imps near the frontline. Summoner has a slightly greater min/max range than bomber. </li> </ul> During the debugging of the above-mentioned features, I also wrote a simple helper function dump_map</code></a> that takes a closure and dumps required map data as a char</code> in the above GIF, pic 1 shows objects (A</code> - an agent, O</code> - a non-agent object) and pic 2 shows available positions (X</code>). Bombs and Commutative Effects</h2> ^ In the previous version of Zemeroth, each of these bombs would have exploded at the beginning of the next turn in order of their creation. But this order is hard to remember and it's not clear from the picture at all. The order is very important as the explosions push back objects - if the first explosion is on the left, an agent will be damaged by the right bomb too. Pushback is not the only possible effect suffering from this. Other possible examples of non-commutative effects</a>: teleportation, armor-breaking acid, immunity to damage, etc. Anything where changing the order of application can change the final state. I see two possible ways to solve this: "Into the Breach"</a>-like approach with explicit numbers;</li> Forbid non-commutative delayed effects.</li> </ol> ItB's approach means just adding this order information explicit in the game's interface. It looks like this: </a> Technically it's possible, but I don't think that it fits for Zemeroth because it's an extremely noisy interface feature, but it's not really a core mechanic. So, I've taken the latter way</a>: the "Bomb" ability was split into two abilities: instant "BombPush" and delayed "BombDamage". The plan is to have three groups of objects with effects: Objects with immediate effects - can have non-commutative effects;</li> General objects with timed effects - only commutative effects allowed;</li> Special rare timed objects - can do whatever they want, but only allowed as unique boss abilities, work in their own special phase.</li> </ul> Other Game Rules Changes</h2> Spike traps were added. They're almost like fire tiles, but permanent. </li> Updated</a> "Poison" passive ability: it can’t, by itself, kill an agent anymore. “Poisoned” status is removed when a target’s strength is reduced to 1. This should make battles a little bit less frustrating and more dramatic. </li> Updated the "Summon" ability: Each agent is now treated individually</a>. The new code treats each summoned agent individually thus preventing summoning weird packs of same imp types. Each use of the "Summon" ability now creates one more imp</a>. It forces the player to play more aggressively. Changed the summoning algorithm to prefer imp types that are under-presented on the map</a>, not just random ones. Seems to work fine now - even with increased summon rate imp types are balanced in count: pic</a>. </li> Randomly-placed agents are not created point-blank to their enemies anymore</a>. </li> Also, randomly-placed objects are now created on different Line</code>s</a>. This prevents Imp Summoners from being created only a tile away from enemies and thus not having any chances to survive. Or Imp Bombers being instantly tied with a melee fight. A line is defined in the scenario files: (owner: Some((1)), typename: "imp", line: Front, count: 4), </pre> There're four possible values: pub enum Line { Any, Front, Middle, Back } </pre></li> </ul> Gameplay Video</h2> So, putting these gameplay changes together: </a> This is a piece of a campaign mode playtest: battles 3, 4, and 5. SVG Atlas</h2> Back to more technical updates. As git is bad at storing non-text files and it's practically impossible to use Git LFS</a> with a free GitHub plan (because of the bandwidth limitations</a>), it looks like a good idea to keep text source files, assets source files, and built assets in separate repositories to make "optimization history editing" (removing old commits) easier. The main repo</a> and the assets repo</a> already existed, but I wasn't storing assets source files in any VCS. So, during v0.5 development, I've created another repo for assets sources: ozkriff/zemeroth_assets_src</a>. The two key files of this repo are: atlas.svg</a> and export.py</a>. The atlas contains all sprites in one file. Each sprite is stored as a named group. As the game isn't that much art heavy, using one file for all visual assets looks fitting, because of it: simplifies sharing parts of sprites and mockups creation;</li> avoids complications of linking/embedding multiple SVG files together (you need to manually edit XML do to this properly as far as I know).</li> </ul> The export script is quite simple, it just calls Inkscape using its CLI interface and tells what named group needs to be exported to PNGs. It boils down to: for id in ['imp', 'imp_toxic', 'grass', ...]: subprocess.run([ 'inkscape', input_file_name, f'--export-id={id}', f'--export-png={out_dir_name}/{id}.png', ], check=True) </pre> There's also a hack to avoid specifying exact sprite PNG sizes as raw numbers in the export script: each named group contains an invisible square (a rectangle for terrain tiles). It can be temporary made slightly visible for debugging purposes: </a> Assets Hash</h2> Another technical assets-related update is that a md5 hash check was added. This should help to detect when someone who is building from source forgets to update the assets. A small checksum.py</a> python script is used to calculate the hash of all non-hidden files in the repo. CI uses it to check</a> that the committed hashsum really corresponds to the committed assets. The expected hash is hardcoded directly into main.rs</a>. If the game is run with a wrong version of assets, now you get a clear error message about that: Bad assets checksum abcdeabcdeabcdeabcdeabcdeabcdeab (expected 18e7de361e74471aeaec3f209ef63c3e) </pre>Tests</h2> One of the benefits of making a turn-based game is that you can relatively easy separate the logic from the visuals and cover the former with tests. A few test scenarios were added</a>. They are completely deterministic. Randomness is mitigated with special agent types with unrealistic stats (for example, accuracy = 999</code> or strength = 1</code>), that allows them to always pass required tests (for example, always hits or always dies on the first hit), and an additional no_random</code> flag in the game state, that causes a panic if agent's stats during the "dice roll" may result in non-determined results (basically, it checks that the coefficients are large or low enough to shut off any dice value fluctuations). "Exact objects" were added to the scenarios. Test scenarios mustn't contain any randomly-placed objects, otherwise the no_random</code> debug flag will cause a panic. Basic test looks like this: #[test] fn basic_move() { let prototypes = prototypes(&[ ("mover", [component_agent_move_basic()].to_vec()), ("dull", [component_agent_dull()].to_vec()), ]); let scenario = scenario::default() .object(P0, "mover", PosHex { q: 0, r: 0 }) .object(P1, "dull", PosHex { q: 0, r: 2 }); let mut state = debug_state(prototypes, scenario); let path = Path::new(vec![ PosHex { q: 0, r: 0 }, PosHex { q: 0, r: 1 }, ]); exec_and_check( &mut state, command::MoveTo { id: ObjId(0), path: path.clone(), }, &[Event { active_event: event::MoveTo { id: ObjId(0), path, cost: Moves(1), } .into(), // small formatting issue, see a note below actor_ids: vec![ObjId(0)], instant_effects: Vec::new(), timed_effects: Vec::new(), scheduled_abilities: Vec::new(), }], ); } </pre> (I didn't use the builder pattern for event construction, even though most of the time two or three its fields are empty vectors, because I've faced some method chains formatting issues</a>) Test scenario consists of a list of commands and a list of expected events. Occasionally, it can check some parts of the state. A prototypes list and a scenario are created from scratch (though, with some helper functions) for each test. It takes more lines of code than reusing a small set of multi-cases scenarios, but the idea is that this way the amount of objects and components in each test is minimized. This way it's easier to diagnose the bug and makes tests less likely to break on unrelated game logic change. A "dull" enemy agent is required only for the scenario not to end instantly. Because the win condition is when no enemy agents are alive. colin-kiegel/rust-pretty-assertions</a> is a super-useful crate when you need to debug failing assert comparisons of big hierarchical objects (some of which may be many screens long in my case). One peculiarity is that I had to replace all HashMap<ObjId, Vec<Foo>></code> in events with Vec<(ObjId, Vec<Foo>)></code> to preserve the order. Otherwise pretty-assertion has been exploding. Other Technical Changes</h2> Moved all crates to Rust 2018</a>;</li> Added a note about 'help-wanted' issues</a>;</li> Used derive_more::From</code> for enums and errors;</li> Migrated to std::time::Duration</code></a> and added time_s</code> shortcut/helper function;</li> Removed</a> some data duplication from the .ron</code> config with objects descriptions</a> using serde`s default annotations and helper init functions;</li> Added a windows_subsystem</code> attribute</a> to hide cmd window on Windows;</li> Fixed panic when a boulder is pushed into fire/spikes</a>;</li> Mergeed all 'line_height' consts and functions</a>;</li> Removed data duplication from objects.ron</code></a>.</li> </ul> Indikator</h2> Gave a presentation about Zemeroth</a> at 8th Indie-StandUp at Indikator</a>. It went pretty good, local indie devs seemed to like the project, especially considering that it's opensource and uses an interesting tech. At least one of the devs has visited our local rustlang meetup</a> afterward. 🦀 It's unrelated, but Zemeroth was mentioned on Amit's page about hex math</a>. Migrated This Devlog to Zola</h2> During the preparation for this Zemeroth release, I've finally</a> switched the static site generator behind this devlog from Python-based Pelican</a> to Rustlang-based Zola</a>. Here's a twitter thread</a> with some migration notes. TLDR is that I've mostly automatically converted all RestructuredText post sources into Markdown, replaced Disqus comments</a> with direct links to reddit/twitter/etc, set up redirects from old URLs. Roadmap</h2> What's next? Some things I hope to implement for v0.6 release are: Replace the text buttons with icons</a>;</li> Reduce text overlapping</a>;</li> Add sound effects and music</a>;</li> Add fighters upgrade trees</a>;</li> </ul> You can find a slightly more detailed roadmap in the project's README</a>. That's all for today, thanks for reading! If you're interested in this project you can follow @ozkriff on Twitter</a> for more news. Also, if you're interested in Rust game development in general, you may want to check @rust_gamedev</a> twitter account that I've started recently. Discussions of this post: /r/rust</a>, twitter</a>. Zemeroth v0.4: Abilities, Lasting Effects and New Unit Types Sat, 03 Mar 2018 00:00:00 +0000 Hi, comrades! I'm happy to announce Zemeroth v0.4. Zemeroth</a> is a turn-based hexagonal tactical game written in Rust. You can download precompiled binaries for Windows, Linux, macOS and android here: releases/tag/v0.4.0</a> This release adds ~2k lines of code</a> - a lot of new features! And it's hard to describe all the stuff only with words and static images so this time I'll try to use more GIFs (btw, Peek</a> is a cool app for fast gif recording). I hope that they won't cause too much problems for the readers. NOTE: Most of the GIFs were recorded on a map of 7 tiles wide, but the actual map is 11. See youtube video in the middle of the article for some real gameplay. Simple walking animation</h2> The first and simplest change is simple walking animations. Compare: That's just a small visual improvement but it makes the game more lively. Gameplay Updates</h2> Wounds reduce attacks by one</h3> New rule: every successful attack now reduces target's attack by 1. It's small but important change because it increases the value of initiative and is relied upon by many abilities. Strong Attacks</h3> In the previous version all attacks were dealing 1 damage. Now, Swordsman and Hammerman (see below) deal 2 damage points per hit. Abilities</h3> Abilities is the main feature of this release. They come in two flavours: active and passive: Each active ability activation requires either Attack (red) or Joker (purple) point and can trigger enemy's reaction attack. Most abilities have cooldowns of 2 or 3 turns long. </li> Passive abilities don't require any action points and are activated automatically: during attacks or at the begining of the turn, for example. </li> </ul> Particular abilities are explained in unit sections below. New Unit: Toxic Imp</h3> Let's start with something simple. This enemy is similar to basic Imp, but does no direct damage and has Poison Attack passive ability. Poisoned unit receives one would at the begining of each turn. Note that poison also takes away one attack from the victim, weaking it even more. Poison reduces attacks of poisoned unit by one. Toxic Imp also has no reaction attacks as he's dangerous enough without them. New Unit: Imp-Bomber</h3> Poison is cool, but it doesn't really changes the game much. One obvious problem of v0.3 was turtling</a> - no movement, boring. Reaction attacks encourage defensive playstyle. So a new unit was added: Imp-Bomber. ^ He has an active ability Bomb and a very simple AI that tries to use it, if it's available, and then acts as a normal Imp. Bombs with delayed detonation is a classic way to help with this. Bomb explodes on the next turn and damages everyone around, knocking them back for one tile. NOTE: As Imps are stupid they can be easily damaged by their bombs. Use it. This enemy doesn't allow you to stay in a good position without movement. But you still can sometimes move back and forth, so... New Unit: Imp-Summoner</h3> ...Soo, meet Imp-Summoner! This unit summons so many imps so the only way to stay alive is to rush and attack him while summoned imps are still weak. Summoners are your main targets. ^ Summon ability creates three imps of a random type. NOTE: Actually, the plan is to make each summon activation even more powerful: call 3-4-5-6 imps, to increase the pressure over time. Summoner is slow - сan either move one tile or attack/cast during his turn - but he has a lot of strength (health) points and has Heavy Impact and Regeneration passive abilities: ^ Regeneration restores one strength point in the begining of every turn. Heavy Impact throws opponents one tile away on every hit (FlyOff effect). New Unit: Alchemist</h3> Let's move to player's new units: meet the first one - Alchemist. He's a support unit and has no direct attacks, but has a bunch of useful abilities. Basic Bomb ability works the same way as it does for Imp-Bomber. Fire bomb and poison bomb are a little bit more interesting: ^ Fire object just deals one damage point each turn to anyone standing in the same tile or to anyone walking through it. ^ Poison cloud object acts similar to fire, but it casts Poisoned effects on agents. This effects deals one point of damage each turn and lasts for two turns. Both fire and poison cloud objects disappear after two rounds. Note that damage from fire and poison also removes attacks from target - this can protect your alchemist in tough situations. Alchemist has one more useful ability: Heal can restore two strength points and remove any lasting effects: New Unit: Hammerman</h3> Slow but powerful unit. His attack deals 2 damage points and he has HeavyImpact passive ability (same as Summoner, see above). ^ Club ability causes Stun lasting effect and FlyOff. Stun lasting effect removes all attacks/moves/jokers from the target for one round. ^ These abilities can be used to move bombs and boulders too. You can push enemy into fire, poison or bomb. Or you can push some other your figher out of danger if needed. Updated Swordsman</h3> Swordsman also got a few updates. His main attack now also deals two points of damage. ^ Rage ability gives a lot of attacks but has a long cooldown, so you need to choose carefully when to use it. ^ Jump ability - think about Diablo's Barbarian (future versions of the ability may get stunning effect ;) ). ^ Dash ability allows you to move one tile without triggering reaction attacks. Allows you to start the attack or to escape from the enemies. It may be hard to escape from a bad position witout Dash or Jump ability: Dash can be combined with Rage and Jump abilities to perform a series of attacks and return back to safety: Updated Spearman</h3> Also got a Jump ability, but of a different flavour: three tiles distance and three turns cooldown. So it's mostly useful for escaping: Gameplay Video</h2> So, putting this all together: </a> It starts reminding something like a real game, isn't it? :) Though a lot of work is still need to be done. Implementation note: RON v0.2</h2> RON v0.2</a> added unwrap_newtypes</code> extension that seriously simplified my config files by getting rid of a lot of braces: Thanks, @Torkleyy! That's all for today, I have to go play Into the Breach</a>! :) Discussions: /r/rust</a>, twitter</a>. Zemeroth v0.0.3: Jokers, Rancor, Blood and more Fri, 01 Dec 2017 00:00:00 +0000 Hi, comrades! Welcome to the second issue of Zemeroth's devlog. Zemeroth</a> is a turn-based hexagonal tactical game written in Rust. It slowly grows into a middle-sized project: Zemeroth</a> has 4.3k LoCs</a> and 82🌟 now. Though I still can't find enough free time to work on it on daily basis and I have to take weeks-long breaks sometimes. So, the progress is quite slow 🐌 but still, I've managed to do some amount of useful stuff during last three months. Here's a short video of how the game looks right now: </iframe></div> Ok, let's talk about what exactly have I done for the project during this autumn. Pre-built binaries</a></h2> The most important change for anyone who wants to try out Zemeroth and don't want to compile it from the source is auto-deployed pre-built binaries. You can download them here: zemeroth/releases</a> They are compiled and deployed to Github's releases by CI servers (Travis, Appveyor and CircleCI) on every tag. The latest release at the time of writing is v0.0.3</code></a>: </a> Linux/Windows and OSX versions are not that interesting - they are built exactly like it was done for ZoC</a>. Deploying Android apk</code>s is a more interesting story. I've stolen basic apk-building script for CircleCI from @tomaka</a> (thanks again!) - https://github.com/tomaka/glutin/pull/919</a> - and it worked straight out of the box. Deploying apk</code>s is harder: circle-ci doesn't provide a built-in convenient way of deploying to Github, so you have to wield some curl/github_api magic. All the magic is packed in .circleci/upload_apk_to_github_releases.sh script</a> (which is based on this gist</a>). Also, some strange branch magic is required</a> if you don't want to run both build</code> and deploy</code> targets on every commit. Btw, old badges were not that clear of what do they mean: Most programmers know that travis's badge usually means Linux/OSX builds and appveyor is for Windows builds. But what does the third one? To fix this I've added custom labels to the badges through shields.io</a>: https://img.shields.io/travis/ozkriff/zemeroth/master.svg?label=Linux|OSX https://img.shields.io/appveyor/ci/ozkriff/zemeroth.svg?label=Windows https://img.shields.io/circleci/project/github/ozkriff/zemeroth/master.svg?label=Android </pre> Looks a little bit better now: And there're two yet-to-be-solved issues: apk</code>s are built in the debug mode</a></li> Deploy precompiled versions of the latest commit to a special release</a></li> </ul> Decorations: Grass and Blood Pools</h2> The Grass</a> is just a randomly-placed decoration, but Blood Pools</a> are also an additional indicator of a successful attack: Jokers and Strength</h2> Now, some actual gameplay changes! To make Zemeroth a little bit more tactical Jokers were added</a>. They can be used either as Attacks or Moves. In the previous version, units were dying from a single hit. That doesn't work well with reaction attacks as they were dying too quickly: fighters should have some kind of basic hit points. So Strength was added.</a> This name is stolen from Banner Saga</a>: as I'm going to use this property also as a basic attack modifier. Right now every successful attack deals a damage of one strength but later a much more fine-grained battle math will be implemented. Dots</h2> To show the most important dynamic information about units on the map "Dots" were added</a>. The current legend is: "Strength" - green;</li> "Attacks" - red;</li> "Moves" - blue;</li> "Jokers" - purple.</li> </ul> @LPGhatguy</a> pointed me out on twitter</a> to a problem with colors: With the amount of red/green in the game so far, you should try it with a Deuteranopia filter! </blockquote> I've googled a simulator: etre.com/tools/colourblindsimulator</a>. Here's an example of its output: And, yeah, that doesn't look readable at all. It's clear that I should change the colors and shapes</a> in the near future. Btw, http://gameaccessibilityguidelines.com</a> is a very interesting resource. I've never thought about a lot of issues raised and explained there. Info panel with selected unit's stats</a></h2> Dots can show only a small portion of the dynamic information about units. Other less important dynamic or static information goes into the side panel. Btw, now you can select enemy units</a> to see their move range and stats in the info panel. NOTE: additionally, a deselection of any unit on the second click was added. Spearman</a></h2> Another important gameplay change is an addition of third fighter type: "Spearman". He has an attack radius of two tiles and can control with reaction attacks a big area of 18 tiles around him. On the picture above the spearman has only one Joker point: this is not an attack unit, he's almost useless during his own turn. But if spearman hasn't used its Joker during his own turn, he has four reaction attacks during enemy's turn: And that's a lot considering that reaction attacks can interrupt enemy's movement. Also, this unit has only three Strength points to accent his defence role. Rancör</a> - a Stupid Component System</h2> Previously, Zemeroth's units were represented by a single struct holding all the stuff as its fields. Not a very adaptable solutions and it was impossible to create a non-unit type of objects. It's the end of 2017 so the solution to this problem is obviously components. With a component system, I should be able to implement: Boulders</a>, Bombs</a>, Fire, Poison stuff</a>, Corpses</a>, etc. I don't think Zemeroth needs a full-featured ECS solution (like specs</a>) as the game is turn-based. A bunch of HashMap<ObjId, ComponentType></code> will do the work fine. So.. I've reinvented another ~~bicycle 🚲</a>~~ square wheel! \o/ Meet Rancör - a simple macro-based component system</a>. I'm not calling this an ECS because it has no systems, it's just a storage. Nothing fancy, you just declare some usual structs for components and create a hidden HashMap</code>-based monster-struct using a friendly macro: rancor_storage!(Parts<ObjId>: { strength: component::Strength, pos: component::Pos, meta: component::Meta, belongs_to: component::BelongsTo, agent: component::Agent, }); </pre> And then use individual fields: parts.agent.insert(id, agent); ... let agent = self.state.parts().agent.get(id); if agent.moves == Moves(0) && agent.jokers == Jokers(0) { ... } ... parts.agent.remove(id); </pre> Or call parts.remove(id);</code> to completely wipe-out the entity. Rancor seems to work fine, but I see two issues: Too many braces in RON file with prototypes</li> Duplication of data between initial values and their base values</a></li> </ul> As I do not expect anyone to use it, this carte lives in the Zemeroth's repo. Btw, see https://gridbugs.org/programming-languages-make-terrible-game-engines</a> and https://gridbugs.org/modifying-entity-component-system-for-turn-based-games</a> articles about component systems and turn-based games in Rust. TOML -> RON</a></h2> Rust community kinda loves TOML, but I'm not a fan of this format. TOML is not that bad, but I find its tables too strange for anything but simple configs. And I've decided to try to use RON</a> format for Zemeroth. (RON's readme</a> has a pretty good list of reasons of why you may not want to use other formats) Thanks to @kvark</a> for starting this project originally and thanks to @torkleyy</a> for resurrecting the project for Amethyst's needs</a>. Boulders and Rocks</h2> To make tactics a little bit more interesting and to prototype non-agent objects using Rancör I've added some tile-blocking Boulders</a>. This is a first non-agent object type in the game. It's a little bit strange that I have different terrain types support for a long time, but not actually using them in the game at all. Meet randomly-placed tiles of TileType::Rocks type</a>. You can move through these tiles, but it requires 3 move points and not 1. Rock tiles and boulders work together with blood and grass to make the battlefield look a little bit less boring. (Yes, I know that it'll be better to use a different texture for Rocks tiles, not just a darker color) Logging: log</code> & env_logger</code></a></h2> I'm tired of adding a special-cased println</code>s to debug something small and removing them before the commit. As I don't have much experience with slog, I decided to replace println</code>s with a classic env_logger</a>. It seems to work, for now, the source code is filled with all kinds of info!</code> and debug!</code> calls. :) Häte: Examples</a></h2> Some news about my silly game engine</a>. It's important to decouple Häte from Zemeroth. First, Häte was extracted to a separate crate inside the repo. The next step is to separate example/test screens. These screens do nothing game-specific so they belong to the engine. There was a bunch of tasks needed to be solved before extracting the examples: Baked GLSL shaders into Häte's source</a>. They are supposed to be dead-simple & tightly coupled with the engine - what's the point of having them in user's assets dir? </li> Baked a default font into Häte's source</a>. I've used the smallest font from this article: http://oxfordshireweb.com/smallest-file-size-google-web-fonts</a>. Karla-Regular.ttf</code> is 17kib only. </li> Settings::default</code></a>. Simplified the examples. </li> Check assets dir from every fs::load</code> call</a>. </li> </ul> Häte: Cache Text Textures</a></h2> ZoC</a> was almost unusable in debug builds: it may take more than 10 seconds to start a game on some machines</a> and now I'm trying to keep Zemeroth's debug builds fast enough. One of the common problems is that Rusttype</a> is very slow in debug builds, especially on Android. As a text in Häte is rendered by creating a separate texture for every string the simplest solution was to cache these textures. Caching is a little bit sloppy solution, but we have no other choice until https://github.com/rust-lang/cargo/issues/1359</a> is implemented. NOTE: Btw, there's a cool hack</a> from @matklad</a>, but you have to compile an outdated cargo from his dev-branch. "Game Development in Rust"</h2> There was a local meetup</a> in Saint-Petersburg this September where @not-fl3</a> talked about his experience as a SHAR</a>'s developer</li> @vitvakatu</a> talked about three-rs</a></li> and I talked about the history of ZoC</a> and Zemeroth</a>.</li> </ul> Everything is in Russian, but here are the links anyway, just in case: full video</a></li> my slides</a></li> </ul> Thanks to JetBrains</a> for hosting the event! Short-Range Plans</h2> RestructuredText -> Markdown</h3> For a long time, I was trying to avoid the use of MD. Mostly because MD has no built-in support for extensions and is MD is forever tied to HTML</a>. I was mostly hoping for RST to become popular enough. There was a chance, but doc team decided to stay with MD</a> and now Rust community doesn't care about RST at all. :( CommonMark</a> solves the standardization problem to some degree. Though, it's still glued to HTML and is not easily extensible. Anyway, I'm not going to use these documents anywhere except in the web browser, so... I'm going to migrate this blog to some rust blog generator</a> from Pelican. This post is written in MD already. Abilities and Lasting Effects</h3> A skirmish game is unimaginable without special abilities</a> and some interesting instant</a> and lasting effects</a> of the actions. So, here are some previews of what I'm working right now: https://youtu.be/Egfyd4VX2YU</a> - jump & knockback</a></li> https://youtu.be/TilgaGspTJk</a> - self-explode</a></li> https://youtu.be/Yg38yeno3sE</a> - poison</a></li> </ul> Whew! That was the longest piece of text in English that I've ever written O.o. That's all for today! :) Discussions: /r/rust</a>, twitter</a>. ZoC is dead. Long life Zemeroth. Thu, 17 Aug 2017 00:00:00 +0000 Soo, yeah, Zone of Control</a> project is officially discontinued. Sorry, friends. ^ "ZoC's dead, baby. ZoC's dead." Why have I killed it? The primary reason is classic: I've overestimated my resources/skills and got totally overwhelmed by the scope: I can't see the finish line and have no idea what exactly I can feature-cut. Strategic mode? Sane UI? Networking? Skeletal animations? Particles? Ships? Aircrafts? Tens of unit types? Oh-oh, I don't believe that ZoC could be really cool without any of these (and some others) features. This situation totally drained all my motivation to continue the project. </li> Slot system (multiple units per tile with fixed positions) is a strange beast. No idea how to make some friendly user interface: two panels (for friends and enemies) solution is ugly, context menus are not cool either. </li> Slots create problems with visual scale: infantry models are just too small, especially on phone’s screen. </li> </ol> </li> Maybe I should make an FPS? No, that's stupid.</a> Ahem, just joking. </li> </ul> Another reason is that my views on what's important for strategic games have changed in the last several years. Now I prefer smaller</a> single-player</a> games with strong accent on emergent complexity</a>. So, some farewell screenshots: </a> </a> </a> ...And that it. Goodbye, my old friend Zone of Control. Zemeroth</h1> There’s one great article: "Finishing a Game"</a>. I have re-read it a dozen times in the last few years. In the context of ZoC’s fail the most important part of that article is: Rule 14: IF YOU DO QUIT, SCALE DOWN, NOT UP Okay, sometimes it is time to call it quits. Maybe there’s just no way you’ll ever finish, and what you have is too big a mess to cut anything out. Maybe the rest of your team has quit already. My hope in writing this list is to help people avoid this possibility, but hey, maybe you’re just coming off of such a project. And sometimes... shit just happens. If there’s no salvaging it, at least make sure that you scale down your next project. It’s easy to set your sights higher and higher, even as your projects become less and less finished. “My SKILLS are improving! I’m learning from my failure,” is a common excuse. But I think this is why it’s important to treat finishing as a skill, too. </blockquote> Sounds reasonable to me. So I need a new much less ambitious project which still shares some of the ZoC’s core values. I’ve spent May and June - in the heavy existential crisis - ahem, resting and thinking about what can I make. Here’s what I came up with: Random-based skirmish-level digital tabletop game;</li> Single player only;</li> 3-6 fighters under player’s control;</li> Short game session (under an hour) and small unscrollable maps;</li> Simple vector 2d graphics with just 3-5 sprites per unit;</li> Reaction attacks and action’s interruption;</li> Highly dynamic (lots of small unit moves as a side effect of other events);</li> Intentionally stupid and predictable AI;</li> </ul> Something in between of Banner Saga</a>, Hoplite</a>, Auro</a> and Age of Decadence</a>. Initial svg mockup (based on my old experiments with 2d ZoC</a>): Ok, that was just the plan. What's actually done already? Here's the code: https://github.com/ozkriff/zemeroth</a> Right now Zemeroth looks ~ like this: Recent "gameplay" video: </iframe></div> What’s implemented: The cornerstone of the game: reaction attacks and movement interruptions;</li> Basic infantry unit type;</li> Hitpoints;</li> Basic AI: move closer and attack;</li> Some basic UI with text/image buttons and grouping.</li> </ul> Android is supported from the beginning of the development (as I’m reusing ZoC’s codebase): Zemeroth’s architecture is mostly taken from ZoC (minus the networking and multiple game states): Scene action system is based on cocos’s one and something I did in dead ZoC’s dev branch: (btw, piston has something similar</a>) Häte2d</h1> About reusing ZoC’s codebase... I’m a fool who don’t learn anything and totally ignored the third rule from finishing-a-game article: 3. DON’T ROLL YOUR OWN TECH IF YOU DON’T HAVE TO </blockquote> Say hello to yet another Rust 2d engine: Häte2d</a> :-D The name is a silly reference to LÖVE2D framework</a> (just in case). NOTE: Häte isn’t a general-purpose game engine (at least right now) and it’s not my goal. Just a simple 2d engine for Zemeroth’s needs. Why haven't I used ggez.rs? Quote from reddit: @pwgen-n1024: have you seen this</a>? its a löve2d clone in rust, it might allow you to save some work. @ozkriff: Granted, I'm well aware of ggez! :-) I'm too lazy to read the docs! NIH syndrome!111 :-D Ahem... It's a cool engine and I recommend it whenever anybody asks me about 2d game engines, but I don't think that ggez's core values match my needs in Zemeroth project: Ggez tries to mirror Löve as closely as possible but I don't believe that what's good for highly dynamic Lua is equally good for Rust.</li> It seems to me that ggez targets beginners and fast prototype-like projects but I'm going to invest a lot of time into this project.</li> I want the engine to be much more opinionated about UI, scene, etc.</li> Right now ggez uses SDL2 (and it's not easy to replace it with glutin) but I really want to use cargo-apk.</li> </ul> </blockquote> Maybe I was wrong and using geez would be a good idea, see Icefoxen’s answer</a>. But so far working on Häte was fun and we’ll see what happens later. That’s all for today :) In case you're wondering, here's full Imgur-devlog which I'm trying to keep updated: http://imgur.com/a/SMVqO</a> Discussions: /r/rust</a>, twitter</a>. This Month in ZoC - 2017.01.24 Tue, 24 Jan 2017 00:00:00 +0000 (Repost from https://users.rust-lang.org/t/this-month-in-zone-of-control/6993</a>) Hi, everyone! :) It has been four months since the first post, sorry. I'm struggling to find enough time for the project plus I was busy with porting glutin to winit</a> for about a month around October. Helicopters</h1> https://github.com/ozkriff/zoc/issues/111</a> Helicopters can fly above any terrain or ground units, but can't capture sectors </li> Most units can't attack helicopters - WeaponType got max_air_distance: Option<i32>;</code> field </li> Helicopters can be seen by enemies even in non-visible tiles </li> Helicopters have a different field of view rules - their FoV have no 'obstacle shadows': </li> </ul> IDLE animation: </iframe></div> It's not easy for ground units to catch up with a helicopter :) : </iframe></div> Haven't got around to implement AA-guns</a> and Manpads</a> yet so the main AA-defence for now is just jeep's machinegun. Reinforcements</h1> https://github.com/ozkriff/zoc/issues/208</a> Players have no starting forces now - everything is bought in reinforcement sectors for reinforcement points. The upper-left corner displays the amount of reinforcement points that current player has and their per-turn increment: Reinforcement sectors are marked by two circles in player's color: There's an additional "reinforcements" item in the context menu: when clicked it opens a list of available units: This opens a list of available units: There must be enough reinforcement points and enough room for the unit. Units have no move or attack points at their first turn. And, by the way, AI has been taught to buy units too. Map selection</h1> https://github.com/ozkriff/zoc/issues/213</a> After the implementation of reinforcements it became possible to add map selection. You can change map by clicking on the current map's name in the main menu screen: It was mostly needed for testing/debugging purposes so most of the maps look like this for now: Tests however are in early prototype phase and are not in the repo yet. Right now they use special maps but I intend to implement some ASCII-DSL like the following: let map = " ... ... ... ... ... ... ... ... ... ... t.. r.. t.. t.. r.. ..B r.A r.. r.. ..C ... t.. ... ... "; </pre> where 't' is a 'trees', 'r' is a road and 'ABC' are positions. Tests work by sending hardcoded commands and waiting for specified events in response. I can't test anything that depends on RNG (attacks mostly) but the movements, FoW, etc are more or less testable. It can't help with errors in visualizer but it makes it easier for me to refactor the Core. Auto-deploy to github releases</h1> https://github.com/ozkriff/zoc/pull/246</a> @Gordon-F</a> has implemented auto-deploy of releases for travis and appveyor. Now you can download windows, linux and osx builds for tagged releases here from the github releases page</a>. Android is totally different story with all its SDKs/NDKs and is still built and uploaded manually. Wreckages</h1> https://github.com/ozkriff/zoc/issues/247</a> Now destroyed vehicles leave wreckages. They only obstruct movement for now. Later they'll be used by infantry as protective covering. When particle system will be implemented wreckages will emit smoke and fire. Towing</h1> https://github.com/ozkriff/zoc/issues/161</a> There're two new items in context menu: "attach" and "detach". You can't chain attachments or attach WholeTile-sized units. Towing system is mostly important for quick reposition of field guns but it can also help with clearing roads from wrecked vehicles. The latter reason will become more important when partial damage for vehicles gets implemented. </iframe></div> Smoothly fading to alpha Fog of War</h1> https://github.com/ozkriff/zoc/issues/210</a> </iframe></div> Opening FoW is a very common action so it deserves to be a little more pretty :) It was easy though I had to rework the FoW rendering code to make it use a lot of independently colored scene nodes instead of a single big mesh. Fixed an old error with units moving into invisible enemies</h1> https://github.com/ozkriff/zoc/issues/106</a> This change caused some refactorings in the codebase: Added a new event type: Reveal, similar to ShowUnit but generated by Core itself and not by the filtering system</li> Merge all *State</code> structs and GameState</code> trait into one universal State struct - #255</a></li> Added a proper FoW layer for air units</li> </ul> Other changes</h1> The short-term roadmap was translated into English and updated</a> </li> AI was taught to capture sectors</a> AI is still in poor state and crashes once in a while. I need to implement replays to reproduce and fix these errors. It's either AI sometimes issues orders to units that are already dead or there are bugs in the event filtering system. </li> Android memory alignment errors are finally gone</a>, thanks to @not-fl3, @tomaka, @brendanzab and @mhintz. Though android port is still not very stable</a>. </li> Fixed bridge slots count</a>. Now bridges are real strategic points which can be controlled or blocked easily. </li> Do not reduce unit morale if the attack was harmless</a> </li> Added "zoom in/out" buttons: because it's simpler than handling multi-touch gestures on android :) </li> </ul> Gameplay screenshots</h1> @ozkriff on Twitter</a> This Month in ZoC - 2016.08.22 Mon, 22 Aug 2016 00:00:00 +0000 (Repost from https://users.rust-lang.org/t/this-month-in-zone-of-control/6993</a>) Hi, comrades! Welcome to the first issue of ZoC's monthly report! ZoC</a> is a turn-based hexagonal strategy game written in Rust. Core game features are: advanced fog of war</li> slot system (multiple units per tile)</li> reaction fire (xcom-like)</li> morale and suppression</li> </ul> GFX and rusttype</h1> Zgl</a>/stb_truetype</a> were finally replaced with GFX</a> and rusttype</a>, YAY :-D !!1 - #183</a> Android</h1> ZoC is now build with cargo-apk</a>. There are still some problems with android version though: https://github.com/ozkriff/zoc/issues/197</a> :( Roads</h1> https://github.com/ozkriff/zoc/issues/152</a> Sectors, victory points and game results screen</h1> https://github.com/ozkriff/zoc/issues/124</a> </iframe></div> Basic smoke screens</h1> https://github.com/ozkriff/zoc/issues/160</a> </iframe></div> Water tiles</h1> https://github.com/ozkriff/zoc/issues/204</a> GUI updates</h1> Replaced unit ids with unit type names</li> Added hit chances</li> Added basic unit info to the upper-left corner of the screen</li> </ul> Fixed switching between normal and wireframe mode for buildings</h1> https://github.com/ozkriff/zoc/issues/182</a> Other notable changes</h1> Fixed armored units reaction to light reactive fire</a></li> Improved error message about missing assets</a></li> Made MapText fading to alpha smoothly</a></li> Fixed annoying vehicle-in-building pathfinder bug</a></li> Added personal independent camera for each human player</a></li> Fixed AI hangup</a></li> </ul> Bonus 1: ZoC on android</h1> Bonus 2: memoir44-mockup of smoke demo map</h1> Weekly links: 1</a>, 2</a>, 3</a>, 4</a>. https://github.com/ozkriff/zoc</a>, @ozkriff on Twitter</a> Градообразующие объекты Tue, 23 Feb 2016 00:00:00 +0000 Показал нескольким знакомым макет, послушал комментарии. Один из повторяющихся - города не выглядят городами, слишком абстрактные, больше похожи на хаотично раскиданные детские кубики. Я об этом не задумывался, моему замыленному взгляду город и так хорошо виден. Даже наоборот, пытался здания раскидать и повернуть как попало, что бы меньше чувствовалась жесткая гексагональная сетка со слотами. По задумке, города (и деревеньки) должны занимать не больше восьми-десяти клеток в радиусе и действительно быть довольно абстрактными - иначе странно будет выглядеть соотношение размеров зданий и техники/человечков. И кое-какая хаотичность в любом случае должна быть, скучные города с улицами ровно под 90 градусов я делать совсем не хочется. Но в то же время города должны выглядеть как цельный многоклеточный объект. Выход вижу в каком-то алгоритме прокладки не влияющих на логику городских улиц и автоматическом визуальном повороте зданий не абы как, а параллельно с улицами. Что бы не запутаться, ввожу разделение: "дорога" - значима для игровой логики и идет строго от центра одной клетки к центру другой, а "улица" - это бутафорское нечто в городских клетках. Около большого здания, наверное, стоит выравнивать мелкие здания относительно него, а не окружающих улиц. Типа, архитектурный ансамбль :) . Если посмотреть на тот же атлас дорог страны, то там от столицы тянутся федеральные трассы, пронизывающие города насквозь: Вот желтое тут - "дороги", а белое/серое - "улицы" и дома. Наверное, надо разрешить особую дорогу по городу прокладывать. На этих клетках нельзя дома строить будет, но через нее будут проходить обычные улицы и такая дорога не будет разрывать целостность города. Хммм, еще надо будет научить отряды внутри города двигаться по улицам (визуально, не логически). Надо будет не забыть добавить еще железные дороги - один в один как обычные дороги, только позволят поезду заезжать на клетку. И тропинки в лесу: лес с деревьями, между центрами клеток нарисована небольшая дорога с особой текстурой - по такому лесу техника сможет ехать, но медленно и с плохим обзором. Но это так, мысли все. "Реально" в макете не успел все попробовать. Добавил улицы и декоративные заборчики с садами у пары зданий. Здания к улицам повернул "фасадами". Заводу трубу прилепил, так чуть понятнее что это завод :) . В таком виде улицы слишком бросаются в глаза для "чисто декоративного" элемента. Возможно, потому что макет довольно беден на детали? В игре можно будет их "запылить" землей по краям, думаю. Еще вопрос, как такое автоматически генерировать можно? Тут-то сетка вручную сделана и довольно хитрожопая: Сделал болванку трехклеточного корабля, у этого придется немного поколдавать с путенажодением, что бы он плавно поворачивал и только по широким рекам мог проплывать. Чуууточку удалось поковырять код между рисовашками и размышлениями. В рамках подготовки к введению системы слотов удалил костыль с константами номеров узлов сцены (#154</a>). Долго пытался понять, как мой код ломает погрузку пехоты в грузовик. Потом понял, что оно и раньше не работало. Отлично! :) Потыкал асимметричность тумана войны (#149</a>), не там все совсем не просто и времени много займет, отложил пока что. Как и отложил задачи о украшении типов-оберток (#120</a>, #147</a>), потому что прямой пользы для прототипа от них не так много. rust-lang/rust#31123</a> - ураа, проверка сборок под андроидом, лед тронулся! Значит, скоро ситуация со сборкой под андроид должна в лучшую сторону измениться. Заглянул тут в обзоры</a> Battle of the Bulge в стиме. Я просто в ужасе от того, сколько отрицательных обзоров в "самых полезных". Какого черта, человеки?! Игра же отличная, просто она отличается от большинства компьютерных стратегий. Идите в ремейки Панзер Дженералс играть, быдлота от мира варгеймов, не портите оценку маленькому шедевру :( . Итак, я опять фактически потратил пару дней на макет и размышления. Пора уже заняться реализацией слотов в коде. Обсуждение на Disqus</a>. Чертов макет! Sun, 14 Feb 2016 00:00:00 +0000 Ладно, X-Com меня начал потихоньку отпускать и большую часть хотелок по макету получилось набросать. Автоматчик: Довольно легко визуально отличить от обычных стрелков должно быть, но на всякий еще сгорбленными их поставил. Закинул в джип еще одного пассажира и подкрутил позы старых: На средний танк прилепил еще одного танкодесантника сбоку: С виду, трех еще можно на танк посадить - как раз отряд и будет. Так, что тут еще на общем снимке виднеется? Огнеметчик, снайпер, пулеметный рассчет, простенькая средняя закрытая САУ на основе среднего танка. Обновил полевую пушку и ее прицепление к грузовику. На планшете смотрится прилично, солдат всех различить можно. Все, считаю "неделю блендера" законченной - толку от дальнейшей проработки макета уже не много, а рисовать я уже устал. Может еще какие-то вещи буду подпиливать в нем, но уже не так целенаправленно. Настало время писать код! Прриступаю к реализации трехслотовой системы! :-D Пришельцы воруют мое время Wed, 10 Feb 2016 00:00:00 +0000 Мой план "усилием воли закончить макет за выходные" с грохотом провалился. (Да, картинка из xcom1, но мне лень искать с новым сектоидом) Внезапно для меня объявился X-COM 2. И внезапно же запустился на моей железяке, хотя все на оптимизации ругаются. Fps, правда, не на высоте совсем. Что могу сказать об игре после пары дней знакомства? Пока в основном положительные эмоции, даже переделанный облик врагов особо не раздражает. Круто, что практически убрали миссии без таймера - хотя люди в половине обзоров и ругаются на таймер, но мне играть стало на порядок интереснее. Тем более, что с новой темой "мы террористы - прибежали, все раздолбали и свалили, пока силы правопорядка не очухались" отлично сочетается. Одна из главных вещей, за которые ругали xcom:eu -что враги ходят по карте группами, которые надо аккуратно уничтожать по одной, и двигаться надо странным образом, что бы случайно не активировать следующую группу. Это же и правда глупо и скучновато было. А теперь у игрока уже не выйдет отсидеться на месте больше двух ходов если ты на месте больше трех-четырех ходов торчишь, то, скорее всего, вообще к цели не успеешь. Я пока вижу один недостаток этого подхода - не та атмосфера, что была в первой части. Тогда солдаты аккуратно прочесывали карту, как, по мнению людей, в реальности охота на прищельцев и происходила бы, а не рвались со всех ног через всю карту. Ну и ладно, меня новая атмосфера вполне устраивает) Немного раздражали несколько нелепые мечи у солдат, но к этому быстро привыкаешь. Еще радует, что гранаты опять можно кидать только по клеткам. Как же много было в прошлой части раздражающих моментов, когда нужно было терпеливо двигать мышку пикель-туда-пиксель-сюда, что бы зацепить всех возможных врагов. Там еще и возможность гранат отскакивать накладывалась на это безобразие. Бррр! В обзорах игру за большое количество ошибок ругают, но у меня всего парочка была. Один из новобранцев был без тела - голова летала сама по себе, пришлось ему костюм поменять туда-сюда в настройках. И один раз планшет, на котором отображается интерфейс взлома, солдат вставил внутрь стены, за которой он прятался, и камера показывала стену. Больше ничего не припоминаю. Вроде мелочь, но мне почему-то очень понравилось - анимации ранений на послемиссионном экране. Как-то компенсирует то, что во время самого тактического боя последствий от ранений почти нет. Плюс, оправдание "они не замечают ранений, потому что адреналин" сразу как-то правдоподобней выглядит - вот же они после боя с ног валятся. Видел отзывы "рандом говно, у меня подряд четыре снайпера промазали при вероятности 80%". Вот возьми и запиши результаты всех случайностей в игре - уверен, что получится чего-то очень близкое к честному, так что не надо ныть. Еще в отзывах часто мелькает: "солдаты промахиваются в упор, это тупо". Ну хз, с моим-то обширным опытом промахиваться в упор в Red Orchestra и всяких шутанах, у меня точно нет желания ругать бедных солдат за подобное :) . Из косяков могу еще отметить пикейщиков. Это враги, которые не умеют стрелять, зато быстро бегают и хорошо бьют оглушающими дубинками. Такой появиляется в поле зрения и на следующих ход уже будет атаковать кого-то из твоих солдат. И если твой солдат не будет вырублен первым ударом (а в первую треть игры такое часто случается), то он его сильно ослабит попаданием, что упростит взятие этого солдата под контроль сектоидами. После первой трети игры появляются варианты: снайпера натравить, поставить на его пути своего рукопашника с "автоатакой" по всему пробегающему рядом, взять пикейщика под контроль своими пси-оперативниками, заминировать подходы. После середины игры он обогащает игровой опыт однозначно. Но вначале игры появление этого врага означает, что возможные адекватные варианты поведения игрока сильно суживаются и это вредит игре. Вначале игры выход один - валить этих гадов всем отрядом из всего оружия, как только увидел. Ну или я играть не умею, тоже может быть))) Еще жалко, что за мехов пока играть нельзя, как в xcom:ew. Жду дополнений. Про xcom:eu было много отзывов про оказуаливание, даже сам поначалу не хотел играть, судил по видео с ютуба. Это уже потом, когда меня уговорили попробовать все-таки я понял, что летсплйщики и играли на простом уровне сложности, и там были только ранние этапы игры и действовали они прямолинейно. От того убого и выглядело. Сейчас считаю, что авторы очень даже круто балансируют между хардкорной и казуальной игрой. И да, как всегда считаю, что проходить надо в режиме "железный человек", без всяких сохранений/загрузок)) Так, ладно, кое-что я все-таки смог заставить себя наклепать. Немного подпиленный легкий танк, самоходка на его основе и болванка джипа: Новая сетка для солдата, даже кое-какой скелет в него вставил: Долго пытался ему размер подобрать, что бы он в технику влезал, но и виден был. Пока вот на этом остановился. Выдал ему винтовку: Не удержался и немного деталей джипу добавил (теперь он смотрится слишком детальным, когда рядом с грузовиком стоит) и пассажиров в нем рассадил пейзажно: Любой пулеметчик смотрится круче, если может ножку закинуть на что угодно :) . Средний танк с танкодесантником: Бронетранспортеров на всех не хватит, кому-то придется так к полю боя добираться. Заодно танк целей будет. Последнее время в реддите стали мелькать библиотеки шрифтовые, приятно. Раньше думал truetype</a> потыкать для замены своих костылей вокруг сишного stb_truetype</a>, теперь вот еще появился RustType</a>. Выглядит вполне прилично (пример</a>). Хорошо, когда есть из чего выбирать. Что же, в связи с xcom-катастрофой переношу цель "закончить с макетом" на конец уже этой недели. Попробую проявиться характер и хоть немного оторвать себя от истребления пришельцев. Первая половина Недели Блендера Fri, 05 Feb 2016 00:00:00 +0000 После пары просьб, решил таки добавить</a> записям желтушные заголовки. Так их и правда немного проще отличать. Набросал мегазадачу</a> по расширенному прототипу тактического режима. Надеюсь, это немного поможет не разбрасываться на всякие левые дела и просто делать пункт за пунктом. Хотелось бы все это сделать к апрелю, за два месяца. Хе-хе, :-D ну посмотрим, как оно выйдет. Никогда и нигде в сроки не укладывался толком, особенно с таким размытым ТЗ. Двери-окна вот зданиям добавил, немного приятнее стало выглядеть, накалякал легкий простенький танк. Деревья кое какие сделал, вместо ворованных. Они не то что бы прям ворованные, но под cc-by-sa, а мне хочется прям свободные-свободные модели в составе игры иметь (#24</a>). Пробую накидать джип, с ним уже явно становятся видны нестыковки в текущих размерах людей и техники. Что-то надо менять. Изначально я хотел, что бы в один слот влезало нечто масштаба Т-35 или маус (последние два снизу, ~10 метров). Все-таки предполагалось, что целую клетку будут занимать только огромные здания, заводы там всякие, а техника, если на всю клетку, то тоже должна бы быть сопоставимой с заводом в размерах, мегатанки всякие. Но, как из картинки видно, если придерживаться более-менее реального размера человечков, то они становятся совсем крошечными, если камеру прямо в землю не утыкать. А я такое уже видел в Кодексе Войны и играть в такое очень и очень сложно: Но просто так взять и увеличить людей я не могу, потому что в игре должны быть джипы, полевые пушки и т.п., где тоже используются модели человечков и, например, джип с увеличенными людьми смотрится как-то так: Хмм, вот я, после некоторого размышления, думаю что делать по этому поводу: Придется убирать требование "в слот влезает техника размера т-35/мауса (10м)", так что в слот максимум помещается техника до 6.5м в длину (без учета всяких торчащих пушек, черт с ними). Увеличиваю людей, допустим, в полтора раза от реальных и увеличиваю технику в обратной пропорции к ее размеру. Т.е. мотоцикл/полевое орудие/джип я увеличиваю ровно как и людей, мелкие танки я увеличиваю уже на меньший процент, средние увеличиваю совсем на чуть чуть, большие танки остаются как есть. А всякие маусы уже в слоты не влезают и занимают сразу целую клетку и черт уж с тем, что они размером с завод будут - еще немножко условностей БОГУ УСЛОВНОСТЕЙ!!^W^W, кхм, в угоду визуальному удобству :). Я там в прошлой записи упоминал, что здания с людьми внутри должны будут отображаться разрезанными/сеткой. Пока себе представляю как-то так: Вопрос, конечно, как это в OpenGL все отображать =. .obj, который пока у меня используется, не умеет хранить просто ребра, ему нужны грани. Менять формат пока не сильно хочется, надо сосредоточиться на прототипе. Есть вариант, в самом блендере, в виде временного хака, какими-нибудь модификаторами сделать вместо набора ребер набор тонких граней. Понял, что в блендере как-то жутко глючит выделение объектов. Погуглил, попробовал всякое, в итоге помогло переключение режима выделения с обычного на "Occlusion Query Based Selection". Странно это все, неприятные мелочи) Вышла четвертая статья</a> от чувака с космической 6DOF игрой, про распределение времени. Эх, там, судя по всему, о случае когда у тебя нет основной работы и ты просто целыми днями делаешь игру - как не свихнуться от такого и чего-то в итоге все-таки сделать. Не сильно мне совету оттуда подходят) Да и вообще, слабо себе представляю, если честно, как можно решиться уйти с постоянной работы в трушные индюшатники и только этим и жить, брр. Залип тут на гифки в хаброзаписи о визуализации потоков в Go</a>, обожаю такие картинки)) В /r/rust промелькнул приятный пост про "try/catch/? vs монады"</a> со срачем в комментариях. Клево, что не все согласились с RFC try/catch/? обсуждения еще идут. Все-таки очень уж частное это решение, в отличие от нормальных монад. Да, с монадами нельзя так просто использовать return, break, continue и т.п. - ну и ладно, пускай функциональщина будет предпочтительней императившины, я совсем не против. В языке и так сильный уклон в эту сторону уже есть. Внезапно узнал</a>, что блогогенератор Jekyll можно вообще локально не разворачивать, а github pages сами могут из .md исходников .html выплевывать. Как-то совсем мимо моих ушей прошло) Ну да ладно, не буду сломя голову переводить днявку на джекил, уже успел к пеликану более-менее привыкнуть. Да и reStructuredText тут изначально поддерживается, мне он больше по душе. Итак, по плану, на этой неделе надо закончить с набросками моделей. Надо бы за выходные несколько видов техники еще допилить, определиться с относительными размерами и, самое сложное, человечка со скелетом и позами с оружием запилить. Ух, ну постараюсь :) . Обсуждение на Disqus</a>. Выходные, размеры, Тарантино и ненависть к людишкам Sun, 31 Jan 2016 00:00:00 +0000 Итак, выходные прошли. Толком ничего не сделал, но надо хоть чего-то сюда написать, раз уж опять взялся журнал вести. Так что вот, на :) : Переложил журнал из гиста в воскрешенный ozkriff.github.io и столкнулся со сложностями с disqus. Сначала оно вообще не хотело загружаться, поправил</a> :) . Потом оно завело для http и https отдельные потоки комментариев, гм =\ . Почитал всякое (типа вот этого</a> или этого</a>). По итогам вклячил</a> js-хак с перенаправлением с http на https (хотя при особом желании все равно можно зайти на http). Несколько комментариев к прошлой записи перекинул на https версию. Немного потупил с вытаскиванием CSV из disqus и его правкой - интерфейс у админки disqus не слишком интуитивен. Но само перемещение комментариев прошло просто. Вроде, все более-менее работает, останавливаюсь пока на этом с журналом. Поэкспериментировал с геометрией людей, но пристойного ничего пока не вышло. Подумываю сделать их мультяшными. Все-таки игра пошаговая, с клетками - в ней много условностей, а мультяшные персонажи с таким гармоничней смотрятся, тоже ведь визуальные условности. Думал, что ноги надо укоротить и туловище сделать длинным, что бы напоминало человечков с бумажных рисунков. Но в 3D выглядит стремно и совершенно непонятно, как таких уродцев сажать в технику. Похоже, останусь с более-менее обычной человеческой геометрией) Листаю всякие http://wiki.polycount.com/wiki/Limb_Topology</a> . Ох, все это немного слишком сложно для меня) Да и не то что бы очень надо пока что, все-таки у меня тут пока что довольно набросочные модельки, я даже не пытаюсь какие-то детали изобразить. Одновременно с прикидыванием геометрии людей медитирую над сравнительными размерами техники (человеки же в нее влезать как-то должны). Отталкиваться все-таки буду от техники второй мировой и около того, не смотря на то, что хочу в итоге дизельпанк/постап. Да и такая основа даже более-менее укладывается в Поздний Дизельпанк</a>. Прикольно, кстати, я думал что бронемашины серии БА больше, как и танки Т-70. Хотя и то, и другое - не так уж далеко от грузовиков-автомобилей ушло (в Т-70 две силовых установки от грузовиков обычных, если не ошибаюсь), так что не удивительно. Все со схемы выше должно влезать в слот клетки, даже пятибашенный т35 и маус должны более-менее запихиваться. Вот тут, с блицкриговскими модельками, даже нагляднее размеры чувствуются (хотя не факт, что они тут такие же точные, все-таки Блицкриг не симулятор): StopGame выложили вторую часть Истории Fallout</a> - очень даже приятный обзор первой части. Приятно было за ужином посмотреть, прям ностальгичненько так) Каких-то вещей даже не знал, все-таки я больше во вторую играл в школе. Сходил на Омерзительную Восьмерку. Как по мне, отличное кино, старый добрый Тарантина вернулся - Бешеные Псы в антураже старой америки. Но подозреваю, что копать на тему исторической достоверности бессмысленно, гм). Фильм, в общем, отличный, а вот зрителей хотелось поубивать. Что бы так же, с литрами кровищи и кишками на креслах. Давненько в кино уже не были, пол года, наверное. Отвык уже :( Слева уселись две ТП, которые вообще непонятно зачем пошли и весь фильм или откровенно скучали, уткнувшись в телефоны, или болтали о папиках, или взвизгивали "ой боженьки, он что в лицо ее ударил?! женщинуу?!", "ой, этой у нее мозги на волосах что-ли? фуу, вот больные!", "ой, негра кровью стошнило что ли?" и т.п. А на титрах громко иронично зааплодировали -"ураа, наконец-то, лучший момент в фильме, зачем только пошли?". Я вот тоже не знаю зачем они пошли. Спереди сидели какие-то мелкие дурочки, которые громко ржали при каждом "нигер" или еще чем подобным, что по моим представлениям должно вызвать максимум ухмылку. И сидели вконтактике с огромного лопатофона с такой яркостью, что меня аж слепило иногда. Справа сидели два милых гопаря, один из которых все время терял нить "тягомотины" и хотел свалить с сеанса, а другой уговаривал своего дружка остаться и громко, даже не претендуя на шепот, пересказывал сценарий и выдавал свои наивные прогнозы по поводу развития сюжета. В общем, временами было сложно абстрагироваться, такое сильно мешает смотреть атмосферный фильм. Вот бы в кинотеатрах были охранники, которые за превышение громкости выводят из зала, эх. Обсуждение на Disqus</a>. Несколько моделек и вечная смерть Fri, 29 Jan 2016 00:00:00 +0000 Defuz предложил, пока я веду журнал в гисте, пинговать о записях в https://gitter.im/ozkriff/zoc</a>, что был способ оставлять коменты и узнавать об обновлениях. Немного поправил геометрию мамонт танка</a>: Но сильно возиться с ним не хочется - мне просто нужен какой-то огромный юнит на всю клетку, чтобы не забыть про них совсем) С вертолетом тоже пока заканчиваю вот на такой стадии: Кстати, на заднем плане, за вертолетом, обрезанные здания виднеются. Примерно так, если что, подумываю рисовать здания в которых кто-то есть. В режиме рендера каркас не рисуется, вообще палки сверху еще должны быть: (на вписаную и описаную окружности внимание обращать не надо, это просто вспомогательные конструкции для размещения зданий в макете :) ) Может еще контуры окон-дверей потом добавлю. В Battle Academy здания с людьми внутри рисуются полупрозрачными, но на деле (для меня, конечно) это очень криво выглядит и ничего не понятно =\ : О, внезапное (эти тоже все обещают "начать вести бложик более постоянно", хех) обновление в тихом и уютном бложике разработчиков моей любимой Unity of Command: http://unityofcommand.net/blog/2016/01/28/dev-diary-3-are-you-experienced</a> Тут говорится о том, что во второй части игры войска надо будет беречь, потому что они будут переходить из сценария в сценарий. Ну и о тонкостях накопления ими опыта рассказывается. Вот, вроде, это клево и логично, что тебя принуждают не разбрасываться армией просто так. Но что-то в первой части UoC было приятно освобождающее в том, что ты мог пожертвовать чем угодно, лишь бы выполнить боевые задачи в срок. Да и в относительно недавно пройденной мной Battle Academy 2 так же. Эх, теперь, наверное, надо будет над каждым отрядом трястись =\ . В более масштабном Кодексе Войны или даже Битве за Веснот меня необходимость побеждать без потерь сильно раздражала. Тоже интересно, конечно, но там надо было выигрывать почти всегда без потери единого отряда, разве что совсем уж мелочью дешевой жертвовать. С одной стороны, это как-то не слишком реалистично, как по мне, в жизни так не бывает). С другой, это создает прямую связь между сценариями: хорошо играешь -потом побеждать тоже проще, плохо играешь - дальше только сложнее будет. Это занятная метаигра, но не без неприятных нюансов: ты заранее не знаешь, какой процент потерь допустим, так что если есть возможность переиграть сценарий, то лично я обычно переигрываю до тех пор, пока не пройду практически без потерь, а то мало ли что в следующих сценариях меня ждет? Это несколько вытягивает удовольствие из игры. Даже виноватым себя чувствовал, если начинал новый сценарий без идеального прохождения прошлого. Лично моим любимым решением этой сложности является перманентная смерть (когда сохранение только одно и только автоматическое), как в новом X-COM, например. У тебя просто нет возможности переигрывать сценарии, так что из-за этого совесть не мучает и просто стараешься аккуратно играть, лишний раз не подставляя ценных ветеранов под риск. Ладно, посмотрим как тут сделают, может пермадез будет, может условия выигрыша в сцерании будут оговаривать какой-то допустимый процент потерь, или в каждом новом сценарии будут выдавать большое количество "казеных" отрядов, или еще что такое :) . Обсуждение на Disqus</a>. Очередной перезапуск Thu, 28 Jan 2016 00:00:00 +0000 Моя последняя попытка вести нормальный журнал провалилась</a> :) . Времени жрет дикое количество. Не умею я, как некоторые люди могут, за пол часа накатать красивую страницу текста :( . После того поста вел каждодневные записи в файлике, что я по проекту делаю, что бы потом из них пост слепить. Через месяц, под новый год таки попробовал - просидел три вечера за этим занятием, задолбался и решил что обойдусь без блога) Так что попробую теперь вести хоть какой-то журнал, в виде маленьких слабо-организованных записей. Как я себе в файлик писал, вот так же - каждый день, если хоть чего-то делал про Зоку, писать что делал, как прошло и какие у меня мысли вообще возникают. Авось кому-нибудь да и будет интересно полистать. Ну и мне потом, наверное, забавно перечитать когда-нибудь будет и вспомнить, какой я был дурной) Собственно, это первая запись :) . Хотя думаю, добавлю пару записей задним числом из недавних разговоров - про тот же план работ. Для начала пускай это дело просто в gist'е живет - каждый день новый файлик. Лениво с полноценным блогом для такого заморачиваться. Заготовка вертолета, гм: В фоне потихоньку вожусь с удалением констант с индексами из кода сцены (#154</a>). Сами константы удалил, теперь все получается динамически, но при движении отрядов или переходе хода оно падает. Надо искать, что я там напутал) Мастерплан и мотивация Wed, 27 Jan 2016 00:00:00 +0000 Знакомый скинул ссылку на вполне себе интересную серию статей в реддите</a>. Хм, ну базовый цикл у меня близок к цивилизации - "Select unit, move unit, combat/gather, repeat." у меня тоже ты "выбираешь отряд, двигаешь/атакуешь/используешь навык, заново". прототип - я большую часть механики беру из игры Battle Academy, так что она уже служит начальным прототипом) Плюс, я вот сейчас "отыгрываю" игру в блендере на макете игры. Туман войны так не симулируешь, а вот базовую логику сражений - вполне. Так-то у меня само приложение сейчас и в ближайшее время, как по нему и видно, на стадии прототипа -практически никакого интерфейса, эффектов, анимацией и т.п только игровая логика, всплывающие текстовые надписи и бааазовая визуализация. как оно сейчас есть оно мне нравилось более-менее, но при попытке сделать карту побольше я понял, что города выглядят страшно криво и бесят меня вот и задумался над переделкой механики - в итоге увеличил клетки Те же технические моменты, типа перехода на glium, я на потом откладываю. Собственно, главное что бы оно на андроиде работало и я мог проверять игру на планшете - в первую очередь для тыкалок же делается. И да, все это - тактический режим, поверх которого должен быть еще стратегический с глобальной картой. Но с стратегическим я пока решил не запариваться сильно, потому что тактический должен быть цельной игрой сам по себе. Стратегический в итоге должен как-то так выглядеть: и определять контекст для тактических сражений. перехожу ко второй статье) вчера утром знакомому уже писал свой план на ближайший месяц-два сделать в блендере модельки-прототипы базовых видов солдат-техники, затем изменить код игры, что бы оно поддерживало три слота, вклячить в игру здания и дороги, затем вклячить новые виды юнитов с базовой математикой боя для них и добавить условия победы в режиме хотсит. Что бы в итоге в это можно было играть полноценно. Предполагается, что это все где-то на месяц. Хочу сосредоточиться на получении чего-то играбельного, пускай и технически убогого и вообще схематического. Когда это сделаю, тогда в планах сначала переход на glium, затем сетевая игра. А дальше план уже более размытый: добавить редактор карт, загрузки-сохранения, кое-какие спецэффекты довести тактический режим до вида "не очень стыдно показать обычному знакомому, который играет в игры, но в их производстве вообще ничего не понимает" и потом начать работать над стратегическим режимом. Точное время на задачи я даже не буду пытаться прикинуть, все равно долго выйдет. Думаю категориями "вот до такой стадии было бы неплохо добраться через два месяца, это еще через месяц-другой". "Are you disciplined enough to stay 100% productive over that amount of time?" -гм, 100% буду время от времени забрасывать к чертям проект на неделю-другую как на новый год) а то так с ума сойдешь) но даже в такие перерывы я где-то в фоне все равно продолжаю думать на зоком, так что уверен, что сам проект не брошу. Да, наверное стоит создать суперзадачу на гитхабе "Закончить прототип тактического режима" с более-менее детальным списком дел в масштабе день-неделя. Постепенное проставление галочек и правда должно мотивировать, я люблю такие штуки)) Перехожу к третьей части, про мотивацию - важная штука) у меня один из способов мотивировать себя - написание всего этого дела на ржавчине) все-таки интересный язык сам по себе. клево с ним разбираться, но и времени на это уходит сильно больше, чем если бы я просто на плюсах написал то же самое, даже свой простенький графический движок. Но мне так не хочется еще и в свободное время пачкать руки в плюсах)) Хм, у меня, наверное, два больших источника вдохновения - это стратегические игры, типа Unity of Command, Battle of the Bulge, В Тылу Врага, Close Combat, Uniwar и т.п. Когда дело ну вообще никак не идет, то я хотя бы на вечер забиваю на zoc совсем и сажусь как следует в чего-нибудь стратегическое поиграть. В процессе почти всегда появляются мысли вроде "черт, сюда бы такую-то возможность добавить, вот было бы круто") И еще схемки - или нарисованные на бумаге в таком духе, я их мноооого рисую когда думаю) или макеты в блендере, как вот который сейчас делаю потихоньку Смотришь на это дело и сразу представляешь, как было бы клево, если бы оно могло "ожить". Что бы вон та артиллерия могла дать залп дымовыми перед вражеским городом, эта пехота забраться в броневики и ломануться навстречу, а вон те танки в это время при поддержке вертолетов зашли в бок и подавили бы с расстояния часть сил врага и блаблабла)) Форы Tue, 26 Jan 2016 00:00:00 +0000 Недавно тут наткнулся на статью про гандикапы</a>. Может для сетевого режима ЗК замена обычных рейтингов на уменьшающиеся при победах гандикапы (форы) и не такая глупая идея. Все-таки вполне себе способ повысить интерес при игре с сильно отличающимся по уровню игры противником. Например, банально давать меньше стартовых очков. Тогда и рейтинг можно упразднить, вместо него использовать размер гандикапа). Типа, когда начинаешь играть, твой рейтинггандикап - 200%. Т.е. у тебя, допустим, 200% стартовых очков, а у топовых игроков будет рейтинггандикап в 60% или типа того. Правда тупо менять количество стартовых очков - слишком дуболомное решение, надо чего-то более хитрое придумать. Для игры со знакомыми можно просто договориться и не тратить все очки или еще какое условие поставить, но это как-то "не круто". Пробовал много раз так делать со знакомыми, но, обычно, весело не было. Появляется какое-то чувство кустарности, которое меня порядочно нервирует. Еще вручную за договоренностями бывает сложно следить. Точно помню пару раз, как я "ой, так у меня же полторы тыщи очков, чего я туплю? Вооот, тут покупаю крейсер и он всех выносит, бббабах! ..ой, черт". Ну и интересный домашний гандикап еще надо придумать, что бы игра не поломалась как система. Надо посмотреть, как это дело в более традиционном спорте используется. В Go вон вообще всякой хитроты понапридумывали</a>. Подумал-подумал и пока решил, что если и планировать такое, то только в виде параллельного обычному рейтинговому топа, в порядке эксперимента, а то слишком уж тут много тонкостей у этого подхода. Но это так, мысли про далекое будущее все :) . Сложности с crates.io и конфиги из открытого космоса Mon, 25 Jan 2016 00:00:00 +0000 Сунулся наконец-то выложить zoc на crates.io. А, оказывается, даже если пакеты лежат в одном репозитории, их надо выкладывать на crates.io отдельно. Посмотрел gfx - они тоже каждый пакет, оказывается, отдельно выкладывают :( . Эх, совсем не хочется загаживать crates.io своими бессмысленными пакетами, они явно никому не пригодятся. Можно бы на модули разбить, а не пакеты, но так инкрементальная сборка будет опять занимать минуту и сложности с привязками к OpenGL возникают. Нафиг тогда выкладывание на crates.io, пока на glium не перейду. Мне не так сильно этот crates.io и нужен, просто немного неприятно, что про твой код забывают при проверке всяких поломок при обновлениях библиотек. Ну да ничего, пару месяцев уж потерплю. Возился в связи с этим с Cargo.toml и Cargo.lock. Хоспади, ну все-таки как мне не нравится этот TOML. =( Он в некоторых случаях и правда неплохо справляется, но при работе с ним все время чувство костылей есть. Как-то у него фокус на частности, а не на нормальное обобщенное решение. В целом ничего формат, особенно для простых конфигов, но вот синтаксис таблиц меня ужасает. Перезапуск журнала Mon, 30 Nov 2015 00:00:00 +0000 Насмотрелся я тут на журналы reangd</a>, cogmind</a>, eao197</a> и всякие другие, решил что тоже чего-нибудь хочу писать. С последней моей попытки прошло около полутора лет) Итак, на момент написания прошлой заметки я работал над Миром Кораблей в питерском wargaming.net</a>. Собственно, я успел уйти оттуда, поработать над казуалками в Zillion Whales</a>, оттуда тоже уйти и осесть в Протее</a>. Так что сейчас я ковыряю ip-телефонию и все игры теперь только в свободное время, зато не надо каждый день "любоваться" на ужасы фритуплея) Я больше не студент, совсем - наконец-то закончил заочку в политехе, ура-ура! :-D Темой диплома как раз и был этот проект, даже презентация</a> вот завалялась. Хотя ничего особо крутого, как мне изначально хотелось, на деле не вышло. Ключевым моментом диплома являлся ИИ. Я там подробно расписал какие они бывают и какие виды подходят для каких игр. А вот реализовать полноценный не успел - сдавался вариант, который только формально можно было назвать "практичным ИИ" (извиняюсь, но лучшего перевода для "utility-based AI" не нашел. "ИИ, основанный на теории полезности" как-то длинновато). Он примерял к текущему состоянию игры захардкоженные шаблоны на основе позиций и типов отрядов, оценивал коэффециент их полезности, и втупую применял их. На специально подготовленных ситуациях выглядело не так и плохо, но это отмазочный вариант, конечно. И с очень стремным кодом, так что в git'е сейчас так и лежит базовый "ИИ" - подъехать в на расстояние выстрела и стрелять :-| . Но общий обыт был интересным) Сама ржавчина, конечно, за это время сильно выросла, с 0.10 аж до 1.4. Вместо извращений по установке зависимостей или возни с git submodules, появился cargo. По достижении 1.0 появилась обратная совместимость. Хотя конкретно от этого я и не в полном восторге, руки у авторов языка теперь "полусвязаны", но переписываний и правда стало меньше, только когда библиотеки чего-то ломают. Да и с этим Cargo.lock очень помогает. Хотя, я уже месяца полтора его не обновлял - ух и сложный же следующий cargo update</code> у меня будет. За полтора года я успел переиграть много во что повлияевшего на мое видение пошаговых стратегий, например: малоизвестная Battle Academy 2</a> из которой я решил фактически передрать ядро механики для тактического режима :) - взаимодействие видов войск, быстрое/осторожное передвижение, хитрая видимость, реакционный огонь, боевой дух/подавление и т.п.; </li> чуть более известная Unity of Command</a> повлияла на мое видение стратегического режима - хитрая система линий снабжения, механика окружений и т.п.; </li> мобильная Uniwar</a> - классная система параллельных сетевых игр, а сама по себе игровая механика напоминает, что шестигранникам минимализм никогда не помешает; </li> серия Wargame, а именно W:AB</a> и W:RD</a> - одна из немногих стратегий в реальном времени, в которую я с удовольствием поиграл за долгое время. Интересна своим балансом между реализмом/"веселостью" и взаимодействием между разными видами войск. </li> </ul> Много думал про пошаговые игры без клеток, все-таки у клеток много недостатков/особенностей. Даже немного экспериментировал - сделал простенькое путенахождение по вручную размеченной навигационной сетке: Путь проложен по центрам треугольников, для оптимизации потом хотел прикрутить funnel algorithm</a>, но до этого этапа не дошло. Если что, шестигранники тут уже ничего не значат, просто на основе работающего прилжожения экспериментировал. Затем, написал простенький "наращиватель" препятствий, который в зависимости от величины угла добавлял разное количество вспомогательных отрезков: Предполагалось, что все юниты будут поделены на несколько групп по размерам и для каждой группы будет поддерживаться своя сетка. Непосредственно преобразованием массива таких "жирных" препятствий в сетку должен был заниматься триангулятор. Мне большего всего приглянулся плюсовый poly2tri</a>: Даже пытался портировать его на ржавчину, но там очень стремная работа с памятью, очень хреново укладывается в модель ржавчины. Пробовал переделать плюсовую версию на работу с массивами и индексами, но потом решил что очень уж много на эксперимент уходит времени, энтузиазм про бесклеточные игры прошел, так что я совсем забросил попытку. Ну да ладно, темы вдохновляющих игр, разных видов клеток и непрерывного пространства достойны отдельных заметок, а эта запись и так большой получается. Теперь, наконец-то, что касается самого проекта. Прежде всего, он переименован из Марoдера в Зону Контроля (Zone of Control). Сокращенно - ЗК/ZoC. Гитхабовское хранилище переехало в https://github.com/ozkriff/zoc</a>. Внешний вид с момента сдачи диплома изменился слабо и выглядит все это безобразие сейчас как-то так: </iframe></div> Собственно, да, я портировал это на android, хотя под линуксом и виндой тоже должно работать. Спасибо Skligus'y за его rusty-cardboard</a>, очень помогло поначалу, и Tomaka за его glutin</a> и android-rs-glue</a>. К сожалению, для сборки под андроид требуется ночная сборка rustc, потому что в android-rs-glue используются какие-то нестабильные штуки. Хотя надо перепроверить, может уже и стабильного компилятора хватит - ржавчина так быстро развивается :). Кстати, да, переписал с glfw-rs на glutin</a> - чем больше кода на ржавчине, тем прощe, особенно при сборке на разных платформах. Еще хотел со своих костылей вокруг OpenGL</a> перейти на glium</a>, но пока не осилил. Переделал с выделения через цветовой буфер на чистую математику - пересечение луча из курсора с плоскостью карты, бла бла блап. Уж очень много от времени отрисоки кадра оно сжирало, да и с шейдерами так меньше хлопот. Но это все про техническую часть. Что касается самой игры, то: два захардкоженых режима на одной карте с одним набором войск - против тупого ИИ или хотсит на двух игроков;</li> от одного до пяти членов отряда в клетке -отказался от идеи иметь несколько отрядов в слотах одной клетки, потому что так и не придумал, как это все нормально отображать и как этим управлять. Хотя, при введении зданий и летающих отрядов, наверное, придется тут усложнить ситуацию;</li> до двух активных очков атаки для стрельбы по прямому приказу игрока;</li> одно пассивное очко атаки для реакционного огня в чужой ход (как в x-com) + неиспользованные в свой ход активные очки атаки становятся пассивными;</li> вероятность поражения с (пока что) захардкожеными вероятностями попадания в зависимости от типа атакующего, защищающегося и местности;</li> кривоватый туман войны, который впоследствии, видимо, будут переведен на менее дискретный алгоритм;</li> заготовка системы боевого духа и подавления - каждый ход восстанавливается 10 очков морали, за каждую атаку снимается по 10, если мораль падает ниже половины - отряд не может стрелять;</li> разная стоимость движения по местности для разных отрядов;</li> два режима передвижения - быстрый и осторожный, который стоит в два раза дороже, зато не накладывает штрафы на точность при стрельбе и при попадании под огонь отряд не лишается оставшихся очков движения;</li> тестовый грузовик для транспортировки пехоты;</li> механика видимости из BA2 с двумя радиусами - "нормальная" и "отличная" видимость. Последняя позволяет увидеть скрытые юниты (например, пехоту в лесу);</li> атаки из засад, если атакующий изначально невидим, с бонусом к атаке и шансом не раскрыть свою позицию;</li> приказ "не стрелять" для отключения реакционного огня при организации хитрых засад или для разведчиков;</li> пока что только четыре вида отрядов: пехота - четыре человека, одна клетка отличной видимости, умеют тихориться в лесу;</li> разведчики - как пехота, только всего 2 человека, зато видят и бегают немного быстрее;</li> танк - громко стреляет и толсто бронирован, зато у него вообще нет отличной видимости (попробуй что через щели в броне рассмотреть) - без пехотного прикрытия рядом с лесом ему ездить не стоит;</li> грузовик - не умеет стрелять, очень хрупкий и подслеповатый, зато быстрее всех остальных отрядов и может перевозить пехоту;</li> </ul> </li> </ul> Ну, вот как-то так. Разработка, как видно, сильно затянулась</a> - - я-то хотел такое уже через пару месяцев иметь, ха! То ли мне просто лень, то ли времени и правда мало получается выделять, черт его знает. Уже мнооого раз полностью терял весь энтузиазм и забрасывал игру на пару месяев, даже пытался чего-то другое делать. Но потом возвращался, что бы все-таки надо довести до ума эту чертову ЗК :) . Да и вышеупомянутые игры сильно помогали с вдохновением) Вот, собственно, вся первая запись. Вряд ли я буду теперь пытаться делать недельные отчеты, скорее буду писать более мелкие заметки по настроению - регулярность вытягивает из любого дела весь интерес. Ну и писать тут буду, наверное, не только по делу - смотрите теги :) . Разработка Мародера - 2014.05.18 Sun, 18 May 2014 00:00:00 +0000 Почти дорисовал базового человечка, так лениво :) . Разработчики Ржавчины мутят чего-то страшное. Хотят убрать mut</code>, иммутабельность. Бррр! Разработка Мародера - 2014.05.11 Mon, 12 May 2014 00:00:00 +0000 Тревис все так и сломан. Потратил кучу времени, пока искал ![macro_export]</code> и тупил вокруг)) Запил MeshId</code> структурку, наконец-то. С горем пополам допилил error_context, выложил как отдельную библиотеку на гитхабе и использовал в мародере. И после отзывов переписал ее к чертям)) Сделал кое-какие кнопки. Криво, но работает. Тестовая кнопка - "конец хода". Перевел свои библиотечки и библиотеки bjz на rustc от rust-lang.org Разработка Мародера - 2014.05.04 Mon, 05 May 2014 00:00:00 +0000 Трэвис сломался и все никак не чинится. Все протухло :( . Почти добил ErrorContext</code>. Перенес на local_data</code>. Заменил все type = ...</code>, которые можно, на структуры. Разработка Мародера - 2014.04.27 Mon, 28 Apr 2014 00:00:00 +0000 Меня поплющило пару дней на тему перехода с 3д моделей на 2д маркеры. Заменил везде &str</code> на Path</code>, так правильней (ссылка на битсквидблог). Заменил структурки struct(MInt)</code> на struct(id: MInt}</code>. Шейдеры с 1.5 на 1.2, что бы можно было запускаться на OpenGL 2.1 без проблем. Перенес исходники в src</code> директорию, а всякое для работы в bin</code> директорию. Добавил в Makefile команду run</code>, которая переходит в bin</code> и запускает игру. Поправил систему слотов. Убрал MBool</code> в пользу обычного bool</code>. В этом был смысл для Си, но тут-то уже все есть. Почти доделал ErrorContext</code>, скоро попробую его внедрить. Разработка Мародера - 2014.04.20 Mon, 21 Apr 2014 00:00:00 +0000 Отпуск кончился. Хочется умереть :) . Забыл написать. На прошлой неделе появился первый отчет об ошибке, ура ура! Правда я хз что с ним делать :( . Наткнулся на серию классных постов об обработке ошибок в блоге битсквида. Сделал кое какое отображение 2д и 3д текста. Решил возвращать текст в экранных координатах, а для отображения в 3д сцене его плющить матрицами как надо. Для поиска всех gl вызовов и вывода только их названий: grep -oh 'gl::\w*(' visualizer/* | sort | uniq </pre> Добавил макрос (фу) verify!</code>, позаимствованный из kiss3d, для проверки gl::GetError</code> после каждого OpenGL вызова. Нашлась парочка ошибок. Надеюсь, это поможет запустить мародера на os x, а то неудобно. что отчет об ошибке столько времени уже висит. Сделал отображаемый пробел и поддержку нескольких строчек в текстовом кэше для font_stash. Камера в начале боя теперь не где-то с краю, а в центре карты. Разработка Мародера - 2014.04.13 Mon, 14 Apr 2014 00:00:00 +0000 На этой неделе у меня был отпуск, о даа. Наконец-то немного разобрался с pelican и начал приводить в порядок и выкладывать эти недельные отчеты на ozkriff.github.io, а то до этого они у меня только в gist`е лежали. По самому мародеру почти ничего не сделал, только выложил на гитхаб очень-очень базовую версию stb-tt-rs и кое-какой код интеграции в мародер. Но по факту текста в игре пока так и нет. Разработка Мародера - 2014.04.07 Tue, 08 Apr 2014 00:00:00 +0000 Аналогично с прошлой - ничего, только смотрю, что б Мародер собирался. Ну и вышел Rust 0.10, ура-ура! Хотя для меня это мало что меняет, все равно использую ночные сборки :) . Разработка Мародера - 2014.03.30 Mon, 31 Mar 2014 00:00:00 +0000 За эту неделю ничего не сделал, только слежу, что бы мародер собирался ночными сборками компилятора Ржавчины. Разработка Мародера - 2014.03.23 Mon, 24 Mar 2014 00:00:00 +0000 Сходил на Manowar, о да, нужно больше пафоса. Только теперь вообще ничего не слышу :) . Мучал glfw-rs, cgmath-rs и самого мародера, что бы они собирались с последней версией компилятора. Сложно было :) Брендан хочет, что бы cgmath-rs был исправлен не таким грубым хаком. Там могут быть косяки с NaN и +/-Inf. Но я туплю как сделать правильно. :( Мой грандиозный страйк помер :(, черт: Капельку поковырял текст. Решил, что не буду использовать cmr/hgl-rs, страшно мне. Лучше все-таки чего-то свое сделаю. Шрифты, шрифты: Сделал выделение отдельных отрядов в клетке: Разработка Мародера - 2014.03.16 Mon, 17 Mar 2014 00:00:00 +0000 Ну что ж. За эту неделю я почти ничего не сделал, времени на Мародера было не так уж много. Зато сходил на концерт Апокалиптики :) . Сделал простенькое и кривенькое перетаскивание карты средней кнопкой мыши. Надо будет еще допиливать. Вернулся к ковырянию шрифтов из kiss3d. Решил переписать font-stash на Rust. Пока сделал только базовые привязки к stb_truetype. Все свободное время в субботу-воскресение протупил с попытками обновить cgmath-rs под ночную сборку Ржавчины: изменения с min\max</code> для чисел с плавающей точкой. Пробовал городить страшные вещи с макросами, но пока так и не разобрался. Еще потыкал qapitrace и узнал, что gl::GetError</code> надо вызывать после каждого gl-вызова. Разработка Мародера - 2014.03.10 Tue, 11 Mar 2014 00:00:00 +0000 Ну, этот понедельник я считаю последним днем недели. Не может у меня неделя с выходного начинаться, это неправильно как-то. Теперь передаю информацию о изменениях размера окна в камеру, теперь изображение не сжимается по высоте или ширине при изменении размеров окна.</li> С горем пополам доделал и закомитил базовую версию поддержки нескольких отрядов в одной клетке. Правда, пока что выделить или атаковать можно только первого из них (того, что с индексом 0) и выделение вынесено на кнопку S</code>.</li> Задумался о системе слотов в клетке визуализатора.</li> Еще наткнулся на блог разработки Cogmind - http://www.gridsagegames.com/blog</a>. Выглядит офигенно, но ссылки на альфа версию или чего-то подобное я нигде не нашел, жалко.</li> Реализовал простенькую обертку над конфигурационными файлами.</li> Изменилась система сборки glfw-rs - вбил костыли в make_deps.sh.</li> Cmr сказал, что c_str</code> - плохая штука. Заменил на with_c_str(||{...})</code></li> анимации движения теперь не зависят от времени отрисовки кадра.</li> И добавил поворот отряда в сторону движения.</li> Исправил поворот камеры - теперь скорость вращения камеры не зависиот от размера экрана: что бы повернуть камеру на 360 градусов по горизонтали нужно двигать мышкой от левой границы окна до правой, не завсимо от размера окна.</li> Добавил класс MoveHelper, отвечающий за передвижение от точки до точки со скоростью, не зависящей от количества кадров в секунду, и использовал его во всех визуализаторах событий.</li> Удалил из визуализаторов событий методы start</code> - пускай все в new делается.</li> Добавил к анимации события атаки летящий снаряд. Ну как снаряд, хрень какую-то :)</li> Теперь отряды принадлежат к какому-то из игроков, над отрядами теперь висят страшненькие флажки.</li> На последок запек ambient occlusion вместо, кхм, "текстуры" "танка". Теперь намного лучше, как по мне.</li> </ul> Byzanz</h1> Гуглил про выкладывание видео в бложик, наткнулся на упоминания byzanz. Офигенно, теперь загажу все посты анимированными гифками! :) https://github.com/GNOME/byzanz</a> Github streak</h1> И да, github streak в 61 день, еее! 80 символов хватит каждому!</h1> Узнал про wc -L \*.rs</code> для поиска самой длинной строчки в куче файлов, прикольно. $ find src/core -name "*.rs" | xargs wc -L | sort -h 59 src/core/src/game_state.rs 59 src/core/src/player.rs 59 src/core/src/unit.rs 65 src/core/src/geom.rs 71 src/core/src/map.rs 72 src/core/src/partial_state.rs 76 src/core/src/pathfinder.rs 78 src/core/src/ai.rs 80 src/core/src/db.rs 80 src/core/src/fov.rs 83 src/core/src/dir.rs 84 src/core/src/fow.rs 91 src/core/src/internal_state.rs 93 src/core/src/filter.rs 121 src/core/src/lib.rs 121 итого </pre> Разработка Мародера - 2014.03.02 Mon, 03 Mar 2014 00:00:00 +0000 Так, что я сделал за эту неделю? Вообще, намного меньше, чем собирался :( . Ну, во первых, решил делать вот эти самые еженедельные записи. </li> Портировал из старых прототипов базовое путенахождение, причем оно происходит не на сервере, а на клиенте, основываясь на знаниях клиента о мире. Т.е., если на пол пути окажется скрытый юнит, то путь через его клетку все равно будет проложен, а уже при симуляции команды на сервере случится сюрприз в виде засады. Раньше: Теперь: Да, пока отряд никак не поворачивается при движении :( . </li> Немного привел в порядок gl_helpers</code>, вынес из него типы Texture</code>, Vao</code>, Vbo</code> и Shader</code>. Ну и спрятал вызовы привязок gl внутри этих классов. </li> Разделил все исходники на директории core</code> и visualizer</code>. Позже, наверное, сделаю их отдельными единицами компиляции. К первому отходит весь код, который не требует визуализации, т.е. сама суть игры, а визуализатор занимается полученеи ввода от пользователя и показом картинки. </li> Постарался сделать так, что бы после вызова конструктора объекта он уже сразу был готов к использованию, а не ждал вызова init</code>-подобного метода в неопределенном состоянии. </li> Добавил в интерфейс визуализаторов событий метод start</code> для, очевидно, начала визуализации события. </li> </ul> Разработка Мародера - 2014.02.23 Fri, 28 Feb 2014 00:00:00 +0000 Тому, что есть на данный момент до игры еще очень далеко. Пока что, по шкале от "демо OpenGL приложение с вращающимся полигоном" до "X-COM, HoMM, Кодекс Войны и др. большие пошаговые игры, которые пришли сходу мне в голову" Мародер находится на минимальном отдалении от левого края. На проект я потратил полтора месяца по часу-другому в день. Большую часть времени я изучал и игрался с Ржавчиной (которая язык программирования) и изучивал-вспоминал основы OpenGL. Есть стремная тестовая модель (вроде как танка), слепленная в блендере за пару минут и покрашенная там же, что бы проверить, как натягиваются текстуры: Других видов отрядов нет. Текстурки - png. Модельки - .obj (самый простой формат, что я знаю). Есть карта из одинаковых шестиугольников серого цвета. В каждой клетке может находиться один отряд. Работает простенькое выделение мышкой (color picking). По кнопке U</code> (_u_nit) в клетке, на которую указывает мышка, появляется новый отряд. Появляется при помощи простенькой анимации - поднимается из-под земли. Такие вот зомби-танки. Отряды можно выделять кликом по клетке, но визуально это никак не отображается. Выделенному отряду можно отдать приказ двигаться, кликнув по пустой клетке, но путенахождение не реализовано, так что он просто полетит по прямой к нужной клетке. Выделенному отряду можно дать команду атаковать, наведя мышку на другой отряд и нажав клавишу A</code> (_a_ttack). Очков здоровия, брони, точности и т.д. нет, атакованный отряд просто сразу умирает. Анимация смерти является противоположностью анимации появления - отряд уходит под землю. Очков действий у отрядов нет, атаковать они могут любое количество раз. По нажатию кнопки T</code> (end _t_urn) ход переходит к следующему игроку (хот сит) и ему показываются результаты действий противников. Отряды не принадлежат к какому-либо игроку и каждый игрок может отдавать приказы любому отряду. Строчек кода на все ушло ~3800. Собирается под линуксом на ночной сборке компилятора Ржавчины. Настроена автосборка на travis-ci.org и я стараюсь не давать коду отстать от ночной сборки компилятора больше, чем на день. Исходники хранятся на гитхабе https://github.com/ozkriff/marauder</a>, для текстур и моделей отдельный репозиторий - https://github.com/ozkriff/marauder-data</a>. Вооооот, так что делать мне еще очень и очень и очень много. :)

ozkriff's devlog

Zemeroth v0.6: Renown, Upgrades, Sprite Frames & Flips, Effect Icons, and Videos

Agent's Info Screen</h2> A basic fighter info screen was added:</p> </p> It's opened by clicking on a small [i]</code> button on the right from a fighter's type in the campaign menu:</p> </p> This screen allows the player to look up stats and abilities before recruiting or upgrading a fighter.</p>

Text Logo</h2> The game now has a (temporary?) text logo:</p> </p>

Zemeroth v0.5: ggez, WASM, itch.io, visuals, AI, campaign, tests

Other Game Rules Changes</h2> Spike traps were added. They're almost like fire tiles, but permanent.</p> </p> </li>

Gameplay Video</h2> So, putting these gameplay changes together:</p>

Tests</h2> One of the benefits of making a turn-based game is that you can relatively easy separate the logic from the visuals and cover the former with tests.</p>

Zemeroth v0.4: Abilities, Lasting Effects and New Unit Types

Gameplay Updates</h2>

Wounds reduce attacks by one</h3> New rule: every successful attack now reduces target's attack by 1. It's small but important change because it increases the value of initiative and is relied upon by many abilities.</p>

Strong Attacks</h3> In the previous version all attacks were dealing 1 damage. Now, Swordsman</strong> and Hammerman</strong> (see below) deal 2 damage points per hit.</p>

Zemeroth v0.0.3: Jokers, Rancor, Blood and more

Dots</h2> To show the most important dynamic information about units on the map "Dots"</strong> were added</a>.</p> </p> The current legend is:</p> "Strength" - green;</li> "Attacks" - red;</li> "Moves" - blue;</li> "Jokers" - purple.</li> </ul>

RestructuredText -> Markdown</h3> For a long time, I was trying to avoid the use of MD.</p>

ZoC is dead. Long life Zemeroth.

Häte2d</h1> About reusing ZoC’s codebase...</p> I’m a fool who don’t learn anything and totally ignored the third rule from finishing-a-game article:</p> 3. DON’T ROLL YOUR OWN TECH IF YOU DON’T HAVE TO</p> </blockquote>

This Month in ZoC - 2017.01.24

Gameplay screenshots</h1> </p> </p>

This Month in ZoC - 2016.08.22

Basic smoke screens</h1> https://github.com/ozkriff/zoc/issues/160</a></p> </p> </p> </iframe></div> Water tiles</h1> https://github.com/ozkriff/zoc/issues/204</a></p> </p> GUI updates</h1> Replaced unit ids with unit type names</li> Added hit chances</li>

GUI updates</h1> Replaced unit ids with unit type names</li> Added hit chances</li>

Bonus 1: ZoC on android</h1> </p>

Bonus 2: memoir44-mockup of smoke demo map</h1> </p>

Градообразующие объекты

Чертов макет!

Пришельцы воруют мое время

Первая половина Недели Блендера

Выходные, размеры, Тарантино и ненависть к людишкам

Несколько моделек и вечная смерть

Очередной перезапуск

Мастерплан и мотивация

Форы

Сложности с crates.io и конфиги из открытого космоса

Перезапуск журнала

Разработка Мародера - 2014.05.18

Разработка Мародера - 2014.05.11

Разработка Мародера - 2014.05.04

Разработка Мародера - 2014.04.27

Разработка Мародера - 2014.04.20

Разработка Мародера - 2014.04.13

Разработка Мародера - 2014.04.07

Разработка Мародера - 2014.03.30

Разработка Мародера - 2014.03.23

Разработка Мародера - 2014.03.16

Разработка Мародера - 2014.03.10

Byzanz</h1> Гуглил про выкладывание видео в бложик, наткнулся на упоминания byzanz. Офигенно, теперь загажу все посты анимированными гифками! :)</p>

Разработка Мародера - 2014.03.02

Разработка Мародера - 2014.02.23

Gameplay Video</h2>
So, putting these gameplay changes together:</p>
</a></p>
This is a piece of a campaign mode playtest: battles 3, 4, and 5.</p>

Wounds reduce attacks by one</h3>
New rule: every successful attack now reduces target's attack by 1. It's small but important change because it increases the value of initiative and is relied upon by many abilities.</p>

Strong Attacks</h3>
In the previous version all attacks were dealing 1 damage. Now, Swordsman</strong> and Hammerman</strong> (see below) deal 2 damage points per hit.</p>

Gameplay screenshots</h1>
</p>
</p>
@ozkriff on Twitter</a></p>

Bonus 1: ZoC on android</h1>
</p>

Bonus 2: memoir44-mockup of smoke demo map</h1>
</p>

Weekly links: 1</a>, 2</a>, 3</a>, 4</a>.</p>
https://github.com/ozkriff/zoc</a>, @ozkriff on Twitter</a></p>

Byzanz</h1>
Гуглил про выкладывание видео в бложик, наткнулся на упоминания byzanz. Офигенно, теперь загажу все посты анимированными гифками! :)</p>
https://github.com/GNOME/byzanz</a></p>