Very good concept! Music does it very well, graphically is very pretty to see. I Think that the gameplay can be improved to a next level to be more fun, but is interesting
davemour
Creator of
Recent community posts
I'm taking note of the improvements and fixes that all of you suggested and I'm working on a new version. I'll release it when the jam is completely ended.
Thank you all, and I'm sorry, I'm relatively new in the game jam world and i went run off time, so I made it too quickly for adjusting these details.
But I found this jam funny because it's useful for training my time management.
Yes, maybe I should invest more time on the controls when slow for making them more friendly. A good control going fast is intended, because in this game going fast has two drawbacks: web is consumed, even if you wan't to, and the scenary is pretty narrow, bot I understand reducing speed should not be so fatal as it is...
I really appreciate your feedback.
Yes, the controls are very tricky, I know... Maybe too much... The idea was to make the player take a balance between speed and control.
Spider web is spawned when you move fast, the bar shows your remaining web charge. The power ups are extra web charges.
The web damages the flies, being destroyed in the process (The fly slowly gets "wired", so the web ends attached to the body of fly, reducing its health, when this is reduced completely, fly gets wired and is killed). This is intencional, but I should have shown it more clearly.
Thank you for your opinion, I'll take into account the tutorial for the next jam and for future versions of this.
First, create a fixed walkthrough formed with N maps. You must try it manually first.
When this works, you can define a serie of parameters that you could vary. The RNG output should be used for calculating these parameters. Begin using manual values for this. Same input should generate the same output map, in order to re-create the previous maps retrieving older values.
Keep in mind that the randomness must be consistent, in order to not make your game unplayable.
Remember that "A good randomness began with a good manual design"
First of all, I want to congratulate the nice work done with this game engine. I wanted to develop a tool like this and I found it on Itch.io.
I like the philosofy of creating the game mechanics from scratch, is ideal for learning and I appreciate it.
But there are a set of things that I miss, and are common to almost every game: GameObjects and behaviors.
Game objects could be linked to a game instance reference, or the scene instance where they belong.
Game Objects could implement a set of behaviors:
- Position system, based on tiles and/or coordinates. Useful for calculating collisions.
- Health system, for perishable objects.
- Camera following system for a given object
- Animation interface, with loop, frame skips and sprite sequence options
Finally, the scene interface should define the game workflow methods (init, update, render).
- Main script would delegate the initialization and update of game state on scenes.
- Game would have a set of scenes and a reference to current scene
This is the approach I follow for developing using pixelbox. It takes ideas from other game engines that could be very useful.
When I finish my first real project with this engine, I want to extract my implementations of these and create a npm package with these.
If you want to collaborate and implement it together in you game engine, you can contact me.
The simpliest way to save data is using localstorage, as @reopucino said.
I use this class definition for saving using it.
- For game data, I use a game instance where I manage all the game elements and game workflow (for this example you can use your own approach). In this implementation, I don't use the game data. Feel free of implementing game attribute as you want.
- This is a generic class with basic operations, so you can extend it for a more specific data management (scores, saved games., archievements...).
- If you want to use another system for managing data (a database, a file...) you could override these methods.
For example, if I want to store data using a web API, I could use the "fetch" library or an XMLHttpRequest instance for sending data in the implementation.
The main advantage of using a solution like this is the abstraction for managing saving and load data that is provided to other modules: They don't need to know how or where the data is saved or from where is loaded.
export default class Storage { constructor(game) { this.game = game; } load(key) { return localStorage.getItem(key); } save(key, value) { return localStorage.setItem(key, value); } add(key, item, value) { const entry = this.load(key); entry[item] = value; this.save(key, entry); } }
And remember: games created with pixelbox are, in fact, html5 applications, so you can use any code that you can use for a web client application.