next »

[Sandwich Generation]

VVVV LATEST GIF,& LINKS VVVV



Play 'LazerGrrl Lite' now in browser for free!!
Itch.io
Gamejolt

Get early access to the full desktop version
Itch.io

Check out the KickStarter video which shows the proposed features for the full version





Find an opponent, chat to devs, give feedback, take place in tournaments, on our Discord
Discord


Also...

Facebook

Instagram

Twitter

VVVV ORIGINAL 1ST POST VVVV





(Crappy Video of it in action (me and my dad playing, not exactly an actual match, just showing it working)


This is the first devlog for this game, and also my first devlog ever!!


I've been a professional game dev for about 4 years but I have never made a multiplayer game. I never even usually *play* multiplayer games.

However I went through a spate of playing two of them recently..

1. 'Go' the ancient Chinese boardgame, which I played on kgs

2. 'Supreme commander' the epic scale RTS, with an emphasis on strategy,  by gas powered games. I played this on the awesome community made lobby FAF, Forged Alliance Forever.[note: In supcom you have a commander unit who can build structures. What sometimes happens in the game is that players will have a 'base-war' by building static defences/ static artillery / shields with their commander.]

During this period I came up with the idea for this game. So I think in my twisted brain the core concepts of LazerGrrl are derived from from those two games.

I thought it I would have a go building it for fun + for the experience of making a multiplayer game.
There was alocal game-dev event coming up so I threw together the prototype in the video with Unity in 2-3 days. Its just a local multiplayer game with controller or keyboard input.

It got a good reaction from some people. Some people were able to have fun competitive games and play over and over. I was not expecting that considering it was such an early build, just the very 1st working prototype from my brain, with no playtesting or thought put into the game design. I reckon if I'm careful with this and make the right decisions it could end up being a pretty good game.

After talking to other devs and seeing people play it (and playing it myself for the 1st time) I started to formulate some initial design principles that will guide the design of the game. They're based on the games I was playing 'go' and 'supcom'.

1. Simple rules and element leads to complex behaviour.  (like in go) For example, only have a few kinds of blocks the player can build, but let them place them in many different  configurations, leading to many emergent strategies and counter-strategies

2. The game is like an RTS boiled down to the absolute core. By which I mean you fight over resources to spend on infrastructure which you use to fight over more resources.

An artist with some pretty impressive stuff agreed to work on it with me. and has already thrown down a few concept sketches.



So next steps are..

1. Get multiplayer working over the internet

2. Get people playing it.

3. Use metrics and feedback from players to inform decision making in the game design

[HuvaaKoodia]

Having made a few local multiplayer competitions (unpublished unfortunately) in the past I can see the potential here. Judging by the prototype getting the laser up and running first seems quite powerful, after all you can plop it down pretty much anywhere. It is possible to build defensively (successfully that is)? Does the laser run out of energy? Planned any more level layouts? How about other block types?

Supcom sure is a fine inspiration for just about everything, even if in the completely other end of the RTS-spectrum. Go seems like a good fit with its complexity stemming out of simplicity, always a good motto that.

"Use metrics and feedback to inform the design"
Not a bad idea. Just keep your hands on the wheel and don't get sidetracked by guesswork or requests.

Good luck! (alternatively: Do well!)

[Sandwich Generation]

Cheers for the feedback!!
"Does the laser run out of energy?"
in this 1st build lasers are limited by how much power you have.
Any group of connected blocks will form a power grid. One power generator will power one laser, any excess power will be turned to money if the grid is connected to your bank. So theres a tradeoff between having more lasers and earning money (if you have a lot of money you can even burn through it by having more lasers then power gens)

"It is possible to build defensively (successfully that is)?"
Well walls cost 5 energy and take 10 seconds for a laser to chew through (which uses up 20 energy) I did see people employ a turtle strategy that sometimes worked and sometimes didnt.

Planned any more level layouts?
I'll try and come up with one layout that works really well 1st. One thing I definitely didnt like in this build was that you dont really fight over resources like in supcom, the 6 power points on your side of the map are more than enough. I have ideas for a new layout that will hopefully foster competition.

How about other block types?
I have a lot of ideas for other blocks but I want to keep it as simple as possible. Ill use my simple elements -> complex possibilities design principle when making decisions. If you could use even the current set in loads of different ways I'd be happy. I think cus you build in this game (as opposed to bomberman where you destroy an existing grid) the more freedom I give players to build and invent new strategies the better.

...

The above being said, that build is sooo early. Literally just 2 & 1/2 days work. Just the 1st working *thing*. I felt I had to build it before I could even start thinking about the game properly. There will be vast sweeping changes to the gameplay.

I thought it was too early to actually put that build up live on itch.io (for the general public) but I'm happy for devs to play. Heres the link if youre interested...

http://lazergrrl.bitballoon.com/

Its wegGL so no install but its only local multiplayer so you'll need more than one person there to play!

[Sandwich Generation]

Hi everyone,

I’m Pablo but you can call me Pab, I’m the artist of LazerGrrl!
Before starting to produce game-ready art assets I wanted to make a concept image that would help me imagine this universe and its characters.
I started with Lazer Grrl herself. My idea is to make her super simple yet unique, thus the few features she has can become iconic.
Also, I got inspired by the first placeholder art made by Brian. I kept the big hands, ovalish heads and cool shades.

Here is an example of two logos. Personally, I prefer the black and white one, I think it looks like a sticker on top and that gives it some attitude, it can also lead to an interesting UI. In my opinion.

All this is WIP and all feedback is very welcome.

Thanks!

[Sandwich Generation]

I got multiplayer working! I have never made a multiplayer game before so this was quite exciting!

Try it out. [enter the online door, if someone else also does so on their pc within 30 seconds you will be matched]
CONTROLS: wsad and space OR left stick and A button

...

I want Lazergrrl to be a webGL game, because people can just hit the link and immediately start playing. No download or install. This greatly reduces the barrier to entry in my opinion. Also the same build will run on windows, osx, linux, android + others maybe.

I'm building it in Unity, so I first looked at Unities built-in multiplayer services.
I quickly ran into the problem of these services not working in webGL builds. Their high level API and low level network transport layer are both restricted on webgl. Basically you'll need a server somewhere running a Unity desktop build for it to work, which seemed like too much hassle so I starting looking at another option.

That option was gamesparks. They provide a backend for games as a service. I've used them before for things like leaderboards. It turns out they have a realtime service for multplayer games. Is it part of their Unity sdk? yes. Will it work in a Unity WebGL build? yes!
I went through their very thorough tutorials on getting started with their realtime services.
Everything just worked and soon I was able to make the other character move over the internet!!

I 've initally built the worst / quickest to do / 'naive' implementation of the netcode. I generally program like that. Do whatevers simplest 1st and if its not good enough for some reason then iterate on it or optimise the bits that need to be optimised, but if it *is* good enough, happy days, its done, move on! I picked that up from reading about John Carmack in the book 'Masters of Doom'

Right now there is a big potential for bugs, it can be possible for two players to move into the same square if they do so simultaneously. Currently if you move on your machine, it sends a packet to all other machines telling them youve moved, theres no one source of truth.
I can fix that by writing cloud code on gamesparks that will be the source of truth for where stuff is in the game. So after I do that, when you hit the button to move...
* your character will start animating
* It will ask the server if the square you want to move into is occupied
* If its not, you continue moving and the server tells the other players you've moved, it also updates its own state with you in that new position.
* If it is already occupied, then the server tells you that square is occupied and you stay where you are.

Another thing is, I am using their 'structured data' in the packets I'm sending, which are like jsons or something. I'm sending packets with ints and other primitives in them. These structured data packets are bigger and therefore slower. If I want to optimize a certain netcode call I can switch it to unstructured data which is just a raw stream of bits. because this game is grid based I'll be able to get a lot of payloads (for instance mvement) down to 1 byte if I want, by individually setting bits to convey information.

Apart from that its actually not bad I think (though this is my first multiplayer implementation so who knows!!). The way multiplayer works is that a players own character and blocks are simulated perfectly on their own machine, and if they move, or die, or place a block, or one of their blocks gets destroyed, then they tell the other players.
In contrast the remote players behaviour does not have to be perfect, they will just appear to do whatever theyve been told. So for example. The local player *must* move from square to adjacent square one at a time, nothing else is possible, the local move command specifies what direction to move in. Whereas the remote move command just specifies a square to move to, so a remote player could jump from one square to another several squares away, this is in case packets are lost or there is lag. Its coded to assume that the information coming from other players is not perfect or in the the right sequence.

[mpixel]

I really liked watching this gameplay! Love the idea keep it up

[Sandwich Generation]

Play it now!

Got loads of work done this week! including...

* Interactive menus
* Player customisation room
* Customisation info stored on server, is applied when u log in.
* Leave and start new game
* Scorekeeping
* New round after round completes
* Esc - back to main menu, you leave the game and other players wins by default
* Can sell blocks at shop, money you get is proportional to blocks health

* Two new design principles.

In addition to the existing ones..

1. Simple elements leading to complex possibilities.
2. Secret RTS

we added..

3. As accessible as possible for new players.
We decided to prioritize the experience of casual player just checking it out for the 1st time. Therefore we want to keep the mechanics as intuitive and simple as possible. This has lead us to make decisions like prioritizing the keyboard as the main control input, as everyone playing on any kind of pc will have a keyboard.
This may sound like a no brainer but there were things in the game that went against that principle which we had actually started to like, notably the awkward controls, we had found a layer of strategy in them, when obstacles were in a certain arrangement it could be impossible to place a block where you want due to how the controls worked.
We decided the controls are the controls, they should be as intuitive and fluid, and not impede you as the player, as much as possible no matter what. Also because of the adversarial nature of a pvp game like this, strategy can be generated by almost any feature, even bugs. For example theres a bug in supreme commander (for reclaiming) that all good players take advantage of and is part of the meta.
We have a lot of ideas for features and tweaks that will add layers of strategy without sacrificing something as vital as intuitive controls.

4. If you have a fun idea, do it.
Already an unwritten rule for us. We're both doing this for fun. This keeps us excited and motivated to work on this project in our spare time for no material gain. Also I think it adds a certain purity to our designs, we are not compromising or fixating on stuff like monetization or fitting in to the market, in our design.
The new menu system is a good example of this. I just thought the idea of the menu system being rooms you walk around in and interact with would be much more fun (for me) than conventional ones so I built it.


* New movement mechanics

Iterating on the movement mechanics was the 1st feature to give me pause. I initially tried several different ideas. We wanted players to be able to move their build cursor without moving the player, to remove that 'awkward controls' issue mentioned above. But we liked the snappy way they currently worked. I made it so if you were holding a block, and were not in constant movement, and were changing direction, then, only the build cursor would move.
I also added a smooth lerping animation on the sprite rather than them just jumping from square to square, but this strangely seemed to make the movement seem much slower, so I changed it so the sprite lerps really fast between squares and then pauses before moving again.
Eventually I thought the controls were getting too complicated, we liked these controls, but the fact that they work differently when holding or not holding a block I think would be jarring to new players.
I then decided what really are the design principles for the movement, and started again from them.
The principles were.

1. Accessible (intuitive, consistent)
2. Responsive.
3. What you see is what you get.

So the final scheme I came up with based on those principles is...
Just the build cursor moves when you change direction at all times. This is consistent.
The character lerps smoothly from square to square, what you see is what you get, eg once the sprite has arrived at a new square you can immediately move again there is no pause.
However I also made the build cursor *snap* from square to square, this is so you can build or remove blocks at all times, even when moving, this was to keep the snappy responsive building from the early build.

So, because there is a pause when you change direction, the overall movement was a little slower than before, to make up for this I increased the speed which the character can move from square to square in a straight line. Previously I had made the time it takes to move from square to square the minimum time in which I could stop on the square I wanted. However, the smooth lerp of the sprite from square to square actually makes it easier to judge when your character will arrive at the next square so these 3 changes (pause when change direction, sprite lerp, faster movement speed) balanced out very nicely.

[Sandwich Generation]

Try it out!

Since shortly after the 1st games meetup where I demoed LazerGrrl, I had a big list of core gameplay ideas I'd like to try out.
I've now implemented all of them. (as well as tonnes of lesser features!!)

* Laserbeams reflect each other 90' when they meet head on
   More on this below..
   
* Mega and ultra Lazers, Blocks and Power Nodes
   There are now 3 levels for blocks, power nodes and lasers. Normal, Mega and Ultra. A megablock can only be damaged by a megalazer or above. Mega power nodes provide 4 power and a mega lazer uses 4 power. Ultra power nodes provide 12 power and an ultra lazer uses 12 power.
   The bigger lazers are built by placing the existing lazer blocks in a row.
   
* New map layout
   Now each player only has 3 normal power nodes on their side of the map, 2 mega and one ultra power node are in the middle to be fought over. The mega nodes are surrounded by weak walls, the ultra power node is surrounded by megawalls, so you must build a megalazer to get access to it.
   The connection points to your bank are now on the side walls rather than the rear, this makes your connection vulnerble to being cut by your opponent.
   The map is now symmetrical in 2 axes, this automatically doubles the strategic possibilities. Eg. now both players could concentrate on one side, or opposite sides, or both split their activities among both sides. I got this idea from the classic supreme commander map 'Finn's revenge'
   
   The idea behind this and the, mega ultra concept, was to address some shortcomings of the prototype.
   1. Players didnt fight over resources, they had more than enough on their side of the map. Now they have less on their own sides and the ones in the middle are far more valuable.
   2. The game didnt escalate, In longer games players would just build more and more normal lasers and pgens. Now the game has the tech vs spam concept from RTSes. you can still spam lots of normal lasers or fewer bigger lazers.
   
* Victory through killing enemy base aswell as enemy player
   If you build an Ultra lazer and are able to power it (you basically need to take the central ultra power node, or else have a ridiculous amount of energy in the bank to burn through) You can now destroy your opponents base (which is made of ultrablocks) and win the game that way.
   
   This was done to address the prototype issue where, Someone could be clearly winning, but the game would drag on, because the loser would simply hide in an awkward part of the map, or on their opponents side. Now if someone has the upper hand they can go for the central power node and build the game ending ultralazer. The losing player can try and harry their efforts of else try and assassinate their opponent with normal lazer spam.

...
   
In general the *ideal* I'm going for with these features is.....   
Far more strategic possibilities with the same small number of elements. (still just the 3 blocks as in the prototype, wall, pgen and lazer)
Yet, hopefully it is still accessible as new players can *still* play it as it was in the prototype, only building the normal level elements.

The 1st prototype was a true MVP (minimum viable product) for a playable game, that I literally threw together in a few days.
In terms of the core game mechanics, I imagine this most recent build to be the most bloated with features. The process from now will be one of playtesting, refinement and *cutting* features until we have arrived at the set of core game mechanics we want to present to the public. There is a Games Fleadh coming up in a couple of weeks. Our goal is to have this '1st public ready' set of mechanics ready for then. We will then use the Games Fleadh crowd as guinea pigs.



Lazer reflection

in theory this is a killer feature.. as it elegantly resolves what happens when lazers meet*, and using only the existing elements adds huge amounts of potential complexity
im thinking, noobs will be, what happpens when lazer hits laser? oh they reflect! and not think  anymore on it. intermediate players will descern the lasers turn right when they meet head on rule.. ans master players will be able to predict complex interactions and use them in their strategies

*In the prototype I did not code *anything* to handle this situation, both lazers just shot each other
 
WYSIWYG

We added one more design principle. WYSIWYG. What you see is what you get. This was a useful guiding principle when I was working out how to handle the movement.
I love the idea that there is no meaningless graphical detail, there can be detail, but it all conveys something meaningful. From vividly drawn crucial things, to more subtly portrayed less significant things. The subtle elements will wash over and be ignored by new players but they will subtly teach more experienced players exactly how the game works.
A really good example of this principle and a new feature I'm very happy with is the 'energy balls'. Now power consumption, production and storage are represented with energy balls. So you will see an individual ball leave a power generator and enter a lazer and the lazer turns on. You will also see energy balls leaving or entering the bank. In the future we wont have numbers for you banked energy amount, it will be represented by energy balls in a storage chamber.
 
All our design principles are now...

* Simple elements leading to complex possibilities.
* Secret RTS
* Accessible
* Fun! (for us to make)
* WYSIWYG

[Sandwich Generation]

TRY IT

GAMEPLAY

So, in my previous post I detailed how I had built a load of new features. Basically all the ideas I had wanted to try out.
We have now done a decent bit of playtesting and, they actually all worked pretty well, it was fun and pretty much played out according to my theories.

however, we have of course whittled them down and made some refinements in the interest of accessibility for new players (Who are *all* players atm).
The biggest refinments are..

* You can no longer place lasers facing arbitrary directions, they will always face towards the opponents side. We really wanted to keep our 5 button controls scheme (up, down, left, right, action) so the way you placed lasers facing different directions was that the laser always faced towards your character as you placed it. Being able to do this did add some strategic richness especially in combination with lazer-beam reflections, however we found this control scheme just to awkward and unintuitive for new players so its gone.

* your base is a big block that takes damage as one unit, also it can be damaged by any kind of laser (no longer just ULTRA ones)

* ULTRA lazers, blocks and energy nodes are gone.. There are just normal and MEGA ones now. Two types of thing is enough, a normal one, and a bigger one.
the ULTRA laser was conceived as a game ender for games where one opponent is clearly winning but cannot quickly kill the opponent because they are hiding and dragging out the game. Now that the base is vulnerable to all lasers this is no longer necessary.


VISUALS

This has been a big couple of weeks for the visuals. Most of the programmer art is gone

blocks convey the following information..

* What is is Wall, Pgen or Lazer
* Who owns it
* how much health it has
* Whether it can connect to another block on each side
* Whether it is connteced to another block on each side[/li][/list]

Energy balls

Before, how much energy you had in the bank and how much energy blocks cost were represented by numbers. Now those elements + energy generation by pgens, *and* usage by lasers are all represented by a unified visual system.
The currency used to buy blocks and power lasers is 'energy balls', they are generated by power generators, stored in the bank, and used by lasers. You can see them moving around the energy grids you have built carrying out these various roles

This still has a ways to go, but we're really happy with it. It *shows* how the game works, how energy is money and also powers lazers. It conforms to our what-you-see-is-what-you-get design principle. We hope the detail will mostly wash over new players but teach them exactly how the game works the more they play.

The biggest challenge programmatically in doing this was that we doubled the value of each energy ball.
Before, I had a simple elegant system governing the energy economy. It decided every second where the energy produced would go, and it would be implemented instantly.
With the introduction of energy balls travelling over time things became a bit more complex, but it was still just one simple addition to the existing system.
The smallest unit of energy in the game was the amount required to power a normal laser for 1 second. So this was 1 unit of energy. With this value a wall cost 3 units and a lazer or pgen cost 10.
We thought representing the price of 10 balls for a pgen or lazer visually was too busy, so we decided to double the value of energy balls. So now a wall costs 1 unit and a pgen or lazer costs 5.
The problem is that now it would take a normal pgen 2 seconds to generate one unit of energy, and a normal laser 2 seconds to use it. I could have increased the tick rate of the economy to 2 seconds, but then, if you happened to place a lazer just after the last tick, it would take 2 seconds for the lazer to request energy + more time for the energy ball to reach it and it to power on. This could be annoying and also confusing for new players, wondering why their laser is taking so long to turn on.
So instead I made the energy economy work asynchronously. Now energy 'contracts' between energy producers and consumers in each system of connected blocks are decided every half second. However, the actual production and transfer of energy happens independantly, so a pgen will produce an energy ball 2 seconds from whenever it produced the last one..
I also wanted to keep certain behaviours that I had in my earlier system, for the energy to be automatically handled somewhat intelligently; energy is not sent to lasers that cannot be fully powered, also lasers prioritize using generated energy rather than using stored energy from the bank, they also get energy from their closest power generator.
I wont go into any more detail, but suffice it to say, implemetning this was *very* complicated. My elegant system is no more. Instead there is now a lot more code dealing with spefic circumsatnces, eg. a class dealing with routing energy to lasers, another one for routing energy *from* the bank. etc.

Also from a multiplayer point of view, each player simulates their own energy economy and simply alerts the other player only when one of their lasers has turned on or off.
The remote players economy and energy balls are simulated, but it is just for show, it has no effect other than visually.
 

[Sandwich Generation]

Try it out





Games Fleadh

 
We demoed at the Games Fleadh in Thurles, Which was atteneded by college students and primary and secondary school students. I was actually suprised at how much the young kids enjoyed playing it. They'd play over and over again and crowd around the screen.

A few things we picked up from testing there and the last games CO-OP were..

*  The items in the shop need to be clearer, perhaps just buttons with text on them POWER, WALL, LAZER

*  *No-one* bothers going for the mega power nodes in the centre of the map.

*  *Everyone* loves the maga lazers and builds them even if they cant power them.

*  Because of the 3 power nodes in a row in front of your base people have a tendency to connect them all up and wall themselves off.

*  Some people try and connect the power node in front of their base directly to their base.


Zeroing in on an MVP

So the stage of large gameplay changes appears to be over. We're gradually zeroing in on the 1st version of the game to be available to the public.
We are really concentrating on a sort of MVP (minimum viable product). We're often going with the simplest implementations, the ones that will work best for new players, which is *all* players at this point. If the game is in any way popular *then* we can fill it out with more features, eg. more levels, customisable rules for games, but right now we are just trying to make that *one* level and ruleset that works best for new players.

One example of this is that the map we are going with is more like the prototype map, with a fairly even grid of single power nodes and no super ones, and also no walls. We've concluded from testing that getting people over the initial learning curve of buildings pgens on the nodes and connecting to your base is enough of a challenge, anymore details people seem to ignore. So they were ignoring the power nodes in the middle as it was just too much to take in.


Visual / Audio tweaks.

* The energy balls are now bigger and volatile looking.

* There is screen shake with chromatic aberration when things explode

* Explosion are no longer pixelated (we had this idea that the floor was a TV, which we've ditched) they have particles and a cloud now.

* Power nodes look like green (ie. neutral) energy balls.

* The other player will always appear as a different color to you on your machine.

* I've done the 1st draft of original music (its like 8bit punk rock) + it now also only plays when action is happening, after the enemy player dies it stops.
 
 
Next steps

So this MVP could easily be done and ready for the public by the end of April, the main programming tasks left are..

* Build lobby system
* Build tutorial
* Build practice AI
* Add Metrics

[Sandwich Generation]

So we are barrelling towards getting our MVP together and making it playable by the public...

New minor features

* 1st properly implemented lobby
When searching for a match, you wait in the arena where you can practice, also you can *stop* searching for a match.

* Improved lazer graphics.
The beam is made from several animating lines. There is a big flare when the lazer starts, and also a kamehameha build up of energy as it is charging.

* Improved lazer sound effects.
The lazers are now in the same key as the music. The different players lazers play different notes, also the MEGA-lazers are deeper and louder chords.


Music

We have added a 3rd member to the LazerGrrl team, Peter Jones, who is making music. The arena music is already done, you can hear it in the video above.
Our art is kind of oldskool inspired, it has a very limited color palette and is simple and diagrammatic, but, it is not pixel art, it is high-res. So its like a sort of retro-modern look. I think Peters tracks compliment this perfectly, they are reminiscent of oldskool video-game music but have a modern richness and production quality.

I (the programmer) had already made some music for Lazergrrl, but it just had a NES style chiptune sound (you can hear it in the video in the last post). I was just going to go with the NES style rock track because I thought it would suffice and it was quick and easy to do, though it did jibe, having a retro-modern art style and a simply retro music style.
Not being a specialist in audio it would have taken me weeks and weeks to achieve anything like this rich retro-modern sound (if I even could).
Getting Peter on board has meant a huge step up in our music game.
 

Netcode: perfection vs responsiveness

One thing I had been planning to do all along was a serverside gamestate. There would be a single source of truth for where solid things were, on the server. This would have made it impossible for two players to move into the same square or place a block in the same square if they both do so at almost exactly the same time.
When I actually started implementing it however I changed my mind.
In order for the server to confirm moves, you might move, and then after sending a message to the server and getting a response back, end up being denied and moved back to where you were. I thought the lag involved in this would really hurt the responsive feeling controls.
Lets say you make several moves really fast and then recieve the response that the 1st move was invalid. It would be very jarring to be moved back several spaces. Conversely, making people wait for a response from the server before being able to make a 2nd move would be frustratingly laggy in my opinion.
I decided to favour snappy responsive controls over a perfect gamestate. I'd rather have some weird things be able to happen in some corner cases rather than have every single move laggy at all times.
Instead of the server-side gamaestate I am just making the game tolerate imperfection, two things being in the same space.


Whats left to do for the MVP?

* Tutorial AI
For tutorial purposes, we are prioritizing an AI you can practice against..(Lazertron 9000) He will be very very bad. We're hoping new players will pick up the basics by watching and emulating him,

* Menus
The concept for these is done (see images below). Just a matter of implementing them. Pablo is gonna really make them pop. Its an opportunity to flesh out the games image, art-style and attitude.

[Sandwich Generation]

Discord.. Playable link for the game is here

Our MVP is nearly complete.
From a programming point of view I have reached the stage where I am simply cleaning up a few things, optimising, bug-hunting.
We have reached that stage in the project where progress is art-bound rather than programmer-bound. I am now thinking about marketing the game.


Tutorial 'AI'

We found through demoing that for an action game, Lazergrrl has a steep initial learning curve. Its a big step to learn that in order to start earning energy you have to..
1. Buy a reactor
2. Place it on power node (green glowy thing)
3. Connect it to your base. 
But, we also found that once people get over that initial step they are good to go and will start discovering different strategies on their own.

The purpose of the tutorial is to get new players past that 1st big step. Once they can do that they are ready to play online.

Instead of a normal tutorial, we just immediately dump players into a match with a *very bad* opponent, Lazertron 9000, we also thought it would be fun if he was megalomanical and trashtalked.

'AI' is in quotes because he is a literal automaton, always making the exact same moves.
The idea behind this, is that brand new players will be able to watch him make the basic opening moves and emulate him. They will see that he built a reactor, then connected it to his base, and then energy balls started flowing into his bank.

Lazertron normally randomly trashtalks the player, but if they are not progressing, eg
not moving, not buying anything, not building a reactor on an energy node, not connecting it their base, or not building any lasers, he will make more helpful comments hinting at what to do until you remedy the situation.





Final tweaks for MVP.

Every time we demoed we got really good feedback and insight. Usually through people not understanding the game and doing completely 'wrong' things. Eg. people would try to connect directly to their base, or wall themselves off for no reason.
Through demoing, and then refining our game based on the insights and feedback we have noticed that these sort of problems are becoming less and less common.
The latest round of demoing was the best yet, but we did get some very clear feedback [the SAME feedback from multiple indpendant people] on a few things. They were..

1. Purpose of blocks is not clear.
   Its quite unclear at 1st look that they are reactor, lazer, and wall. The very bad original dev art was probably clearer in this regard.

2. The base needs a health bar.

3. Energy ball production and movement should be more apparent.
   I can improve this by..
   Making them travel slower.
   Giving the energy balls a bigger glow.
   Show the energy balls being generated in the reactor and then bursting out.

We have already made good progress on all of these issues. We'll probably do one more pass before release.


Whats left to do.

* Menus

[Sandwich Generation]

Check it...

[Sandwich Generation]

Just a quick update showing the new health bars. This was a requested feature and really helps imo.
Now players will be able to see how quickly their base and blocks are being damaged, and how long they have left to live.





Discord.. Playable link for the game is here

[Sandwich Generation]

We took a break from this to work on other stuff.
Back working on it now and MVP is pretty much done.
Here is one of the final features, the 'match found' screen.

[Sandwich Generation]

Block and base art tweaks

Over the course of development we regularly play-tested, and got really good feedback about the art, and how it could be clearer and more useful to the player. Over several iterations we made big improvements and we could see them having an effect, as new players would no longer tend to make the mistakes they did in the previous iteration.
The only problem with this was that we made lots of little changes one at a time. The end result was a little inconsistent or muddled.
We have revised the last iteration of the block and base art, incorporating all the positive changes we made, but rationalising the final product somewhat.
This boils down to..

1. White borders are skinny again now.
Because they act as health bars and 'go down' rather then turn black as damage is inflicted, they now longer need to be so thick.

2. Reactor is a circle now.
All the blocks are different shapes now, which should differentiate them, also the wall block does appear to be the strongest (which it is)

3. Reactor has 'sun' on it.
So there arent many symbols or ways of representing something that says 'makes energy'. Previously we had a nuclear trefoil, but we didnt like that as it was too 'real worldy'.
Power generators / sources of some kind, *are* quite common in games, but they also generally arent very distinctive. They tend to be circular or symmetrical glowy things. So thats what this is now.

4. Black lines
All blocks now have black lines on them denoting how they can connect to neighbouring blocks.

5. Energy ball receptacle
So for quite some time we have had this representation of a place where energy balls go when they are consumed, in lasers or in the shop. For a while they've been grey circles. I didnt like having that extra color there (grey) as the art style of this game involves a limited color palette.
Now any place where energy balls are used, or generated, is a black circle with a transparent hole denoting the place where the energy balls go.
So, this is all now consistent and also does not use any extra colors.

The proposal


In game

[Sandwich Generation]

New victory music. Check it...

[Sandwich Generation]

Here is a promo video draft. Feedback very welcome!

Because the game has such a steep learning curve at the start, I decided to make the video explain how to play somewhat. So people have a rough idea what to do before they actually load the game up.

It just shows one game being played from start to end, with text explaining what to do, but edited so it is not too long.





Also I learned how to make gifs! I used giphy for the 1st time, very cool site!





Still looking for people to try the beta by the way!

[Sandwich Generation]

Landing page draft 1

So I started a landing page. Here it is atm. Feedback very welcome!




Also demoed the game again at the games co-op and got some more great feedback.
I'm gonna try a few things to make the mechanics easier to understand.

More feedback and visual tweaks to make

1. Put the power generator symbol on the energy nodes, so they are clearly associated with one another.

2. Make th bank fill up linearly rather than in the current pattern of crosses.

3. Show the cost of the blocks as a linear row of dots.

4. Show the blank spaces for energy balls to be stored in the bank. So anywhere an energy ball can go: out of a power generator, into a laser, into the shop, will all be consistently represented.

AI

Probably the biggest problem this game is gonna face is lack of players. If someone else isnt online you wont be able to play. We're thinking about writing an AI. So say if a person has been waiting in the lobby for 1 minute they will just be matched with the AI... Or they can just choose the play the AI themselves. Not sure how we'll handle that.

I've started thinking about how to implement the AI and I have made a few decisions.
1. It doesnt need to be very *good* at the game. If the other player thinks they're playing another human then they'll enjoy winning and be more likely to play again (apparently 80% of people quit an online pvp game and never come back if they lose their 1st match)
2. It needs to appear human, so it needs to make mistakes, and not move perfectly, or do things perfectly efficiently. Also it should be as unpredictable as possible, so it doesnt just always do the same thing.

So, I'm going to bake in a lot of randomness, if that makes it a worse player thats ok.

[Sandwich Generation]

We demoed LazerGrrl over the weekend at the 8-bit gaming conference in Griffith College Dublin.
It went down really well! A lot of people really got the game and dug it. Some people kept coming back to play it again and again. I was also surprised by the number of young kids in this category. I never would have thought kids would particularly like this game, as at its heart its more like a purely strategic game like 'chess' or 'go' than an action game, but they seem to.
We got loads of good leads and made connections to help market it also.

Another thing that came out of it is that we are going to look into Facebook as an additional release platform for the game.

Here are some pics of us at the conference...