sphere rpg engine v1.5 [Dev Log] Making a game as a pet project

SilicateWielder · January 25, 2017

Note: I welcome any questions and comments people have regarding anything in this thread.

Welp, while I already have a Trello page for this, I thought it would be nice to be able to write down my journey as work on this pet project goes along.

At the time of writing this initial post, I currently have about 300 + lines of code, which to be honest is quite unimpressive. I should also mention that the majority of my coding time has currently centered around frames.js in order to clean it up, optimize it and debug weird parts of code. Not to mention adding comments where they are needed.

So, where do I stand now? Well, the code currently is built for the Sphere v1.5 API which utilizes Javascript 1.5, however as of last night I have installed Minisphere 4.3.8 which uses the much more modern Sphere V2 API and Duktape for it's JavaScript interpreter. While Minisphere still allows me to use my Sphere V1.5 code I'm going to be adapting my code (while it's still in it's infancy) to the newer API so that I can leverage more performance and hopefully make use of any extra features that Minisphere provides me with.

Also, full-screen finally works, I'm quite glad I went against reason and wrote my code to adapt to different resolutions, now if only I could implement features for changing resolutions on the fly. This probably wont have multi-player support, unless I decide I want pain and take the time to learn it. The Players window is just for show currently.

Screenshot:

Spoiler

SilicateWielder · January 25, 2017

After looking through the MiniSphere API, several additions appear to have been made, including the addition of support for 3D objects without having to switch graphics modes. Although I'm not quite sure how to use these yet. However this does open up the possibility of making my game 3D with pre-generated models and such.

I've made note of some functions that will need changing around in order to comply with the newer API, I've also noticed that unlike sphere 1.5 I am able to change display resolutions on the fly, which is a feature I was hoping would be available. Now to see if it's possible to switch between Windowed and fullscreen modes.

A dispatch API seems present within the API of MiniSphere, I'm currently unsure what it's purpose is for, but intend to ask the developer directly assuming I'm allowed onto the Sphere forums.

SilicateWielder · January 26, 2017

As of last night, I have implemented text buttons under buttons.js, and have figured out a way to bind simple functions to them.

Initially I was considering the usage of images to create tileable blocks, however I stumbled upon a GDC video that went over 8-bit and 8bittish art, one of the topics mentioned was palette cycling, which seems like an interesting idea, I may make use of this technique in order to create my image assets for the game.

In other news, I think i'm getting close to a final idea for what kind of game I want to design.

SilicateWielder · April 6, 2017

I've scrapped my code because Minisphere doesn't support audio

But all is not lost

As of two weeks ago I restarted the ENTIRE project, this time opting for an isometric viewpoint rather than a side-scroller.

With that in mind I have also run into two issues:

Sphere has a VM size of 6.1 megabytes. This means I'm gonna have to get creative with how I manage my assets if I want more than just a few things in the game.
Fullscreen works again on Windows 10, however it does not display properly thanks to the outdated DLLs that sphere uses to access graphics APIs

However, despite this I have continued to chug along and have done the following

0A - Partial Implementation of the isometric terrain renderer (Estimated to be at about 35-40% completion)
- 0A-001 - Implementation of code that allows for taking standard images and rotating them within an imaginary 3D space to store as isometric tiles without having to render 3 dimensional objects. (Only useful for map editing, and live asset grabbing such as for texture packs)
- 0A-002 - Implementation of function for rendering individual tiles (Useful for game development)
- 0A-003 - Implementation of terrain rendering functionality
- 0A-004 - Implementation of terrain modification functionality
- 0A-005 - Implementation of tile generation functionality (Useful for prototyping)
0B - Partial implementation of the cursor library (Estimated to be at about 3-5% completion)
- 0B-001 - Implementation of base functionalities
1B Partial implementation of framework to allow the cursor library to integrate into all other parts of the game engine
- 1B-001 - Implementation of function for reporting the cursor's status [INCOMPLETE]
- 1B-002 - Implementation of function for checking whether the cursor is within the collision box of an object or UI element.
0C - Implementation of waifu.js, a console for situations where one isn't built into an API or IDE. (This is unofficially complete)

Explanations of how functions are performed

0A-001.

This functionality takes a loaded image and uses it to create what is known in Sphere as a surface, these surfaces are useful as they can be easily modified and edited within the code.

Knowing this, the code has been written to first rotate the image within the surface around it's Z-axis on a 2-dimensional Cartesian plane, as the surface itself cannot be rotated. The surface can then be re-scaled down to the proper dimensions.

However we cannot scale the image without knowing the height and width of the new surface. This is calculated beforehand when the constructor is created based on what parameters it is created with.

0A-003.

This is a bit difficult for me to explain but I'll do my best

in order to properly render the tiles so that they align in a grid a more complex method of calculating the tile positions is needed.

I came up with a two rules for producing an isometric grid: All tiles within a row are to iterate down by half-height and right by half of their width from the point of origin within the map. Each row must move back left by half of the width of a tile from the starting point of the previous row, and move down by half of the height of a tile from the previous row.

Following these rules you can produce a near-perfect grid system, I say near-perfect as you will have overlap depending on how you render your tiles. I do not know how to fix this as of now without losing significant performance. Currently all tiles are just "stamped" to the screen from a modified image stored within a map.

Additionally, in order to grab the texture for a particular tile within a map you must first multiply the width of a row by the row that the tile is on, then add to the result which column that the tile is aligned with. This will allow the script to grab the tile ID within the map's data and then use that ID to grab the texture from the textures array within the constructor for blitting to the screen. This is done for EVERY tile that does not return a null value in the map data.