Here we write about Nikki and the Robots development and other news. Be sure to subscribe! Visit our reddit forum and join IRC for even more info!
Nikki 0.3 "Edward"
Nikki and the Robots 0.3 is out! [get it here] Soon we will start a level contest which is why we gave this release the name "Edward".
We decided to abandon batteries as energy source for robots to avoid slow pace and annoyingly repetitive gameplay. Instead Nikki's targets are:
1. Collect Batteries
(as many as possible)
2. Use Robots
(they do not require ⌁energy)
3. Press Switches*
(to complete levels)
Collecting battery cells will serve high-score lists and <SPOILER>in the story mode it will allow for progression; a certain amount of batteries will be needed to enter the next part of the game</SPOILER>. We will explain the meaning of switches another time..
0.3 Changes include:
- Battery counter and timer inside levels
- High-score display in level selection and level-end screens.
- Bugfixes! One of the most horrible ones prevented linking robots to terminals in the editor.
- Player-configurable controls
- Death zone (lower limit for levels)
The level competition will start soon and it will affect the future development of Nikki greatly, so please test-ride this release [again, get it here] as hard as you can! Bugs go to Launchpad or our IndieDB forum (did we tell you we got a forum?).
Level editor tutorials will be released very soon as well!
Tags: art, game design, nikki, open source, press
13 Responses to “Nikki 0.3 “Edward””
-
Iwan says:
Thanks for mentioning this. As far as I know this has been already fixed in the repository. :)
-
Josh says:
On Windows Vista SP2 it’s unbelievably slow. “core.exe” seems to be taking up an entire core, running at 50% on my dual-core machine, and it takes 2 seconds to react to pressing down to go down to the next option in the main screen.
-
Many thanks for this report! We’ll fix the problem ASAP.
-
ねこ says:
Some feedback:
Those push-down buttons are very fun to simply interact with. Usually games simply have two states for a button and a simple boolean collision check to determine when to move it into the down/activated state. Even games with physics engines usually constrain the button to the vertical access and do not allow it to move around in any other way. Here though, the button is very fun to simply screw with, at least for a few seconds when new to the game. It is little bits of polish like this that make great games stand out from the rest. I was very glad to see it wasn’t the normal access-constrained button ‘physics’ I am used to.
The background and tile graphics were terrible, I assume this is totally placeholder though.
I encountered some lag that simply should not be possible while playing the game. I have a modern machine but your game took up an entire core (I’d recommend considering multi-threading the physics or something, but really, this game has absolutely no excuse for taking up so much CPU time in the first place!). It is likely you just have the fps uncapped though, so simple solution.
Robots are a lot of fun to control, maybe for the rotation you could add two smaller thrusters on the side of the robot to make it clear how that works and add more polish? Check out the rockets in the game ‘Cortex Command’ for an amazing similar control scheme and feel.
-
Another thing, I think you should scrap the tutorial levels. I would integrate the text from them into the first couple of real levels. Nobody wants to a play a stupid tutorial, they want to get into the action. What this means at the moment is you’ll have players jumping straight to the real game, and not know fundamental controls. For this game though, that is almost acceptable, the controls are quite intuitive, but I did not find the key-mapping very intuitive myself, necessitating the little tutorial. (I would recommend having multiple keymappings for every single action, there is no downside. Map all the a,s,z,space, and x keys). A lot of games take this minor-tutorial-in-the-background-of-first-level approach and I think it works out great.
When I jump on the platforms I feel like their little eyes are about to go ‘-_-’, that would be so so so cute :3.
-
Actually, for robots, have you considered making the two thrusters individual controllable? This adds quite a bit of difficulty to get used to it, but has a lot of potential for being extremely challenging, fun, and rewarding. Would not recommend it at all though if you want to keep the game casual.
-
Glad you like the button. :) We like it too! Usually they are probably kept simple to prevent them from not working.
There will be good graphics for story mode and at some point in the freeplay mode as well.
Thanks for the report! Can you provide your specs? Windows? What version/cpu/SP/Gfx Card?
I actually took a look at cortex command for thinking about the jetpack robot: http://www.youtube.com/watch?v=UWnWHVeC-qU side-thrusters might be the way to go to make the bot more forgiving.
-
The lag was observed on Linux 2.6.38-8-generic #42-Ubuntu i686, GeForce 7300 LE, NVIDIA 270.41.06.
-
Jason says:
I used a jetbot and it hit Nikki off the terminal. It trapped Nikki from re-reaching the terminal and Nikki could not push the bot.
-
Why not jump on top of the robot then? :)
-
Ah wait, I get it: it was in celldrops, right? :D Oh well.
-
[...] Game Nikki and the Robots 0.3 released [...]
Leave a Reply
1.0 AVAILABLE NOW!
BUY STORY EPISODES!
VOTE ON GREENLIGHT!
SUPPORT NIKKI!
bitcoin: link
When I updated from inside the game, the text was too wide and didn’t show properly. In particular the url which the game was downloaded from was pretty long. You might want to tidy that up.