FishingCactus

Members
  • Content count

    42
  • Joined

  • Last visited

Community Reputation

1862 Excellent

About FishingCactus

  • Rank
    Member
  1. Algo-Bot Returns

    @jbadams I knew you would like that news
  2. Algo-Bot Returns

    Over a year after the release of Epistory - Typing Chronicles, we are proud to have reached the milestone of an 'Overwhelmingly Positive' User Review score on Steam. This feels like a perfect time to reveal our next original title: Algo-Bot. Algo-Bot is a programming puzzle game taking place on an interstellar colonization ship, crossing the galaxy in search of new grounds to settle for humanity. Once again, we’ve teamed up with Epistory’s writer, Joseph J Clark, to give Algo-Bot a light storyline with a touch of British humor. The concept of the game dates back a few years when we held a Kickstarter campaign to finance its production. Even though the Kickstarter didn’t reach its target, we promised the enthusiastic community that we would make the game if Fishing Cactus managed to secure a budget for it - and here we are! With more funding secured than our Kickstarter campaign was aiming to raise, we’ve plunged our fingers into the original prototype and dug out the core experience. Out of this, we are building a brand new game with improved story elements, design, graphics and more. The game tells the story of an Algo-Bot unit helping a robotic personal assistant - PAL - navigate the maze-like spaceship. As the player, you will take the role of the operator and use a visual programming language to issue a sequence of commands to Algo-Bot. Will you manage to solve all the puzzles? Thanks for reading. Don't hesitate to talk with us on Discord, Twitter , and Facebook.
  3. Shift Quantum Systems

    In this article, we will cover a few aspects of the systems implemented in the code base of Shift Quantum. From how blocks composing the levels are managed, to our command system for the in-game level editor, including how we generate those commands from the HUD, you will have a better idea of how we handle all of this in code. Separation between model and the view Because basically our levels are a grid of blocks, early on in the development of the game we thought it would be best to separate the data from its representation. This would have several advantages: The game would only have to manipulate some raw and abstract data without having to take care of where to place the blocks for example. It's possible to have multiple representations of the model: a 3D representation like now, but also a complete 2D sprite based view if needed ( to generate a map for big levels for example ). It is very easy to write unit tests to validate that the data is correctly handled by the model, enforcing the validity of the various operations on the model throughout the development. The model contains all the information related to the level, like the width and height, the current color space (Black or White), the rotation of the grid, or all the blocks coordinates. It also contains information used only by the in-game level editor, like the cursor coordinates and rotation. The model communicates with the other classes using events. Lots of events... Here is a non exhaustive list of the names of the events to give you a rough idea: FOnInitializedEvent FOnWorldRotationStartedEvent FOnWorldRotationEndedEvent FOnWorldColorUpdatedEvent FOnBlockRegisteredEvent FOnBlockUnRegisteredEvent FOnDimensionsUpdatedEvent etc. The other classes which want to know when something happens in the model just need to subscribe to those events and react accordingly. For example, the level view is interested for example in knowing when the dimensions of the grid are updated, to adjust the boundaries around the play space, or when a block is registered, so the view can move the block to its correct location in the 3D world (because the model does not even know the blocks are in a 3d space), and so onaEUR| One thing to note is that the model does not perform any logic when you update its data. ItaEUR(TM)s up to the caller to take care of removing an existing block before adding a new one at the same coordinates. More about that later in the commands section. Level Editor Commands During the incubation meetings, maybe the first answer given to the question "What do you think is important to have in an in-game editor?" was an Undo-Redo system for all the operations available. So we obviously had to implement a command pattern. This is a very well-know pattern, so I don't think we need to dive a lot in the details. But if you need a refresher, here are some links. Nonetheless, I can give you one advice: your command classes must be as lightweight as possible. No logic should happen in the commands, because the more logic you put inside, the more complicated it will be for you to handle the Undo and Redo parts of the contract. As such, the declaration of the base command class is very simple and straightforward: UCLASS() class SHIFTQUANTUM_API USQCommand : public UObject { GENERATED_BODY() public: USQCommand(); FORCEINLINE const FSQCommandContext & GetContext() const; virtual void Finalize(); virtual bool Do(); virtual void UnDo(); void Initialize( const FSQCoords & coords ); protected: UPROPERTY( VisibleAnywhere ) FSQCommandContext Context; }; I think you will agree it can hardly be less than that. You may notice we don't have a ReDo function, because Do will be used in both scenarios. To execute those commands (and of course to UnDo and Redo them), we have a command manager component attached to our level editor actor. As you can guess, its definition is very simple: class SHIFTQUANTUM_API USQCommandManagerComponent : public UActorComponent { GENERATED_BODY() public: USQCommandManagerComponent(); bool ExecuteCommand( USQCommand * command ); bool UnDoLastCommand( FSQCommandContext & command_context ); bool ReDoLastCommand( FSQCommandContext & command_context ); void ClearCommands(); private: UPROPERTY( VisibleAnywhere, BlueprintReadonly ) bool bCanUndo; UPROPERTY( VisibleAnywhere, BlueprintReadonly ) bool bCanRedo; UPROPERTY( VisibleAnywhere ) TArray DoneCommands; UPROPERTY( VisibleAnywhere ) TArray UnDoneCommands; }; And its implementation is a classic too. For example, the ExecuteCommand: bool USQCommandManagerComponent::ExecuteCommand( USQCommand * command ) { if ( command == nullptr ) { UE_LOG( LogSQ_Command, Error, TEXT( "Can not execute the command because it is null." ) ); return false; } if ( command->Do() ) { DoneCommands.Add( command ); for ( auto undone_command : UnDoneCommands ) { undone_command->Finalize(); } UnDoneCommands.Empty(); bCanUndo = true; bCanRedo = false; return true; } return false; } One function which deserves a bit of explanation is Finalize. You can see this function is called on commands which have been UnDone at the moment we execute a new command, before we empty the UnDoneCommands array. This allows up to do some cleanup because we know for sure the commands won't be executed again. For example, when we want to add a new block in the world, the command generator will spawn that block, initialize it, and pass the block as a pointer to the RegisterBlock command. When we Do that RegisterBlock command, we just kind of toggle on the block (make it visible, set up the collisions, etc.), and when we UnDo the command, we do the opposite (hide it, disable the collisions, and so on). Finalize then becomes the function of choice to destroy the actor spawned by the command generator. void USQCommandRegisterBlock::Finalize() { if ( ensure( Block != nullptr ) ) { GetOuter()->GetWorld()->DestroyActor( Block ); } } bool USQCommandRegisterBlock::Do() { Super::Do(); return ensure( GetTileManagerComponent()->RegisterBlock( *Block, Context.Coords ) ); } void USQCommandRegisterBlock::UnDo() { Super::UnDo(); ensure( GetTileManagerComponent()->UnregisterBlock( Context.Coords ) ); } void USQCommandRegisterBlock::Initialize( const FSQCoords & coords, ASQBlock & block ) { Super::Initialize( coords ); Block = █ } There are two things worth noting: Because the command manager only executes one command at a time, and because any action we do is made of several commands (for example, adding a block in the grid is made of at least 2 commands : remove the existing block at the cursor coordinates, then register the new block), we have a special command class named USQCommandComposite. It stores an array of sub-commands. Those sub-commands are executed linearly in Do and in reverse order in Undo. You may have noticed the FSQCommandContext structure. Each command holds a context internally, which is used to store some global informations at the moment the command is initialized (just before being executed for the very first time). This allows us to restore the cursor position and the zoom level of the camera when we undo / redo any command, allowing the player to have the editor in the same state as it was when he first executed an action. Command generation Because our commands are very simple, we need to put the logic elsewhere. And because we need a way to bind the generation of those commands to the UI, we created class hierarchy deriving from UDataAsset. This allows us to make properties editable in the UE4 editor such as the sprite to display in the HUD, the text to display under the sprite, the static mesh to assign to the cursor, or the maximum number of instances of a given actor which can be spawned in the level (for example, we only allow one start point and one exit door). Here is an excerpt of the definition of this class: UCLASS( BlueprintType, Abstract ) class SHIFTQUANTUM_API USQCommandDataAsset : public UDataAsset { GENERATED_BODY() public: USQCommandDataAsset(); FORCEINLINE bool CanBeExecuted() const; virtual USQCommand * CreateCommand( ASQLevelEditor & level_editor ) const PURE_VIRTUAL( USQCommandDataAsset::CreateCommand, return nullptr; ); protected: UPROPERTY( BlueprintReadonly ) uint8 bCanBeExecuted : 1; UPROPERTY( EditAnywhere ) TSubclassOf BasicBlockClass; UPROPERTY( EditAnywhere, BlueprintReadonly ) UTexture2D * UITexture; UPROPERTY( EditAnywhere, BlueprintReadonly ) FText DisplayText; // … }; For example, here is the editor view of a command data asset used to add a game block in the level: Our command generator assets are grouped by categories, which is another UDataAsset derived class: In the in-game editor UI widget, we just iterate over all the commands of the selected category, and add new buttons in the bottom bar: When the player presses the A button of the gamepad, we know the selected command data asset. Now, we just need to create the command out of this data asset, and give it to the command manager command: bool ASQLevelEditor::ExecuteCommand( USQCommandDataAsset * command_data_asset ) { if ( command_data_asset == nullptr ) { return false; } if ( !command_data_asset->CanBeExecuted() ) { UE_LOG( LogSQ, Warning, TEXT( "The command %s can not be executed." ), *command_data_asset->GetClass()->GetFName().ToString() ); return false; } LastCommandDataAsset = command_data_asset; auto * command = command_data_asset->CreateCommand( *this ); return CommandManagerComponent->ExecuteCommand( command ); } To finish this part, here is the implementation of the command data asset used to register a game block in the level: USQCommand * USQCommandDataAssetAddGameBlock::CreateCommand( ASQLevelEditor & level_editor ) const { if ( !ensure( GameBlockClass != nullptr ) ) { return nullptr; } // Get needed informations, like the cursor position, the current displayed color, and so on… // Early return if we want to register a game block on coordinates which already has the same game block if ( tile_infos.Block->IsA( GameBlockClass ) && tile_infos.BlockPivotCoords == coords ) { return nullptr; } // Spawn the game block auto * game_block = level_editor.GetWorld()->SpawnActor( GameBlockClass ); // … and initialize it // Fill the array with all the coordinates the new game block will cover (some blocks are larger than a single tile) TArray used_coords_array; game_block->GetUsedTileCoords( used_coords_array ); const auto opposite_color = USQHelperLibrary::GetOppositeColor( world_color ); auto * command = NewObject( game_mode ); command->Initialize( "AddGameBlock", coords ); // For each coordinate used by the new game block, unregister the existing block FillCompositeCommandWithUnsetCoords( *command, *tile_manager, used_coords_array, opposite_color ); auto * set_game_block_command = NewObject( game_mode ); set_game_block_command->Initialize( coords, *game_block ); // Finally, register the game block command->AddCommand( *set_game_block_command ); game_block->FillCreationCommand( *command ); return command; } As you can see, there is a lot more logic than inside the various commands, because here, we take care of all the steps needed to execute a final command. As mentioned in the first part, the model does not perform any logic related to the integrity of its data. It's then up to the command generator to make sure for example that all the coordinates of the grid which will be covered by a new game block are first cleared up. This can expand quickly, because maybe one of the coordinates to clear is part of another game block. Then the complete game block must be removed too. But as we can not leave holes in the grid, we must in a last step fill the holes left by removing this game block, but not covered by the game block we want to add, by basic blocks. This gets really hefty in the command generator which allows to resize the level, as you can imagine. And this is where being able to unit-test the model comes in very handy. (VERY!) That's all for today's article. We hope you found it useful and helped you understand a few of the systems we currently use inside our game.
  4. Epistory Retrospective - Looking back over the development of Epistory

    Thanks to you for the support and comment :) 
  5. [font=arial]Once upon a time[/font] Epistory is a typing adventure game, built with Unity3D and released on March 30, 2016. It received very positive reviews - both from critics and players - and sold over 100k copies (including bundles). You can see the game's Steam page here. We recently opened a Discord channel for the company, which you can join using this link: discord.gg. It's been one hell of a ride! In this retrospective article, we'll try to give you a sense of progression from the early prototypes up to the release of the game we all know and love. We'll also talk about the great endeavor a game like this represents, even though Epistory isn't a big game by AAA standards. We'll share some of our successes, failures and missed opportunities. [font=arial][/font] [font=arial]We tried several art styles for the collectible images. First try, not in the final game.[/font] [font=arial]It was the best of times, it was the worst of times[/font] The most critical thing to do in game development is to identify and remove the risks. You take the riskiest feature, and you try it as fast as possible because you don't want a nasty surprise when it's too late to make changes. With an adventure typing game, we didn't know how the typing mechanic would work out: so we created a playable prototype very early on. Our primary goals were to test a typing mechanic to interact with items, handle character movement (which was tile-based at the time), and the mixture of exploration, puzzles and arena fights. Early game development is the best part because all opportunities are still open and you get to try a lot of interesting things. But it is also the worst part as most of what you try is not as interesting as expected. You experience optimism and doubt at the same time. You can see our first working prototype yourself, but keep in mind that it is really barebone and that no artist was involved (it is made with the Construct 2 engine). After that point, development restarted from scratch, with a different engine (Unity 3D), but with all the experience we gathered from the prototype. Play the prototype [font=arial]There was a girl[/font] [font=arial]When the prototyping phase ended, our next goal was to find a new take on the typing game genre, mostly focused on arcade gameplay for short game sessions. We were aiming for 18 short dungeons instead of the 8 large dungeons and overworld we currently have.[/font] [font=arial]Being a relatively small studio, we had to settle on the amount of money available for this adventure. At the beginning, our budget was around EUR125k. We'll explain later why and how but by the end, we were talking about EUR300k. That's 3 and a half people for a year and a half.[/font] [font=arial][/font] [font=arial]Second attempt at an art style. Also not in the final game.[/font] [font=arial]And she rode upon the back of a great fox[/font] Since the first story ideas, we tried to link the typing mechanic with the process of writing a book. We started with a muse giving a writer's inspiration by typing words in a fantasy world which represented the writer's mind. As in the final game, at the beginning the world is empty and there is no story, so the project was called The Heroine of no Tale for quite some time. Mildly interesting fact: we got used to the acronym "THONT" and used it for a long time even after we named the game Epistory. Now the nickname is simply "Epi". If you launched the prototype, you'll have noticed that the girl was walking and that there was no fox around. The great three-tailed fox is based on a mythical creature, a Japanese nine-tailed fox, which looked good in a papercraft style. But the real reason for its existence is that we needed to give the girl a mount, so that we could realistically increase movement speed without changing the world scale. [font=arial][/font] [font=arial]We have a paper fox in the studio![/font] [font=arial]But they were lost[/font] At the start of the development, it was decided that Epistory would serve as an experiment for a new way to manage our projects. Instead of having one project manager serving as an overseer for the whole project, the whole team would be its own manager while one of the Fishing Cactus directors would act as a client/producer. At that time, there were only three developers in the team. One game designer, one programmer and one 3D artist. Each acted as the manager of the other two, responsible for updating the task list, validation of quality standard and so on. Of course, when the project first started we didn't immediately see the implications of that kind of organization. After all, there's so much to do! Creating a list of tasks feels pointless when you don't even have a character moving in the game world. Over time, we organically divided the tasks usually dealt with by a project manager among ourselves. One of us would mostly handle the communication with the externs (localization and audio) while another would mostly deal with the task lists and keep an eye on the schedule and deadlines. In the last few months of development, the three of us would take a few hours to do a full update of the task list and the estimated time left, to make sure we were still on target budget-wise. All in all, we think it worked OK. There's room for improvement, but as a first experiment, it could have been a train wreck! [font=arial]They had always been lost[/font] The first control system, inherited from the prototype, was tile-based and used DFJK to move. We grew tired of the way this worked: it was too slow, too clunky. We quickly changed over to navmesh-based movement, to unleash the player's freedom of movement. This was a lot better: we solved puzzles faster and had a better sense of exploration. But something kept nagging at us. Why did we use DFJK to move instead of WASD like any other game? That's the question we got from everyone who tested the game at that point (and continued to hear even after release!). The answer is that we did not want the game to teach a bad typing behavior, because by playing you'll get used to typing that way. So we wanted to place the control keys on the middle row, where your fingers are supposed to rest on a typical typing position. But having cardinal direction controls aligned on a single row was very confusing. So we began searching for more intuitive controls while maintaining good typing form. After repeated internal playtests of many weird control schemes (like 8 keys to handle 8 directions), we settled on EFJI (plus, after popular demand, we added WASD). This stays close to the default typing position and puts each diagonal direction to the corresponding key (that works more naturally because of our isometric-like view). That binding passed our ultimate "intuitivity" test: running in perfect circles without looking at the keyboard, which means that you can switch naturally between the eight possible directions. [font=arial][/font] [font=arial]Final recommended movement keys[/font] [font=arial]Until a path appeared[/font] A few months after starting development, we saw more enthusiasm for the project's potential both inside the studio and among players. At first, we didn't know if there would be public demand for a typing game so we were really cautious. After showing the game a bit, we knew that we would be able to make something that players would be interested in. Besides that, the first independent game of Fishing Cactus has to be a critical success for the studio's image. Our confidence was increasing and we decided to commit more resources to the project, considerably increasing its budget. What was supposed to be a small-ish arcade game was now going to feature a deeper story and have a bigger scope overall. The game was already in an advanced state: we had prepared a short demo for the upcoming Gamescom and we had the first hour or so of gameplay ready. [font=arial][/font] [font=arial]We added a meteorite early to test some story ideas. We kept the effect, but the text changed a lot![/font] We tried doing the story ourselves but it quickly became clear that, a) we were not gifted for that skill and b) we already had a lot of work just creating the game. We applied for pitches from writers for the game with story and structure intentions. We received a lot of answers: some of them were comical, some were a bit disturbing, but one struck us as the perfect match for the game. The idea of a narrator looking for inspiration shifted to a deeper story: something personal, emotional, and introspective - something which can be read on different levels. We use different fonts and voices to give the player a few hints. You can read more about the story without spoilers. With the story in place, we began searching for a voice. We needed someone who was capable of reaching the emotions needed for the story. Strangely enough, we received a lot of samples sounding like a radio commercial. Not bad by itself but so far from what we were looking for. Finally, we found her! Rachael Messer has a lot of experience voicing games and her voice was just right for Epistory. Her voiceover added a powerful dignity to the narration which really helps the story come to life. [font=arial]And so she followed[/font] The next big step was to rework the introduction of the game according to the new story direction and finish the first dungeon. The goal was to bring that first hour of the game to final quality, kind of like a large vertical slice. Usually, a vertical slice (or VSD for vertical slice demo) is an early demo of the game that aims to show how the game could be at its best. It sets the target for the final visual quality and gameplay experience, but only for a small part of the game. Imagine that we take the final game and cut a thin slice of it; that's your vertical slice. With one hour of gameplay at the middle of Epistory's development, we had the same objective as a vertical slice but with a larger chunk of the game. The other objective of polishing that part of the game was to get it ready for an early access release. [font=arial]Was the path leading her?[/font] And finally, that day came. We released Epistory in early access on September the 30th 2015 with the first chapter of the story (two of the eight dungeons). An early access release is like a mini-release: you feel the same joy and relief of leaving your game to the players, though it reaches a smaller audience than a full release. But the game is not finished so you come back the next day as if nothing had happened. Well, actually not, because when you wake up the next day, you have received a lot of feedback for bugs and features. Mostly bugs. That means extra work for us to do - and quickly, because new players are seeing the game while you are working. It can be stressful, but that is valuable feedback we could never hope to get from internal playtests alone. So, thank you to all of you who took the time to write comments and send feedback. That core group of early players also helps the game grow in popularity. And that is the other reason we released in early access: to build a community around the game before the actual launch. We get Steam reviews, shares on social networks, media coverage and word of mouth. When you are an indie and don't have a marketing budget that equals your development cost, it is what makes the difference between a commercial success or failure. [font=arial][/font] [font=arial]Here's the third style for the images - the one that made it into the final game[/font] [font=arial]Or was she leading it?[/font] Naturally, we developed and added the rest of the game in the order of the story. The initial plan was to release it chapter by chapter throughout the early access, and we did that for the second chapter. But that method was taking us too much time to make temporary versions of the game, and we needed that time to make the game as polished as it could be. Since the updates were not really followed by more sells or visibility, we took the decision to wait and release the rest of the game in one batch. While we are talking about the dungeons we can reveal some small anecdotes for each one. As the first one to be made, Burning Hollow, has been the most reworked dungeon. From a linear beginner level, we restarted from scratch to add hidden treasures and backtracking. Forgotten Forest and Drowning Halls were more straightforward to design: the first one is focused on getting lost in a forest (more than what we could do in the overworld). The second is focused on solving puzzles. Ice Mausoleum has a lot of props which are modified versions of the ones in Burning Hollow as they are basically both underground caverns. One difference is that we added a bit of elevation on this one. For the next half of the game, we were more experienced and we didn't want to make the same thing over and over. So we tried to make the dungeons look different, mostly by making them less flat. Creation City does exactly that: it has 7 stages and from the final fight at the top you can see everything behind. All items are sorted by stage and the stages above you are hidden so they do not block the camera. The more technically challenging was probably the Crystalline Mine because we added a new gameplay system with light switching. Setting all those lights and having the words hidden in the dark was way more complicated than we expected. Shattered Isles' design is inspired by the part in Forgotten Forest where you can see small islands floating under the level. Finally, Lost Desert has regular point of view of the mountain that symbolizes your final goal. The mountain you see there has additional parts that are hidden when you actually reach it. [font=arial]She didn't know. It was just there[/font] For eight years, we developed games for others and we used to keep our games secret until the publisher decided to release it. So, our first question was: when should we make the game public? Having the choice of going public early in development was quite shiny and new and definitely what we wanted. But the real question was: what did the game need? Releasing a typing game as your first product is a big challenge. We knew from the beginning that Epistory was going to be a fairly niche game. Too often categorized as an educational game, we tried to emphasize on the art style and the "RPG - Adventure - Puzzle" side of it and after early feedback from the community, we came up with a tagline: "If Zelda and a keyboard had a baby, it would be Epistory." We didn't like to explain our game solely by comparing it to others, but with such a nebulous concept, it felt like a necessity. Our whole team got involved with public communications, which was definitely an advantage to us. It saved us time and helped present a better image of ourselves. It helped with community management, both during events and when we needed to write articles about development. The idea was to try our best to give a real, honest insight into development to people who followed the project. We will publish an article diving deeper into our communication strategy soon. [font=arial][/font] [font=arial]One of our marketing images.[/font] [font=arial]All of a sudden, she knew where she was[/font] Throughout early access, we were careful to always be present, active and helpful in the Steam forums. We were (and still are) firm believers in direct communication between players and the development team. It creates a strong community and we even received praise just for being there. It's also great to get to interact with streamers and YouTubers, mostly as a surprise random encounter in the video's comments or the chat. Since we don't have the resources to organize extensive playtests, checking Let's Plays was a major source for bug hunting and player behavior analysis. Our tutorial messages were updated to be clearer after seeing videos with players not fully understanding the fire magic burning effect. Thanks, by the way, to any streams and LPers who gave us this excellent feedback! By February 2016, after releasing two chapters on early access, most of the game was ready. The finishing touches were being added to the last dungeon of the game. The ending sequence and the accompanying video were being finalized. The list of bugs was shrinking day by day as we polished the game, getting it ready for its big day. [font=arial]She was home[/font] Fast forward a few weeks and: Launch Day! The game has been polished until it shines like a mirror. After several months of prototyping, followed by a year and a half of production, we were finally ready to hit the big green LAUNCH button. In the days that followed, we were ecstatic. The players loved the game, the critics loved the game, we loved the game and we were -and still are- proud of our achievement. But this was only the first part of the journey. To this day, one year after that release, Epistory is still being worked on albeit at a slow pace. We can't wait to share our next projects with the community. [font=arial][/font] [font=arial]Anniversary T-shirt.[/font]
  6. Shift Quantum

      Hi Guys, This month, we celebrate the 1st year anniversary of our first self-funded game: Epistory. We feel like it’s the right moment to announce our next game, in development, Shift Quantum. Associated with the puzzle-platformer genre, Shift Quantum takes you through the mental maze of your brain in search of a way out. Who knows what secrets can be found behind cold and logical human thinking?   The Challenges Gameplay Shift was originally a Flash game series that has had many versions such as Shift DX and has been ported to iOS, PSP and Nintendo 3DS by Fishing Cactus. The gameplay revolves around a room that is half black, half white, one of which is solid. When the player shifts, the room flips upside down, and the opposite color becomes solid. The goal is to get keys and reach doors while avoiding spikes and other objects. One of the many challenges we’ll have to face will be to build an entire game based on 1 single cool mechanic and to take it to an entirely new level while keeping the original spirit intact. New Art Direction The original games relied on a very simple black and white style; nothing in color and not even gray. In a nutshell, nothing that could interfere with the comprehension of the level.   Nine years after the first Flash version of the game, we now imagine a Next Gen Shift game that has more to offer visually than its predecessors. The new art direction will enhance the gameplay and create the context for a richer story.   Strong community aspect One of the strengths of Shift rests on the level editor. We already provided a level editor with Shift DX, but this time, the level editor will be more integrated into the whole experience.   Most of our pre-production phase was dedicated to the editor and not the game itself.We designed it from scratch to provide the best possible user experience of the Editor. Our goal is to allow the community to build levels that will be implemented in the story with the same tools that we use to create the game itself.   A new engine Even though we created the first prototype in Unity last year to test the basic gameplay mechanics and to help us validate the art direction, we chose to develop the game using Unreal Engine 4.     There are multiple reasons behind this choice: Two members of the team already have a solid experience with this engine. It was not a leap of faith into the unknown. After the pre-production phase, it was clear to us that we can develop the complete game using this engine. We are a very diverse studio. We don’t like to focus primarily on 1 technology for example. It’s not because we have developed multiple games of various sizes with Unity or our proprietary engine, that we don’t have a look at other possibilities. Shift Quantum was the perfect opportunity to expand our knowledge and our experience. Because we plan to release the game on several platforms, being able to use an editor that is used by many companies to build AAA games is a real plus. This way we can also benefit from a state of the art animation system, a great material editor, and all the other built-in tools which help us save a lot of time. After almost three months of development, we are more than certain that going for UE4 was a great choice. We have the same velocity as with our games developed using Unity. Moreover, using a codebase which has been used and proofed over the past two decades makes us to more confident in the success of this game in the long run. Thank you for reading!   Follow us on Indie DB, Twitter and Facebook IndieDB @shiftquantum Facebook.com
  7. How to create a second blog

    Thank you very much for the help.  @jbadams it's in our plan. We actually have a team that will start to work on it soon :) 
  8. Hello,   Two years ago, I created a blog for our game Epistory and now we are developing another game and I'd like to create a new blog. Unfortunately, I can't find how to do it. There is no "new" button in my blogs manager.    Can you help me?    Cheers,
  9. Coming Events

    Hi Guys,    We will be at Gamescom (Germany) and Tokyo Game Show with our game Epistory this summer. I was wondering if some of you plan to be there as well.    Let me know if you have other events in your plans :)
  10. Major Update

    [font=tahoma]After weeks of hard work, we present to you the new and shinier version of Epistory. You spoke and we listened. We understand it would have been better for most of you to receive the update in chunks over the weeks but given the amount of changes it was a lot easier for us to handle one big transition to the new version instead of several small incremental versions. We even had to stop planning for a workshop beta. Without further ado, here's the changelist: Added/Improved[/font] [font=tahoma]Mod support.[/font] [font=tahoma]Profiles (multiple saves) support.[/font] [font=tahoma]Steam Cloud support.[/font] [font=tahoma]Distinction between gameplay and story language.[/font] [font=tahoma]Splash screen only when the game launches.[/font] [font=tahoma]Removed mouse cursor during gameplay.[/font] [font=tahoma]Improved arena wave randomness.[/font] [font=tahoma]Single letter words always get typed, even in the middle of another word.[/font] [font=tahoma]Several small improvements for the map.[/font] [font=tahoma](slightly) Improved performance, (massively) reduced spikes.[/font] [font=tahoma]V-Sync option.[/font] [font=tahoma]Custom mouse cursor.[/font] [font=tahoma]Fixed[/font] [font=tahoma]Several sound errors. Please let us know if you still encounter any problems.[/font] [font=tahoma]Game not loading on Linux when the OS is not set to English locale.[/font] [font=tahoma]Several small bugs for the map.[/font] [font=tahoma]Several small errors in the story texts.[/font] [font=tahoma]Several keyboard specific patterns.[/font] [font=tahoma]Music/effects volume preference not always respected.[/font] [font=tahoma]Entering the "Ice Mausoleum" door without triggering the scene change.[/font] [font=tahoma]And of course several small improvements/fixes across the board that would be too long to list. As always, we welcome your feedback and bug reports.[/font]
  11. Fonts of Wisdom: Choosing Typefaces for Epistory

    [color=#333333]Choosing a font is never easy and for Epistory, it nearly drove me mad. We didn't have to find only one font, but[/color][color=#333333] three. Three fonts that needed to match together, follow constraints and have their own identity.[/color] [color=#333333]We had just a few constraints:[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]To support a wide range of symbols (French, Portuguese, Polish accents, Russian symbols...)[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]To always be easily readable[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]To give an idea or a hint of its purpose[/color] [color=#333333]...Simple.[/color] [color=#333333]Typing Font[/color] [color=#333333]The first font we decided to work on was the typable one: the font that will lead players through the game and on which the gameplay relies. The difficulty was to have a font readable on which we could add different kinds of feedback: such as the kind of magic needed, the right magic selected and so on.[/color] [color=#333333]We also wanted to suggest that the font belonged to a book, so we chose a font with serifs. "Optimus princeps", already used for the subtitle in our logo, was our first selection but there were too many missing symbols. [/color][color=#333333]Instead, it became our reference for our future selections.[/color] [color=#333333]Serifs turned out to be a bad idea. The problem we encountered with those fonts was that they were not easy to read at all. I'll spare you from all the steps we passed through because it will be a long and annoying description of research. Instead, I'd prefer to simply explain why we choose "YanoneKaffesatz".[/color] [color=#333333]At first we added constraints in order to determine with precision our needs:[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]Find a vertical font that allows us to add long words without taking too much space[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]Simple, no serifs, no extravagance to increase the readability[/color] [color=#333333][font=symbol][size=2]. [/font][/color][color=#333333]Large enough for adding FX (but not too much)[/color] [color=#333333]After that, our decision came naturally. We forget it too often, but sometimes "feeling it" is the most important way.[/color] [color=#333333]Feeling the Font[/color] [color=#333333]When your brain drives you mad with all its "what if", it's time to turn it off and focus on what the font makes you feel.[/color] [color=#333333]The "YanoneKaffesatz" was, for me, the perfect font for many reasons. The regularity of the letters suits to a "book", to a story, and the roundness feels "womanly". Eech letter is readable, serene... perfect for when half-dozen monsters come to you.[/color] [color=#333333]For the main story font, which appears drawn on the world, our research didn't last as long as for the first font. We noticed quickly that "Kingthings Petrock" would suit to our needs. Like "Yanone", it was large enough to be readable in the bright grassland as well as in the dark cave, not too fanciful, but it also has the style of an illuminated manuscript, suits the story we wanted to tell.[/color] [color=#333333]The Secret Font[/color] [color=#333333]Our last font one keeps a secret... it's a whisper, it's like it isn't really there and as soon as you see it, it's already gone...[/color] [color=#333333]I chose this one only by instinct. I wanted something womanly, something personal, handwritten but not conventional. It had to be attractive... and disturbing as well. When I found "luna" I knew right away that it was the font I was looking for.[/color] [color=#333333]With Unity, I added some effects to this jarring, mysterious text: a little cloudiness that makes it less material and increases the impression of strangeness. The reasons why I chose it are pretty much spoilers so I won't expand on that subject.[/color] [color=#333333]I spent weeks - maybe months - on these choices, but I've learned a lot. Principally to trust myself. I've done my best on it and sold a part of my soul for the game.[/color] [color=#333333]In the end I hope that you'll enjoy the experience - because that's what really matters.[/color]
  12. Epistory is now out on Steam!

    Hi Fox Riders! Epistory is finally fully released. Can't wait for you to discover the end of the game. Good luck with hours of game waiting for you. Also, we'd like to thank all of you for the support and love during the early access. Don't hesitate to share our new trailer around you. In the coming weeks, we plan to fix the very few remaining bugs you could find in this version. We are even thinking of adding more languages. But now let's party! Play the game here.
  13. Finding the Right Words

    [font=arial]The challenge of localizing of a typing game[/font] [font=arial]In Epistory, typing is the sole interaction the player has with the game. You get to type a lot of words, in fun, varied ways, so we end up with a lot of text content. We don't just use random words, but words that fits with several constraints (of theme and gameplay). That makes the translation work crucial for the experience of the non-english speaking players.[/font] [font=arial]So let's take a look at the main challenges we had with localizing our text-based content and the solutions we came up with.[/font] [font=arial]The Story's Script[/font] [font=arial]First of all, the easiest and less interesting one, the story's script. Well, the way the story is made is a very interesting topic (and our writer wrote an article about it). But its localization is just a regular translation.[/font] [font=arial]In the game, script text is displayed as sentences scattered across in the game world, that you can read as you explore. As a result, the script looks like a list of unrelated sentences. The challenge was to give our translators a sense of how those sentences were linked together to form a whole story. We wrote comments about the context of each sentence and it worked just fine. It was particularly useful to give instructions on what was the most important aspect of the text to translate: was it the literal sense, an underlying meaning, or the style (like when there is an alliteration)?[/font] [font=arial]Words to Type[/font] [font=arial]Outside of the story script, our other use of text is to display prompt words. We show words alongside "interactive elements" to trigger some kind of interaction - like planting a flower or destroying a rock. Our intention was to give meaning to what you type while avoiding repetition. But we couldn't possibly manually assign a specific word to each element. We also needed to easily control the complexity of the words used, to keep the difficulty balanced. And finally, we had to deal with languages having different word lengths and special characters.[/font] [font=arial]Gameplay wise, our solution was to give to each kind of element a dictionary from which a word is picked up randomly. The dictionaries have a given theme and word length restrictions. For example, the action of creating flowers is defined as easy, and so its dictionary has words which are flower names under 8 characters. The destruction of a rock is considered harder (thus it gives more points), therefore its dictionary uses scientific names of minerals between 8 and 10 characters.[/font] [font=arial][/font] [font=arial]For localization, translators were asked to fill up the dictionaries using the same constraints for every language.[/font] [font=arial]Several Languages in Early Access[/font] [font=arial]Epistory is reaching the end of a six-month early access period, during which we added story content as well as gameplay features. All that content was available in English, German and French since the first day of early access. Spanish was also added later on.[/font] [font=arial][/font] [font=arial][/font] [font=arial]On the one hand, it was a good thing to make early access available in several languages (at least, that's what our German and French players said). Besides opening the game to more buyers, it allowed us to check the quality of the early access builds thanks to our most dedicated players. For example, without them, we would not have thought about creating a German-Swiss dictionary (which uses "ss" instead of "ss"). One German fan even proposed to proof-read the script directly![/font] [font=arial][/font] [font=arial]On the other hand, that forced us to go through translation process several times as we iterated on the script and level design, which is quite time consuming. The challenge here was to allow an easy integration on our iterative versions.[/font] [font=arial]After several adaptations, we ended up with a configuration that works (surprisingly) well: the script is in an Excel document that directly exports an XML file, while the dictionaries are in a Google spreadsheet with a homemade script that exports a JSON file.[/font] [font=arial]The key was to keep a limited number of languages during early access (3 more languages will come at release). But given the amount of work required to do the translation and keep it up to date, I would not recommend to do that for games with heavy text content. It is preferable to stick to English, at least until the source content is sure not to change too much.[/font] [font=arial]Special Characters[/font] [font=arial]All those beautiful languages have their own eccentricities and colloquialisms, and it is far from obvious to know how they are used when you don't speak that language. What concerned us the most were the special characters (o in French, ss in German, ? in Polish...). We even have a Russian translation, which means cyrillic alphabet.[/font] [font=arial][/font] [font=arial][/font] [font=arial][/font] [font=arial]Our first approach was to work closely with professional translators in order to have a good understanding of each language. We asked a lot of questions about what special characters are used, how frequently they occur, what keyboard layouts are popular, and so on.[/font] [font=arial]That information helped us set up the rules for the words that players have to type (the dictionaries). We decided that common special characters are an important enough part of a language to be conserved. But the very rare ones (that exist mostly because of etymological history) and the ones that require more than one keystroke have to be avoided. In short, we wanted to avoid any frustration from players confronted to the most complex words their native language can provide.[/font] [font=arial][/font] [font=arial][/font] [font=arial]The other side of the problem was to display those words with a unique font. We have several fonts depending on where text is used in the game, but we did not want to change the font depending on the language. We choose the simplest solution: which was to meticulously choose the fonts we wanted and add any special characters ourselves. We had to buy a specialised software licence, but finding a good font with all the characters required would have been an almost impossible struggle.[/font] [font=arial]Editable by Players[/font] [font=arial]Finally, I want to add something that is not a challenge but an opportunity. We are leveraging our heavily text-based content as an advantage: it's easy for anyone to edit and create something by just changing the dictionaries.[/font] [font=arial]That's why we will find a way to let players edit and share their own dictionaries to be used in the game. We've already met a teacher who wanted to use Epistory to teach foreign languages to his students. So we hope to see a lot of inspired user-created dictionaries, from the funniest jokes to the most serious creations.[/font] [font=arial]If you want to have fun with word as much as we do, Epistory is currently available in early access and will be released the 30th of March 2016 in 8 beautiful languages.[/font]
  14. How extra budget can increase your visual quality... and put you into troubles

    Thank you guys :) 
  15. Epistory

    All assets and screenshots of Epistory