I installed it last night by switching to my Australian google play account, but I don't think they'd populated Japan yet, because beyond my starter my entire city was devoid of any markers or wild pokemon of any kind.

My ability to play is also very limited, because it spikes my phone to about 100'c almost instantly and chews through 3% battery per minute. It also refuses to keep gps connection with the app in the background, so I have to physically have my phone out and running the app at all times when exploring.

I'm excited for the game, but there are definitely some bugs that need working out. I was also very disappointed by the extremely limited character customization.

I've been working on an html5 game. My engine is currently using a variable time step because at the time I started writing it I was fairly convinced of the reasoning behind this method. However, I'm beginning to think that in a pixel style game this might not be the way to go. I end up having to deal with tunneling, rounding everything to get integer pixel values, and various other issues, and In the end I've had to cap the timestep to 30 fps minimum anyway,and accept slowdown after that. It seems like variable timestep is "the way one does these things", but I wonder if it's just not suitable for low resolution pixel games. Does anyone have feelings about a variable timestep versus fixed? Am I missing something? I'm just looking for the input of people who may have more experience with this than I do before I go in and refactor my code. Thanks.

I don't think variable timesteps are the be-all-and-end-all of game programming.

There are a few factors to consider:
-Total overhead of your game - is there really that much risk of dropped or delayed frames on your target systems? If not, why bother with a delta step?
-Competitive fairness - does your game use shared highscores? Would slowdown give players a competitive advantage? If so, you might need delta stepping.
-Are you trying to emulate the behavior or aesthetic of an older system? You've got a pixel game, you want it to play like the Atari or something - does delta stepping sound good for that? Probably not.

If you do go with delta stepping, you have to make sure you actually have everything else in order too. You've complained about tunneling, but if you're using a variable timestep for physics, all of your collisions should be taking the interpolated positions into account anyway. Your render cycle needs to be completely unhitched from your physics, and needs to take into account how far between physics steps it's calculating (ie, interpolated movement). For a pixel game, this might be a lot of math to end up just keeping sprites at the same position because they're sitting on integer values anyway.

It's normal to have a "maximum step" on variable timestep physics, because shit can get weird if you get a badly dropped frame otherwise, but if you're hitting that maximum step a lot, you probably need to look at whether you're a) being very inefficient, b) being overly ambitious with your minimum system requirements target or c) need to look into offering reduced graphics and/or physics options for lower-end systems. If your actual framerate is a long way off your target framerate, the game is going to play badly regardless of the fixed-ness of your timestep.

You know, at the risk of sounding helpless some more, would anyone be so kind as to say what fundamentals are probably the best to start with? And by that I mean yeah, ok, I know how to get a map in and move around. I collide fine, all that, but when you start talking about turn-based ANYTHING I start to really not know what all gets *required* for that, because best I've seen is things about MAYBE arrays, and MAYBE x, MAYBE y.

Fundamentals include:
-understanding the base datatypes that are available to you - so usually, a whole bunch of different kinds of numbers (integers, unsigned integers, floats, etc), booleans, strings, characters, arrays, etc.
-knowing how control structures (if, else, switch, while, for, try/catch, etc) will perform not just vaguely, but intimately
-understanding variable scope (this will be different from language to language)
-if applicable, understanding object oriented programming concepts (classes, inheritance, overrides)
-having a strong working knowledge of logical operators (<=, !=, ==, etc) and if applicable, bitwise operands (>>, <<, ~, !, etc)

Once you have a good understanding of all of the above, it shouldn't really be an issue of "I know how to make a 'walking on a map' program but I don't know how to make a 'battle system' program."

You decide what you want to make, plan it out (if necessary, using the all-powerful flow chart - seriously, flowcharts are great for algorithm design), and then program it.

There's a lot of faffing about at a hobby level before you can hope to answer that question yourself.

Oh boy, when you get bugs in this sort of low-level thing, you really get bugs.

I had this assembly:

Code:

     addui     r1,r0,2#10000001    
     sh        TILE_MAP(r4),r1
     addui     r1,r1,1
     sh        TILE_MAP+2(r4),r1  
     addui     r1,r1,1
     sh        TILE_MAP+4(r4),r1  
     addui     r1,r1,1
     sh        TILE_MAP+6(r4),r1

Super innocuous, right? But every time, the value of r1 became ridiculous after the second operation. I spent ages trying to figure out how I could possibly have something wrong with an opcode as simple as "add integer unsigned". I even built some GUI elements that allow me to pause execution and step through, cpu cycle by cpu cycle.

The actual cause of the bug?

Code:

case OP_SH:
          bus.writeHalf(r[a_i] + a_Ksgn, r[a_j]);
break; //<-----------THIS
case OP_SLAI:
          r_write(a_j, r[a_i] << a_Kuns);
break;

The labeled break statement was missing in my CPU implementation, meaning every save halfword op was causing an unwanted shift left arithmetic immediate operation.

I guess I'd just never needed the value of the j argument register after doing a sh operation before...

Flash is free if you don't want the ide. Download the flex sdk from the Adobe website and compile with flashdevelop.

The CoD example was quite interesting, because it definitely seemed to be trying to at least say something.

Usually in CoD games, you shoot the enemy and they die. Until they die, the fearlessly attack you. However, in that scene, we had people crawling leaving trails of blood, people trying to pull injured loved ones away from the shooters, uninjured people running away from the violence.

The stark contrast is apparant because in CoD games (and most other shooting games), your enemies always seem to be willing - perhaps even eager - to die. They die cleanly, and there are thousands other that look like them. It never feels like much of a crime to gun them down.

So, what were they trying to achieve with that scene? I doubt it was any particuar "war is bad" message - probably they were trying to make the bad guys look as bad as possible, so gunning them down in droves felt even more justifiable.

Actually, I happen to have a handy example for you.

In this zip archive are four files: http://puu.sh/pPuiF.zip

Go to my website at http://vo-em.com and load mapdemo.dlx with the "load dlx" button.

This is a virtual console I've made which works a lot like a gameboy - even the memory locations for the cartridge are the same.

Use the arrow keys to walk around. This is a regular map demo. Have a look at how PPU memory is organized with "2" on the keyboard, and have a look at how RAM is organized by pressing "3". After you're pressed "3", press "k" to jump to the memory address of the tile map, and see how it moves when you move the character.

Next, load up "glitchedmapdemo.dlx". This map demo has the routines that stop the player walking off the map disabled. This causes all kinds of problems so you won't be able to walk left and right to begin with. Walk straight down as far as you can go, then start walking to the right. You'll notice that you get all kinds of bizarre graphical artifacting. If you keep walking, you'll even see a sprite that is in sprite memory but unused in the map!

If you watch the tile data memory as you walk, you'll see as all kinds of unwanted data get loaded into map memory, and the PPU just obediently puts them on the screen!

If you search around at the cart1 location in memory (press w in tab 3) (you can scroll memory up and down with [ and ]), you might even be able to find the map data, and be able to find where the erroneous map data is being loaded from.

If you're interested in seeing how this works, the source code to both of these demos is included; the .dls files can be loaded with any text editor. If you ctrl+f search "LOOK HERE" in glitchedmapdemo.dls, you will be able to see which routines had to be disabled in order to allow this glitch to occur.

EDIT: I've made a change to glitchedmapdemo.dlx which allows for more glitchiness. You can get it here: http://puu.sh/pPx5J.dlx

Be aware that walking too far to the left or upwards will now crash the game (you'll be able to see the registers counting up to infinity on the cpu debugger at page 1)

This version was created by removing the part of the Mod16 subroutine that prevents negative numbers from coming out of it. Specifically, I commented lines 865 to 867, inclusive:

Code:

srai r3,r1,31 ;r1= abs(r1)
xor r1,r1,r3
sub r1,r1,r3

Thank you for the explanations!

Is this the concept of a buffer overflow then?
I'm wondering how easy this would be to replicate in Python, C or Ruby..

I can't speak for Python or Ruby, but this should be very easy to recreate in C.

Judging by your musing and interest, I'm going to take a wild swing and say that you're toying with the idea of a game in which doing this sort of thing is actually part of the game mechanic, rather than just an exploitable glitch?

EDIT: I don't actually know if there's a better term than buffer overflow for this specific thing, I'm not too good with terminology...

Different people learn differently. I'm guessing you like learning by accomplishing a goal related to your project. So if you want to extend your programming skills, just pick something *very* small, but custom. Try to make it. Use whatever tools you like; the point is to learn to make something that you previously couldn't. If you pick something small it's easy to exceed your expectations, which can help you feel very accomplished.

In time you gain enough of these practical skills that you end up just making things instead of learning new things.

Yeah I guess that's where I actually started to encounter some issues -- and what I meant in one of my earlier replies.

I would have a thing I could sort of do, just not how I need, so I'd work at it, not get it, go to the forums, get insight, and be good.

Only that started to dry up FAST once I got more focused, and I mean... it's fairly important things, but at the same time, people started to draw question marks as an answer instead of being able to guide me when I was almost-but-not-quite-there.

That's where I got lost. I was starting to have half-baked stuff and then, well, here I am, wondering if I'm just not using the most conducive thing for my project.

/Shrug

If you're still having issue with control structures, variables, and states (eg, you can't take your plan for a battle system and stats and turn it into an algorithm that does what you want it to), then you really need to take a look at both your scope and your goals.

Firstly, your basic programming ability is not currently up to scratch. If your goal is to be able to build these things yourself, you're going to have to work on fundamentals a bit more. This can be within the scope of your own project (ie, prototype a very stripped down version of your battle system, then iterate it gradually to improve it), or it can be outside the scope of your project (practice by making small demos and whatnot to improve your OVERALL ability). Once you get to a certain level of competence, you won't need people to guide you whenever your goal deviates from the available tutorials.

Now, if your goal is to just build a game, and you don't particularly care about your programming level, you need to look at the scope of your project. Is your battle system truly unique? If not, there is probably already an engine out there that handles the majority of it for you. Could you twist RPGMaker to do what you want it to? Is there an open-source RPG engine that you can find and figure out? Probably, unless you're really breaking new ground.

If your project is unique, and you don't have the programming skill to build it yourself, or the inclination to learn, then it doesn't matter what environment you build it in, be it unity or C or visual basic, they're all just programming languages/environments in the end. They hold your hand to different degrees but an algorithm is an algorithm whether you write it in PHP or Brainfuck. You'll need then to either find someone to collaborate with you for the technical side of things, or modify the scope of your project to fit your abilities or available tools.

As a linguist-translator-programmer I can tell you that this sort of thing would've saved me a lot of time and my clients a lot of money on some past projects.

I had one project where the English comma was used as a delimiter, and essentially had to modify the text renderer and batch-process all of the script engine directives to use a different delimiter in order to produce my English patch.

Game developers often think "we'll finish the game, then sort out the localization later", but they would have faster releases and less monetary overhead if localization was considered from the beginning.

Basically, the gameboy has no memory protection. So, if your map is 16 by 16 tiles, and you don't expressly code anything to stop the player walking to the 17 tile, you're going to end up with your player walking outside of the map and into whatever is stored next in memory. It won't crash the device, necessarily, it will just cause shenanigans.

This is true for lots of devices from the same era, but it's especially true for the gameboy because a) memory is packed very tightly due to small cartridges and limited RAM and b) with the way its PPU works, it will just take whatever you point it at (within a certain space of memory) and put it on the screen.

This is a looot of fun. Really takes me back to my motorcross madness days.

I've only been time trialling, but I love the lack of course overview that forces you to learn the track.

So far I've managed to break into the low 1:15s, good enough for fourth, but there must be something I'm missing, because the guy in front has a 1:07.

My main suggestion would be to offer a keyboard overview for the controls screen - not all of us have gamepads, and it's a pain fumbling around to find the right buttons.

I'm currently working on a "hello world" tutorial, as part of the start of a series of tutorials on programming for this thing. I figure if I make something ridiculous, it might as well be educational.

Previously when working on programs for the console, I'd used flash's "trace" feature to debug problems in my assembly, but obviously that's not something the "end-user" (if there is such a thing) could do.

As such, I've gradually been adding debug tools to the emulator that make it easier to write programs for it.

Today, I added a memory viewer that lets you directly look through device memory. There are a bunch of hotkeys to jump to useful addresses, and you can scroll manually with the square bracket ([]) keys. Here's what it looks like:



Ugly, but functional.

The system debug console is not used very much at the moment, but you can access it with the ` button. You can write to it from any page using the box at the bottom. At the moment, it only has the commands "peek" and "poke", for reading and writing to memory addresses. It is actually a fully-functioning console that I wrote for earlier projects, so I can add commands to it over time. I plan to have it so that clicking a memory address in the debug viewer will auto enter a poke command in the console input.

There's also a currently-unused breakpoint system which I plan on adding console functionality for.

Finally, I've been working on the wiki, mainly on a page explaining how to write for the assembler, which is now available on the homepage. You can read it here.

EDIT: Oh, I also added back in the functionality to load .dlx executables, since this is the "debug" player and it doesn't make sense to have to export a cartridge for every iteration of your development.

I think that the majority of procgen games focus on mechanic mastery because that's about all they can achieve. Essentially, the game has a core mechanic, and then the procedurally generated aspects are just the game throwing different scenarios at the player in order to challenge that mechanic. Perfect mastery exists when you essentially overcome the proc-gen nature of the game by developing strategies that are effective regardless of the product of the procgen algorithms.

Less-explored procgen focuses would be exploration, discovery, and communication.

For example, a game where you find unique, uncharted land would be proc-gen exploration.

A game where you categorise procgen'd creatures would be a discovery game (think pokemon but where it actually makes sense for you to be filling out your pokedex).

A game where you simply live in a city and make friends and enemies with NPCs who have proc-gen's lives would be communication.

However all of the above is considerably harder to procedurally generate in a meaningful way, because the things that make fictional lands exciting, fictional creatures interesting, and fictional characters' lives enthralling is very hard to capture in an algorithm. It's very hard to procedurally generate 'inspired' content.

The more "hooks" (eg, human-designed aspects) the algorithm relies on, the less longevity the algorithm will have before it starts repeating itself and becomes, once again, a mechanic master game.

To clarify, I mean that for example, in the "living in a city game", the programmer is going to have to come up with various lists of words that can describe the NPC's situations, tastes, natures, etc. But no matter how long that list is, it's going to become homogenenous after enough gameplay. Before long, metagame discussions will emerge like "oh no, he has a 'flighty' nature, he's probably going to end up in an 'affair' scenario. I just finished one of those, so I'll talk to someone else".

If your working solo - keeping tabs on ideas, tasks and so on in a notebook is always helpful - as previous posters mentioned; it keeps you focused and helps from needing to constantly remind yourself of a good idea until you implement it.

That said - if your working in a team - a GDD is helpful. Similar to iterative design - I would say you should build the GDD as you go - any ideas you have put them in a section as a Design Backlog, focus on nailing down things such as the player experience goals and other elements that you can agree on. I wouldn't say sit down for 5 hours and just create a fully fledged design document - because either you will have to deviate from it eventually or you may end up locking yourself from creating a much needed change. Just keep your GDD organic in it's content - but at the same time make sure you nail down on certain very important points depending on where you are with your game. For example, if your nearing the end of the game's development - don't suddenly change everything unless you think its necessary. On that note - if your just starting off the project, experiment and keep the GDD as organic as possible and build on it iteratively.

If you're anything like me, even just keeping a checklist of milestones and essentially gamifying your game development is a great motivator.

This is all I have to contribute. It was made as a font for my engine's debugger. It probably won't take a lot of sleuthing to guess where the inspiration came from 

Um, nope, I have no idea who inspired that. Who was it?

Looks nice, btw Simple 5x8

I remember it being very close to one of the Pokemon fonts, though I don't remember which.

Today I wrote up a basic template file for writing programs, as well as an address file for the linker.

I also uploaded the assembler tools suite I've been using.

It's now technically possible to "build cars with my wheel", but the assembly tools are all command line so you'd have to be a very smart cookie to figure them out without instruction.

I will be writing a guide to the tools and toolchain usage tomorrow.

If the character makes you roll your eyes, that's usually a bad sign.

I've always liked the "shit test".

If you can't imagine your character taking a shit without breaking character, you have a problem.

Generally speaking, game characters that really suck are the ones who act stupid just to advance the plot. But that just goes back to the eyeroll test.

Sadly, it's one of the main points of democracy. If majority wants it - it has to be done. Even if this majority is dumb.
I hope that Scotland will think again about necessity of its presence in UK.

When the "majority" is literally just a smidgen over 50% and the breakdown shows massive swings between regions and demographics, are the citizens really being represented in any meaningful way?