Concept Art Updates

Exploring some new styles. The first image was built tile by tile using Tiled. The inspiration came from old Japanese maps. The “mood” was exciting at first but it felt to me like it overpowered the design of the game.

The change in perspective (2nd image) felt like a breakthrough. The Prince lends itself to symbolic art much more than I realized. This was a very unpolished doodle but it aligns much better with the quick, casual nature of the gameplay.

japanese island isometric concept

Screenshot 2015-05-18 17.22.48

Animation Iterations

We’re updating the homepage in an effort to get something accomplished this week. Just kidding – really we’re starting an email database and the homepage needs to streamline viewer subscription. While the hood was popped, I went ahead and upgraded a handful of other assets. After spending an inordinate amount of time on animating a header graphic, I thought it might be cool to share the iterations. Take a look..

Here’s my static header image.

static homepageThe goal is to make an animated gif in which the sun rays rotated. It’s a pretty big graphic so file size is definitely an issue. However, for the first pass, we just want to get a benchmark. Enter “header-1.gif”

header-1.gif

robot and city 1Okay not too bad. Length is one second and the timing is 24 FPS. Loop timing is off though — you can see a little “tick” when it restarts the loop. File size is 567 KB which is WAY too big. Let’s see what happens when we cut the frame rate down.

header-2.gif

robot and city 2Whoa. Feels like watching Wheel of Fortune. In this version, the frame rate is 24 FPS but there’s only 4 frames. Let’s see what happens when we match make the frame rate AND the frame count equal (both at 4).

header-3.gif

robot and city 3Love it now that I’m looking at it (several hours later). But in the moment, it looked way to choppy.

header-4.gif

robot and city 4Seems too fast to me when I look at it now. At the moment of creation, though, this looked great compared to my first few iterations. At that point I was happy with the sun rays and decided to add some motion to the robot.

header-5.gif

robot and city 5

Overboard. Added several changes at once: back and forth movement to the robot, blinking eyes and motion blur. Since we’re still just dealing with 4 frames of animation, a small motion blur effect was added to every other frame to add the shaking effect. I wanted it to seem like the ground was shaking as the robot walked. Fun to see this but it needs to be dialed back.

header-6.gif

robot and city 6

Took out one of the blurred frames. Now the ground only shakes for every other rock/footstep he takes. Also dabbled with the eye blink. Still too much.

header-7.gif

robot and city 7Reduced the frame rate a bit to slow down the animation. It’s better but still not where it needs to be. I ran it by Steve and he suggested the stomping might be too much for the homepage. We want people to feel relaxed, happy and engaged.

header-8.gif

robot and city 8

Went back to the smooth higher FPS look. Steve said we can make the file size work using technology of which I’m un-aware. Who knew. It’s nice to have a programmer as a partner. Eyes are kawaii.

header-9.gif

robot and city 9Here’s the final… for now. After writing this, I can see about 5 more things to change/add but it’ll have to wait. On to the next thing!

Screenshot Saturday: Alpha 1

 

Screen Shot 2015-02-28 at 11.53.37 AM

Our gameplay is basically split into two halves. The first half involves exploring a 10×10 map and setting up castles. Read more about the rules and gameplay here. This week we got an alpha prototype running and were able to play 1 vs. 1 over the internet. In the long term, the game will have full color isometric graphics but we decided to make an ascii version to test and polish gameplay before building it out. So it may not look like much, but this is a HUGE milestone and we’re really excited. Thanks so much to our programmer, Steve.

Raster VS. Vector Graphics

vector raster castle artWe’re in early alpha right now and the art style has yet to be finalized. I love the loose explorational aspect of this phase of visualization and decided to use my two favorite programs (Adobe Illustrator and Adobe Photoshop) to flesh out a little castle drawing from a previous post. Results (right) can be technically classified as Vector and Raster based renderings. Why do I qualify their descriptions with the term based? Well, here’s where it can get a little confusing. Let me explain.

What’s Raster, Precious?

A raster – or bitmap – image is made up of individual pixels built on a dot matrix (a.k.a. a grid).  For example, a 100 pixel by 100 pixel image has 10,000 individual squares (pixels). The file format stores a color value for each specific square. When zoomed in, it’s easy to distinguish the individual squares. We all refer to this “look” as pixelated. When zoomed out, the pixels all blend together to form the shapes, tones and values that make up a picture. Usually, our brain doesn’t notice any of these details and just says, “Hey! That’s my friend Bryan”. Additionally, when it comes to creating game art, raster-based programs traditionally lend themselves more to textures and detail.
Common Raster Formats: JPEG, GIF, PNG, BMP

What’s a Vector, Victor?

A vector image, on the other hand, is described in terms of a mathematical equation. In the case of our 100 by 100 graphic, the computer DOESN’T store individual pixel values. Instead, it renders the shape according to the equation. This is often visually displayed during creation as a path with nodes. The math talk is confusing, but beyond saying it’s a “mathematical equation” there is minimal math use involved for the artist. The main benefit is that, inside a vector-friendly program, the size of the image can be scaled infinitely without loss of quality (i.e. blurry pixelation). Also, file size is significantly smaller. One caveat, vector graphics programs (like Inkscape and Illustrator) are used mostly for the initial creation of images/graphics. For final implementation, in most 2D applications, they have to be exported to raster. For example, in my day job as a graphic designer, I often design logos in Illustrator as vectors. However, when I’m finished and need to provide something for the client to use in print and on the web, I give them JPEGs, PNGs, etc. They also get a vector (master) version but usually the only time it gets used is for professional print jobs.
Common Vector Formats: EPS, PDF, AI, SVG

2 blue circlesA Little Note of Caution

So what’s confusing? Vector and Raster are technical terms that describe a file’s format, BUT because of the nature of the vector process and popular trends, it’s easy to start using that term to describe a graphical style instead of the format. Look at these two blue circles. One is vector rendered and the other raster. Can you tell the difference? Doubt it. Our two terms can’t accurately be used to describe them stylistically even though their construction was based on their respective processes. This is not the case for the castle renderings. The smooth lines and flat color shapes of the castle on the right stylistically look digitally created.. in a word, well, vectorized. But technically, I could’ve made both of these castle images in either a bitmap or vector program. It’s a minor detail but important to understand before starting image creation. You don’t want to spend a ton of time creating art that can’t be re-scaled. For example, I whipped up the castle on the left in photoshop for fun. When I finished, I really liked it but because I didn’t plan ahead, I can’t scale this image without losing detail. A best practice in this case would be to always work on a large canvas.

That’s all for now. Much more could be said (and has been). There are so many articles on this topic. A quick google for “Raster VS. Vector” popped back this, this and this. There are hundreds more.

Good luck. By the way, which castle style above do you prefer?

Tired of jumping through hOOPs

jumping through hoopsEverybody who writes code, whether they’re self-taught or took classes in school, encounters the concepts of object-oriented programming. It’s in every book, it’s behind most APIs, and it’s been the focus of language designs for the past 20-25 years. In both academia and the industry, the conventional wisdom is that OOP is the best, maybe only, way to manage a large codebase. But that hasn’t been my experience, and it hasn’t been the experience of many people, and I think many coders, especially in game programming, are starting to look for alternative approaches to code organization. What I want to do here is go over a couple of aspects of OOP that I have personally found to be roadblocks to getting things done, and then look at some information for alternative approaches.

OOP vs Experience

The problems engendered by OOP vary from person to person, but in my experience there are two main tenets of OOP that keep causing problems when I use them for the construction and organization of code: 1) modelling after real-world objects , and 2) the insular functioning of objects. The first is problematic because aiming to create code that models real-world objects almost always leads to unnecessary abstractions that conceptually muddle the aims and functioning of the program. Our code doesn’t work with “real-world” objects. It works with data. Inputting and outputting data. Of course, wrapping data into abstractions is almost always beneficial at some point, e.g. when working with a Color object is preferable to working with independent RGBA floats, but the abstractions should come about naturally from the needs of the code, rather than being designed up front from what we expect the code to be. I feel like starting a project with a bunch of UML diagrams ignores the fact that I don’t know what the final state of the code will be, even if I know what the program will do.

The second tenet that I find problematic probably has a better technical name, but what I mean by “insular functioning of objects” is that typical OOP takes the mindset of working on one object at a time, usually in a hierarchy. I’m thinking of a scene graph, for example: I take one entity and update it. Then I take each child entity, update those, and then follow their child entities, and so on, until I’ve covered the entire graph. This approach has some advantages, but I think that when I’ve followed this design, I’ve done so because that’s the abstraction that I was starting with, not because the data I was working with was hierarchical. In fact, what I usually find is that the code only needs to work with parts of entities at one time. For example, I need just the position and velocity to update position. Or I just need the time keeping and textures to do the animation. But the code almost never needs the entire entity with all its member data. This approach is closer to how we normally handle particle systems. And the big reveal here, at least for me, is that the easiest, most direct thing to do is almost always the particle system approach, while typical OOP would have us starting with a scene graph.

Alternatives

Component-Entity-System: The component-entity-system (CES) approach was my first step away from the traditional BaseClassSubClassSubSubClass inheritance model, and it has saved me many, many hours of frustration. Adding data & functionality through inheritance leads to tightly coupled systems, and this makes growing the code virtually impossible. CES, on the other hand, keeps entities as plain containers of components, adds data through components, and functionality through systems. Components are then be added and removed from entities as needed. Systems typically keep track of components and do the work of updating them. Plenty of people are writing about CES, but I found this to be a great introduction, this to be really useful in getting into more details.

Data-Oriented Design: Data-oriented design (not to be confused with data-driven design) starts with the premise that the purpose of writing code is move and manipulate data, and any abstractions that aren’t needed for that purpose are unnecessary at best, and time-consuming distractions at worst. Data-oriented design typically has a two-fold benefit: it clarifies the purpose of the code you’re writing, and it (potentially) makes it much faster through optimized CPU cache usage. If you remember from my last post, we’re currently working in JavaScript and PHP, so optimizing for the CPU cache isn’t something I can do at present. But I do find that thinking in terms of “get this data in” and “get this data out” to be useful. It keeps me away from writing code for the sake of better abstractions. For more information here, I like this article and this talk. In the talk, Mike Acton spends a lot of time going over ways to better think about cache usage, which is (really) useful if you’re working in C/C++, but he also spends some time on modelling real-world objects vs modelling the data.

Compression Driven Programming: Compression driven programming is also known as semantic compression, and it is founded in the idea that structures in your code should emerge from their usage, as opposed to being designed up front. The concept of compression here is the same as GZIP compression. Start by writing your code to do what needs to be done, without functions or data structures. When you find that some code gets used more than two or three times, then that’s a candidate for “compression”. Pull it out and make it a function. Likewise, when you find that some data always gets passed around together (like the RGBA floats of a color), then that’s also a good candidate for “compression”. Pull it out and make a struct or class. Following this approach ensures that you only have the abstractions that make sense in your code. The article that everyone references is this one by Casey Muratori. I think this commentary on that article is good for pointing out that there are good and bad ways to compress and come up with abstractions. And finally, in this video (also by Casey Muratori), he talks about how to use compression driven programming throughout a project to work towards an unknown goal. (That video is kind of long, so I deep linked the relevant discussion, which lasts about 10-12 minutes.)

Conclusion

The alternatives here certainly aren’t mutually exclusive. In fact, I think we can take key ideas from each to become more effective and efficient at creating code. A simplistic but useful way to look at these would be to say that Semantic Compression tells us how to identify code and data that’s worth abstracting. A Component-Entity-System approach gives us a flexible framework for organizing those abstractions without getting tangled up in an inheritance hierarchy. And Data-Oriented Design gives guidance on how to work with the abstractions in a straightforward way that works well with memory.

OOP probably has its place somewhere. Maybe in GUIs? The bottom line, of course, is to do what works best for you. Just don’t let conventional wisdom lead you down a rathole of theoretical correctness when clean, working abstractions can be had much more simply.

A Daring Move:
Rewriting the Prototype from Java to JavaScript

rewrite_angel_and_demon

The Gambit

This week we decided to rewrite the client prototype and change its run target. The prototype is not even done, and we’re already rewriting. This is usually taken as a bad sign in a project, but I think rewriting going to pay off. That’s the gambit.

I wrote the initial code in Java, and it was targeting the console. When the prototype was ready, I would send a JAR file to Andrew, and we could start work on refining and balancing game mechanics. Now the prototype will be in JavaScript, and the text output will be written to a <div> instead of a terminal. It’s the same basic idea, so why the rewrite? These are the pros and cons.

Pros

  • Faster Playable Iterations
    I know there will be bugs that need to be fixed. And I know we’ll want to try different settings for the game. Making changes playable in the JAR means: building the JAR, finding it on the filesystem, sending it through email or Dropbox, and waiting for Andrew to download and run. Making changes playable on the web means hitting save and telling Andrew to reload the page.
  • More Configurable Output
    Doing a console version was supposed to focus on game mechanics, as opposed to graphics, animations, UI, etc. Good idea in theory, but I ran into some problems.
    For example, there’s no universal way to clear the terminal in Java. Best thing you can do is check the OS at runtime and manually send the command: Runtime.getRuntime().exec("cls") for Windows, Runtime.getRuntime().exec("clear") for everyone else. But that works neither in the IDE output, nor in mintty. It’s not a huge deal to have infinitely scrolling text, but compare that to document.getElementById('id').innerHTML = ''. Advantage HTML.
  • A Weak, Dynamic Type System
    This is something that usually drives me crazy about JavaScript, but this early on in the process, I can see the advantage. The server side code is changing everyday, and with JavaScript I can just take whatever JSON string the server sends back and start using the values. In Java, whenever the server sends back new data, I need to change class definitions, track fields that get renamed, parse String to int, etc.

Cons

  • The Rewrite Itself
    The rewrite took about 2 days, and that time could have been spent on new functionality.
  • A Weak, Dynamic Type System
    What’s an advantage in the earliest stages is also a drawback once the code starts getting a little complex. There’s no way to see what’s really in an object until runtime. This gets so much worse with 3rd party libraries. What’s in the jqXHR object, for example? The jQuery docs here are really frustrating. I kind of just want a list of member variables and member functions, and it’s easier to get that from Chrome’s Dev Tools than from that documentation.
    A stronger type system lets a Java IDE provide most of this information, but I haven’t found one that can do the same for JavaScript. Maybe this is why people like WebStorm so much—I haven’t tried it. If it can do that, then it’s probably worth the $50. Anyway, </rant>.

Conclusion

So we obviously thought the move would be beneficial enough that we decided to commit the time to it. Fortunately nothing unforeseen popped up, and the rewrite didn’t take too long. I think the trickiest part was adapting the logic from Java’s synchronous (new URL(url)).openConnection().getInputStream() to jQuery’s asynchronous $.getJSON(url, callbackFunction).

So what do you think? Are there pros or cons that I missed? Should I have just used Java Web Start instead? (Just kidding.) Feedback is welcome. Hit us up in the comments, or @robotfriendgamz.

feedback

Rules for The Prince

rules for the prince

OBJECT OF THE GAME:

Capture the opponent’s Prince. This is accomplished by destroying the Castle in which the enemy’s Prince is hiding.

prince surrenders to princeQuick Summary of Gameplay:

The Prince is a 10-15 minute turn-based strategy game played on a 10×10 tile map. It’s a mini “4X” game split into two phases: Exploration & Battle. In Phase One, you explore for resources and build 5 castles in strategic locations. In Phase Two, you deploy your resources offensively/defensively, guess where the enemy’s Prince is hidden, and attack the enemy.

Games We’re Taking Inspiration From:

  • Civilization V
  • Settlers of Catan
  • Battleship
  • Chess
  • Poker

prince sees island in telescopeRomantic Background Story:

You are the Prince of an expanding Kingdom and your father has sent you, the Imperial Guard, and some troops in search of new lands to colonize. After months on the open ocean a thin strip appears on the distant horizon, and soon your fleet is near enough to smell the sweet vegetation of rich, uninhabited island. “At last!,” you think, “This is Heaven.” You know the king would be pleased. You send out a scout and prepare to disembark. But in the night, the scout returns with the unfortunate news that another fleet is preparing to land on the other side of the island! Thinking fast, you decide to lead your troops immediately to find the best places to build strongholds.

This island will be yours—by force, if necessary. There’s not a moment to lose! Now, where should you and your scouting party land?

GAMEPLAY:

Phase 1: Explore & Build

Click to Enlarge
  • Turn 1: Players each land their Prince on a coastal tile (see Map). The Prince can see the terrain on all adjacent tiles. All other tiles remain shrouded in fog of war.
  • Turns 2+: For the remainder of Phase 1, the Prince can move one tile in any direction. After the Prince moves, the player has the option to build a Castle on any exposed tile. Both players have 5 Castles each.

The terrain consists of several tile types (mountains, hills, forest, etc) and may have one of a few possible resources: iron (offensive points), stone (defensive points), and gold (bonus points).

After the final Castle has been deployed, the Prince is no longer in play as an explorer piece. When both players have placed all 5 Castles, Phase 1 is over, the map is revealed and it’s time for battle! On to Phase 2.

Phase 2: The Battle!

Phase two consists of a series of battles, one per turn. Each battle has two parts (A & B):

  1. Hiding the Prince and placing the Imperial Guard.
  2. Distributing resources to offensive or defensive use for each castle and planning the attack.

5 castles

Phase 2-A: Hiding the Prince

  1. First, review strengths and defenses of your Castles.
  2. Now hide the Prince in any one of your Castles. The opposing player won’t know where your Prince is located. But choose carefully! If the Castle holding the Prince is destroyed during the battle, you lose the game.
  3. Next, place the Imperial Guard in any one of your Castles. This can be the same Castle that now hides the Prince, but keep in mind that the location of the Imperial Guard is shown on the map, so your enemy will know where you’ve place the Guard. The Imperial Guard completely shields its Castle from the first enemy attack, no matter the strength of the attack.

After both players have chosen Castles for the Prince and the Imperial Guard, this part of the turn is over. Each player can now see the location of the other’s Imperial Guard. (See Map 2)

cannon battlePhase 2-B: Battle

  1. Observe where the enemy’s Imperial Guard is stationed. The Imperial Guard greatly improves that Castle’s defenses.
  2. Select your first Castle. Offensive points, defensive points, and bonus points are determined by the iron, stone, and gold around the Castle. Let’s say this one has 4 offensive points, 5 defensive points, and 3 bonus points.
  3. Assign bonus points, which can be split between offense and defense. For this Castle, you can use your 3 gold to boost to end up with any of the following:
    • 7 offense / 5 defense
    • 6 offense / 6 defense
    • 5 offense / 7 defense
    • 4 offense / 8 defense
  4. Assign the enemy castle that this Castle will attack. The attack will use all of your Castle’s offensive points.
  5. Repeat steps 2-4 for your remaining Castles.
  6. Finally, assign the attack order for the battle. For example, Castle 3 goes first, then Castle 5, then 2, then 1, then 4. The order is important because the enemy’s Imperial Guard will completely rebuff the first attack on its Castle.

When both players are finished assigning resources, the Battle begins and both player’s attacks happen simultaneously. In the aftermath, players review the damage they’ve been dealt, and the damage they’ve wrought. A Castle’s damage is calculated by subtracting the Offensive Points used against it from its Defensive Points. If the Defensive Points drop to zero or below, the Castle is destroyed.

If both Princes are still alive, the next Battle begins. The game ends when one player destroys the other’s Prince. If both Princes are destroyed in the same round, it’s a tie.

So that’s it! We’re aiming for a quick, fun 4X experience. The concept is constantly evolving and if you have any thoughts, please leave feedback below or email info@robotfriendgames.com.

feedback