moved stuff around

arise-source/en/index.md

@@ -0,0 +1,13 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Index: English"
+
+Author:: "Jose Falanga"
+Description:: "English Index"
+Language:: "en"
+Thumbnail:: ""
+Published Date:: ""
+Modified Date:: ""
+
+toc:: "true"
+content_header:: "false"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->

arise-source/en/rehosted/find-the-fun/index.md

@@ -0,0 +1,26 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Find the Fun First"
+
+Author:: "Uber Entertainment"
+Description:: "Find the Fun First"
+Language:: "en"
+Thumbnail:: "arise-icon.png"
+Published Date:: "2008-10-03"
+Modified Date:: "2025-10-13"
+
+content_header:: "false"
+rss_hide:: "true"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->
+
+# Find the Fun First
+
+
+> Originally posted in the now defunct uber.typepad.com blog. You can find an archived version on [The Internet Archive](https://web.archive.org/web/20250911234829/https://uber.typepad.com/birthofagame/2008/10/find-the-fun-fi.html)
+
+When starting a new project my motto is "Find the Fun First". I've seen too many projects ramp up a full production team based on a loosely written design document (or tome). They grind out new tech subsystems and art resources for a year or two only to discover the game isn't any fun. Why isn't it fun? Is it because the design doc is so incomplete? Are the programmers not delivering tech on time? are the artists falling behind in the production schedule? Having ramped up too early it's quite likely all of these are true, however they're not to blame for why the game isn't fun.
+
+When we prototype our gameplay we use a process called "whiteboxing". This simply means we create the absolute minimal amount of code and art in order to support a particular game mechanic or feature. Often times the minimal visual representation is simply a white box, hence the term. If your game isn't fun with 100% whitebox assets and code then it isn't going to be fun with $10 million in beautiful art and robust game subsystems. The less you've invested in art and code during the prototyping phase, the cheaper it is to change things when they don't work out. What sounds fun on paper doesn't always work in game.
+
+You can spend a year or more in this phase and spend relatively little money. The unfortunate part is that when trying to sign a deal with a publisher you're likely going to have to create something "pretty". This usually means the dreaded "vertical slice" which is one of the worst industry practices in existence. That's not to say there is **no** place for a vertical slice, but it certainly doesn't belong anywhere near the prototyping phase. This is a topic that deserves it's own post in the future. For now, I'll just leave it saying it's in our best interest to stay as long as possible in the prototyping phase. Lean and mean.
+
+Once upon a time Scathis and I had the pleasure of working on a project together, just the two of us, for a solid year before even bringing on an artist. Our goal was to come up with some innovative gameplay that could be executed on some existing technology with relatively little changes. In that time we tested tons of ideas, threw out most, and eventually honed in on some really great gameplay. When we brought in our art director he brought in a welcome breath of creativity and was vital to bringing our fun, yet ugly game, to life.  For this reason, we're very excited to have had our art director come on board last week. We intentionally wanted to bring him on early in the process as his virtuoso ability will enable us to prototype ideas that  have advanced technical art requirements such as intricate animations and material compositions. Expect to hear from him soon!

arise-source/en/rehosted/index.md

@@ -0,0 +1,13 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Index: Rehosted"
+
+Author:: "Jose Falanga"
+Description:: "A collection of re-hosted content from lost places and times."
+Language:: "en"
+Thumbnail:: ""
+Published Date:: ""
+Modified Date:: ""
+
+toc:: "true"
+content_header:: "false"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->

arise-source/en/rehosted/vertical-vs-horizontal/index.md

@@ -0,0 +1,33 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Vertical Slice vs. Horizontal Layer"
+
+Author:: "Uber Entertainment"
+Description:: "Vertical Slice vs. Horizontal Layer"
+Language:: "en"
+Thumbnail:: "arise-icon.png"
+Published Date:: "2009-04-16"
+Modified Date:: "2025-10-13"
+
+content_header:: "false"
+rss_hide:: "true"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->
+
+# Vertical Slice vs. Horizontal Layer
+
+> Originally posted in the now defunct uber.typepad.com blog. You can find an archived version on [The Internet Archive](https://web.archive.org/web/20250914133730/https://uber.typepad.com/birthofagame/2009/04/vertical-slice-vs-horizontal-layer.html)
+
+I've [mentioned before](../find-the-fun) [(archive)](https://web.archive.org/web/20250914133730/https://uber.typepad.com/birthofagame/2008/10/find-the-fun-fi.html) I think the Vertical Slice (VS) is one of the most abused industry practices. By definition, it ought to be a version of your software that is near final quality in a small subset of its domain that represents the overall product. If you're making Call of Duty 4 it might be "just one mission" complete with working AI controlled enemies, HUD art, polished control scheme, in-mission cinematics, and near final quality art assets. The problem is getting to this vertical slice actually requires completing a huge portion of the game. For example, the subset of character rigs and animations required for the level may be 80% of the animations needed for the entire game. The UI and HUD are an often underestimated amount of work yet having near final quality versions of them for "just one mission" is saying that entire subsystem needs to be nearly complete. The requirements may say 3 weapons out of the 15 that will be in game, but you'll be doing more than 1/5th of the code underneath to meet those requirements. If employed too early in development the VS can derail an entire project or worse put it on the fast track to nowhere.
+
+So when is the appropriate time to build a Vertical Slice? I say after the few Horizontal Layer iterations are complete. What's a Horizontal Layer? Glad you asked. When we prototype at Uber, we prototype the entire game from beginning to end. This includes single player, multiplayer, main menus, option screens, cinematics, mission briefings, etc. When the entire experience is laid out in whitebox form, that is with temporary art assets and most likely temporary code, we call that a Horizontal Layer (HL). This gives us the best sense of the actual work required to complete the game, and the iteration on the HL creates a breeding ground of creativity as trying out new ideas is quick and inexpensive.
+
+Now, you and I well know in the real world there are often constraints and external forces that result in a VS being embarked upon before the entire game has been covered with HLs. This can work though if properly planned and there has been at least a couple of HL iterations laid in the specific area the VS is targeting. In fact this is exactly what we recently did on our current project. We built an HL for just the core MP game experience, and after several iterations on that decided to go for a VS with a subset of the content. This allowed us to put together a really kick ass gameplay video that we showed off, in private, at GDC.
+
+My diagram-fu is weakened when working on my laptop’s track-pad, but the diagram below still serves to illustrate a few key points.
+
+![A lot of slices](graph.jpg)
+
+First, components of the game (Single Player, Tutorial, etc) differ in the amount of work and are so represented by different width blocks. As each HL is complete quality goes up. The VS sits on top of the HL and therefore is elevated in quality by it. In this diagram two vertical slices are created for two different portions of the game; single player and multiplayer. You can see that the slices themselves are of different widths. This represents the amount of the component the VS is meant to demonstrate. For example the single player VS may only be showing off one portion of one campaign mission, whereas the multiplayer VS might be demonstrating nearly fully functional gameplay on a variety of maps. Also note that each slice was started during a different HL iteration. Had the VS for single player began on the 3rd HL iteration it would have achieved a higher quality level.
+
+Our focus now is on laying Horizontal Layers for the rest of the game, which can be broken up into several distinct segments. After iterating upon these layers several time we’ll go vertical, possibly on multiple ones simultaneously.
+
+To summarize, the Vertical Slice is a useful tool when employed in a controlled manner at the right time for the software, but can be disastrous if executed in contrary conditions. Here’s a rule of thumb: **Iterate on an Horizontal Layer that covers the desired areas of the game at least 3 times before taking on the Vertical Slice**.

arise-source/en/software/index.md

@@ -0,0 +1,13 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Index: Software"
+
+Author:: "Jose Falanga"
+Description:: "Thoughts on software and its many applications"
+Language:: "en"
+Thumbnail:: ""
+Published Date:: ""
+Modified Date:: ""
+
+toc:: "true"
+content_header:: "false"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->

arise-source/en/software/katas/blind-monster-kata/index.md

@@ -0,0 +1,31 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Blind Monster Kata"
+
+Author:: "Jose Falanga"
+Description:: "Kata to try the Mute Ping Pong constrain"
+Language:: "en"
+Thumbnail:: "kanagawa.jpg"
+Published Date:: "2025-09-08"
+Modified Date:: "2022-09-08"
+
+content_header:: "false"
+rss_hide:: "true"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->
+# Blind Monster Kata
+## Constrains
+[Mute Ping Pong](https://kata-log.rocks/mute-ping-pong)
+
+## Rules
+Write the core system of game, with the following rules:
+- There is a human in a room.
+- The room is represented throug a grid of tiles of arbitrary size.
+- The human starts in an arbitrary place in the room.
+- The human can move anywhere in the room.
+- The goal of the human is escaping the room. This is done by reaching the tile adjacent to the door.
+- The human makes noise while moving, but is silent if crouches.
+- Crouching makes movement 2x slower. If takes one second to move between 2 adjacent tiles, moving while crouching takes 2 seconds.
+- The passage of time is represented with a turn-based system. Each turn represents the same amount of time (eg: one sencond)
+- There is a monster in the room. The monster is blind, but can hear very well.
+- The monster starts at the tile adjacent to the door.
+- The monster is searching for the human. Will go to any tile where there is sound, at twice the walking speed the human has.
+- If the monster is in an adjacent tile with the human, will hear the heartbeat and localize it immediatly. Doing so will attack and kill the human.

arise-source/en/software/katas/conway-kata/index.md

@@ -0,0 +1,23 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Conway's Kata"
+
+Author:: "Jose Falanga"
+Description:: "Kata to try different programming paradigms"
+Language:: "en"
+Thumbnail:: "kanagawa.jpg"
+Published Date:: "2025-09-08"
+Modified Date:: "2022-09-08"
+
+content_header:: "false"
+rss_hide:: "true"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->
+# Conway's Kata
+
+This is an exercise on programming paradigms, implement the rules using as many programming paradigms as you know. Personally I recommend testing OOP and ECS.
+
+## Rules of Conway's Game of Life
+
+- A living cell with less than two neighbors: Dies
+- A living cell with two or three neighbors: Survives
+- A living cell with more than three neighbors: Dies
+- A dead cell with exactly three neighbors: Becomes alive

arise-source/en/software/katas/index.md

@@ -0,0 +1,13 @@
+<!-- BEGIN ARISE ------------------------------
+Title:: "Index: Katas"
+
+Author:: "Jose Falanga"
+Description:: "A collection of programming katas"
+Language:: "en"
+Thumbnail:: ""
+Published Date:: ""
+Modified Date:: ""
+
+toc:: "true"
+content_header:: "false"
+---- END ARISE \\ DO NOT MODIFY THIS LINE ---->