WHERE TO GO FROM HERE - PART 2

As I eluded to in the last post, I am working through the numbers trying to decide if an episodic production and release through Kickstarter is a viable option.

So, we now have a course and a destination… Which honestly is a very welcome and refreshing change.

Why use Kickstarter?

As a marketing platform it allows to reach a wider audience, not just my current customers but those new to the hobby and those who never knew DreamForge was even a 'thing'. I think we all know that the train has stalled, and its going to take a lot of effort and lots of attention to get it rolling again. Perhaps there will be a time that I can move off the Kickstarter platform, but for now… The broader exposure is required. This exposure comes at a price, Between the Kickstarter fees, the currency transaction fees and the backer support fees in the form of a post Kickstarter service to collect shipping and allow backers to add items or options, we are looking at near 10% in fees alone.

Expectations:

Not every Kickstarter campaign will succeed, that's OK. If the demand for a particular kit is not there, then its not… No harm no foul, we move on to the next product offering. I completely expect for there to be unfunded projects that never make it to plastic and possibly (if there was enough interest) may see a resin release instead. There will be changes to how DreamForge approaches on hand inventory and even they type of products offered, not all offerings need to be Iron Core specific, it provides far more flexibility in product development than making sure each product fits neatly into the project I have already started. If I get an itch to do…well anything, it gives a platform to see if all of you are also interested.

How will that work? And what does that look like from the customers side?

The plan is to have a very focused Kickstarter for a single product, its actual production costs and any profits expected will need to be folded into the funding goal. This is a strong departure from the retail model, where revenues are gained over time and the investment/debt is front loaded.

Product availability outside the initial Kickstarter will be limited, 10% to 20% beyond the total needed to fulfill the Kickstarter will be run, some of that will be soaked up by the inevitable issues, damaged kits, mispacked or missing items from a kit and kits that never make it to the backer and get lost in transit. 

There may be re-runs offered on popular kits in future Kickstarter's, but there will be minimums that need to be met, typically a 500 unit run will be needed. If I feel that the kit will sell, I may assist with purchasing some of that re-run myself, to provide stock on hand. The best way for a customer to approach this is to buy what you want and what you think you will need at the time of the offering, I cannot make a promise that there will be a second run if the overall interest is not there.

Customers will need to pay for the actual shipping costs for the products they back.

Shipping, as we all know is stuuupid expensive from the US to anywhere outside its borders. Each Kickstarter will be shipped directly from China to mitigate the expense to the customer as much as possible, this means most of the world will likely see a drastic cost reduction, but the US will see an increase. Why don't I just ship the US from the US? Well, because it's a hidden cost, one that would need to be calculated into the Kickstarter… Someone has to pay to get it to the US before it could be sent out from our warehouse, add to this the staffing costs, the shipping package costs and overhead, and it becomes a real issue that has not been factored into the per kit price… We are running as lean as possible, to provide a per kit price that is as low as possible, there will be no room for uncalculated expenses.

How are the Kickstarter's structured?

This is open for revision, but the plan is to absorb the costs and required profits into a 1000 minimum unit run. If it costs $40,000 for the molds, production, boxes and services, then the cost of each unit would be $40.00. 

What happens if a Kickstarter goes nuts and the total funding far outstrips the required funding goal? Do you get a discount? Discounts will be offered when you pick up multiple kits, not by the overall success of a product. Those are profits that get re-invested to make DreamForge healthy, to pay for game development, to pay for additional stock, to help pay for re-release of the current line of kits, as those tools will need to be re-cut at some point. I am not pulling the discount off the table, but for the foreseeable future, I have a lot of catching up to do and core development that needs to happen for DreamForge to grow and thrive.

I want to be clear, this is not going to be a song and dance Kickstarter model, there 'may' be extras offered if there is room on the sprues, ( I will try to pack them the best that I can) but anything extra in the form of products adds to the costs and I am not bulking the costs to deal with that. I am trying to keep the price per kit to you as low as I possibly can.

Longer term with the releases and stock on hand.

Obviously, this model does is not ideal for some aspects of brand development, limited supply concerns may not be ideal but it's not unusual when we look around the industry and other companies that made their way on Kickstarter. I am not GW, I do not have their sales volume or the resources available to behave like GW. Please understand that expecting a small manufacture in plastic to be able to behave and function as one of the top two or three in the industry, may not really be a reasonable expectation. I will strive to get there, but until the financial aspect of that shift make sense, I will be doing what is best for the growth of the company with the resources available. 

I think we can all agree, that Iron Core needs at least two to three full factions, terrain and a rules set, so as we move through these requirements, I will try to weight when it becomes viable as its own free standing IP. The goal is to grow the brand, expand the product offering, make available some of the older kits and even start to offer some options for those not interested in Iron Core. Fantasy, Cyberpunk and a myriad of other avenues are available and the wider the base of offerings, the more stable the base.

All of this is dependent on me, making what you want, delivered at a reasonable price within a reasonable time.

I am very excited about the prospect and the future. I am really looking forward to exploring your 'needful things' and if they can be created and successfully funded in an episodic, backer driven environment. I hope that you join be on this new course and help guide my had in future releases.

Soooo many itches to scratch, so little time :P

I will be reaching out in a few locations looking for honest feedback and direction from all of you.

• Through surveys sent to my mailing list… So please sign up on the DreamForge-Games website if you have not.

• Through my Facebook group DreamForge-GamesArtist Retreat  (please do not try to message me here) For whatever reason FB and I do not sync well…. I must be an old fart, not a huge fan of FB or twitter :P

• On Dakka Dakka (I could start my own forum but it's a waste of energy, at least at this stage)

• And, well...here but its not very good for two way conversations.

Not So Lucky!

What's going on everyone!?

Today was spent running errands and preparing for our big move to our new place so by the time we got home this evening, everyone was ready for bed. 

That being the case, I decided to play a solo game of Carcassonne on the mobile app for the #2019gameaday challenge. 

Tonight I got my butt kicked by the Ai which surprised me because I thought I was actually doing good, lol!

As always, thank you for reading and don't forget to stop and smell the meeples! :)

-Tim

Tech Book Face Off: Rails AntiPatterns Vs. The Rails 5 Way

It's been a while since I've cracked open a Ruby on Rails book, and there were still a couple of these books that I've been meaning to read. So far the Rails books I've read have been beginner's books and tutorials. With this latest pair of books, I wanted to go deeper into Rails and learn how to program fluently in the framework. The first book, Rails AntiPatterns: Best Practice Ruby on Rails Refactoring by Chad Pytel and Tammer Saleh, was published way back in 2010 when Rails 2.3 was cutting edge. I took a chance that the book would focus more on timeless advice than version-specific tips and tricks. The opposing book, The Rails 5 Way by Obie Fernandez, was published much more recently at the end of 2017 and should be at less risk of being out-of-date. Although, it looks like Rails 6 will be out soon. One thing's for sure: technology doesn't stand still, but that shouldn't matter too much if the books take that into account. Let's see how they fare.

VS.

Rails AntiPatterns

Most programming books will tell you the right way to do things and give examples of how to implement that advice. This book takes a different tack and instead shows you what not to do, with examples of how to refactor those mistakes into clean Rails code. This change in approach is refreshing for the intermediate to advanced programmer because over time we develop certain habits as we try to discover how to do things in a language or a framework, and they're not always the best (or even very good) ways of doing those things. Having a book to help identify where our code has gone astray and how to fix it is a helpful tool indeed.

I was a bit worried about reading a book specifically about Rails that was written so many versions ago, being that Rails 2.3 was out at the time and we're now heading into Rails 6.0. I normally don't mind reading older books about programming in general, since those books have been filtered by time and tend to contain plenty of wisdom that has survived current fads. However, this is a book about a specific web framework, so if it is over eight years old, how could it possibly still be relevant? I needn't have worried. Most of the book focuses on general good programming practices within the context of the Rails environment. Such advice is still as valid in Rails 6.0 as it was in Rails 2.3, even if some of the implementation details have changed.

The structure of the book works well, with ten chapters each focusing on a different topic of the Rails framework. These topics range from the obvious models, views, and controllers on which the Rails architecture is based, to the related services, testing, and databases that are all a part of web application programming. Each topic covers a few antipatterns with descriptions of a common programming mistake and why it's wrong, followed by one or more solutions that fix up the antipattern into beautiful, DRY code. The obvious solutions—like that views should contain strictly display logic, controllers should be thin, and models should contain all of the business logic, but broken out into helpers and plain Ruby objects—are covered along with a number of less obvious antipatterns. Some of the more extended solutions are quite satisfying to follow as the refactorings morph an ugly hack into a pretty Rails implementation.

Throughout these refactored antipatterns the authors relate clear reasons for why things should be done a certain way and sound advice on how to choose between competing options. For example, when discussing whether or not to use scopes to create chainable filters on models, they say:

There are downsides to this approach, including problems with readability and simplicity, as well as abuse of the Law of Demeter. Whether you use this approach is a judgment call on your part. Will you use the added flexibility? Is it better than defining a handful of separate finders? Like many advanced refactorings, this one has no easy answer and depends greatly on your tastes.

I appreciate the honesty of this advice. In programming, as in most things in life, not all rules are hard and fast. Multiple good options can and do exist, and in these cases it comes down to a judgement call from the programmer, given the context of the specific situation. Experience and taste will develop into a programmer's style, and as long as they're not making a poor choice for the wrong reason, it's okay to prefer one viable option over another.

The authors aren't always so amenable to choice in correcting antipatterns. They do discourage attempts at divining the future, as in this example:

Developers new to the template pattern tend to want to err on the side of flexibility. This is a form of future-proofing, and it's a mistake—especially when working in a language as geared toward agile development and the refactoring cycle as Ruby.

It's almost always better to spend time fixing real problems in the here and now instead of trying to predict and head off future problems that may never happen.

The whole book was full of insights like these, and it was all packaged in easy-to-read prose and concise, relevant examples of how not to write Rails code, followed by how to fix it. I found it to be a quite enjoyable way to learn better Rails programming practices, and it reminded me of an old chess book that had followed a similar format: How Not to Play Chess. Seeing the mistakes that can be made and their consequences clearly laid out can prove quite helpful in identifying our own mistakes and seeing the path to correcting them. This teaching method was expertly executed in Rails AntiPatterns, and I highly recommend giving it a read if you do any programming in Rails.

The Rails 5 Way

This was definitely the longest book on a programming language or framework that I've read in a while. Weighing in at over a thousand pages, it definitely achieves tome status, and strives to be a comprehensive map of the Rails 5 framework. The forwards and introduction recommend reading it straight through at least once to get the lay of the land and see everything that's available in Rails before using it as a reference.

I would agree that knowing what tools are available in any given language or framework is half the battle when attempting to develop solutions as efficiently as possible. If you know that something you want to do is possible and you know where to look to research how to do it, then you're already ahead of the game in reaching an optimal solution. However, I was not going to read all the way through this book, considering the last third of it is a pure reference listing of the Active Model and Active Support APIs. That's skim-worthy material at best.

At least another third of the non-appendix part of the book is also reference listings of various APIs in the Rails framework. The trouble with this reference material is that it is interspersed with actual guidance on how to use the different parts of Rails. That makes it much harder to skim through the boring, tedious method descriptions without missing tidbits of more useful information, so most of the book was kind of a slog.

Obie Fernandez took a slightly unconventional approach to covering Rails, and instead of starting with Active Record, he started at a high level by covering the Rails configuration and environments, then followed the flow of a request by going into routes, REST, resources, and controllers before getting to Active Record. After five chapters of the various aspects of Active Record, he continued with Action View, helpers, and Haml, followed up by an assortment of short chapters on session management, security, Action Mailer, caching, background processing, Ajax, Turbolinks, Action Cable, and testing with RSpec. Whew. Like I said, comprehensive, and even if some things couldn't be included in depth, they were at least mentioned so that the reader could be aware of them and do more research on their own.

Some chapters were quite useful and informative, like the main chapters on the MVC architecture of Rails. These chapters contained a fair amount of good advice and recommendations that can save developers a lot of trouble, such as:

Rails' schema definition provides the authoritative record of truth for the latest version of your database schema. If you need to recreate your database on another server, you should be using db:schema:load, not running all the migrations from scratch.

Anyone who's tried to run a long chain of migrations while setting up an application on a new machine can attest to the futile debugging situation you end up in when one of the migrations inevitably fails halfway through. Using the schema is definitely the way to go. I also found the chapters on security, caching, and Turbolinks to be quite helpful, and I learned a bunch of great things that will help me build better Rails applications.

On the other hand, there were large swaths of the book that were pure drudgery. Most of the helpers chapter was like this with page after page of very similar method descriptions:

11.3.1 asset_path(source, options = {})
Computes the path to asset in public directory. If :type options is set, a file extension will be appended and scoped to the corresponding public directory. All other asset *_path helpers delegate through this method.

<...code example...>

11.3.2 asset_url(source, options = {})
Computes the full URL to an asset in the public directory. This will use asset_path internally, so they behave the same way. If the :host option is set, it overrides the global config.action_controller.asset_host setting normally set in config/environments/production.rb.

asset_url "application.js", host: "http://cdn.example.com" # => http://cdn.example.com/assets/application.js

Also aliased as url_to_asset.

Ugh. This kind of stuff is much easier to search for in the online Rails documentation when you need to look it up, not by paging through a giant book. I was also surprised at how much of these method descriptions ended with comments about how useless they were. Maybe 20% of the methods would have a description of what they did with a code example, and then Fernandez would end it with saying he had never found a use for this method or you would never want to do things this way because some other method was much better. That got more than a little frustrating as the book dragged on.

It may sound a bit strange to criticize this book for including ways not to do things in Rails, having just praised a book whose entire structure was showing how not to do things and then showing the right way, but this is different. In Rails AntiPatterns, the author was showing common mistakes when programming in Rails and how to fix those mistakes by using Rails the right way. My complaint with The Rails 5 Way is that time is spent describing irrelevant methods that may have been included in the framework for completeness or for a specific, uncommon use case, but are hardly ever used in practice. When those things are included in a book whose title asserts that this is how things should be done, it muddies the waters.

Between the appendices, the long lists of method descriptions, and the inclusion of dozens of methods that are rarely used, this book is probably three to four times longer than it needs to be, all for the sake of being comprehensive. It was light enough on actual recommendations for how to use Rails, focusing more on every single thing that's available, that a more appropriate title would simple be The Rails 5 Documentation.


I much prefer reading programming books that directly address the 'how' and 'why' of programming, like these books I previously reviewed on how to use Rails. The Ruby on Rails Tutorial is especially good and the latest version is also up-to-date with Rails 5.  Even Rails AntiPatterns is still relevant nearly a decade later because it addresses the fundamentals of developing in Rails. I would rather leave the 'what' of programming to the online documentation where it is easily searchable and stays updated to the latest version of the tools. In that respect The Rails 5 Way falls flat. It would have been a much more compelling book if it had stripped out all of the drab documentation and focused on showing the right way to program in Rails and explaining why that was the best way to do it. As it is, reading through Rails AntiPatterns and referring to the online documentation is the more productive path.

Warsow Is Now Warfork And On Steam

Warfork Gameplay (livestream - skip ahead 1m20s)

Last updated 2019-08-22 (see bottom of this article).

The title says it all. Warfork is the revival of Warsow. Warsow is cool (and super hard to master) but does not have servers running and no development ongoing.

Warfork is an ironically-named fork of Warsow, has CC0 art assets and is for now only released on Steam. The source supposedly is mostly based on qfusion, the source code is supposed to be available as a DLC.

I recognized one of my own CC0 sounds in the game (dong.wav) without attribution (which is totally fine both legally and morally) but it's too bad that assets (especially the nice announcer voice) can't be re-used/re-shared with voluntary attribution without digging around for it first.

Some art is limited by containing trademarked logos. Would be cool to have clean versions if anybody plans on packaging Warfork for official distro packages eventually.

Shortly after launch time there were around 50 people on all servers, later it was even more. Let's hope it ends up being a success and that many other open source games will dare following!

Warfork on Steam: https://store.steampowered.com/app/671610/Warfork/
Warfork on Discord: https://discordapp.com/invite/VY95TKZ

Fun for me: I found out about Warfork two hours before release time as I was checking out a discussion about bringing Unvanquished to Steam.

Y'all better start with itch.io for distribution first. ;)

Discuss about this article on our forums here.

Update 2019-08-20: 

1. To my knowledge, the Warfork team is not required to publish the source, the offer to provide the source in the license included in the Steam release might suffice. Somebody who cares enough might try to contact them and ask for the source. [Oh wait somebody already did]. This worked when I asked for the source of an OpenArena Android port on the Play Store years ago.
2. I was wrong about Warsow not being under development - Its Beta was updated just days ago. However I'm there are no regular servers available for players.

Update 2019-08-22:

The source code is there: https://steamcommunity.com/games/671610/announcements/detail/3327517968305237985

This post was retrieved from freegamer.blogspot.com.