Jump to content
  • Advertisement

Brunni

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

14 Neutral

About Brunni

  • Rank
    Member

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    Production
    Programming

Recent Profile Visitors

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

  1. Thanks a lot for your feedback if you want to try let me know (I plan to release it shortly but I already have a working version)
  2. Brief presentation and history As I was developing some small arcade-style games for my portfolio, I missed the fun of old-school graphics architectures, like the ability to easily deform the screen, recolor objects at runtime, etc. It turns out that developing this kind of raster effects is not easy at all. After all, I spent more than two years to develop this clone of Outrun called Highway Runners (link): So I set myself to create a simple engine for these effects. Since I'm a huge fan of the arcade boards of the late 80s, I took this model: what if we still made this graphics architecture nowadays? Arcade machines of the time were often overpowered and sometimes required games to come with their own CPU, so what if we could just plug in modern CPU/memory and power the board with modern games? Technical decisions Since I wanted to make the games to be easy to share, I chose after some deliberation to go with Javascript. Although I would have loved other choices like Lua, mainly in order to be able to restrict the VM, I found Javascript to be much more fun to play with when hacking around with my API, plus it would save a lot of development time and would still be portable in case needed. I wanted the game to load instantly, just like a ROM image, and have a simple programming model with named graphic data, something like `drawObject('mario', x, y)`, or `drawObject('mario', x, y, { palette: 'luigi'})`. So I made an architecture with multiple ROM areas (one for Palette, one for Sprite and one for Tilemap) which contains all graphics pre-baked at ROM build time. Furthermore the graphics memory would all be accessible for read and write (for instance replace colors on the fly, swap tiles or sprites with others to animate the whole screen, add/remove objects in tilemaps). Since it runs on the web, I wanted competitive space usage. For that I'd simply use PNG images for resources and putting indexed color data in the RGBA components. PNG are compressed as a variant of ZIP, thus providing additional compression for the whole ROM for free. It should run entirely on the GPU through shaders (i.e. not drawing tile by tile, but one BG/sprite = one poly). The additional step of building the ROM images could be cumbersome, but it was not avoidable if you wanted to define which hardware palettes were associated with what graphics (you don't want to create one palette per sprite, else you lose many of the advantages of indexed colors), and also for many advanced ideas, so I made the best of this; furthermore this can be implemented as a process that watches for any changes in the graphics directory and rebuilds the ROM + transpiles JS files instantly when needed. Initially I went with limitations off-the-roof; the idea was: "Infinite" full-screen BG layers with matrix transformation (baseline: 8 of them) "Infinite" sprites of any size, as freely deformable quads (similar to the Sega Saturn), further transformable as a whole plane (initial tests showed that I could draw quite more of them than Pixi). 4 or 8 bits per pixel (256 colors) 32 bits RGBA master palette entries 2048x2048 sprite data and map data textures (up to 16384x2048 sprite pixels, 4096x2048 map cells), 256x256 palette data (65536 colors). BG layers can scroll, be splitted horizontally or vertically, scaled/rotated per line. This architecture proved to be extremely powerful, but there was one catch: it just wasn't fun at all to make games with. After all, why bother with parallax when you can just overlay an infinite number of sprites or tilemaps? Why even bother with tilemaps, with palettes? And when do you know when your game is inefficient, when it might not run on some mobile devices? Good practices are not inferred through the API at all. There's not even stylistic guidelines, like 8 bit frameworks give you (simple colors, animations, avoid over-crowding the screen, etc.), you feel just as lost as with Unity, and it's not even as powerful. What I wanted deep within was to give people a glance at the fun of developing games in the 80s, and also a playful opportunity to learn. Enter the FANTASY ZONE CONSOLE It was clear, I needed to think about limitations. This framework wouldn't be for everyone, but what it was targeted at should be great. I'm living in Tokyo and know well the author of Pico8, who coined the term of "fantasy console". Since my original models were such as Sega System 16, Outrun hardware, Namco System 24, etc. I chose to go with 2 BG layers only, 256 sprites covering up to once the screen, add transparency effects but with no overlay support and only one effect for the whole scene. And see what I could do from there. I would say that the most difficult task of the project in the end was to decide and experiment with these limitations. I've noticed that many people who make frameworks have problems defining it right for users because they only use it for one of their projects (usually a big one), or because they use graphics from existing games for their tests. I realized that I was guilty of all that too, and it's only when I started creating small games on my own (after all, if my framework is as simple and fun to use as I say, I should want to make loads of games with it!) that I realized that the human constraints for making graphics, code and music/sfx in 2019 are pretty different than that of 1980s. As much as you'd love animating the graphics of Castle Of Illusion, you will find yourself at trouble trying to draw something of similar quality! Therefore the framework should not be made to be used primarily with such graphics, but likely some simpler, lower resolution ones. And limitations should be there to guide you, prevent you from overworking the graphics, but rather instead toy with them in the code for instance. The initial target as far as game styles go are: Racing games (both Outrun "raster" or F-Zero "mode 7" style) Platformers Space shooters I'm currently making a "top-view" platformer with it (pseudo-3D with the shadow on the ground to guide the player), I'll show a first demo soon. Try it? I'll continue with other blog posts about development, and especially what those constraints ended up to become exactly, but I've already got online a first version with some demos. It runs directly in modern browsers, although I know that there are some remaining issues on some browsers. https://brunni132.github.io/vdp16-samples/ Try it and let me know what you think any feedback is extremely valuable!
  3. Brunni

    Spring physics

    This time I want to speak about my early experiences with building a Mario Kart feel for the game, implementing suspensions. I've been holding back because of many findings recently, at a point where I'm not even sure that we need them still Nevertheless implementing a spring will be useful in many other mechanics, and it's probably one of the simplest "complicated things", adding a touch of randomness to your game, and the entry point to bringing a kind of challenges that, whilst they may be frustrating, can sky-rocket the replay value to players. This is the very beginning, so we just have a box, representing our racing car. We'll apply gravity only for now. Gravity just means that for any time step, we're adding an acceleration of "G", the universal gravity constant (or the one that you choose for your game). Concretely, imagine that you subdivide the simulation time into small steps (milliseconds apart), and you compute and apply the forces at that time. The acceleration will affect the velocity, the velocity will affect the position. If you're not convinced, you can try this very simple script into Unity, which you add to a cube that has no rigid body. public class TEMP : MonoBehaviour { private Vector3 velocity = Vector3.zero; private Vector3 acceleration = Vector3.zero; void FixedUpdate () { acceleration = Physics.gravity; velocity += acceleration * Time.fixedDeltaTime; transform.position += velocity * Time.fixedDeltaTime; } } You'll see that your box accelerates down more and more, just like real gravity. You can try to look at the values to understand what happens. Basically the acceleration is the result of applying the same force constantly (with no other force opposing it). In Unity, the following will result in the same, assuming the cube this time has a rigid body with Use gravity unticked: public class TEMP2 : MonoBehaviour { void FixedUpdate() { GetComponent<Rigidbody>().AddForce(Physics.gravity, ForceMode.Force); } } So the spring is implemented on the same model, because it's what we call a reactive device. As a super simplified description, the spring has a rest compression (a percentage of how compressed it is, with 1 being that it's fully extended, and 0 fully compressed, that is of zero length) which it tries to get back to, opposing what it can of force to bring the objects which it's attached to together. When extended, the spring will apply force to the the item at the other end to pull it (it'll pull the ground too, but since we can say that its mass is infinite and it won't budge, it's enough to resolve it only on one end), the velocity of that item will gradually increase, and with nothing to stop it, the item will go below the rest ratio. When it gets lower, the spring will start to pull it back up, but since the object already has some velocity (inertia) downwards it'll take time to stop and start to go back up. Then again, the object will be pushed up until it reaches the green line, go past it, and then be pulled again. This can be implemented very simply by the following formula: F = -k * (x - d) Where k is the stiffness of your spring (the bigger this, the more the spring will "push" or "pull", so the more impulse it will give to the object toward the rest point, which will make the spring appear stiffer), x is the current length of the spring, d the length at rest (green line above). This will give us F, the force that needs to be applied to the spring at any time (that is in our timesteps, inside FixedUpdate). By implementing that, we'll that typical bouncing effect. In the current implementation, the object will never stop bouncing. For that we need to add what we call a damper. A damper simulates the energy loss due to the action of the spring, so that it might stabilize eventually to the rest point. The formula is: F = -k * (x - d) - b * v Where b is the damping constant, and v is the velocity between the two points connected by the spring. In our case, we can use the velocity of our rigid body, assuming that the ground is not moving. Try it, and play with the damping and stiffness constants until it feels right. I'd suggest printing the values so that you can understand what happens. In another article, I'll elaborate more why we use these springs and what to expect from them.
  4. I always liked playing both Mario Kart (the most was on DS) and Crash Team Racing. There's just something fascinating with the mechanics of the game. I could play it endlessly, despite a small number of different circuits. Actually I like racers in general. Two years ago I made a racer looking like Outrun, which is another type of game which I loved as a child (at a time where games didn't yet have a defined standard, so it was OK to just play to hit the road and explore environments, without princess to save, big boss or other deadly stake). Link: https://itunes.apple.com/us/app/highway-runners/id964932741?mt=8 But still, back to Crash Team Racing, I always wanted to make my own clone for fun, and I gave up due to lacking physics knowledge (and free time). This remained a dream though, and this time I committed to it harder, and learned, fiddled with every concept until I grasped it. It started with an inspiring video about Space Dust Racing. I think that's the one mentioned everywhere when it comes to developing an arcade racer. I think I kinda knew that it was lacking a lot of concepts that I'd eventually have to fiddle with, but many people were saying that the theory was alright, so I started. I also created a topic, which I'll now turn to a blog: Anyway as with many things the very hard part was the beginning. It's amazing when I think about how at first I was unsure about everything. About how I had to swallow my ego and realize that I wasn't able to implement a simple spring correctly, or to understand the true implications. Well I can say that I still don't truly understand everything, but it's enough to get what my car does and make it do what I want so so this blog may just start with a common and sweet "Believe in yourself" claim I hope to develop it into a fully playable game (homebrew quality though), focusing on the mechanics, and detail here some specific algorithmic areas. I'm not sure yet of the final form, maybe I'll want to get as close to the CTR as possible. Maybe I'll go for something else and think about special challenges that I could bring to the table. Here's how it looks for now Not playable demo yet, but feel free to leave your impressions, suggestions, and anything that you'd like to see in such a project CarGame-v2.mp4
  • 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!