TIGSource Forums

VVVV LATEST GIF,& LINKS VVVV

(https://media.giphy.com/media/9xijAdMcmQ0PsXJxlI/giphy.gif)

Play 'LazerGrrl Lite' now in browser for free!!
Itch.io (https://sandwich-generation.itch.io/lazergrrl-lite)
Gamejolt (https://gamejolt.com/games/LazerGrrl-Lite/349963)

Get early access to the full desktop version
Itch.io (https://sandwich-generation.itch.io/lazergrrl)

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

https://www.youtube.com/watch?v=ttBHUCAj3e4

Find an opponent, chat to devs, give feedback, take place in tournaments, on our Discord
Discord (https://discord.gg/CxtnKrG)


Also...

Facebook (https://www.facebook.com/LazerGrrlGame/)

Instagram (https://www.instagram.com/lazergrrlgame/)

Twitter (https://twitter.com/Lazer_Grrl)

VVVV ORIGINAL 1ST POST VVVV

https://www.youtube.com/watch?v=j5HtPJUNRDA

(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 (https://en.wikipedia.org/wiki/Go_(game))' the ancient Chinese boardgame, which I played on kgs (http://www.gokgs.com/)

2. 'Supreme commander (http://store.steampowered.com/app/9350/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 (https://www.faforever.com/).[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 (http://pablobredow.com/) agreed to work on it with me. and has already thrown down a few concept sketches.

(https://image.ibb.co/gCWk8m/Lazergrrl_concept1.jpg)

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

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!)

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!

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!

(https://preview.ibb.co/mxA5yx/concept_one_two_logos.png)

https://www.youtube.com/watch?v=OblqLKb3WiY

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

Try it out. (http://lazergrrl.bitballoon.com/) [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 (https://docs.unity3d.com/Manual/UNetUsingHLAPI.html) and low level network transport layer (https://docs.unity3d.com/Manual/UNetUsingTransport.html) 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 (https://www.gamesparks.com/). 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 (https://docs.gamesparks.com/tutorials/real-time-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.

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

https://www.youtube.com/watch?v=Jbg-LPl3khs

Play it now! (http://lazergrrl-dev.bitballoon.com/)

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.

https://www.youtube.com/watch?v=AgJtzg_sz1U

Try it out! (http://lazergrrl.bitballoon.com/)

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' (https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fgamereplays.org%2Fimages%2Fgame%2FSupCom%2Fmaps%2Ffinnsrevenge.jpg&f=1)
   
   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 (http://gamesfleadh.ie/) 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.

(https://image.ibb.co/ggk9q7/insanity_SMALL.png)

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

https://www.youtube.com/watch?v=4VX6v1UlbdI

TRY IT (http://lazergrrl.bitballoon.com/)

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.
 

https://www.youtube.com/watch?v=XImkTc2KMGo


Try it out (http://lazergrrl.bitballoon.com/)





Games Fleadh
(https://preview.ibb.co/ka5bqS/20180322_105721.jpg) (https://ibb.co/mFO7x7)
 
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

https://www.youtube.com/watch?v=xIJMJ4sWAek

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 (https://soundcloud.com/petejonesmusic), 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.

(https://thumb.ibb.co/nw3Su7/menus_concept0.png) (https://ibb.co/nw3Su7)

(https://thumb.ibb.co/eONsSS/menus_concept2.png) (https://ibb.co/eONsSS)

(https://thumb.ibb.co/h6nFgn/menus_concept3.png) (https://ibb.co/h6nFgn)

https://www.youtube.com/watch?v=2v2QToOUFO4

Discord.. Playable link for the game is here (https://discord.gg/Fnr2qQR)

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.

https://www.youtube.com/watch?v=VljEsDRx_qQ

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

Check it...

https://www.youtube.com/watch?v=OFfK8M3pjGU

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.

https://www.youtube.com/watch?v=SVYXzuk2YUg

Discord.. Playable link for the game is here (https://discord.gg/Fnr2qQR)

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.

https://www.youtube.com/watch?v=Ip_cmsJipt8

https://www.youtube.com/watch?v=dWvEMoVSTJg

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
(https://preview.ibb.co/kQCJWd/theory.png) (https://ibb.co/iE2wHJ)

In game
(https://preview.ibb.co/j6GCrd/DEVLOG1.png) (https://ibb.co/bW1OxJ)

New victory music. Check it...

https://www.youtube.com/watch?v=DEcMTXk3V_U

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.

https://www.youtube.com/watch?v=_WLBqEOzKkc

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

(https://media.giphy.com/media/vgAxjied9KCXSRY7Fr/giphy.gif)

(https://media.giphy.com/media/clFGjk6oV2tAqtjiSq/giphy.gif)

Still looking for people to try the beta by the way! (https://discord.gg/Fnr2qQR)

Landing page draft 1

So I started a landing page. Here it is atm. (http://lazergrrl-landingpage.bitballoon.com/) Feedback very welcome!


(https://thumb.ibb.co/eDFETd/website.png) (https://ibb.co/eDFETd)

Also demoed the game again at the games co-op (https://www.facebook.com/events/1057328557753328/) 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.

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...

https://www.youtube.com/watch?v=3DdLdbYrSM4

(https://thumb.ibb.co/eROh5e/20180728_143702.jpg) (https://ibb.co/eROh5e)

(https://thumb.ibb.co/g0qeke/20180729_103255.jpg) (https://ibb.co/g0qeke)

(https://thumb.ibb.co/cBkjJz/20180729_163910.jpg) (https://ibb.co/cBkjJz)

We will be demoing our game at Dublin Comicon starting tomorrow!!

I have made a new much more conventional tutorial to try there.
When demoing the game I have explained these steps to people *scores* of times. This tutorial automates what I would normally say.
Both players go through it simultaneously.
One of the biggest potential issues with this game is the fact that the learning curve is so steep at the beginning. If this tutorial works out at Comicon then we'll probably replace the existing tutorial with it.

https://www.youtube.com/watch?v=IqOWjM5RvKE

We demoed at Wexworlds (https://www.facebook.com/Wexworlds) in Wexford

It was great! Had a lot of people crowding around waiting for a game at times. We also organized the 1st two LazerGrrl tournaments ever! Totally impromtu!

Our Discord is now growing a decent rate (we have over 80 people) and we have 16 people currently signed up for the 1st online tournament ever.
If you wanna sign-up to head to out Discord (https://discord.gg/ruscmzh)

Anyway heres a pic of stormtroopers playing it...

(https://thumb.ibb.co/mTWoLz/20180818_125921.jpg) (https://ibb.co/mTWoLz)

So for the 1st online LazerGrrl tournament ever, taking place on thursday (for which 18 people have signed up for so far). I am hastily making a few features. They will not be polished and you will only be able to access them with secret keyboard commands.

We need a way for people to be able to host and join the game of a specific person.. Even now with only 80 people on the Discord it can be hard to actually play the person you want to.

So the 1st part of that is exposing the username and password to the user..
So here that is in all its glory!!

(https://thumb.ibb.co/g4K6Qz/SECRETlogin.png) (https://ibb.co/g4K6Qz)

This was already happening in the background. But I didnt want a login screen as thats a barrier to entry.

ps. Join the tournament and play the game on our Discord!! (https://discord.gg/ruscmzh)

So in addition to the secret login/logout/change details screen, I also built a secret screen so players can host an join a match. If they want to play someone specific.

(https://thumb.ibb.co/jgdy8K/unknown.png) (https://ibb.co/jgdy8K)

Ive also been working on allowing a 3rd player to spectate. I reckon I'll get it done before the tourney. Its almost there...

https://www.youtube.com/watch?v=51_wd1Qtz5U

So I demoed at this...

https://www.facebook.com/celticthrowdown/videos/235978227149380/

It seems fighting game players are a good audience for LazerGrrl.

Also our game will be getting demoed in Brazil tomorrow!
So, Portuguese is the 1st language the game has been translated to!

(https://preview.ibb.co/gM3q2p/menuPORT.png) (https://ibb.co/bTqETU)

(https://preview.ibb.co/n1sB8U/tutePORT.png) (https://ibb.co/gin02p)
short hair poems (https://poetandpoem.com/hair)

So we need a company logo to put in our promo video for LazerGrrl...

(https://image.ibb.co/kxo55K/image.png) (https://imgbb.com/)

Say hello to 'Sandwich Generation' !!!

Started writing AI for LazerGrrl (for new players to practice against) a few days ago.. Its coming along nicely, now it is afraid of laserbeams!

https://www.youtube.com/watch?v=Z1zsvJC_A9g

So aswell as being able to move, the only other thing the AI can now do is ECO.

https://www.youtube.com/watch?v=JAGAbCLNiUc

I must say I'm really enjoying this! Writing AI is so much fun..

I'm doing quite a good job programming it too imo.
Overall its kind of a hodgepodge of different AI programming techniques specific to this game.
This game, is kinda like chess, in that you have to plan out moves and make several moves in succession in order for them to make sense.. Eg you have to build a pgen, and then build walls to connect it. But *also* its a realtime game where the enemy action can interrupt or spoil your plans.

Before writing any code on this I had a good old think + sketched out some ideas, and also re-read this page (https://www.gamedev.net/articles/programming/artificial-intelligence/the-total-beginners-guide-to-game-ai-r4942/).
I actually think that page is great, its remedial, but imo if you are familiar with, and 100% understand, everything on that page, you will be able to begin tackling writing AI for most games.

Theres definitely a behaviour tree of sorts in my code, but also planning is baked in. So a node on the tree can have a sequence of subnodes that need to complete one after another in order for that node to complete. If a node 'fails' then, its parent fails too.

I've been following my own good coding practices and so far this has been a very enjoyable experience. The code seems very solid and so far is eminently maintainable. Theres tonnes of flexibility to add whatever features I feel like to the system.
For me good coding practice is..
1. The fundamentals. Tiny classes, tiny methods.
2. Bottom up approach. Start off writing useful little utilities and then compose them to form higher level elements. Then compose those to form even higher level elements. The best software architecture imo is no architecture.. Sometimes you'll end up needing to choose a software architecture, and when that happens the choice is super important, but that choice also locks you in to a certain pattern, so if You can avoid it, do.

So, my AI code is made up of.
1. Static reusable 'Tool' classes where all the hard stuff / meaty calculations are done.
2. Lots of tiny classes like the one below that make up my behaviour tree..

(https://preview.ibb.co/mRwO9p/image.png) (https://ibb.co/fFZApp)

Bookmarking this to check out later. I love the Sandwich Generation logo.

Current state of the AI

https://www.youtube.com/watch?v=vP5kgnTeQ4Q

My AI is starting to resemble and actual opponent now..
I think he would beat a brand new player in his current default configuration!

My AI design has main 3 main branches on the decision tree..

1. Eco
Build and connect reactors to earn energy

2. Attack
Build lazers

3. Defend
Avoid personal lazer fire, and protect base and blocks with walls

So far Eco and Attack have been implemented (somewhat)
All that remains to do, to have a serviceable opponent for new players is...
1. Implement the Defend part of the decision tree
2. Add some chance to his decision making. (Currently he's deterministic, which is good for testing purposes, so I'll leave him like that until later)

Ok lots of things to report!!

Release deadline is October 14th... So I've been crunching a bit.. I havent had time to post here!

1. Cool AI vs AI video

https://www.youtube.com/watch?v=sfk75ObxhIQ

AI is done for now... Its more than good enough to play at the end of the tutorial and as a 1st practice opponent
I think this video is cool.. The reason they are making the exact same moves is because this AI reacts deterministically to their opponent. So, as they are both AI's, each of their opponents is doing the same thing, to which they respond identically... Until they both try to fit through a one square wide gap, and then they diverge.

2. Tutorial is done!

https://www.youtube.com/watch?v=rxERvdPTTRQ

I turned the 2 player tutorial I had been using when demoing the game at cons into a single player tutorial.
This tutorial has been tested with scores of people, iterated and then tested again (when demoing) So I have confidence in it.
Also I reckon this new single player version is now UNBREAKABLE.. Please try and break it!

3. Block stacking rule

So because of the internet and me wanting my game to be super responsive (more on this in previous posts),, its possible for players to place blocks on the same square if they both do it at exactly the same time.
Now if that happens both blocks explode.
This 'block stacking' usually only happens when very high level players are playing very close to each other and making lots of fast moves... But I thought I had to add this rule, in order for this game to be able to be taken seriously as a competitive pvp game.

4. Custom games exposed.
So now everyone can..
1. Host a custom online game.
2. Join a custom online game.
3. Change their name.
Before it was doable via a secret feature, and it was super-janky... Now its exposed to the public with a decent UI and it works nicely.

join
(https://preview.ibb.co/hnmfe9/image.png) (https://ibb.co/fNt46p)

host
(https://preview.ibb.co/cjk6K9/image.png) (https://ibb.co/iegP6p)

change name
(https://preview.ibb.co/n8UNsU/image.png) (https://ibb.co/gy78XU)

So here is a rough draft of the promo video..

I'm (the programmer) gonna do another days work on this at least.
I need to sort out the audio levels, currently the SFX from the game footage are super low.

Then the artist is gonna polish it up (and he is actually *good* at this sort of thing!)

Also the music guy is gonna properly edit his track to match (You can hear my *very* crude edit, where I just cut pasted bits to get the timing ok)

https://www.youtube.com/watch?v=UA543jjZEEg

Anyway I think this is a big step up from the last one (https://www.youtube.com/watch?v=_WLBqEOzKkc&feature=youtu.be)..
I've never really done this sort of thing b4 so I'm really pleased with myself.   :)

Also I hate doing this sort of thing!! I started this on Tuesday but probably spent almost 2 days procrastinating and not getting stuck in.
This is probably a few hours work for someone good at this. I set aside 4 days to get this into good enough shape to hand over to the artist. Its just a bit of video editing, but because its so far out of my core skillset it feels like a big accomplishment.. It felt harder to do this than to write the AI lol!

So LazerGrrl is now public!!!!
Its 100% free to play in browser.

Itch.io (https://sandwich-generation.itch.io/lazergrrl)  
Gamejolt (https://gamejolt.com/games/LazerGrrl/349963)
Kongregate (https://www.kongregate.com/games/Sandwich_Gen/lazergrrl)

From now on I'll mainly be marketing and telling people about it..
I might make some small changes, and I *certainly* will fix any bugs people find.

Eg. I might try and funnel new players to tutorial 1st, then practice vs AI bots and then PVP.
I got one report from someone who missed all that, jumped straight into pvp and didnt know what to do.
Feedback on that issue would be appreciated!

The plan now is..

If its reasonably popular
do more on it. Make a paid deluxe version with these features.. and other requested features..

* Windows build, mac build, linux build... Also maybe Switch Android, iOS  builds(edited)
* more than two players per match
* spectate matches
* save and share replays
* tournament mode
* Ranking system and online leaderboards(edited)
* more maps
* Procedural maps, different every game
* Make your own maps(edited)
* character customisation
* Custom matches with lots of different game options, eg Lazer reflection, ULTRA-lazers,lazer orientation, friendly fire

Also maybe do a Kickstarter for that.

If not
Move onto next game :)

So.. in classic fashion you release game and then realise theres like 10 features you should have done.

Just did a small Update.. Now you can see your opponents name in the VS screen and win/lose screens. Theres also a secret keyboard shortcut to show names during the game. Thats on the Discord.

(https://preview.ibb.co/k3d2Ff/vs.png) (https://ibb.co/cSODML)

(https://preview.ibb.co/d8qcgL/winlose.png) (https://ibb.co/fZRuT0)

So just fyi I've actually been devlogging on the games Discord (https://discord.gg/CxtnKrG) since launch.
But quick catchup the game got a great reception and now were proceeding with more work which were calling LazerGrrl Extra, which we've launched a Kickstarter for (https://www.kickstarter.com/projects/1759116142/lazergrrl-extra)

The following is about a little feature I'm currently working on which is kinda tricky, advice appreciated!

today I'm working a small but significant new feature, to help noobs understand the game
One of the big issues new players seem to have, is that they dont understand that Lazers use energy.. They tend to build loads of lazers, cant buy anything else and get stuck.
so I'm adding an income gauge to the base.
I'll also change the tutorial to highlight it.

(https://preview.ibb.co/jb3uKf/image.png) (https://ibb.co/d4FVs0)

Ive actually tried a few things.. Coming up with something that wont confuse noobs even more is hard!

(https://preview.ibb.co/fWTN5L/image.png) (https://ibb.co/mKhh5L)

so above is the the simplest idea, and the 2nd simplest idea
the whole point of this feature is that it is aimed at total noobs
so they're the only options I'm considering
I'm considering the 2nd simplest one as it would actually have some utility to non noob players aswell
Heres a video of 2nd simplest idea in Action...

https://youtu.be/i9ghcIbhgaQ

Heres the new income gauge in an updated tutorial.
I think the tutorial is better this way, I also think the gauge can be improved.

https://youtu.be/2flUysB7C60

I have a few other ideas for the gauge..

(https://preview.ibb.co/kWz7qL/image.png) (https://ibb.co/nwshPf)

So I've been devlogging on LazerGrrls Discord. (https://discordapp.com/invite/CxtnKrG)
But I thought I would post this here.. as its pretty epic progress.
My 1st time having a game with 4 players.

You can also see new lobby and matchmaking system which is in progress.
And also procedural levels, which I did a little while ago

https://youtu.be/f7ZsOkppwo4

So I am actually devlogging on the games Discord (https://discord.gg/CxtnKrG)
But here is something cool!
The 1st ever 2v2 match online test.
(ps. The feature im working on will allow arbitrary numbers of players)

https://www.youtube.com/watch?v=2QdSxAGgrig