Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1865 Excellent

About FishingCactus

  • Rank

Personal Information

  • Role
    Business Development
  • Interests


  • Twitter
  • Steam

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. NanotaleTeaser_with_sound.mp4 Something is wrong with the heart of magic. Play a young archivist venturing out into a dying world, cataloging its mysteries and its wonders to unearth the truth. Nanotale is the new adventure from the Typing Chronicles franchise and the spiritual successor to the acclaimed Epistory. We are proud to finally be able to announce the development of our new typing game, Nanotale - Typing Chronicles, the spiritual successor to 2016’s acclaimed indie title Epistory - Typing Chronicles. Something is wrong with the heart of magic. Play a young archivist venturing out into a dying world, cataloging its mysteries and its wonders to unearth the truth. Nanotale - Typing Chronicles is an atmospheric typing adventure RPG set in a colorful vibrant world that blooms to life under the words of Greg Buchanan [www.gregbuchanan.co.uk]. Developed by Fishing Cactus Games with the same core team as Epistory - Typing Chronicles, we can’t wait to share the adventure! Wishlist the game NOW Weekly Updates Today is the opening of our Steam page, and with it, the beginning of us being able to talk about the project. To make sure that communication between players and devs flows perfectly, we will post weekly updates about the game on the following channels: Nanotale Steampage Twitter Facebook [www.facebook.com] Discord [discord.gg] Your voice is important Many of player participated in our survey last year about those features they loved in Epistory and how they would like to see these features in our next title. That survey has been used as a solid base when brainstorming about the Nanotale - Typing Chronicles. It helped us to capture the DNA, the essence of Epistory, to create a new game that we hope will please the community. Sometimes decisions have to be taken. Some are harder than others, but we will count on you to continue to enlighten us about what you think of Nanotale - Typing Chronicles. We want you to take part in this incredible new typing adventure with us! Leave us your thoughts in a comment and don’t hesitate to spread the news all around you! Thank you!
  2. FishingCactus

    Nanotale - Typing Chronicles

    "Hark, stranger. Be still a moment. Listen to the sounds… Do you hear them, far off in the deep?" Since time immemorial the Archivists have studied and cataloged the mysteries of the planet, observing its changes and holding to our vow of neutrality. Yet from the Ancestral Forest to the Blue Desert, the world is suffering. The Tree of Life sings the Final Song and we can feel it in our flesh: the world is dying. We bear witness, but we cannot interfere. We contemplate in silence. Nanotale - Typing Chronicles is an atmospheric typing adventure RPG set in a colorful vibrant world. Follow Rosalind, a novice Archivist, as she journeys out into a valley to collect plant and rock samples for further analysis. The valley is peaceful. War is a thing of the distant past. Nothing can go wrong with such a casual task... can it? Wishlist the game on Steam
  3. Shift Quantum is OUT! Challenge your limits in pursuit of happiness as dystopian worlds collide. Set in a dystopian world of tomorrow, where a simple program places happiness within everyone's reach, you connect to one of Axon Vertigo’s experimental test subjects and plug into Shift Quantum’s black and white maze. Use the unique SHIFT mechanic to invert the world, create negative spaces, move blocks and modify gravity to avoid the deadly traps and reach the exit of all 117 labyrinths. At the end, will you truly discover happiness? Included with Shift Quantum is a user-friendly in-game level editor, allowing players to create their own mind-bending levels to share with communities cross-platform. Challenge and be challenged, rate each level and get the top feature on Axon Vertigo’s leaderboard. Shift Quantum is all about contrast. Whether in the atypical art style, the unique SHIFT mechanic, or the dual-sided narrative, you can feel constant conflict as an omnipresent aspect of the game’s design. This is also reflected in the atmospheric, dystopian and cyberpunk-esque soundtrack, devised by music composers Volkor X and Simon Felix, who worked together in a ‘call-and-answer’ format, wherein each track of the score is a contrasting piece produced by the other composer. STEAM: Store.steampowered.com … PlayStation: Store.sonyentertainmentnetwork.com … Nintendo Switch: Nintendo.com … Xbox One: Microsoft.com … So... hype?
  4. FishingCactus

    Shift Quantum

    Now Available STEAM: http://store.steampowered.com/app/700520/Shift_Quantum/ … PlayStation:https://store.sonyentertainmentnetwork.com/#!/cid=EP4807-CUSA11475_00-SHIFTPREORDER001 … Nintendo Switch:https://www.nintendo.com/games/detail/shift-quantum-switch … Xbox One:https://www.microsoft.com/en-us/store/p/shift-quantum/c56md02tbxsn … Axon Vertigo, the world's leading authority and most trusted friend in cerebral contentedness programming, promises to deliver better life quality for everyone with the Shift Quantum program. Connected to the cyber-noir action-puzzle platformer, you will be tasked to solve puzzles and create negative space by inverting the world to transform barriers into escape routes. Shift the world, twist your environment, bend your mind to unveil its secrets and solve each brain-drilling level. Make use of all special gameplay blocks to overcome obstacles and get to the exit to find the happiness you have been searching for and promised by Axon Vertigo. Join Axon Vertigo's Level Editor for the Shift Quantum program to create your own custom levels and publish them to the community to get played, rated and featured. Don't limit your challenges, challenge your limits. FEATURES Stylish black and white game world set in a cerebral cyber reality 8 new and unique gameplay elements to challenge your brain with puzzle and action mechanics A brand new story based on a mysterious AI controlled character Solo content with over 100 unique levels that will test your abilities like never before An easy-to-use, fully fledged cross-platforms level editor allowing you to create your own levels Share and play levels from other platforms (Xbox one, Playstation 4 and Switch) Level creation contests, speedruns and weekly votes for top levels and showcase Astounding cyber-noir soundtrack to Shift Quantum created by Volkor X and Simon Felix. Controller and keyboard support Big picture support Steam achievements and leaderboards Cloud save progression 4K Supported Steam Controller supported
  5. Independent developer Fishing Cactus brings their charming new programming game to Steam Mons, Belgium, February 14, 2018 - independent game developer Fishing Cactus (Epistory - Typing Chronicles, 2016) announced today that Algo Bot, a pan-galactic coding-based adventure puzzle game, is available on Steam for $9.99 USD. In the rich single-player story campaign, Algo Bot meets PAL, a cantankerous and aloof line manager, and Gemini, the cheerfully eccentric shipboard computer. When a routine recycling job goes horribly wrong, Algo Bot and this unlikely band of heroes must work together to save the sleeping colonists on board the Europa. Algo Bot is a unique futuristic adventure puzzle game, delivering a one-of-a-kind programming gameplay experience, teaching basic programming concepts in a fun and entertaining way. Algo Bot’s features include: A bittersweet story with two lovable heroes Over 40 programming puzzles set in 5 unique environments Easy to understand for beginners, but difficult enough for puzzle enthusiasts Play with various programming concepts Backtrack to already cleared levels to optimize your solutions Stunning 3D graphics The British Touch: we’ve teamed up with Epistory’s writer, Joseph J Clark, to give Algo Bot a light storyline with a touch of British humor Algo Bot is available now on Steam for $9.99 USD in English, French, Spanish, German, Russian, Polish and Italian http://bit.ly/2Due9Ou
  6. Hello Guys, I am happy to announce the release of Algo Bot on Steam on February 14th, 2018. Steam page for wishlisting Twitter Facebook Algo Bot is a puzzle game which challenges players to control the movements of a lowly maintenance droid aboard the pan-galactic colonization ship Europa. Over 46 levels, players must devise algorithms to carefully control Algo Bot’s path, borrowing concepts from the programming world - including variables and subroutines. In the rich single-player story campaign, Algo Bot meets PAL, a cantankerous and aloof line manager, and Gemini, the cheerfully eccentric shipboard computer. When a routine recycling job goes horribly wrong, Algo Bot and this unlikely band of heroes must work together to save the sleeping colonists on board the Europa. Algo Bot blends basic programming skills with gameplay to make a fun, creative and ultimately satisfying puzzle game.
  7. FishingCactus

    Algo-Bot Returns

    @jbadams I knew you would like that news
  8. FishingCactus

    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.
  9. FishingCactus

    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?EUR? 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 on?EUR? One thing to note is that the model does not perform any logic when you update its data. It?EUR(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< USQCommand * > DoneCommands; UPROPERTY( VisibleAnywhere ) TArray< USQCommand * > 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?EUR(TM)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?EUR?), and when we UnDo the command, we do the opposite (hide it, disable the collisions, and so on?EUR?). 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< ASQBasicBlock > 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< ASQGameBlock >( 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< FSQCoords > used_coords_array; game_block->GetUsedTileCoords( used_coords_array ); const auto opposite_color = USQHelperLibrary::GetOppositeColor( world_color ); auto * command = NewObject< USQCommandComposite >( 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< USQCommandRegisterBlock >( 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?EUR(TM)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?EUR(TM)s all for today?EUR(TM)s article. We hope you found it useful, and helped you understand a few of the systems we currently use inside our game.
  10. FishingCactus

    Epistory Retrospective - Looking back over the development of Epistory

    Thanks to you for the support and comment :) 
  11. [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]
  12. FishingCactus

    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
  13. FishingCactus

    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 :) 
  14. 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,
  15. FishingCactus

    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 :)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!