GOTY

Hello,

Mage Fighters (temporary title) is a game I started working on a few weeks ago, but that I have been thinking about since years. This is a 1vs1 mage duel game about channeling magical element to unleash powerful spells at your opponent. The game is a mix of action and strategy mostly inspired by classic fighting games and Magic the Gathering: Fight opponents (ai or online players), gather new spells, build your spell book and become the strongest mage around!

The small GIF bellow shows the current state of the game. Art-wise it mostly uses assets found here on itch, plus few things I did myself. Under the hood Nez/MonoGame is used for the rendering and a custom made deterministic engine handles the gameplay/physics (in a nutshell it means that frame perfect online play is possible). The overall gameplay is mostly designed but the evil is in the creation of the various spells and their balance!

I figured out Devtober would be the perfect excuse to work on the game on a daily basis and write progress reports. The goal being to have a demo on itch by the end of the month! I'm looking for an artist interested by the project willing to develop the universe (you have white card) and make the art (it could be non pixel art too). So if you are an artist AND the project seems interesting to you please contact me with a portfolio by replying to this post!

I don't have any money to pay you, I can only offer 50/50 rev share... I know... I know...

Yes, the server records the best run of each player, then you play 'against' the ghosts of the top 50 players :)

Just checked, everything seems correct. Was there an error code? Did you tried again?

> my laptop survived 200 000 bullets in pygame
but will the player survive 200 000 bullets?

If you have discord, hit me there: dir3kt#4321

Hello,

I'm making an isometric dungeon crawler, a bit like Diablo but simpler and with a lower resolution. In this game you are reincarnated as a monster, trying to survive by defeating other monsters and feeding yourself from them. The game takes inspiration from Isekai novels, mostly "So I'm a Spider, So What?".

If you are a pixel artist interested in creating the graphical universe and the pixel art, you can contact me here or over Discord (preferred):

dir3kt#4321

You can look at my itch page for my Portfolio.

MS-DOS is not a retro console, it's an operating system for personal computer :p

EDIT: Some of the iconic Sega consoles such as the Game Gear or the Master System are missing!

Everything in the title ^^

Can be 2D or 3D. Using Unity.

Just got my first batch of proceduraly generated cards, fresh from the oven! The basic idea is to randomly generate the card's abilities and stats, then calculate the cost. I'm planning on adding more to the syntax such as triggered abilities, durations and conditions.

Thanks! I could also go with 18,446,744,073,709,551,615 cards if needed!

But I like the idea that at some point, even unlikely, the pool might get exhausted. A bit like a set of real printed cards: Once it's gone it's gone. This is still very hypothetical but I could imagine releasing a new set of cards using new game mechanics and improved generation algorithm in the (far) future.

So what that? Basically it's Hearthstone with 4,294,967,295 cards :) 

Core principle

I got this idea after watching the 'programming the universe' video (just google "one lone coder programming the universe" if you want to see it). What One Lone Coder does is get a 32bit seed in function of an x,y position, and from this seed generate a solar system. The same seed always generates the same solar system so the world is consistent. Instead of generating solar systems, my idea is to generate a playing cards!

The overall game would be like a simplified hearthstone, so a simplified CCG. This is still under construction. My current idea is to simply have 'action' cards and 'unit' cards. Actions perform an effect, units have atk/def and can optionally have abilities (e.g. haste, shield, ...) and/or triggered abilities (e.g. when enter into play do that, ...). Units can attack opposing units.

Each card as name,  zero or many abilities and an atk/def for units. The cost for playing the card is calculated after the generation,  this is how the game is balanced. I'm not sure about the name/art. My current idea is to simply have the seed in hex for the card name, an no art. But this could change.

Every time a player receives a card, he simply gets the next card (=seed), and this card belongs to him/her. Players receive a bunch of cards when they create an account. They can then get new cards by playing the game, completing simple quests, or recycling cards from their collection (in this case the card, the seed, is gone forever). There could be trading, card duplication and more elaborated systems but this is optional.

Oh dear you are way out of scope for a 7 days jam!

My idea for the jam is to create the fictional game rules (on paper), the card generation algorithm and a small client to view the cards. This will be like a card gallery of random cards. The goal being to have cards that seems relatively balanced yet still quite different and interesting (that's the hardest part believe me).

The real actual digital card game with card collection, online game and matchmaking will be done after the jam.

How do you do it?

I'm using the Kotlin language the develop the whole stuff. The main reason is that I want to share the card generation algorithm between the client (web, mobile, native) and the back-end (native). The front-end is done using the KorGE game engine.

Do you need help?

I'm open to any idea, suggestions and chit chat. Contribution in any forms are also welcome. I could use help on the generation of card names and/or arts. Also could use some help for the graphical design of the frames. I plan to make a libre card game so everything will be  under an open source license.

Hey, thanks a lot for your interest in Pix64! It is actually a tool I initially created to let my kids have fun 'programming' games ;)

Unfortunately building for MacOS is a rather difficult, and obscure task.  It is not possible to start the application by double clicking the icon, it must be started from the terminal. Did you tried that?

Open terminal application, then (first line by be different):

cd ~/Downloads/Pix64_1_1/
open -a Pix64.app

(the -a option is needed otherwise it will not find the carts)
if it doesn't work, could you try to type 'mono' in the terminal? The application requires mono to be installed and I'm not sure if it is by default.
If the issue comes from mono I could re-bundle the application in a way that doesn't need it.

Because it’s the GitHub jam and its all about open source?

Bravo pour votre jeu! Super boulot :)

Windows? :D

Looks nice ;)

Any chance for a non-apk version?

Very clever cart!

Frogger is such a classic, it deserved to be ported to Pix64 :)

The blood update
This week we added the first monsters to the game. There are some greenish goblins you can smash! A GIF has been added to the original post. Also we have a discord server with some early prototype available. If you are interested and would like to help the development of the game through meaningful feedback, feel free to join! We don't bite.

Project update #1

The rendering engine as been reworked almost from scratch, it now supports multiple layers, animated tiles and tire marks on the ground! Another major change is going away from "room to room" scrolling to a smooth scrolling. Honestly this is less charming (in a retro way), but it is much better for gameplay and player comfort. On the gameplay side key/door has been added for making puzzles. Finally the car collision has been improved which is a subject I will go into details during this project update. But before that, let's have a mandatory downscaled-to-3MB-to-fit-the-limit GIF to show the current state of the game:

Collision detection

Usually collision in MonoPunk is handled using axis aligned bounding boxes (AABBs). This is generally perfectly fine for platformers, top-down RPG/shooters, shmup and so on. But Dungeon Racer is a bit different story. The level layout is and will remain square (this is the dungeon part!). But the collision between the car and the edges of tile/entity quickly became a frustrating nightmare. This is what happened when the car was driving too close from an edge:

The problem is that the hitbox cannot be too small otherwise frontal collision looks strange. But then when arriving at a 45 angle near an edge, the car collides. Here is a quick rundown of the options I listed:

1. Use unaligned boxes so that the hitbox rotates when the car rotates. The best way to do that would be to use a 2D physic engine such as Box2D, set all bodies to trigger and use the engine for collision detection only. This seems a viable approach but I was not found of using and physic library and all  its side effects.
2. Use a circular hitbox. This seems like a good solution. Circle to AABB hit check math is easy, the hitbox doesn't rotate. But still I though it would be better to have etched corner on the tiles.
3. The last solution is to use pixel mask which means using a bitmap to store collision information of an object. This is quite easy to implement, should be fast given the low resolution, and allows for ANY shape.

Although all options are viable, I choose to go with 3. Not only this seemed a nice addition to MonoPunk, but also it solves all my issues. MonoPunk has been improved in a way that it supports most types of collision pair. So that you are not force to use pixel masks everywhere as this could be costly. So for example it is possible to collide an AABB against a pixel mask. This is also very convenient for map collision as most tiles doesn't need a pixel mask. Here is how collision now looks like:

What's next?

There is still work left on the car physic, this will conclude the core engine of the game. After that focus will be put on user interface and level design to have a first working 'race' in order to validate the core mechanics of the game.

This is the devlog of a game that should never have existed... Sorry. Let me introduce you to...

"Super Dungeon Racer"

What's that? It's dungeon crawler racer. Drive your car through Zelda style dungeons, collect loot, avoid traps and solve puzzles.

-> https://discord.gg/6hcnvxv <-

early protoype (10/11/2018)

early protoype (23/11/2018)

Why do a devlog? I figured out it would be an interesting exercise to take the time to reflect on the development on the game. I will also try to give some insight on the technical/design aspects. Sharing can only be good right?

Who are we? Two guys trying to break reality and make games. I'm taking care of the game design and programming. Bahototh  is doing the pixel pushing.

 The game is currently being developed in the frame of GitHub's GameOff 2018 jam (theme: Hybrid). As the jam is about open source I decided to take the opportunity to make my own engine available. This is an engine I have been using, breaking, improving, hacking and cleaning during the last 3 years.

MonoPunk: https://github.com/jlauener/MonoPunk

The aim is to create a small dungeon crawler were the main character is a car. It's a bit like an hybrid between Micro Machine (for the car control at least) and Zelda. The game is procedurally generated from a set of predefined room templates. Currently we are  heading towards a "time attack" game were you have to reach checkpoints in order to continue playing. It might be infinite or not. More details should come once the mechanics are fleshed out.

Dungeon Racer: https://github.com/jlauener/DungeonRacer

Disclaimer: Dungeon Racer is at the prototype stage and no binaries are provided yet. We might have alpha/demo later during the jam.

Hey! Really like the idea behind this card. Remind me of the Pinball Construction Kit, somehow. There was a small problem with a section of transparent color (alpha 0) which broke the cart. Here is a fixed version.

Played your game for a while and liked it! Especially how ships from different factions are going from island to island. It gives some realism to the game.

It took my sometime to understand I need to go where there is the arrow and the white water to interact with the harbor. Also combat during combat I would have liked to see the enemy HP, maybe. So yeah it lacks a bit of feedback but overall a great game!

Very interesting concept. Especially like how you can select which enemy/item is in battle using the grid system, that's brilliant.

However as already pointed out, it's very difficult to get a grip on the combat system. Besides missing feedback, I think the main issue is that first combat is already very complicated. It would be nice that the game starts simple with few enemies/items, and characters with single ability. This way the player can slowly get used to the game system as the game complexity ramp up.

I totally understand you ran out of time on this one. It's quite impressive what you got done.

Pix64 is a fantasy console I made for previous year edition of the Jam. To make games you simply feed the console with 64x64 PNGs files following a given palette. No coding required. Only pure pixel pushing! You can use this fantasy console to make a legit #lowrezjam entry.

To celebrate the start of 2018 edition I added MacOS/Linux support. You can check it out here: https://zappedcow.itch.io/pix64

PS: Yeah this is kind of a shameless plug... Still felt like it's worth sharing :)

PS2: I'm not so sure about how well the MacOS/Linux build works as it has been barely tested. Any feedback/help welcome :)

A 64x64 deck-building game, such a lovely idea. I'm already looking forward to try your game! It's seems quite ambitious for a 2 week project though if you stick to the core stuffs and prioritize your work I think it's definitively doable.

Good luck and (more important) have fun!

4x4 tile/sprite set. CC BY 4.0 license:

 https://zappedcow.itch.io/micro-dungeon-set

:D

Auto next works the same way, so currently there is the same bug. Does it answer your question?

Thanks for reporting that, should be fixed next release. As a workaround you can name your carts 'cart_01, cart_02..., cart_10'. This fixes the sorting.

Very good idea! Didn't managed to get fast enough for the last part though !

That's impressive. I knew there was the 1 hour jam. But doing a game in 1 minute! i guess that's the power of Pix64 :D

Oh yeah that's strange. Quite a bug actually! I should be able to fix that on a next release (hoping no existing carts rely on this "feature").

PS: Sorry for the late reply..

Made an simple AND gate inspired by your cart :) This one doesn't have a latch but it should be easy to add one.

You are welcome!

By the way I just released (coincidence with the jam?) a new version of the Pix64. You can check the devlog here:

https://zappedcow.itch.io/pix64/devlog/24614/pix64-v11

Those defend carts... Very good use of the player color! I'm always thrilled to see new, unexpected, use of those simple pixels :)

Oh. That's brilliant! Provided an uterly huge PNG size we could be a computer :D

Haha made it! I have to say it's quite an interesting cart.

You can run Pix64 (untested) using the following command within the Pix64 folder:

mono Pix64.exe

Normally mono is supported and installed by default on most Linux distributions.

Hey, thanks for your interest in Pix64 :)

You can zip your image(s) and publish the game as such. Check those jam entries for example:

https://srgovindan.itch.io/boy

https://tiagor2.itch.io/route-64

Impressive collection. I like how you explored the breakout mechanics and use of the Jam's theme.