Way back in the summer of 2008, I was deep in yet another obsession with N-Game (technically, just "N"), a ridiculously fun Flash game first released in 2006. It combines a very simple set of gameplay mechanics and clean vector graphics with challenging timed levels. If you haven't played it before, I strongly recommend you try it in your browser right now (but don't blame me when your productivity drops to zero for the next two months). Still back in 2008, I started a topic here about a monochrome N port called M-Game, which I undertook with the blessing of the original N authors. Their challenge to me was that if I ported N, it would have to be creative and introduce some twist on the original gameplay mechanics.

Unfortunately, as the screenshots below show, after I got running, wall-sliding and -jumping, and coins working, I got frustrated with collisions on slopes. In the end, I put the project on indefinite hiatus, and I fear now it may never be done. There's a silver lining, though! Geekboy and Unknownloner have agreed to work together with me on a TI-84+CSE port of an N-like game, a project that I'm very happy will actually see some progress despite being on a depressing To-Do list. I have a lot of ideas about how we should do it, and I think they do as well (perhaps even conflicting Wink ), so this topic should be a good place for us to discuss it, get feedback from you guys, and provide eye candy.

Iambian may be joining in randomly as well for optimization and general Rawring reasons Razz That being said, I am happy to attempt this game as, well its a fun game and I look forward to working on it.

KermM you said you had an email regarding copy-write and such like that. If you could forward that or post the pertinent information that would be much appreciated.

Aside from that Unknownln is working on the Mapping engine so he is the one on the spotlight right now. We are currently toying with the level formats. I am envisioning something like this
(this is a very brief writeup to just explain a general structure)


This will keep the data small and easy to work with for the most part. handling collision with terrain might be a challenge but even with the vectorized data should not be that hard. Even more so if we SubDivide the data and such, But that's just one of many possibilities
Can confirm.

Anyways, we should probably decide on double buffer vs single buffer.

One thing to keep in mind is that no matter which way we go, the static parts of the level should only be drawn once. I see an advantage with double buffering that we can just erase the entirety of all moving sprites, instead of trying to apply deltas properly. Less flickering is also good. If we could pull it off though, I think single buffer could be faster.

On the subject of rendering levels, I was thinking that the graphical data should be separate from the vectors for walls used for collision, a little bit of data dupe to make things simpler.

I was thinking of splitting the level up into arbitrary triangles, and filling them, since that's a thing I know how to do. Solid rectangles of color could also be defined since those would fill faster than non-axis-aligned triangles.
I personally vote for half res mode. I would rather it be smooth and fluid then possibly flickery and choppy. But which will be faster/easier to code for I guess is the ultimate question.
This sounds like a great idea! Can't wait to see where it goes. One thing that I have found is that collision detection becomes really fun when you have different surfaces to collide off of. Good luck! Smile
Before we get carried away with level design, I should mention that I was thinking of a design with full-resolution and single-screen, non-scrolling levels. Small sprites, say 8x8 or 12x12, would allow us to fit surprisingly complicated level into a single screen, and careful management of the onscreen objects would allow updating smoothly without the need for double buffering.

Unknown: You were thinking of vector rather than tile walls?
KermMartian wrote:
Before we get carried away with level design, I should mention that I was thinking of a design with full-resolution and single-screen, non-scrolling levels. Small sprites, say 8x8 or 12x12, would allow us to fit surprisingly complicated level into a single screen, and careful management of the onscreen objects would allow updating smoothly without the need for double buffering.

Unknown: You were thinking of vector rather than tile walls?

I agree that single screen levels is probably a given (follows the original game too). Vectors were the first thing that came to find for walls, but I guess tiles could work. I'm cool with either, depends on what whoever writes the physics prefers. I'm really kinda leaning to using double buffering, at least initially, since I think it will be simpler to code. At least allow us to see something on screen. It might be worth switching later at some point if we have a performance problem, but we probably won't have enough moving objects for it to be a problem.

Probably worth mentioning that if we did vector based levels, it'd take basically no effort to switch resolutions (just scale coordinates).

Also, take anything I type right now with a grain of salt because it's 1 A.M.

Day 2, edit 3:
It occurred to me that even if we didn't double buffer, it'd still probably be advantageous to use half-res mode because it would allow us to keep all X coordinates in a single byte.
Well from a speed standpoint tiles would be faster and would be loads easier to compute the physics for. That being said vectors would allow fancier levels in my opinion and not limit us to connected tiles. Which can be averted and managed with a ton of different slope tiles.
If we do tiles I most definitely vote for 8x8 leaves more room for level design later on. With using tiles it does make collision detection for enemies easier as well. Just the mullings of the day I'll clean the post up later. Typing these up from a phone isn't fun.
Going to get some code going tomorrow that can render tile maps so geekboy can make a level editor

What slopes do we want available, just 30/45/60° or 15/30/45/60/75 or what?
I would say what ever the original has. Which is all of the slopes :p
Currently building level renderer off the following format:

20 * 15 bytes = tile data, 1 byte per tile (tile ID)
tiles stored in rows, currently going off 8x8 tiles in half-res mode.

No fixed size: spawn points for sprites/coins/mines/whatever
For each one:
1 byte - type
1 byte - X (Top left corner)
1 byte - Y (Top left corner)

A type of 255 signals the end of that data, and doesn't have a corresponding X/Y position.
I suggest looking at the Sonic 2 physics engine for inspiration about how to implement physics and tiles.
DrDnar wrote:
I suggest looking at the Sonic 2 physics engine for inspiration about how to implement physics and tiles.

Honestly I was just going to wing it and learn along the way. I have a ton of ideas of how I would want to implement this, and am willing to spend the time to test all the ideas I have, That being said looks like some good info regardless!

@ UnknwonLN looks simple enough I am currently looking at qt I might whip up a few small helper scripts like the one you made in java to work with the data it self. We shall see. But I plan to at the very least made a basic level editor for the data structures.
Should we decide on a fixed size for all the sprite objects that are initially spawned so that they can be drawn by calculating an offset to sprite data, or should I just hard code in rendering to do a bunch of like 'cp XX' and manually load the addresses for the sprites.
You could just use a Lookup table for the sprite data, That's what I would do at least makes referencing stuff easy. And adding new stuff easier.
geekboy1011 wrote:
You could just use a Lookup table for the sprite data, That's what I would do at least makes referencing stuff easy. And adding new stuff easier.
Yep, I think that would be fair. We're not going to stuff sprites into the level data though, are we? As far as I can tell, we should just use a standard sprite set to keep levels nice and small.

Edit: I think in terms of physical dimensions, though, we should definitely stick with fixed-size sprites that are either 8x8 or 12x12.
No we won't be, My comment was based on us devs adding / changing pictures and images for ingame.
geekboy1011 wrote:
No we won't be, My comment was based on us devs adding / changing pictures and images for ingame.
Ah, okay, that seems reasonable. I was listening to you guys talking about what sounded like packing levels and sprites together on HCWP, and got confused. Smile Also, just to make a note from our discussion there, we all agreed that using the xLIBC palette makes the most sense in terms of space and speed.

Edit: As nagged, my email exchange with the creators of N about permission for porting, from back in 2008:
KermMartian wrote:
Metanet Software:

I am an independent developer for TI graphing calculators, and I am interested in porting N to said calculators. All of my work is free-as-in-beer and free-as-in-speech, so I would like your permission to include most of the elements on N gameplay in my version. I wish to distribute it freely with source, which I believe is in the spirit of the original N, and was planning to call it M (unless you'd be comfortable with calling it N). I've been playing around with some physics and collisions, and I've managed to get most of the movement physics down except for slopes. I'm not requesting source or algorithms, merely your permission to create a port of N. Thanks in advance. Oh, and if you'd like a screenshot of my progress thus far on the physics:


Christopher Mitchell (Programming alias Kerm Martian)
Metanet wrote:
hey Christopher,

While we respect your desire to program games (esp. on such a cool platform!), and of course your love of N, I'm sorry to say that we can't officially license a version of N. But the thing is, you really wouldn't want us to. We're perfectionists, and I'm being honest when I say we would need to have input on your project, and we would get really nitpicky and probably cause you a lot of headaches. We are REALLY nitpicky about incarnations of our games Smile N is all we've got right now, made with love, care, lots of time and lots of Red Bull -- I'm sure you can understand why we'd want to keep our IP as tightly controlled as possible.

The other problem these days comes with the need to protect our IP since we've started making offshoots of N like N+ for XBLA, DS and PSP. We're now legally obligated to take more responsibility than we were 4 years ago when we released N, and although we're really trying not to sound all corporate and stodgy, you propose a tricky situation, and our hands are tied. I'm afraid we might even have to ask you to use other images for the character and title screen because they fall under the umbrella of our IP. You could make a clone called M, as you say, but you'd have to maybe make it feature something else as the main character -- how about a mime? That could be fun.

N came about because of a passion for games, a desire to experiment and a need to play something that didn't yet exist...We're not totally convinced that a clone of N is exactly in keeping with that spirit, though we understand your intentions are good. Could you not re-invent the concept, change the feel of the game, and make it your own? It's obviously great and important to be inspired by other games (heck, N was inspired by plenty), but we would feel more comfortable supporting a situation where we could contribute to the growth of something really cool in its own right. Does that make sense?

Anyway please write back, we would love to discuss this further!
KermMartian wrote:
Hello M&R,

Thanks for the response. I completely understand that you can't officially license a version of N, and I presumed it would need to be at least nominally different from N (ie, named something different). I agree that due to the limitations of the platform and my own commitments (I'm currently a student), it would be better if anything if I worked on something that wasn't an attempt to accurately clone N. I can understand your concern about your IP completely; I've put enough blood, sweat, tears, and hours into my own freeware to see where you're coming from.

I also understand what you're saying about going in a new or unique direction with the game I'm thinking of, so I hope you wouldn't mind if I run an idea or two past you. One of the main problems I was running into while brainstorming M was the size of the screen compared with a PC. I was considering a side-scrolling engine to allow for larger levels, but that doesn't really work too well with the N concept, as you generally need to plan out your approach ahead of time. I was chatting with a few of my peers about the problem and they suggested incorporating elements of the 2D Flash clone of Portal, specifically, being able to aim and fire portals on select surfaces, which might add an interesting element to the gameplay and make the dynamics work much better with the small screen. This might still be too close to the breakthroughs of two existing games. Oh, and I would certainly be willing to go with some kind of non-ninja theme; in fact, I think it would be more fun for me (not to mention users) if I tried to come up with something else.

Thanks for your time, and I look forward to your response.

Christopher Mitchell
Metanet wrote:
hey Christopher,

I love the idea of a blend of N and Portal! That could be phenomenally fun. Obviously once you get the game mechanics down the levels are the really tricky part -- are you planning on making the game more puzzle-oriented or more action-oriented? Changing the dynamic so you don't need to plan out your path ahead of time seems like it could be helpful.

Yeah, it seems like you'll have to be very creative given the substantial limitations of your platform -- but we think limitations often inspire better ideas and better games, so we can't wait to see how you work with them and what you come up with!

Will you keep us posted?

TL;DR: Start with the N idea but add different mechanics. That's why I think some portalling (or time mechanics, or something else?) are a good idea and perhaps even necessary.
Time mechanics would be sweet and i would be game to run with that.

To scope my ideas out on that I would not want to add say extra buttons and switches and stuff. Maybe different colors of the N character, Maybe in a sense where there are 2-4 Ninjas and each of them runs in parallel but you can set their paths and have them run together to confuse and navigate maps in different ways.
I love the idea of a time-travel thing. Maybe where you need to press combinations of buttons to open doors, or use yourselves to distract enemies? This sounds like something with a lot of potential. In other news, I mocked up full-res and half-res levels. In my judgement, the half-res version makes levels that are just too small, even if the full-res levels might strain the eyes a bit. Wink

Edit: It should be noted that both of these use 8x8 sprites. It might be worth considering full-res with 12x12 sprites as well. Or even 10x10 sprites.

Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 3
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum