The concept is inspired by late 2000 browser games. Back then, browser's capabilities were limited and connections were slow.

The game is a gladiator game where heroes fight one another till death. Usual features for that type of game were inventory management, leveling your heroes, leaderboard and RPG functionalities.

Games were real-time but turn-by-turn where one or both players submit their action each turn. At the end of the fight, the victorious player gained, in-game currency, items, and/or experience. The goal was to level up your heroes, gain rare equipment, and win tournaments.

What it does

It's a gladiator game, where heroes fight again each other till death. Each turn, players select an action (attack, defense, special). An action costs stamina to perform. If a hero does not have enough stamina, he can only defend himself but cannot attack nor uses his special (which is different for each hero). Stamina can be recovered by resting. But If a hero rests, he exposes himself and becomes vulnerable to enemy attack. The key of the game is to predict the opponent's action in order to inflict the maximum amount of damage while avoiding critical hits.

After a fight, heroes need to rest for a few hours in order to regain health and stamina. Players can speed up the recovery with healing potions. Potions can be bought via the store using gold pieces (in-game currency) or euros. Gold pieces (GP) are earned after each fight. GP also let player hire new heroes. Each hero has slightly different features and skills.

Players can also subscribe to a booster for a monthly fee. Boosters increase the regeneration rate as well as the amount gained after each fight.

Finally players can join a guild. By becoming a guild member, player's heroes gains in-game bonuses such as improved defense or attack. In return, the player has to pay 20% of his gains to the guild's master. Guild's bonuses depend on the banner owned by the guild's master. The banner can buy bought in a special store by guild masters.

How we built it

The game is mainly based on wix-realtime to communicate events between players or the server and the player. Wix-realtime is also used for the quick match feature.

Game state, transactions history, and heroes are persisted with wix-data.

The guild system is built on top of wix-group.

The in-game store is made with wix-store.

The subscription system is based on wix-paid-plan.

Game pages are designed with wix-router.

The regeneration system uses wix-scheduler to heal heroes every 5 minutes. Once a hero is fully healed, the scheduler sends a notification by email through wix-triggered-email.

Marketing emails are also automatically sent with wix-automation.

Project testing (both manual and unit test) were performed using backend functional testing. Functional testing is also used to run management scripts (reset a game, give items, generate store inventory,...)

The whole project is supported by velo package developed by code enhancement studio The design is based on a template

The project also relies on a few NPM packages: mainly Mobx for state manage, date-fns and lodash. It uses chaijs to perform unit testing.

The game was built on EditorX and designed to be responsive on all device sizes.

By choice, the project only uses Velo native API and Wix out-of-the-box elements. Therefore, It does not rely on web custom components or iframe.

Challenges we ran into

The first challenge was to get acquainted with wix-realtime API. This has never been requested by any client so I took the opportunity of the hackathon to try it. To start I create a game that required near real-time communication between parties. Unfortunately wix-realtime is not instantaneous and the lag prevented the game to be playable. I could have use another platform to build the game but I wanted to develop a project 100% on Wix. Once I pivoted the project to a turn-based game, the wix-realtime API perfectly fits my requirement. I did encounter small bugs and design issues but nothing that could not be hacked. The main problem was the payload limit of 10kb per message. At turn 25, messages stop being delivered to players because of that payload limit. The solution was to only return the last round's events and to perform the update on the client side. Another challenge of working in real-time is concurrent editing. Both player need to update the same game at the same time which can create issues if a player override another player's action. This was tackled via tricks such as optimistic lock and using reference items.

Another challenge I had was how to test the game logic. The game mechanism supports a large range of actions and effect thus making it hard to manually test every combination. So I decided to build unit tests to ensure that all actions have the intended effect.

Sound management was also a bit challenging as only 1 song can be played at once on Wix. I intend to have different track and sound effect playing at the same time to create an ambiance but that was not possible. Nevertheless I built a sound system that would play different sound according to different action and event (new round has started, attack, hurt,...)

I also ran into a rendering issue, with the battlers animation (little in-game character). Animation is handmade by replacing frame every 200ms when an action is cast. The problem was that the frame was not in cache the first time the animation is played translating into a succession of missing images. To solve that problem I create an asset preloader that would force the browser to load a list of assets when the website is rendered for the first time. Now when battler doing there action, each frame is displayed from the cache and the result is smooth animation

Lastly, I find the Wix application widgets to be not as responsive as the rest of the elements, and configuring them was slow and cumbersome. The project design and UX would be better with custom frontend elements (especially for wix-group).

Accomplishments that we're proud of

I'm really proud of the game engine. It was design to be extensible without the need to code any new feature. For instance, heroes and actions can be added by editing resource files. The same thing goes for store inventory that can be generated via a resource file.

Building a unit test on Wix is surely something I'm glad I did and will reuse in my future endeavor.

What we learned

I learn a few new API that I never had the chance to work with before, mainly wix-realtime, wix-group

Finally, I feel I'm reaching the limit of what can be done on Wix Editor wise. At the end of the project, the editor became slower due to the amount of code (I presume). Even though it was possible to work, it didn't not feel as smooth as on a smaller projects.

What's next for Wix Arena

I focused my work on the code side of the project but the site requires some improvement UI-wise as well as better navigation and error recovery.

Then, the sky is the limit! As I said, the game engine was design to be easily extend. My main limitation was UI resources (animation, hero, effect). Here a few ideas that could come next:

  • New Heroes and action
  • Hero's leveling and build (pick 4 action out of a larger set at the start of each fight)
  • Leaderboard and tournament (based on wix Event)
  • Hero equipment
  • ...

But in the end, this will remain a hackathon and technical demo of what Wix and I can do :-)

Project was developped by Code Enhancement Studio. You can find complementary info about this project and Velo on our Code Enhancement Studio

Built With

Share this project: