DEV Community: Joel Ruiz

ACOS.games – Middleware platform for ReactJS multiplayer web games

Joel Ruiz — Wed, 12 Jul 2023 18:32:36 +0000

Hi Devs,

I engineered this platform to support building multiplayer games for competitive gamers. Game development uses JavaScript for both client and server, and focuses on Trivia and Board game genres, but all played in real-time.

The platform manages all the functionalities outside of your gameplay and user interface, which includes: networking, matchmaking, rankings, timing, replays, deployment, and many other features.

There is an SDK and Simulator that helps speed up development tremendously, but you as a developer will remain focused on authoring gameplay via the JSON game state and displaying the changes to that state on the browser.

Many hours were spent ensuring the website is supported on most devices, with tough resiliency to ensure users can get back into matches when traveling on degraded cell service. This will allow perhaps having a battle royale with 100s of people playing in a single match of a trivia game. It always bothered me how online trivia games only allowed up to like 8 or 16 players.

I'm about halfway on my roadmap, but the core foundation of the platform is settling in. Now, its time to expand into the more community focused features.

That is where you can help, by pushing the limits of my systems. Break things, enhance things, all is welcome.

The platform behind the website will be open-sourced in the near future, but you can access the ACOS simulator and existing games on GitHub.

Play or develop a game on: https://acos.games

Read the documentation at: https://sdk.acos.games

Learning to code? We can help you build your first game. Simply join us on Discord. https://discord.gg/ydHkCcNgHD

Happy Coding!

A Cup Of Skill - Creating multiplayer web games at the speed of light.

Joel Ruiz — Wed, 12 Jul 2023 06:11:00 +0000

Joe found a passion to developing games. He built a many games. He soon discovered a pattern that was continously repeated time and again. The basic requirements for a full featured game were rebuilt from scratch for each new project.

Then, on one eventful day, Joe wanted to play Trivia with a party he was hosting at his house. But all the available Trivia games on the phone were limited to only a few players.

Joe had enough.

He tinkered, he researched, he bled, he sweat, he missed sleep.

He built half of it so far, and would like to show it to you today.

Play or develop a game at
https://acos.games

Read the Docs
https://sdk.acos.games

This platform provides game developers with an SDK for ReactJS and JavaScript code to build competitive multiplayer games and deploy them on ACOS for free hosting. Games are played in real-time, but the multiplayer is state based, for genres like Trivia and board games.

JSON game state is synchronized automatically to all players in an efficient TCP websocket stream. Matchmaking and ranking is modeled after Rocket League's system, where it's segregated by player ranks, parties, games and modes.

Replays of every match let you revisit the games of your stakeholders. Developer documentation and Simulator provide an easy to work with environment.

All that said, it is still in an early release stage. There is a road map of features to include tournaments, achievements, and persistent player data for all games.

Learning to code? We can help you build your first game. Leave a comment or join us on the Discord link found in the website.

Easy State Management on ReactJS with flatstore

Joel Ruiz — Tue, 11 Feb 2020 13:22:21 +0000

State management is the biggest concern for any developer when starting a new app. The few choices available (redux/mobx) are designed for enterprise-level development, where state management follows a strict pattern.

Pfffft... Who needs all that for a quick prototype or medium sized application.

flatstore -- ReactJS state management at the speed of light. Get/Set state from anywhere with component re-render.

Let's build an example React app

The example above shows dev.to articles with a random page button using the API
https://dev.to/api/articles?page=1

The rest of this article will focus on building the simple app using flatstore. We will build 4 files to put all of this together.

DevAPI.js
Articles.js
Article.js
PageWidget.js

This flatiron example and more can be found here
https://github.com/joetex/flatstore-examples

DevAPI.js

import flatstore from 'flatstore';
import axios from 'axios';

flatstore.set("articles", []);
flatstore.set("page", 1);

export default async function apiDevArticles() {
    let randomPage = Math.floor(Math.random() * Math.floor(20)) + 1;
    flatstore.set("page", randomPage);

    try {
        let response = await axios.get('https://dev.to/api/articles?page=' + randomPage);
        flatstore.set("articles", response.data);
    }
    catch (err) {
        console.log(err);
    }
}

At the top, we define the default values using flatstore.set.

A simple function then uses axios to GET request the dev.to API. You no longer need to follow any programming patterns. This API function can be created anywhere, but for organizational purposes, this was created in its own file.

The random page number is stored in page, and the API response (JSON Array) is stored to articles in the flatstore.

Articles.js

class Articles extends React.Component {
    constructor(props) {
        super(props);
        apiDevArticles();
    }
    render() {
        return (
            <div>
                <h2>dev.to Articles</h2>
                <PageWidget />
                {this.props.articles.map((article, index) => (
                    <Article id={index}></Article>
                ))}
            </div>
        );
    }
}
export default flatstore.connect(['articles'])(Articles);

This file calls the API in the constructor (or anywhere you want!), loops through all the articles, and renders an Article component passing the array index to id property which we will use soon.

flatstore.connect is where we begin seeing how components can hook into the data. It may have up to 3 parameters (example in Article.js):

An array of string keys to automatically watch from the store.
function onCustomWatched for generating the same array as #1 with code.
function onCustomProps for customizing the actual key/value stored in this.props of the component.

The data is automatically stored into this.props.articles matching the key name used by both apiDevArticles and flatstore.connect.

Article.js

class Article extends React.Component {
    render() {
        return (
            <div>
                <a href={this.props.url}>
                    <img src={this.props.social_image} width="75" />
                    <strong>{this.props.title}</strong>
                </a>
                <br />
                <span>{this.props.description}</span>
                <br /><br />
            </div>
        );
    }
}

let onCustomWatched = (ownProps) => {
    return ['articles-' + ownProps.id];
}
let onCustomProps = (key, value, store, ownProps) => {
    return { ...value }
}
export default flatstore.connect([], onCustomWatched, onCustomProps)(Article);

Now we can render each article.

You'll notice flatstore.connect is using two new parameters that are callback functions.

onCustomWatched returns an array of store keys to watch, and using the components own properties for id, we can specify we only want to watch for articles[id] in the store, incase only that object changes.

Note: You can drill down to a specific child of an array or object using the syntax {object}-{key} or {array}-{index}. For example: articles-1, will return articles[1] from the store. Or go crazy with something like articles-1-tag_list-0

onCustomProps is where you define the structure of the value that gets appended into this.props. In this example, we just spread all the article data into this.props, so it can be accessed like this.props.title or this.props.description.

PageWidget.js

class PageWidget extends React.Component {
    render() {
        return (
            <div>
                <button onClick={() => { apiDevArticles() }}>Random Page</button>
                <span>Page #{this.props.page}</span>
            </div>
        )
    }
}
export default flatstore.connect(["page"])(PageWidget);

Simple usage again. Just watch the store for "page" changes, also call the API again when clicking the button.

Whew! I hope that was simple... I spent more time writing this article than coding that react app.

If you have any questions or suggestions to improve flatstore, please feel free to leave a comment or send me a pull request.

Enjoy!

Easy State Management on ReactJS with flatstore

Joel Ruiz — Tue, 11 Feb 2020 02:31:53 +0000

State Management is the biggest concern for any developer when starting a new app. The few choices available (redux/mobx) are designed for enterprise-level development, where state management follows a strict pattern.

Pfffft... Who needs all that for a quick prototype or medium sized application.

Spoiler Alert! I'm promoting my own state management library...

flatstore -- ReactJS state management at the speed of light. Get/Set state from anywhere with component re-render.

Feel free to send a pull request with all the files deleted. Just kidding don't do that!

Let's make a React app

The example above shows dev.to articles with a random page button using the API
https://dev.to/api/articles?page=1

The rest of this article will focus on building the simple app using flatstore. We will build 4 files to put all of this together.

DevAPI.js
Articles.js
Article.js
PageWidget.js

This flatiron example and more can be found here
https://github.com/joetex/flatstore-examples

DevAPI.js

import flatstore from 'flatstore';
import axios from 'axios';

flatstore.set("articles", []);
flatstore.set("page", 1);

export default async function apiDevArticles() {
    let randomPage = Math.floor(Math.random() * Math.floor(20)) + 1;
    flatstore.set("page", randomPage);

    try {
        let response = await axios.get('https://dev.to/api/articles?page=' + randomPage);
        flatstore.set("articles", response.data);
    }
    catch (err) {
        console.log(err);
    }
}

At the top, we define the default values using flatstore.set.

The random page number is stored in page, and the API response (JSON Array) is stored to articles in the flatstore.

Articles.js

class Articles extends React.Component {
    constructor(props) {
        super(props);
        apiDevArticles();
    }
    render() {
        return (
            <div>
                <h2>dev.to Articles</h2>
                <PageWidget />
                {this.props.articles.map((article, index) => (
                    <Article id={index}></Article>
                ))}
            </div>
        );
    }
}
export default flatstore.connect(['articles'])(Articles);

This file calls the API in the constructor (or anywhere you want!), loops through all the articles, and renders an Article component passing the array index to id property which we will use soon.

flatstore.connect is where we begin seeing how components can hook into the data. It may have up to 3 parameters (example in Article.js):

An array of string keys to automatically watch from the store.
function onCustomWatched for generating the same array as #1 with code.
function onCustomProps for customizing the actual key/value stored in this.props of the component.

The data is automatically stored into this.props.articles matching the key name used by both apiDevArticles and flatstore.connect.

Article.js

class Article extends React.Component {
    render() {
        return (
            <div>
                <a href={this.props.url}>
                    <img src={this.props.social_image} width="75" />
                    <strong>{this.props.title}</strong>
                </a>
                <br />
                <span>{this.props.description}</span>
                <br /><br />
            </div>
        );
    }
}

let onCustomWatched = (ownProps) => {
    return ['articles-' + ownProps.id];
}
let onCustomProps = (key, value, store, ownProps) => {
    return { ...value }
}
export default flatstore.connect([], onCustomWatched, onCustomProps)(Article);

Now we can render each article.

You'll notice flatstore.connect is using two new parameters that are callback functions.

PageWidget.js

class PageWidget extends React.Component {
    render() {
        return (
            <div>
                <button onClick={() => { apiDevArticles() }}>Random Page</button>
                <span>Page #{this.props.page}</span>
            </div>
        )
    }
}
export default flatstore.connect(["page"])(PageWidget);

Simple usage again. Just watch the store for "page" changes, also call the API again when clicking the button.

Whew! I hope that was simple... I spent more time writing this article than coding that react app.

If you have any questions or suggestions to improve flatstore, please feel free to leave a comment or send me a pull request.

Enjoy!

What will programming look like in 100 years?

Joel Ruiz — Fri, 31 Jan 2020 04:42:08 +0000

Think about the languages you use. What improvements will make them better? Now repeat that improvement process 10^13 times.

The year is now 2120, and development of code has been evolving through the ages for four generations.

You now have 3 physical modes of software development:

Typing syntax with keyboard (legacy)
Talking in natural language the software requirements to an AI IDE that translates to working application. (most popular)
Thinking in a dream state, which attempts to extrapolate the ideas into software requirements passed to an AI IDE that translates to working application. (experimental)

Natural Understanding AI has taken central role in everyday development, handling every facet of hardware and software development. Even the legacy coders cannot escape its grasp, as its integration in computers is far too deep.

Computer Science has shifted into linguistic teachings, to better transcribe the nuances of development. The English language has added millions of words to its dictionary to improve intent.

You want to build a video game, so you begin speaking...

Cavemen brandishing spears with the style of Call of Duty 103. Build and Launch.

You wait a few seconds until the progress bar is done.

Build Successful.  Launching...

You successfully made a Call of Duty 103 clone of cavemen, with thousands of spears. Before the screen starts, you are alerted to Copyright Infringement, and your social score has been flat-lined. A security facilitator will arrive at your door shortly.

You hear a knock at your door. The latest Iron XO is at the front steps. It does not wait for you to open the door. It melts a perfect silhouette through the door, and warns you to obey the law.

You decide to make another video game, so you begin speaking...

Cavemen brandishing spears with the style of Call of Duty 103, remove all copyright infringements. Build and Launch.

You shatter share the game with the world and play with a few random people, before going to bed and deleting the share.

Software development has been completely automated.

You are no longer needed.

Thinking in {} objects

Joel Ruiz — Fri, 04 Oct 2019 03:47:36 +0000

Objects, hashmaps, maps, dictionaries, it goes by many names, but one thing remains the same.

They are your best weapon at optimization and keeping code elegant.

Arrays vs Objects, believe it or not, they both have their time and place in your code. We cannot cheat our computer's limitations, but we can easily hit 70% or more efficiency with just these two, while the other 30% may require different data structures.

If you haven't learned how objects work under the covers, take a look at this image below.

Hashmaps start with the string key converted to a hash number, and then using the modulus operator, the number is bound to the range of 0 to array length. There are extra steps for collisions, but it's negligible in the grand scheme of performance.

Let's get down to business with some simple examples to skyrocket your optimization.

Battle #1: select, if, objects

//-----------------------------------
//select statements
select(state) {
    case 'Texas': return 1;
    case 'California': return 2;
    case 'Florida': return 3;
    case 'Colorado': return 4;
}

//-----------------------------------
//if statements
if( state === 'Texas' ) return 1;
else if( state === 'California' ) return 2;
else if( state === 'Florida' ) return 3;
else if( state === 'Colorado' ) return 4;

//-----------------------------------
//object initialization
let states = {};
states['Texas'] = 1;
states['California'] = 2;
states['Florida'] = 3;
states['Colorado'] = 4;
//...
//object get value
return states[state] || 0;

Do you see which one is the best? It is {} every time. The object can be initialized at the start of your app into memory, and then accessed whenever needed later. This gives you the option to write the object in a configuration JSON file for easy modification. The switch and if statements, on the other hand, have to be processed every time and have to be hard-coded.

Battle #2: search in arrays, objects

//-----------------------------------
//Arrays #1, loop to find
for(let i arr)
    if (arr[i] == 'Texas') return true;

//-----------------------------------
//Arrays #2, use helper function
return arr.includes('Texas');

//-----------------------------------
//Objects #1, use 'in' syntax
return ('Texas' in obj);

//-----------------------------------
//Objects #2, check if undefined
return obj['Texas'] != undefined;

//-----------------------------------
//Objects #3, use helper function
return obj.hasOwnProperty('Texas'):

Arrays will always have to loop and check each index. Even array.includes will loop behind the scenes. If you have 100,000 items in array, your program will lag.

Objects only need to calculate the hash number of a string. Note, you may see a performance boost if using 1 character string vs 32 character string, as it has to loop through each character to create the hash number.

Battle #3: insert into arrays, objects

let insertPos = 5;
let value = 'Texas';

//-----------------------------------
//Arrays #1, move items up 1 and insert
for(let i=arr.length; i>insertPos; i--)
  arr[i] = arr[i-1];
arr[insertPos] = value;

//-----------------------------------
//Arrays #2, use helper function
arr.insert(insertPos, value);

//-----------------------------------
//Objects #1, set directly at mapped position
obj[insertPos] = value;

Again, don't be fooled by the array.insert function. It has to move the other indices further up the array by 1 behind the scenes just like the for loop.

Objects never have to push elements, as their home is unique. I must say though if your object's hidden array fills up, it will have to copy the values to a bigger hidden array.

Battle #4: static functions, dynamic functions

let command = 'min'
let x = 5;
let y = 3;

//-----------------------------------
//Static
function min(a, b) return a < b ? a : b;
function max(a, b) return a > b ? a : b;

if (command === 'min')
    min(x,y);
else if (command === 'max')
    max(x,y);

//-----------------------------------
//Dynamic
let mathlib = {};
mathlib.min = function(a, b) return a < b ? a : b;
mathlib.max = function(a, b) return a > b ? a : b;

mathlib[command](x,y);

This short example shows using a custom command, perhaps selected by a user.

Arrays may appear as the clear winner, and it might be with very few commands.

However, your code will quickly grow into a big mess of if statements. If you consider growth, and knowing that objects will always scale more elegantly, your codebase will remain readable and maintainable.

If you need to sort the data in an Object, you will be forced to copy it into an array, and this is perfectly fine.

Now, go take advantage of mapping, and control your performance.

React... Why so complicated...?

Joel Ruiz — Thu, 03 Oct 2019 04:42:47 +0000

React has really great concepts. But when it comes to data management, everyone keeps coming up with more ridiculous methodologies and frameworks with attempts to create syntactic artwork.

I'll say it right now.

It's unreadable and overly complicated, more than it needs to be.

Oh, you think differently?

Let's start with the popular Redux for React, with the most basic example.

export const setVisibilityFilter = filter => ({
  type: 'SET_VISIBILITY_FILTER',
  filter
})
//...
const visibilityFilter = (state = VisibilityFilters.SHOW_ALL, action) => {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

2 files, 12 lines of code, one purpose, set the visibility filter value. And it is still incomplete! We have to add the reducer to the store, import the actions wherever we want to use them, all the while VSCode is just asking, huh? what?

But you might say, it's about having a predictable state container. Well, once you add thunks and start mixing state values, predictability flies out the window.

In addition, these reducers are simple, but in real-world applications, they are never as simple. They grow large, so you start breaking them up into functions, which don't fit nicely in the same file, so you create more files. Now you are bouncing around all these files just to manage one state of data.

Let's jump into Reacts version of redux, oh boy, settle in.

const initialState = {count: 0};

function reducer(state, action) {
  switch (action.type) {
    case 'increment':
      return {count: state.count + 1};
    case 'decrement':
      return {count: state.count - 1};
    default:
      throw new Error();
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <>
      Count: {state.count}
      <button onClick={() => dispatch({type: 'decrement'})}>-</button>
      <button onClick={() => dispatch({type: 'increment'})}>+</button>
    </>
  );
}

Alright, a full example just for you. How many seconds did it take you to follow the code and all its purpose? You rockstars would probably say about 3-5 seconds. Well duh, you bathe in this all day.

Take a look at useReducer. This provides all the technology for mutating the state of your component. What would happen to the code if we need to use, say, 2 or 3 different states. Now you've introduced some serious ugliness...

const [state1, dispatch1] = useReducer(reducer1, initialState1);
const [state2, dispatch2] = useReducer(reducer2, initialState2);
const [state3, dispatch3] = useReducer(reducer3, initialState3);

You better not use that naming.

Does anyone even useReducer? This becomes a formatting nightmare to manage all the reducers, just with this example using 12 different named variables. The amount of naming you have to do will just grow larger the more code integration you attempt to perform.

The next ridiculous is with React's Context...

const ThemeContext = React.createContext('light');
class App extends React.Component {
  render() {
    return (
      <ThemeContext.Provider value="dark">
        <Toolbar />
      </ThemeContext.Provider>
    );
  }
}

It's more readable. But, we are forcing data to have a relationship with a specific component in a parent/child fashion. This is not ideal in real-world, where business requirements change frequently, and you end up having to heavily refactor to fit in some weird edge case.

class ThemedButton extends React.Component {
  static contextType = ThemeContext;
  render() {
    return <Button theme={this.context} />;
  }
}

Why would you do this to yourself. You basically created a global variable that has to be individually referenced for each type of context! What if you need 10 different context categories. Let me play my violin for you while you figure out how to best format it, for the next few days.

Let's move on to MobX...

class ObservableTodoStore {
    @observable todos = [];
    @observable pendingRequests = 0;

    constructor() {
        mobx.autorun(() => console.log(this.report));
    }

    @computed get completedTodosCount() {
        return this.todos.filter(
            todo => todo.completed === true
        ).length;
    }
}
const observableTodoStore = new ObservableTodoStore();

Annotations, annotations, annotations. These are eyeball magnets in any language, but some people love them, so they get a pass for now. At least we are starting to get back on track with the time tested Services-oriented programming.

@observer
class TodoList extends React.Component {
  render() {
    const store = this.props.store;
    return (
      <div>
        { store.report }
        <ul>
        { store.todos.map(
          (todo, idx) => <TodoView todo={ todo } key={ idx } />
        ) }
        </ul>
        { store.pendingRequests > 0 ? <marquee>Loading...</marquee> : null }
        <button onClick={ this.onNewTodo }>New Todo</button>
      </div>
    );
  }

  onNewTodo = () => {
    this.props.store.addTodo(prompt('Enter a new todo:','coffee plz'));
  }
}

ReactDOM.render(
  <TodoList store={ observableTodoStore } />,
  document.getElementById('reactjs-app')
);

This seems a bit cleaner right. Except, now you have to manage passing your store and its data down the hierarchy again like the Context example above. This went backwards pretty fast. This is the reason Redux came out, to avoid having to trickle down your data manually.

That being said, I do enjoy the Services nature to having direct access to the methods and data with no exotic formating.

Can all of this be done better? Maybe... I wasted my weekend prototyping my ideal setup, but this is not a problem that can be easily solved by a single person.

Here is an example of what I mashed together...

//Run a query against DuckDuckGo API
export async function SearchDuckDuckGo(query) {
    let url = 'https://api.duckduckgo.com/?t=flatstoreExample&format=json&q=' + query;
    try {
        let response = await axios.get(url);
        let results = ReduceResults(response); //grabs only the results

        flatstore.set("ddg", response.data);
        flatstore.set("ddgQuery", query);
        flatstore.set("ddgResults", results);
        flatstore.set("ddgResultCount", results.length);
        flatstore.set("ddgError", false);
    }
    catch (error) {
        console.log(error);
        flatstore.set("ddgError", error);
    }
}

Focus is on readability and usability. A simple action to Search DuckDuckGo. It does its work, then saves the data in key/value format.

Ok, great, you the man, now what about showing it? Well, I played my violin over the weekend thinking about it, and came up with something like this...

class SearchStatus extends React.Component {
    render() {
        if (this.props.ddgError)
            return (
                <div style={{ color: '#f00' }}>
                    {this.props.ddgError.message}
                </div>
            );

        return (
            <div>
                <i>
                    Searched {this.props.ddgQuery}
                    with {this.props.ddgResultCount || 0} results.
                </i>
            </div>
        );
    }
}

export default flatstore.connect(['ddgQuery', 'ddgResultCount', 'ddgError'])(SearchStatus);

Redux was brilliant in using a higher-order component. This allows you to remove all the framework craziness away from a component, and let the magic be done in the background.

In that respect, I stole it. But, we just want specific data points, so why not allow the user to directly specify what keys we need without circlejerking yourself.

I couldn't help myself, I had to go further. Real-world applications get complicated fast with all the business requirements coming from three or four levels above you. We need dynamic control, so we are back again to getting inspiration from redux's connect prop mapping.

class TodoResult extends React.Component {
    render() {
        return (
            <div className={this.props.completed ? "completed" : ""}
                onClick={() => { todoToggleComplete(this.props.id) }}>
                <span className="result-title">{this.props.desc}</span> -
                <span className="result-date">{this.props.dateCreated}</span>
            </div >
        );
    }
}

let onCustomWatched = (ownProps) => {
    return ['todos-' + ownProps.id];
}
let onCustomProps = (key, value, store, ownProps) => {
    return {
        ...value
    }
}
export default flatstore.connect([], onCustomWatched, onCustomProps)(TodoResult);

Except, this time we are limiting the onCustomProps to only those keys we specifically are watching. I even added object drill down, so I can watch a sub-item of the main "todos" object. React is about reacting only when needed, so I tried to only react when the components relevant data changes, with minimal coding effort for the developer.

I spend a lot of time teaching React, so most of this rant comes from what I see is confusing the new developers. There are many misunderstandings with coding in React, due to the complexity of modern JavaScript syntax used by the latest frameworks. It achieves very little, with so much code and files.

I was happy with the result of my prototype called flatstore, but its no where near usable in the real-world, so it'll be another one of my new projects that gets to ferment on GitHub.

In the meantime, I'll be wishing for one of you geniuses to bring back simplicity to programming.