Firework - zaproszenie do Partnerstwa

Dzień dobry,

Nazywam się Jan i zajmuje się Business Development w Firework (fireworktv.com) - nowej, rewolucyjnej platformie krótkich wideo prosto z Doliny Krzemowej. Firework jest amerykańską odpowiedzią na rosnącą popularności wideo w formacie 30-sekundowym. Mamy bardzo wysokie zaufanie wśród inwestorów, dlatego w pierwszej rundzie udało nam się uzyskać $30M funduszy m.in. od Lightspeed Ventures, który był pierwszym inwestorem Snapchata.

Wyróżniamy się przede wszystkim wysoką jakością contentu i profesjonalizmem twórców. Nasza baza składa się już z ponad miliona profesjonalnych wideo stworzonych przez 400,000 twórców. Widząc gwałtownie rosnące zapotrzebowanie wśród wydawców internetowych na wysokiej jakości wideo, stworzyliśmy narzędzie nowej generacji - Firework Network. Jego zadaniem jest wykorzystanie wysokiej jakości contentu do celów marketingowych. 

Proponujemy partnerstwo B2B, gdzie my dostarczalibyśmy bardzo wysokiej jakości, 30 sekundowy content z naszego Feed'u. Po co? Co 3-4 wideo byłoby profesjonalną reklamą, z której Firework i Państwa strona dzieliliby się zyskami. W przeciwieństwie do mało pasujących do strony Google Adsów my możemy przygotować specjalnie dostosowaną do tematyki strony Playlistę.

W związku z powyższym, rozmawiamy z wybranymi wydawcami i blogerami, którzy staliby się naszymi partnerami w Polsce. Jeśli mają Państwo własny content, możecie go wykorzystać do promocji na Waszej stronie, lub nawet na innych stronach podłączonych do Firework Network.

 

Przykładowe wideo z różnych kategorii: https://firework.ispringcloud.com/acc/Wm82ZGIzMzkxMA/s/33910-3k3Mi-ozbUQ-B5mWu

 

Przykładowa implementacja Firework Network na stronie: https://letsott.com/, lub na polskiej stronie https://redmik.pl/

W załączniku przesyłam krótkie podsumowanie Firework Network. Jeśli jesteście Państwo zainteresowani tym tematem, prześlę więcej szczegółów.

 

Pozdrawiam,

Jan Smardzewski Business Development

jans@loopapps.com

+48 502 593 480

fireworktv.com

Tech Book Face Off: How To Design Programs Vs. Structure And Interpretation Of Computer Programs

After reading and reviewing dozens of books on programming, software development, and computer science, I've finally come to a couple of books that I should have read a long time ago. I'm not quite sure why I didn't read these two books earlier. Distractions abound, and I always had something else I wanted to read first. I still wanted to see what they had to offer, so here I am reading How to Design Programs by Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi and Structure and Interpretation of Computer Programs by Harold Abelson, Gerald Jay Sussman, and Julie Sussman. As I understand it, these books are meant to introduce new students to programming so not reading them until now will probably make it difficult to accurately critique them from the perspective of the target audience. I'm still going to give it a try.

VS.

How to Design Programs

While I have read many programming books as ebooks on my Kindle, this is the first book I've read as an online book. It's available in print version, but the online version looked nicely formatted and was heavily cross-linked, which was quite helpful. Also, since the book was right alongside my code editor, I could easily try out the problems and copy-paste code into the editor to run it.

The programming language used in this book as the vehicle for learning was a variation on Scheme called BSL (Beginning Student Language) that had heavy restrictions on the language features available for use. For example, lists could not be constructed with (list <list of elements>) or '(<list of elements>), instead needing to be built up from (cons <element> <list>). These and other features were added with BSL+, ISL (Intermediate Student Language), and ISL+ as the reader progressed through the book.

I was not a big fan of this approach, since it was tedious to learn the wrong way first (or at least the way nobody actually writes code) and then learn the right way that also makes more sense. Starting with the reduced forms of the language didn't add anything to the explanations, and it mostly served as a point of frustration as the reader was forced through unnecessary tedium until the nicer language features were introduced. It was also not clear by the end that ISL+ was equivalent to the full Scheme programming language, so by the time the student reached the end of the book, they wouldn't even be sure that they had learned a real programming language.

The book was quite ambitious, since learning how to design programs starting from square one actually involves learning three almost distinct things at once: the syntax of a programming language, how to write code, and how to program. The first task is about learning what a programming language is, what keywords and punctuation are available, and what it all does when put together in the correct structure. This task alone can be overwhelming for the new student. Then, the second task, learning to write code, involves taking a small, well-defined problem statement, thinking up a solution to it, and translating that solution into code that can execute in the newly learned programming language. Normally, once some part of the language has been learned, the first two tasks can be done together, and they support each other as the student practices them both.

The third task, learning how to program, is a much deeper activity that takes a much longer time to become proficient. Learning how to program is not just about solving bigger problems that may not be self-contained or well-defined. It's about learning how to organize all of the required code to solve the problem in a way that makes that code easy to understand, is less likely to suffer from bugs, is testable (and tested), and hopefully is flexible and extensible. I'm not convinced that this book taught this much more advanced skill, or at least not thoroughly.

The book starts out with a little prologue chapter entitled "How to Program." It gives a short introduction and a few examples of how to write some simple programs in BSL, and here the authors try to get the reader excited about what they'll be learning in the rest of the book. I had some misgivings about it. They have a strange way of trying to connect with the reader by disparaging various subjects that the reader is likely taking in school, or at least has fresh memories about, like physics:

Physics?!? Well, perhaps you have already forgotten what you learned in that course. Or perhaps you have never taken a course on physics because you are way too young or gentle. No worries.

I don't understand this kind of writing. It's not cool and it's not helpful to pretend to joke along with students about how much physics or mathematics or any subject sucks. It drives me nuts. Why can't we encourage students to take more of an interest in these subjects by showing how the knowledge can be useful, interesting, and dare I say, fun?! Thankfully, these comments don't continue in the rest of the book, but it's still irritating that they subtly perpetuate this anti-learning bias. It ended up coloring my opinion of the book in a negative way.

The rest of the book is split into six major sections with "intermezzos" between each section. I'm not quite sure why the intermezzos are there because they just seem to continue on with more topics that would fit in as additional chapters within the six sections, but that doesn't matter much. The first section introduces BSL features in more detail than the prologue, and it also lays out the recommended steps of a design process in chapter 3. These steps are touted as the steps for how to design a program, but they're really steps for how to design a function. The process is fine as far as it goes, but it doesn't really scale to large programs. This process is used and refined throughout the book.

The first section only introduced language features that allow for fixed-size data, so the next section introduces lists and recursion. It's a whole five chapters on lists, including basically a whole chapter of problems for the reader to solve. I don't remember lists being quite so hard to understand that it would require five chapters to adequately get the point across, especially with lists being a fundamental data structure of Scheme. Sorry, BSL+. Part of the problem is that the authors seem to explain things in as many words as possible. The text ends up plodding along with slow, tedious explanations, some of which don't even make much sense.

Another part of the problem of understanding in this book is the poor choice of variable names. When the authors are not using single-letter names (shudder), they're using names like alos. What is alos? Is it like, "Alos, poor Yorick! I new him, Horatio?" No, that's not right. That would be 'alas.' Instead, alos means "a list of strings." But why not just use list-of-strings, or even strings if you're into the whole brevity thing. The point is, these super abbreviated and truncated variable names make things more confusing than they need to be, because you have to keep the translation to the full name in your head along with the meaning of the variable and the rest of the code. Using full words for variable names makes the code so much more readable and understandable. It's not like we're working under any space constraints with the text of the code, except for the constraints of our own working memory.

The third section goes into detail on functions and how they enable abstractions that will make the programmer's life easier. Abstractions allow the programmer to solve low-level problems once and then think about harder problems from a higher level. It's a critical programming skill to learn. This section follows a similar format to the last one, with four chapters on functions done in excruciating detail, one of which is full of problems for the reader. We also advance to ISL for this section, and near the end we achieve the final level up to ISL+. Yipee! I remember hating when textbooks would introduce one way of doing things and then later contradict themselves and reveal the real way of doing it. This failing is worse with simplified languages, so I'm pretty tired of "student languages" by now.

The next section covers intertwined data, which is a convoluted title for a section that doesn't have a strong theme. The chapters in this section range from introducing trees to building a simple interpreter to processing multiple lists in parallel. The fifth section focuses on recursion for five chapters, and here they make the distinction between structural recursion, which is based on scanning lists, and generative recursion, which is more general and doesn't use lists as the looping mechanism. The final section discusses accumulators that are used with recursion to enable calculating properties of data that requires keeping track of additional state during the recursion. It's basically passing extra state variables in the recursive call in order to calculate aggregate or cumulative values on the data. All of these sections continued to have chapters near the end that were filled with extra problems for the reader.

This book was super long at nearly 750 pages—one of the longest programming books I've read in a while—and it did not seem like it covered enough ground to warrant that length. There were also 528 problems in total, so a huge amount of practice if the reader worked through all of the problems. Most of the problems were pretty decent, and they stayed relevant and reasonable for the material covered beforehand. But the book as a whole didn't hold up to its goal of teaching the beginner how to design programs. Learning how to program is a huge undertaking, and I don't believe it's possible to adequately cover that whole process in one book. On top of that, the level of discussion in much of the book was too complex for the beginner, and it would just as likely serve to confuse them as to teach them. Conversely, it doesn't seem to work well as a second programming book, either because it is so slow and tedious and long. By the end all we've learned is the basics of Scheme, lists, functions, and recursion. The Little Schemer taught much more in a more entertaining way in less than 200 pages. I can't recommend slogging through this book instead.

Structure and Interpretation of Computer Programs (SICP)

This book was the textbook for the entry-level computer science course at MIT for a number of years. I, unfortunately, was unaware of it until after I had finished college (not at MIT) and had come across it mentioned in a blog post by Steve Yegge, I think. Ah, yes, here it is. Apparently, that's also where I got the idea to read How to Design Programs, but fortunately, SICP was a better recommendation. I also didn't have the same issues with the book's humor that Steve did. I didn't mind the silly names of the students in the exercises, (you always know that Louis Reasoner got it wrong; you just have to figure out how) and some of the other jokes were actually kind of funny:

In testing primality of very large numbers chosen at random, the chance of stumbling upon a value that fools the Fermat test is less than the chance that cosmic radiation will cause the computer to make an error in carrying out a "correct" algorithm. Considering an algorithm to be inadequate for the first reason but not for the second illustrates the difference between mathematics and engineering.

I mean, come on. That's not half bad for a computer science joke. The majority of the book was not about fun and games, though. It's a serious book on introducing the computer science student to how programming languages—particularly Scheme—work.

SICP is split into five fairly balanced chapters. Each chapter starts off easy with an introduction to the material covered in the chapter and more detailed explanations of the mechanics of Scheme or the interpreter or whatever is the topic for the chapter. As things develop, the difficulty ramps up until near the end you can feel your brain going numb and draining out of your ears. Then you get a breather at the beginning of the next chapter with another gentle introduction.

The first chapter starts off with the requisite intro-to-the-language stuff that every book for a new programming language needs. After covering Scheme's operators and primitives, we move on to functions and immediately jump into recursion. By the end of the chapter we're learning about how to pass functions around as arguments and return values, and I wonder how an entry-level student could really grok all of this in a semester course. This is just chapter 1!

Chapter 2 teaches us all about how to structure and process data in Scheme. Since the fundamental data structure in Scheme is the list, this means we're going to get very comfortable with list processing (which is how Lisp gets its  name, see?). Between these first two chapters, we gain a thorough understanding of the foundations of Scheme and how to put together Scheme programs to do interesting things with data. Even after reading so many books on programming and practicing it in the field for a couple of decades, I was quite enjoying this "beginner" programming book.

Helpful exercises are interspersed with the text throughout the book, generally at the end of each subsection, and they are quite well thought-out exercises. With 356 exercises in all, they provide a ton of practice to ensure that the reader is understanding the material. At first they seem to be somewhat random but standard fare, asking the reader to solve programming problems with rational and complex numbers and other such mundane mathematical problems. Then, near the end of chapter 2, we learn how to implement generic arithmetic operations that can automatically promote and demote arguments from one class of number to another. It's pretty slick, if somewhat impractical. I can't think of a system where this behavior would be necessary, but it's cool to get it working nonetheless.

The next chapter kind of let the wind out of my sails a bit. The previous chapters had really exemplified the elegance of Scheme with beautiful functional programming, but now we had to learn about the mucky reality of objects and mutable state. This chapter introduces the set! operations that allow variables to be changed in place instead of creating and returning new variables that are set with the define primitive. The allowance for changing variable values enables the creation and maintenance of objects with state, and this complicates the analysis of program execution because now we have to deal with side effects. The authors did a nice job of explaining when objects are useful, because we don't want to use them for everything:

The object model approximates the world by dividing it into separate pieces. The functional model does not modularize along object boundaries. The object model is useful when the unshared state of the "objects" is much larger than the state that they share. An example of a place where the object viewpoint fails is quantum mechanics, where thinking of things as individual particles leads to paradoxes and confusions. Unifying the object view with the functional view may have little to do with programming, but rather with fundamental epistemological issues.

The second half of the chapter continues on from objects with concurrency, which does not play nice with mutable state at all, and introduces streams in order to deal with that problem. Streams are a mechanism that enables lazy execution of functions on lists. Instead of performing all of the computations on a list at the time the processing function is called, the function will return another function that will do the computation on its corresponding list element at the time that element is needed to be read. It's wild and confusing at first, but working through the exercises helps clarify how it all works.

Chapter 4 tackles the task that all Lisp books seem to reach eventually, and that is to write an interpreter. How to Design Programs did it. The Little Schemer did it. SICP does it to, but it doesn't simply stop with one interpreter. No, after the basic interpreter, we go on to write a lazy interpreter that does delayed evaluation. Then, we write another interpreter that does ambiguous evaluation, meaning the programmer can specify a problem and an input range for that problem, and the interpreter will perform a search to find a solution (or every solution) that satisfies the constraints of the problem. Think that's enough? Not now that we're on a role! The final interpreter extends Scheme to be a logic language similar to Prolog. You would think the previous ambiguous interpreter would be a good basis for this extension, but the text uses the lazy interpreter as the base instead. Extending the ambiguous interpreter is left as an exercise.

Things are getting pretty mind-bending by now, so why don't we finish things off with something truly warped. The last chapter goes through implementing a register machine model in Scheme. What's a register machine? It's basically a model of a computer that uses fixed registers, a load-store memory model, and low-level operations to execute an assembly language. Then we need something to run on this register machine, so we modify the interpreter to run on top of this assembly language. Now let's step back and think about what we've done. We now have an interpreter that takes in Scheme code, spits out assembly code, and runs it on a model of a computer (the register machine); and this is all done inside another Scheme interpreter running on a real computer. Wat? Let's think again about what we've done:

From this perspective, our evaluator is seen to be a universal machine. It mimics other machines when these are described as Lisp programs. This is striking. Try to imagine an analogous evaluator for electrical circuits. This would be a circuit that takes as input a signal encoding the plans for some other circuit, such as a filter. Given this input, the circuit evaluator would then behave like a filter with the same description. Such a universal electrical circuit is almost unimaginably complex. It is remarkable that the program evaluator is a rather simple program.

It's mind-blowing, really, but we're not done. The last part of the last chapter walks through building a compiler so that we can compile Scheme functions down to the assembly language of the register machine, and modify the register machine so that it can run the assembly code directly instead of it being fed from the interpreter. If that's not enough, the last two exercises are simply about writing a scheme interpreter in C and a compiler in C instead of what we just did in Scheme. Easy-peasy, right?

While these last two chapters were fun and fascinating, they were quite a stretch for one book. The first three chapters plus the basic Scheme interpreter would have been enough for the learning experience. I'm not sure how much practical knowledge readers would get out of the rest of the interpreters, the register machine, and the compiler. The explanations became very mechanical and it felt like a major effort just to fit in the code listings and brief descriptions while still keeping the book around 600 pages. Beyond the issue of cramming a bunch of complex stuff in the last chapter and a half of the book, there are much better books out there on compilers and interpreters, like the dragon book or Writing Compilers and Interpreters, that go into more detail and explain those details more thoroughly. Likewise for machine languages and computer architecture, if you really want to understand the underlying machine language and hardware, Computer Architecture: A Quantitative Approach is excellent. Although, for a lighter introduction, Computer Organization and Design might be a better place to start.

That criticism notwithstanding, SICP is an excellent book on both how to write programs in Scheme and how to write a Scheme interpreter. It's a solid textbook for a second course in programming, but not a first course. I can't imagine most entry-level students would grok everything this book tries to present, so it would be good to have some other programming language under your belt before tackling this beast. Given its age, it's still surprisingly relevant as a programming textbook, and quite enlightening.


SICP is far and away the better book in this face off. True, How to Design Programs is meant for a less technical audience, but I'm not convinced that it would be an appropriate book for non-programmers, either. Scheme is just not the right introductory language, and something like Python or Ruby would be a much better learning language. Taking that consideration out of the equation, SICP packs a ton more content into 150 less pages, and it goes in much more depth on both basic programming concepts like lists and functions, and advanced concepts like streams and interpreters. Did I mention it also uses way better variable names? The code is much easier to understand as a result, and it's only the complexity of the concepts later in the book that make that code difficult.

Definitely pass on How to Design Programs, but if you're in the mood to level-up your fundamental programming knowledge, give SICP a look. If you're so inclined to read it online, check out this version at Sara Bander's GitHub site. It's rendered in a beautiful Linux Libertine font that's an absolute joy to read on a screen, and the footnotes come up in text boxes when clicked. It's the best experience I've had reading an ebook.

SuperTuxKart 1.0 Release

It's been a long and winding road for mascot racer SuperTuxKart, but after more than ten years of continuous and dedicated progress, the team has finally announced the release of build 1.0, marking an important development milestone for the project.

 As quoted from the official release post:

Yes, if you have followed our development a bit, that might be a bit of a surprise. But we have been asked why we don't call this release 1.0, and the majority of us developers discussed this and decided that indeed this release is a major milestone that deserves the big 1.0 number.

Indeed a nice surprise and definitely a big step forward with the inclusion of online multiplayer!

See more new features in the official release video:



As usual you can download the game here. Also don't forget to head over to our forums to provide some feedback to the developers.


Code License: GPLv3
Assets License: CC BY-NC-SA 3.0

This post was retrieved from freegamer.blogspot.com.

The Black Gate: The C.S.I. Effect

The Fellowship has managed to infiltrate Britannia with the closest thing this world has ever had to a church.

        

For a game that gets really good, Ultima VII does not start promising. Particularly disappointing was the character creation process. This is the first Ultima since II not to allow any importing of characters. Character creation had of course reached its peak in Ultima IV, where the gypsy's questions sorted you into one of eight classes and determined your starting attributes. Ultima V and VI lowered the number of classes to functionally three (fighter, bard, and mage, with the "Avatar" class a kind of synthesis of the three) but still let you go through the gypsy exercise, the specifics of which were retconned in VI. You could choose a female Avatar for the first time, and select from about half a dozen portraits whether male or female.

Ultima VII offers the fewest options of any of the games in the series. You can only type your name and select your sex, and there's only one character portrait for each sex. And they're both horrible--although the male Avatar does fit with the canonical portrait ORIGIN has been pushing on players since VI, including the two Worlds of Ultima spin-offs.

I briefly considered playing a female character, which I never do for the Ultima series, but I didn't feel like looking at her portrait for dozens of hours, either. Why did ORIGIN reduce character customization? Was it just a matter of not wanting to spend the programming time to vary the portrait that shows up in dialogue? That's a lazy approach for a company that did such a meticulous job with everything else.

          

The female Avatar has Evil Resting Face.

            

I sighed and chose the male portrait, naming him "Gideon"--my official alter-ego for any character I'm really invested in. 

The opening moments beyond character creation are as chaotic as anything, especially for a new player. We start with a street scene in what turns out to be Trinsic. Two characters, one of them white-haired, are standing outside a stable and trading laments over some horrid event. Suddenly, the red moongate appears and spits the Avatar onto a paved (or at least cobblestoned) street with gas lamps--the first sign that Britannia isn't the same Dark Age kingdom we last saw. 

          

Where were moongates that open inside the city in the last couple of games?!

        

The white-haired, bearded man turns out to be Iolo, who immediately recognizes the Avatar despite not having seen him in--as he quickly reveals--200 years. Iolo and Dupre and Lord British are still alive because they originally came from Earth. No explanation is given for the longevity of the rest of the Avatar's companions. The time jump isn't really necessary at all, except perhaps to explain why Britannia looks more Colonial than Medieval. I don't buy the rapidity at which the Avatar returns to his friendship with people who haven't seen him in two centuries. I had some good friends when I was in my 20s, but I doubt I'd recognize them if I lived to be 220, nor would I attach a lot of significance to our friendship given all the other people I would have met, and all the other things I would have done, in that intervening time.

I soon learn that "something ghastly" has happened in the stables. The other person is introduced as a stablehand named Petre. I am encouraged to go and look in the stables for myself, which sounds fine to me. All I really want to do at this point is turn off the damned music. But I don't have time to do even that, let alone enter the stables, because there's a sudden earthquake. Iolo pipes up and suggests that Lord British might know the reason behind it. The tremor, we later find out, is caused by the events of the Forge of Virtue expansion. But, damn--did it have to happen immediately? This is like modern Elder Scrolls and Fallout games where you buy the expansions and you get 8 pop-up messages the moment the game starts telling you where to go to start the DLC missions. Could they maybe be spaced out a little?

Recovering from that, I'm about to move when suddenly the mayor of Trinsic comes hustling in from stage left. Iolo introduces him as Finnigan. Finnigan is doubtful that I'm the Avatar at first, but he ultimately relents and asks me to solve the murder that has just occurred. At this point, all my Avatar wants is a quite room and an Advil, but he gamely accepts the quest, which immediately prompts a dialogue with Petre. When can I finally turn off the @#$&ing music!? Not only do I find it repetitive and annoying, I suspect it's responsible for the fact that the dialogue keeps freezing.

          

It's a choice, but "no" just gets you trapped in town.

          

It becomes clear that in fact two people have been murdered: someone named Christopher and a gargoyle named Inamo. After some more dialogue that I miss because the game froze and implemented all my clicks when it un-froze, I finally have control. I turn off the music and save the game, and immediately things start to improve. The first thing I notice is that, with the music gone, there are background noises. I'm a big fan of games that use sound effectively to create a sense of immersion, and ambient sounds are a big part of that. We have a couple of different types of birds chirping in the distance and waves crashing on the shore to the east (Trinsic is a coastal city).

As we discussed last time, the interface has gone almost all-mouse, something I find maddening given that Ultima pioneered the efficient use of the keyboard. You right-click and hold to walk, with walking speed increasing the further you get from the Avatar. You left-click to do almost anything else. Single-left-clicking looks; double-left-clicking talks and uses; clicking and dragging moves and picks up.

          

The Avatar's attributes.

         

There are still a couple of useful keyboard shortcuts: "I" to open inventories, "C" to enter and exit combat mode, "S" to save and load, ESC to close windows, and the venerable "Z" to bring up character statistics. It's here that I found my Avatar has 18 in strength, dexterity, and intelligence. There's a "combat" statistics for the first time, and I've started the game at Level 3 with the ability to train 3 attributes. Iolo is also Level 3 and has about the same statistics.

The inventory has been much discussed. You get an image of your character with lines pointing to slots for left and right hands, legs, armor, boots, gauntlets, rings, helm, neck, missile weapon, cape, and backpack. Ultima VII: Part Two will turn this into a proper "paper doll" screen where the character image itself changes to reflect what's equipped. For now, you click and drag things in and out of those slots. The Avatar has started with leather boots, leather leggings, leather armor, a dagger, and a backpack.

         

The Avatar's inventory and pack.

          

It's the backpack where things get crazy. You can stuff a lot of things into it (as well as bags and other containers), and the little icons freely overlap. Finding a small object like a key in a backpack full of torches, reagents, documents, and other objects is at least as hard as it would be to find a real key in a real stuffed backpack. Even though it's been almost 15 years, I remember that the last time I played, I organized items strictly by character--the Avatar has all the quest items; Iolo has all the food, and so forth--so I wouldn't go crazy.

     

So far, it's not so bad. The Avatar has started with a map, three lockpicks, a torch, 10 gold pieces, a cup, an apple, a bottle of wine, and a bread roll. I don't think the cup serves any use at all; although a lot of items can be used together in this game, pouring the wine into the cup doesn't seem to be one of the options.

    

All right. Time to explore dialogue. I double-click on Iolo and get six options: NAME, JOB, TRINSIC, STABLES, LEAVE, and BYE. These still aren't really "dialogue options"; they're just keywords. And I frankly preferred it when I had to type them myself, then watch for the response to see what other keywords I might use. Now, the keywords just spawn automatically in response to the dialogue. When Iolo tells me that his JOB is adventuring with the Avatar, I get AVATAR as an option. Clicking my way through them all, I learn that Shamino has a girlfriend who works at the Royal Theater in Britain and Dupre, who was recently knighted, is probably in Jhelom. (Have I been knighted? If not, why the hell not?!) Britain has grown to encompass Paws and the castle and dominates the east coast. Lord British will probably want to see me. 

             

Dialogue options with Iolo.

             

Petre has wandered off somewhere, so I finally enter the stable. This is accomplished via a "remove the roof" interface that I believe was pioneered by Charles Dougherty in either Questron II or Legacy of the Ancients. (I wonder if ORIGIN licensed the "look and feel" of this game element from Dougherty.) The interesting thing about Ultima VII's approach is that entering one building removes the roofs of all buildings, so you can see items and people inside adjacent structures even when there's realistically no way your characters would see into those locations.

Inside the stables is perhaps the most gruesome scene in any RPG so far in my chronology. (Well, no. I forgot about the two Elvira games.) The aforementioned Christopher is lying spread-eagle on the floor, each limb tied to an unspecified "light source," his body hacked beyond recognition. A nearby bucket is filled with his blood. The gargoyle Inamo is in a back room, pinned to the wall with a pitchfork.

            

It's cool that we've reached the point that such complex scenes can be graphically depicted.

           

Several tools are strewn around the stables, including a rake, a shovel, another pitchfork, and a pair of tongs. A key lies next to Christopher's body, and near Inamo is a sack with some bread, a torch, and a few gold pieces. Footprints are all over the dirt floor and head out the rear door. As my character investigates, I'm conscious of how much authentic role-playing I'm now doing. I mean, I already know basically where the plot is going, but I still take the time to go over everything in the stables. I move objects to makes sure nothing is underneath them. I click on things I'm not sure about to get their names. I investigate, realizing as I do so that this is one of the few RPGs up until this point to offer a level of graphical complexity and object interactivity detailed enough to make such an "investigation" possible. This is the future of role-playing in RPGs, I think. Sure, it's not bad to have dialogue and encounter "options" that let you maintain a consistent characterization or morality, but when the very interface of the game allows you to make decisions consistent with your character, you have something special. Unfortunately, Ultima VII will not only be one of the first games to support this kind of gameplay but also one of the last.

Petre the stablehand wanders in said rear door. He says he's the one who discovered the bodies. Inamo was apparently his assistant, and lived in the little back room. (Wingless gargoyles, I recall, are less intelligent than their winged brethren and used mostly for manual labor.) Christopher was a blacksmith who made shoes for the horses. Petre assumes the murderer was after Christopher (a logical guess given that his body was the one posed) and that Inamo was just in the wrong place at the wrong time.

      

We follow the footsteps out back and around the corner, where we soon come to the city gate. The gate is down and a guard patrols the room with the winch. His name is Johnson, and he says when he arrived for his shift, he found the previous guard, Gilberto, unconscious on the ground. This suggests the murderer made his escape through this gate, knocking out poor Gilberto on the way. I'd like to leave the same way and scout the outskirts, but apparently I need a password to leave the city (the manual alludes to this) and I don't have it. He suggests I ask Finnigan. I do climb up to the city walls and see the docks just beyond the gate. I have to wonder if the murderer didn't flee via boat or ship.

          

No clues this way.

        

Finnigan has taken off, so I settle in for a systematic exploration of Trinsic's streets, starting by heading right out of the stables. I note that double-clicking on the street signs gives me street names, and I'm pleased to find that I can still read the runic writing without a guide. The stable is on Strand. Slightly to the west, we come to (in non-runic writing) the Avenue of the Fellowship and, right in front of us, the Fellowship hall. Might as well get it out of the way. I take a deep breath and enter.

       

I'm a little concerned, on a role-playing level, that the Avatar technically hasn't been exposed to the Book of the Fellowship and thus has no reason to be cautious in his exploration of their hall. This concern is lifted when I find a Book of the Fellowship on a table right in the entryway. I imagine the Avatar reading it, asking Iolo, "What the hell?", and getting a shrug. 

The only person in the hall is a woman named Ellen, who says she runs the branch with her husband, Klog. She goes through the Fellowship philosophy and suggests that I see Batlin at the Fellowship headquarters in Britain to join. She claims to know nothing of the murder, having been home with Klog all night. I resist the urge to ransack the Fellowship hall and move on.

           

Hand-feeding my characters out of the backpack.

          

The Avatar complains about being hungry as we leave, so I feed him some bread. This is one of the legendary annoyances of the game. Characters have to be hand-fed throughout the game even though it's trivially easy to find food--one of several examples of a game element created for want of a true purpose.  

Up the road is the shipwright, Gargan, who offers deeds and sextants, neither of which I can afford. The notepad comes out and the "to do" list begins. Gargan has nothing to offer on the murder.

             

I was going to object to the name of the ship, but apparently some eels have scales.

       

I note that his house is filled with chests and containers. This is going to be true of a lot of houses in the game. Ultima VI was the first game in which the Avatar had an incentive to steal liberally from such containers, but this game is the first with no karma consequences. Instead of waiting until I have 80 gold pieces to buy a sextant, I can just remove one--and a gold bar besides!--from the pack in Gargan's bedroom. You can steal things right in front of the occupants--clean out entire stores while the owners stand mute in the center of the room--with no consequences. Well--almost none. Eventually, Iolo starts making some alarmed remarks.

             

Stop complaining about how hungry you are, and I won't have to steal a roast.

         

Heck, even the damned Guardian has something to say about it:

          

Really? Burglary is where you draw the line?

          

And I think maybe Iolo and your other companions leave you if you steal enough. The neat thing is that there's a real incentive to steal. You start the game broke, and the nature of your mission doesn't leave a lot of time for extensive wealth-gathering. But I'm going to stick to my tradition of taking my role as the Avatar seriously. I'll do it the hard way. The sextant and gold bar stay in Gargan's case.

    

I think you get the idea, so we'll speed things up from here:

            

• A young woman named Caroline is on the streets recruiting for the Fellowship. She says that they have their meetings at 21:00. It turns out that Christopher was a Fellowship member.

• There's a two-story house on the west side of town with a parrot on the first floor. No one tells me that it's Christopher's house, but the key we found with his body opens a locked chest on the second floor. The chest has a Fellowship medallion, 100 gold pieces, and a terse note that says, "Thou hast received payment. Make the delivery tonight." I take the gold and note.

• Markus the trainer runs a store south of Christopher's house. He offers to train in combat skill. I decline, not having enough money, and forgetting how training works in this game. I'll revisit it later.

• A guy named Dell runs an armory in the southwest part of town. We do find a secret lever that opens a back room stuffed with weapons and armor, but again I decline to steal. I spend 50 gold pieces on a sword to replace my dagger.

• In the far southwest part of town, we find the healer. Gilberto is lurking around his shop with a bandage on his head. He didn't see his attacker, but he did note that The Crown Jewel was at the dock at the beginning of his shift and gone when he woke up from his concussion. He believes it was sailing for Britain.

         

Everything seems to be channeling me towards Britain.

         

• The healer has a copy of The Apothecary's Desk Reference, which reminds me of the standard Ultima potion colors. Black is invisibility, blue is sleep, orange awakens, purple conveys magic protection, white is light, yellow heals, green poisons, and red cures poison. I think I already had that memorized.

           

Visitors from the NetHack universe are suspicious.

       

• The pub and inn is called the Honorable Hound. The owner and server, Apollonia, openly flirts with me. I buy a bunch of loaves of bread. The inn's register shows that four people have stayed there recently: Walter of Britain, Jaffe of Yew, Jaana, and Atans of Serpent's Hold. I suppose the murderers probably didn't register, but you never know. We spend a night in the inn at the end of all of this.

               

There are so few role-playing moments in which "murder" and "flirt" are equally valid dialogue options.

           

• I find Finnigan at City Hall in the center of town. He relates that he's been mayor for three years. The Rune of Honor, which used to sit on a pedestal in the center of town, was stolen years ago by someone claiming to be the Avatar. It somehow found its way to the Royal Museum in Britain. Finnigan thinks this is symbolic somehow. The most important information from Finnigan is that he was present in Britain four years ago for a ritualistic murder with similar characteristics.

• Finnigan's office is hidden behind a couple of secret doors. I find them but don't find anything incriminating in the office.

        

This game is a bit odd in that it doesn't hide secret areas; it just hides the means to access them.

         

At 21:00, I peek in on the Fellowship meeting. It consists of Klug shouting the elements of the Triad of Inner Strength while the members shout things like "I believe!" and "I am worthy!" In between, Klug runs around lighting candles and occasionally genuflecting to the Fellowship icon behind the lectern.

             

 

Spark is unmoved by the testimony of Fellowship members.

         

The Guardian's face appears to taunt me as I enter Christopher's workshop on the south end of town. A boy named Spark--Christopher's son, which no one bothered to mention--is clutching a sling and running around frantically. He's supposedly fourteen, but his portrait makes him look about six. Spark tell us that his mother died a long time ago, so now he's an orphan. The Fellowship had been harassing his father lately, and a week ago Christopher and Klog had gotten into an argument. Christopher had been making something for the Fellowship--something probably stored somewhere in the smithy. Either Christopher was a bit disorganized, or someone has recently tossed the smithy.

          

Dick.

            

Now that I know Christopher had a son, I feel bad about looting the gold. But Spark offers to give it to me for investigating his father's murder. He says that he woke up from a nightmare the previous night and went looking for his father, and saw a wingless gargoyle (not Inamo) and a man with a hook for a hand hanging around the stables. He begs to join the party, and I agree. He comes with leather armor and a sling. Honestly, how were the first words out of Iolo's or Petre's mouths not, "Christopher has a kid. We'd better go see if he's okay"?

            

I don't know when Iolo started calling me "milord," but I confess I don't hate it.

             

Where Christopher is dead and his son is part of the party, I don't mind taking things from the smithy. We loot about a dozen gold pieces and some clothing items. I try to make a sword by putting a sword blank on the firepit and operating the bellows, but I can't get the sequence right. I think it's possible. I don't find whatever Christopher was making for the Fellowship, unless it was pants or sword blanks.

           

Spark, you must have seen your dad do this before.

         

My time in Trinsic closes with a return visit to Finnigan, who questions me on all I've learned and pays me 100 gold for what I've uncovered so far. He puts me through a copy protection exercise before giving me the password to the gates of Trinsic: BLACKBIRD. All signs point to visiting Britain next. We head outside. I find nothing at the docks except the fact (which I'd forgotten) that the developers managed to animate waves crashing on the shore for the first time in an RPG.

           

Another first for the Ultima series.

           

Continuing a theme started in Ultima V, the developers do a good job making Trinsic feel like a real place. Each resident keeps a schedule, including going to work in the morning, eating or stopping by the Honorable Hound for an evening meal, going to the Fellowship meeting (if a member), and tucking into bed at night. Every NPC has a house with personal belongings. When it gets dark, they light candles in their houses. During the day, they open shutters with comments to themselves like "Too nice a day for these to be closed!" They have brief conversations when they encounter each other. A dog and a cat roam the streets.

This is all admirable, but the problem of course is that this simulation has come so far that we can no longer regard the NPCs and buildings we see as a representative sample of the real number of NPCs in town. They're clearly the entire population. The fabled city of Trinsic houses 10 people. By modeling daily life in such a realistic way, the developers call attention to the lack of realism inherent in population size. We notice the same problem even in modern games.

            

Finnigan won't let me leave town until I relate what I've learned.

          

I'm hard-wired to create typologies out of everything, and this is something that needs a typology. Very few games in the 2000s adopt the "old school" model of towns-as-abstractions, which is most obvious in "menu towns" but also exists in games like Ultima II, where the geography of each city is just the broadest lines with the most important places (e.g., shops but no houses). BioWare has adopted what we might call the "matte background" model where the parts of the game that you can explore are just the most important parts, but the graphics suggest unending blocks of additional houses and buildings in the background. They populate the streets with a dozen generic NPCs to every important NPC, cleverly annotating the difference with sharpness of color and other indicators.

     

Another model for which we need a name is the Assassin's Creed/Grand Theft Auto approach where there is a realistic number of buildings throughout the geography, including houses. You just can't go into most of them; it would take far too much programming time to give them all interiors. The streets are also teeming with generic NPCs with basic AI. It's far more realistic than, say, one of the cities in Skyrim, but also a little disappointing when there are so many doors you can't open.

       

The Elder Scrolls follows the Ultima VII model. The developers' philosophy is that you should not only be able to enter every building that you see but also find clothes in the closets and forks on the table. This comes with Ultima VII's drawbacks. Which model do you prefer, and can you think of a better approach (or one I didn't mention at all)?

Time so far: 3 hours

*****

Potential bad news on Planet's Edge. I'm running into a bug where if I try to beam down to Rana Prime, the game not only freezes but somehow corrupts the files so that I have to fully reinstall the game, start it, create a new save, and then load an old saved game to get my former party back. But then it corrupts again the moment I try to visit Rana Prime. No one else seems to be reporting the same issue, so I'm not sure what to make of it. Rana Prime does seem necessary to finish the game. I'll keep playing with it; ideas appreciated.

Wrong package delivery address

Your delivery is scheduled for tomorrow, by 2:00 pm Tracking #: Withheld Ship date: Returned Scheduled delivery: Shipment Notice Apologies for being late to deliver. Our dispatch department discovered an error in the profiled address details. Your correct location address is needed urgently. Update Address   Please do not respond to this message. This email was sent from an unattended mailbox. This report was generated at approximately 5:10 PM CDT on . All weights are estimated. The shipment is scheduled for delivery on or before the scheduled delivery displayed above. FedEx does not determine money-back guarantee or delay claim requests based on the scheduled delivery. Please see the FedEx Service Guide for terms and conditions of service, including the FedEx Money-Back Guarantee, or contact your FedEx customer support representative. To track the latest status of your shipment, click on the tracking number above. Standard transit is the date and time the package is scheduled to be delivered by, based on the selected service, destination and ship date. Limitations and exceptions may apply. Please see the FedEx Service Guide for terms and conditions of service, including the FedEx Money-Back Guarantee, or contact your FedEx Customer Support representative. © 2019 Federal Express Corporation. The content of this message is protected by copyright and trademark laws under U.S. and international law. Review our privacy policy. All rights reserved. Thank you for your business.